Should OpenWrt/LEDE support devices with only 4MB Flash?

For Developers
74

[quote="metai, post:67, topic:1018, full:true"]Wait, are you serious? At the moment there is no official release build for any device (as of this post, the buildbot has been building packages for 17.01 for the last few days), and there is no word from any dev in the matter. And yet you are making the blanket statement "4MB devices won't be able to install GUI (LuCI)" on the official web page.[/quote]I actually wrote that sentence as a stopgap until we could make something better. It's technically true. Devices with 4MiB can't install a damn thing through opkg, especially 250-ish KiB packages like luci, and it's not exactly news. Luci is the most sought after package most newbies want to install after flashing LEDE so it's good enough for a stopgap.

As you may notice, it has been replaced with another statement by tmomas and I currently proposed a more elaborate error message in this post that will clear that "my 4 MB device will never have a GUI" issue you raised

But in general yes, we need a clear warning for newbies, there are many devices that are still technically supported but are not recommended, and we need to make sure newbies stay clear of them (because seriously, with like 20$ you can buy stuff with 128MiB RAM and 16 MiB flash).

75

@slh Good assessment with facts, that's much better than a random opinion.

@tmomas how about cloning slh's analysis in the article where we explain the issue in the warning messages ? A paragraph like "In-depth analysis of the issue" or something.

