Support for Easybox 904 LTE

I meant the developer i talked to have not looked into the buscon/addrsel parts if they are fine.

About the ILI9341 - just follow the "upstream first" path if changes are required to the driver.

Well, I'm open for patches.

I think the most important part is the "Add bad block table implementation" patch that should not break the functionality of oder NAND devices that use BBT-pattern. This is probably recently the deal breaker for merging the device to mainline openwrt.


I uploaded a new snapshot with the latest changes and rebased to upstream.
Due the recent changes on NAND subpage size detection, it may possible that you ran into an bootloop.
If so, please restore the box with the latest recovery image (fullimage.img) as usual.

Thanks for @arnysch @kovz @majuss and all others for the helpful suggestions/patch creation/testing.

@QAuge I'am so excited for this! I will test it this evening and finish my guide for all the "normal folks" to get the DSL working again. A big thank you to everyone involved! :slight_smile:

FWIW, I'm having no luck with that latest 2018-12-05 snapshot. I didn't even try to upgrade, just went ahead and did a full "fresh" install through your fullimage.img of the same date. It boots, the LCD comes on and displays statistics for one or two seconds, then it freezes and the router eventually reboots.

Edit: Sorry for not being more specific, I don't have UART prepared on this device.

Hm, thats weird.I had this too on the first run of the EasyBox but not on further runs. I suspected, that the load was too high, because I was trying to enter the web frontend while the device was booting up.
Interestingly there are no logs about this - in the serial console I can only see, that the U-Boot comes up again.
Maybe you can try the nonsmp image which I uploaded today.

Well that's weird. I had it reboot three times yesterday, so I shut it down and didn't turn it on again. For kicks, I turned it on right now after your comment, and lo and behold, it runs just fine now. Seems like it didn't just need a reboot but rather a power cycle.

It's an indication that there's something off, even if it is not particularly major. I hope it's just something that fails during first boot. It would be worrysome if excess load would make the device reboot.

The sad thing is, that there's no log, no exception and also no error message from the kernel. So it's really hard to get the reason why it behaves like this. I hoped that the missing display driver synchronization has influenced this, but this is fixed from @arnysch - so another thing is maybe a bummer.
In the past my box was running 60days or more without an reboot. Other cycles show reboots after a few hours.- with the an untouched system. Mostly in the morning when I switched on my smartphone and therefore some network load was arriving the box (prosody) and another pc wakes up from suspend at the same time.
So maybe someone can perform a network load on this?


Here's a suggestion, and I know I asked for it at various other occasions: Can you create an image that is as close as possible to a regular bare-bones OpenWrt image? I.e., only the base system with essential kmods, LuCI, and the software specific to the machine (Wifi? LCD?).

Your image still comes with 300+ preinstalled packages, from ebtables to Perl, and it could very well be that the first initialization of any of these packages would lead to a reboot. Since it's now possible to install packages from the official repos there is no immediate need to compile them in anymore.

This way we could rule out that it's one of the "nonessential" packages that misbehaves.

Edit: I know, beggars can't be choosers, I am aware that we are getting "your" image that is tailor-made to your requirements. However, I think this time my request goes beyond "I don't need all those packages, please take them out."

Here is a Patch for Upstream (snapshot) Openwrt too,
It contain the newest commits (05.12.2018) from QAuge

But not testet unfortunly my Buildmaschine (Raspberry Pi) are slow

Hm, at least I see the point to create a version from a stable tag (maybe the next one?) with only essential packages preinstalled. But I don't know what's really essentially. Prosody and privoxy, openvpn are not essential true - but does this also count for LCD4Linux for example? And for the lua modules which are used to enable/disable the lcd4linux after some time? Of course I can move them out, if there's no need for them - but some of the package can't be installed later from an repo (atm) since I doesn't uploaded the precompiled ones somewhere due lack of webspace to provide a third party repo.

I'm not too familiar with the build process, but I believe there are configs for the "official" images that should provide a good baseline.

At any rate, everything custom compiled for the device should go in, i.e. everything that isn't just pulled in from the official repo or can't be installed from the official package repo.

I would say no. The LCD is an integral part of the device, we can argue that LCD4Linux is necessary to use it.

I didn't pick up where I left off months ago, but I was working on replacing that LUA script with a shell script, and I remember that it worked out fine. Then I had the idea to do something with triggerhappy (that can recognize the different buttons instead of just "reacting" to all of them), and then I got distracted, and now it's December. Bah.

The problem here is that the LCD- and touchpad support (and the additional configuration and packages to make it do something useful) diverges a lot from this baseline.

I'm using these configs in addition to the baseline of lantiq-easybox904+luci (which isn't totally minimal either, but a lot closer):

### kernel configuration

### busybox modifications (devmem, i2c, fb)

### enable the display

### touchpad

### RaLink iNIC
1 Like

Hey that's a good start.

1 Like

Ah, the spurious reboots without anything in the logs. Usually that's the Lantiq xrx200 watchdog kicking in under heavy load. I can make that happen on some xrx200 devices if I log in to LuCI while the router is busy (e.g. during bootup, while initializing DSL or doing heavy routing tasks).
By the way, reboots due to a watchdog trigger event may have network problems (phy not found for some ethernet ports) on some xrx200 devices which can be fixed with a manual reboot.

You could try to modify the watchdog timeout (if possible) or reduce the load during peak times.

Getting a minimal version (no LCD/touchscreen) of the Easybox 904 merged in OpenWrt (possibly including bootloader) would be really nice and could serve as a baseline for additional patches. The Easybox 904 is an attractive target due to the amount of RAM and flash compared to other xrx200 devices. Having a display is cool, but the router is usable even without it.

That, and it is still the only device that comes with an Annex-B modem and working dual-band wifi -- all other current targets are either single-band wifi or Annex A. Also, having been distributed as an ISP's IAD, it's cheap and readily available second-hand. It would make a perfect go-to all-in-one target for Germany.

AFAICS there is another option for NAND which does not require a kernel patch:
Write a tool which converts the NAND contents between the two different bad block table (BBT) implementations. That way, you can run the conversion once and then flash uboot/kernel with standard BBT implementation.

But then you HAVE to update the uboot which may causes incompatibility. I personally don't want to force people to do this, because it causes an risk of bricking the device.
And in my case one of two boxes don't like the self compiled uboot (crashes after booting) - so people which have that kind of boxes will not able to use the image.