Support for Easybox 904 LTE

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.

Not to mention that requiring a bootloader modification will pretty much immediately kill any chance of getting it accepted as an official target.

I wouldn't go quite that far, as the bootloader must be replaced for many other lantiq devices anyways (e.g. o2 box 6431, BT Home Hub 5 type A, many more), but it's certainly nothing to be taken lightly (losing the old badblock list would be another reason trying to avoid this). It might make getting official support a lot easier though.

The HH5a bootloader doesn't have to be replaced (just uploaded and run), but yes, I see your point for some special targets. However, I distinctly remember some head honcho on the mailing list stating something to the extent of "OpenWrt strives not to replace the bootloader, if we have to replace the bootloader, we won't accept the target", although I can't recall where it was anymore. My mind may be playing tricks on me.

At any rate, not replacing the bootloader seriously increases acceptance.

O.k., you're right about the BT HH5a (it's been a while), but on the Arcadyan VGV7510KW22 (O² Box 6431) and several other ISP branded devices replacing the bootloader (brnboot in that case) with u-boot is necessary (at least for openwrt-lantiq-xrx200-arcadyan_vgv7510kw22-nor-squashfs-sysupgrade.bin). Obviously this is frowned upon, but it might still be an easier option.

I have make a raw build and it works, but i use the old linked uboot.

When the router boot up, for a short time it looks likes if it hangs them it works, at this moment i can see that lcd4linux need 89% CPU usage.
But only for a short time

The only problem is no working f2fs

A more sensible reworking of the lcd4linux configuration notwithstanding, I think there's a quick fix for that.

The lcd4linux.conf that comes with the images has several display widgets set to a refresh rate of "tack", which is further down defined as "150", meaning they are supposed to be refreshed at 150 millisecond intervals. This is not only quite unnecessary, it also leads to lcd4linux using up ~10% CPU on those widgets, and ~30% at peak times when other widgets refresh. Which may also be the reason why QAuge decides to shut down lcd4linux when the screen is off -- it just takes up too much CPU like that.

Increasing the "tack" value to 1000 or 2000 (1 or 2 seconds respectively) or straight up replacing "update tack" with "update 1000" immediately reduces CPU load to < 1% (and in the process removes the need to shut down lcd4linux since the CPU load is not an issue anymore). I haven't looked into it further, as I said I fell out of tinkering with the device a few months ago, but I think a slightly delayed initialization of lcd4linux may help with the initial CPU spike, too.

Some clarification about the short freeze when starting up the box. This is the case, when the wifi driver uploads the wlan firmware to the wifi soc, which is connected to the network.The freeze occurs also at the stock rom.

1 Like

Hi, I have an old Tp-Link Archer MR200 (LTE modem) and I want to renew it.

I have a look to Vodafone EasyBox 904 LTE in web pages. It is cheap (second hand), but I want to ensure that:

  1. is it unlock for all LTE SIM cards? Or is it only for Vodafone? In that case, is it easy to unlock it?
  2. Is openwrt working with the LTE SIM card? I dont mine to loose DSL as I want to use it only with SIM CARD
  3. What bout 5 Ghz wifi ?

Thanks a lot guys,

The Easybox 904-lte variant is not supported now.
It exist only an opened image of original FW (the original FW based on openwrt (10.03 or so))
see the thread inside old forum (link in post 2).

The Easybox 904xDSL variant will supported with a fork or a patch.
On this device all hardware will support but without ISDN and Simcardreader,
but note it exist some restrictions like WLAN only AP mode are possible, not all ADSL annexe, etc.

Ok, thanks a lot. I have just delete this idea from my head.. Thanks.

--- Changes to release ---
I uploaded a new SMP build which is now based on the configuration of @slh (Thanks!).
I added LuCI because I think this is a good thing for end users.

I also wanted to use a branch with 18.06 to comply with stable releases, but it is using kernel 4.9 for the lantiq target. So I defer this until the next round where 4.14 is used =)

1 Like

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.