(note that I'm not asking you to do it, I ask your opinion here. I can move things to wiki too)

76

Also big yes to this. @tmomas do we have a field for this in the ToH? I remember that one of the goals in LEDE ToDo was to categorize the devices in support classes like this.

1 Like
77

@slh Thank you for this perfect explanation.

Yes please, go ahead!

78

full / limited / minimal support

No.
I remember that we had discussions about this when building the current OpenWrt ToH, which ended in having the "Unsupported" field, where things can be put that are not working. This information is more valuable than a classification "limited support", where you anyway need to state somewhere what limited means for this device.

79

I remember that we had discussions about this when building the current
OpenWrt ToH, which ended in having the "Unsupported" field, where things can
be put that are not working. This information is more valuable than a
classification "limited support", where you anyway need to state somewhere
what limited means for this device.

"limited support" is possibly the wrong term, because it can be confused with
"partial support" where some parts fo the device are not usable by openwrt.

In the continum that I listed above, limited means that the standard image
distributed by LEDE will install and run, but that you are going to have severe
trouble installing anything after that (although with the imagebuilder approach,
you can change what's in the base image and probably install some other stuff)

This could be because opkg hits OOM, or because there are not enough flash
blocks left free to be usable. The exact definition can be discussed and
hammered out. It doesn't really matter which limit you run into, just that you
have run into a limit.

But it means the same thing for all devices, it's not something that varies in
meaning by device.

The idea is to identify devices that are still able to be installed with the
standard release image (including LUCI if that's in the what we define as the
standard release image) but that you can't expect to add anything else in
addition.

The devices are perfectly usable, just maxed out to start with.

The minimal support category is for the devices that you can no longer fit the
standard release packages onto. They can still be used with custom images, but
are very much in the 'experts only' category.

based on the discussions that I've been seeing, the criteria for hitting
'limited support' are

RAM: 32M

This is because as I understand things, opkg won't run reliably with 32M, but
is comfortable in 64M

FLASH: 4 flash blocks available (effectivly 1 flash block of storage after
overhead)

This is not X MB of flash because the amount of flash left after compiling
things is going to vary from device to device (instruction set density, flash
block size and what kernel modules are needed to support the hardware are three
significant things off the bat).

The analysis last night on the difference between having 5 flash blocks
available and having 4 is what I'm relying on. Per that discussion, 5 flash
blocks is still fairly usable, but at 4 you can still store configs on the
system, but not any noticable packages.

It may be that we want to set the limit a little higher, or that there is a way
to reduce the number of flash blocks that the filesystem keeps idle, so let's
discuss if this is the case or not.

Ideally, the build process would be able to generate a warning at the end of the
build if the particular image created is that tight. (and it may be that it's
tight/unusable in some filesystem types but not in others).

David Lang

80

Just providing my rather pragmatic opinion on the topic here:

  • I do not believe in arbritarily dropping device support
  • We usually support devices as long as it is feasible
  • A device should be considered supported as long as
  • it is possible to build bootable images
  • small enough images can be produced to still allow configuration persistence
  • no patches or other modifications to the source and buildroot are required

Eventually we might need to think about support tiers like:

  • Full => allows for running gui, has working opkg and plenty of space to allow packages
  • Medium => allows for running gui, has working opkg and at least enough space for setting up extroot
  • Small => bootable images can be built when either sacrificing gui or opkg while still having configuration persistence
  • Micro => only choice are heavily tailored custom images that require special measures like pre-shipped configuration, NFS mounts, preconfigured extroot etc.
5 Likes
81

Thanks jow for sharing your point of view.

How do we get now the classification Full/medium/small/micro for each supported device? As far as I have understood, there is no general rule, and free space after installation (and hence the classification) depends on the specific device.

1145 devices in the ToH
638 devices listed as supported by LEDE
170 thereof with 4MB flash

I can certainly add a new field to the dataentries, but before doing so, I would like to have the classification for each device, in order to have this field filled for all devices and being useful for the users.

A list that is automatically generated via script would be prefered; a manually updated list should be avoided (high maintenance effort, never complete, always outdated).

Could you generate such a list?

82

Thanks @jow for the insight. And I share the concerns from @tmomas - it will be hard to create and maintain a list.

I started this thread to ask the question "Should LEDE support devices with only 4MB Flash?" The clear answer is, YES.

The discussions also revealed two follow-on recommendations:

  1. For people who want to buy a new router for your home that "just works", we need to make the recommendation to seek a model with 8/64 mbytes.

  2. For those who want to use an existing 4/32 mbyte router, our recommendation should be, "It may work, and will certainly be more effort than using a 8/64 mbyte router. Check the device page and forums for assistance."

Choice #1 is the easy path; Choice #2 is sort of "choose your own adventure."

Beyond that, I would want to stay away from defining various levels of support since those suggest much larger commitments of attention/effort/understanding than most/any of us are willing to offer.

1 Like
83

Thanks jow for sharing your point of view.

How do we get now the classification Full/medium/small/micro for each supported device? As far as I have understood, there is no general rule, and free space after installation (and hence the classification) depends on the specific device.

1145 devices in the ToH
638 devices listed as supported by LEDE
170 thereof with 4MB flash

I can certainly add a new field to the dataentries, but before doing so, I would like to have the classification for each device, in order to have this field filled for all devices and being useful for the users.

A list that is automatically generated via script would be prefered; a manually updated list should be avoided (high maintenance effort, never complete, always outdated).

Could you generate such a list?

Is it possible to get the amount of available flash out of the build system?

David Lang

84

That is a good summary. The key thing is to warn people looking for a new router that anything below 8/64 can be considered challenging.

I feel that trying to figure out yet another classification and to maintain it would be too burdensome in the long run. We should not make the device database over-complicated.

85

I'm using LEDE even on Nanostation2 4MB flash/16MB ram - with Luci.
This is internal AP so don't need:

  • disabled IPv6,
  • remove all related elements to iptables
  • remove dhcp servers,
  • remove opkg - not needed as I don't have more place and ram :slight_smile:
  • added LUCI and zram

I have few router TP-link 4MB flash/32MB ram so there just disable IPv6 and remove opkg, and add Luci, wireguard, Zram

So I think there is no point to complain just read:
https://lede-project.org/docs/guide-developer/use-buildsystem

And once again thanks developer for their hard work and making openwrt/LEDE so modular that everyone can take what want/need

86

My suggestion for supporting 4MB devices with honest releases is just to scope them back to the epoch they birth from.

The means the build config removes IP6, SSL, and thrifted other features (dnsmasq extra lite). Non-ssl luci and qos scripts are mostly plain text and squash nicely. SQM has unique binary dependencies and doesnt.

LEDE/OpenWrt are not just for enthusiasts. Low income markets benefit greatly from back generation hardware given new life with open source software.

87

Maybe... But only if they come with significant technical backup.

There's a corollary in with eyeglasses. In the US, there are dropboxes around where you can donate your old prescription eyeglasses. It feels like a "good thing to do".

But the costs of sorting, categorizing the prescriptions, repairing, cleaning the used glasses, then trying to match them (both for the prescription plus the style) to people who come in is daunting, and arguably not even cost effective.

The same argument holds with routers. I would only advocate LEDE (or or any open source firmware) for someone who already knows (or is motivated to learn) how this stuff works. You can get a pretty decent $12-15 router from eBay. Putting LEDE on it, without the safety net of a local friendly techie, is beyond most people's pain threshold.

2 Likes
88

This is what I repeatedly see in the OpenWrt forum: I have a device with only 4MB flash. Which packages can I safely remove to get OpenWrt (+some other packages) on it?

Would be worth mentioning this in the Frequently Asked Questions: Before installation, or setting up a separate wiki page for this FAQ if the answer is too big for the FAQ.

89

The usual suspects are IPv6 and PPP and its relatives (and their LuCI front-ends). Of course, not everyone can/wants to do without that, so... There's no catch-all solution for everyone.

90

luci-ssl isn't enabled by default (for the security concious, it really should be, but it's both an issue of size (hard to fit into 4 MB at all) and making it more difficult for the user to deal with self-signed certs - not all browsers do allow ignoring the certificate error). IPv6 can't be disabled for a release build, because toggling the setting has quite significant effects on conditionals in kernel and other packages, but given that all firmwares are created from one kernel/ packages build, you'd have to decide to toggle the setting for all (even the routers that are more than capable) or no one (which would be a bad idea and quite a regression these days, with DS-lite becoming common place).

That is the problem, devices with 4 MB flash/ <=32 RAM are quite limited, yes catered individually for your own needs, you are able to extend their life time by quite a bit, but these tradeoffs are pretty individual. This is nothing you can really solve in the prebuilt (release-) firmware images, once they've fallen off the cliff and no longer fit the 'default' release image.

Edit: a quite 'entertaining' illustration of this could be TP-Link TL-WR841N(D) - LADUS build, which goes back and forth which components are actually needed. While ppp/ PPPoE isn't necessary for cable customers, users with ADSL/ VDSL usually hard-depend on it - at the same time many cable users will need IPv6 functionality (DS-lite), while ADSL/ VDSL users typically still have a real IPv4 address (and either full dual-stack or no IPv6 at all). The same argument goes for pretty much all other (de-)listed features, neither of them is particularly large, all of them can be considered basic functionality for a modern router - but you simply can't fit them all at once.

91

I updated the Quick Start Guide with a note that the procedure described on that page requires an 8/64 MByte router.

https://lede-project.org/docs/guide-quick-start/start
and
https://lede-project.org/docs/guide-quick-start/start#why_we_require_8_mbytes_of_flash

92

Done. Everyone are welcome to correct/add/remove this post in
https://lede-project.org/faq/before_installation

93

Tweaked that post. Please check for correctness. (It might help to list the correct package names to add/remove)