The system looks great in its new "clean" default. Minor issues aside (we should look into getting LuCI to properly recognize the wifi settings, and adjust LCD4linux to settings that don't bother the CPU), it is a great starting point now.
However, I sysupgraded to your latest build yesterday evening, and then decided to "soak test" it. In its absolute default configuration and without anything connected and just wifi on, had the box sitting overnight. In this time, it randomly rebooted several times and in the morning I found it with an "unable to boot" screen, refusing to boot again.
I will flash it on my other box (I have two) and "soak test" it in a similar manner to rule out a hardware fault.
After some tests, my box is also rebooting in a unpredictable manner.... The sad thing is, that no reason is printed in the serial messages. I suspect some wifi issues. Can you try out by disabling the rt38.. driver and report back? ( '/etc/init.d/rt38... disable')
Quite possible. Last night, after installing, while I had LuCI's "wireless" interface page open in the browser, ssh connections would drop and not allow new connections until I closed the LuCI page (which was, at the time, polling the wifi interface on a regular basis). I couldn't reproduce it though, so I wrote it off as an unrelated coincidence.
Test unit is "soaking" now with disabled wifi driver. So far no reboots, but it has to run quite a bit longer than two hours to make an assessment.
Yup. It seems to be the wifi driver alright. 20 hours in, 20 hours uptime, not a single random reboot.
For comparison: with active wifi, it had a first random reboot within an hour, and completely died after less than 12. (What I'm especially worried is that it actually damaged the installation, I had to go through a complete reflash to remedy that. And at this point was I lucky it didn't damage the bootloader?)
Edit: It managed an uptime of around 30 hours with nothing connected but the power supply, then out of the blue, it rebooted randomly.
Edit 2: The Home Hub 5A -- another Lantiq device -- would reboot if the DSL port is unused. Apparantly a patch was submitted for 17.01.something, but I am still looking for that patch and whether it made it into the generic target or was specific to the HH5A.
Hi I build an image with a patch from the master-lede branch of Easybox-904x git (19.01.2019), createt by the script from post # in this thread
and the files from how can we make xrx200 faster thread Post #1 how can we make xrx200 faster thread
and the script from Post 7#
General it works and it looks like a better irq balance but it does not speed up.
The wifi works to
other problems are:
The VDSL2 modem connects but it locks like not right work:
It shows me Annex A but my Provider have Annexe B and i have choice an Annex B firmware
"option ds_snr_offset" Have no effect
And i have to less speed. (95Mb/s instead off 100Mb/s)
The other problem it fear that i have playing the NAND-flash to dead i get strange errors like:
and sometimes the flash lost data, no idea if an pattern exist.
Update on the soak testing: With /etc/init.d/rt3883 and /etc/init.d/dsl_control disabled, the box has been sitting idle for ~70 hours now without any reboots. I would say that the box is stable in this setup.
Preliminary conclusions, as far as I'm qualified to draw them:
It seems very obvious that the RT3883 wifi driver is very much broken, to the point where it not only reboots the system but actually breaks the installation. This happens without the wifi driver loaded, too. See below.
The unsolicited reboot after 30 hours quite neatly fits the "24 to 48 hours" timeframe that is mentioned with the HH5A's "DSL watchdog". But that's hard to prove or disprove from a single occurrence. More testing is required.
lcd4linux is spamming dmesg and the logfile quite a bit. Amongst the errors that are related to not being able to ping google (which are of course due to no net connectivity), it is constantly complaining: fb_ili9341_eb904 13000000.display: fbtft_update_display: start_line=239 is larger than end_line=0. Shouldn't happen, will do full display update
I'm starting a new test round now, again with dsl enabled, to prove or disprove the watchdog timer. (I manually switch off the LED on the shell, so the red LED is a quick indicator that the box has rebooted.)
Edit: Less than 8 hours later I arrived home to find the Easybox sitting on the "Your Easybox couldn't be started" red screen of death. So something effectively killed the system again, and this time it wasn't the wifi driver.
build additional packages LCD, Keypad and Wifi via SDK using all feeds.
create an image via imagebuilder
It runs stable since some hours the only problems are:
Keypad are not working:
root@OpenWrt:/# dmesg | grep -i key
[ 13.366678] eb904_keypad 0-0014: Error while parsing <eb904,ctrl-rst-gpio> <-517>!
[ 13.463182] eb904_keypad 0-0014: Error while parsing <eb904,ctrl-rst-gpio> <-517>!
root@OpenWrt:/# rmmod eb904_keypad
root@OpenWrt:/# rmmod matrix_keymap
root@OpenWrt:/# insmod eb904_keypad
[ 2005.381173] eb904_keypad: Unknown symbol matrix_keypad_build_keymap (err 0)
[ 2005.387090] eb904_keypad: Unknown symbol matrix_keypad_parse_properties (err 0)
failed to insert /lib/modules/4.14.98/eb904_keypad.ko
root@OpenWrt:/# insmod matrix_keymap
Failed to find matrix_keymap. Maybe it is a built in module ?
LCD working but Backlight do not turn off automatic.
Telefon-POTS-FXS Working, but only on one Port (U) i guess missconfigured or mechanical defect.
DSL: not tested
My Router run stable at the moment can it happen tha your router are unstable because NAND (to often overide ?) or elekrical mechanical problems ?
(see my post before) i solved this with reinstallation of the same image
This particular device has been flashed less than a dozen times. It has been sitting doing nothing and still rebooted into a broken state after a few hours. I'm not quite sure what you mean by "electrical mechanical problems", but it didn't have a lightning strike or a car accident.
unfortunately there is still no offical support to this device in Openwrt-wiki. Is it maybe possible that it is because of the wrong topic name? We discuss only Easybox 904 xdsl here an the topic says Easybox 904 LTE...
Could also someone please conclude the actual information and a how-to or something? Maybe @QAuge , @arnysch or @henning-schild could say somehing about what's going on atm or how to proceed into offical support of Openwrt and solve the issue with XRX200 closed source...
I stick with my Box still on an older image and don't know how to proceed to be honest. - It syncs also like often from @majuss described with 18/2 on a 100/40 VVDSL2 subscriber-line.
Thank you very much for all your efforts already at this point!
It is an General problem of the modems in xrx200 and it is more helpfull to open an separat thread.
But i think you need a vectoring capable Modemfirmware
see this post #3 for explanation.
You must extract an Modemfirmware from an Stockfirmware image like Fritzbox 7490 and copy them to your Routersystem
Them you should add the lines "option firmware "path-to-fw"" in the /etc/config/network under dsl
About: ""Add bad block table implementation" BREAKS all other NAND devices that use BBT-pattern"
Of it looks like the best way but this should done by a person that are have contact to the Kernel-developer and do know what are BBT are.
Them i guess it need long time to implement and a result ( so i guess ) are an extra Kernel config parameter.
For this reason it is not better to add a new Kernel parameter like MTD_NAND_CUSTOMIZED_BBT_VGV952CJW33EIR and hatches this service to ./config/Config-kernel.in
Because there is an other problem: the Easybox-904xDSL need a special openwrt-config like:
Or is this not a Problem ?
But at the moment i can not test i have some strange read errors on mtd device and i have not idea if it a hardware error, a problem with this devicetype or an general linux problem.
While that might make things a bit neater, it won't really help the problem at hand, as the same kernel image is shared among all devices of a (sub-)target. Meaning if you need to enable your hypothetical MTD_NAND_CUSTOMIZED_BBT_VGV952CJW33EIR, and you do, if you want to support the EB904xDSL, you break all other xrx200 devices with NAND at the same time - nothing won. What would be needed here is some way to influence the kind of BBT at runtime, either by adding some kind of quirk for the EB904xDSL or maybe DTS side configuration.
Yes, those are a problem, but compared to BBT and switch support an optional one (display/ touchscreen don't 'need' to work for basic device support --> defer to stage 2).
This is not a problem. DEVMEM is used only to set needed MAC delay settings for port, where Ralink WiFi SoC connected. We can extend device tree parameters for xrx200 ethernet port to set this delay in the register. It just where done as DEVMEM manipulations in original firmware from Arcadian, but, indeed, this is a MAC settings register.
There a alot of things that fail and can be the reason for the different errors:
So i do not explore for it because it sucks, anything is always wrong since months,
It was not possible to build an stabel fullworking image.
(I build USB-Storage and f2fs inside my kernel)
At the moment i try to build a solution for the special-NAND-bbt-patch-destroy-other-devices problem.
I use minimal images without f2fs and USB-storage support and they are working (but possible that my Flash are defect on a higher position)