Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| meta:infobox:432_warning [2017/02/05 16:47] – [Extensibility] fixed links, rephrased some sentences bobafetthotmail | supported_devices:432_warning [2021/11/29 01:43] – [Warning about 4/32 devices] richb-hanover | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4/32 warning | + | ====== |
| ~~NOTOC~~ | ~~NOTOC~~ | ||
| - | Every operating system requires | + | <WRAP round info 100%> |
| - | - Sufficient | + | **TL; |
| + | \\ | ||
| + | Devices with ≤4MB Flash and/or ≤32MB RAM (so-called "4/32 devices" | ||
| + | </ | ||
| + | |||
| + | Default builds of OpenWrt 21.02 can only run on 8/64 devices. | ||
| - Sufficient RAM for stable operation | - Sufficient RAM for stable operation | ||
| + | - Sufficient Flash to accommodate the firmware image | ||
| - | **Devices with insufficient/ | + | ===== Low RAM can lead to instability ===== |
| - | ===== Usability ===== | + | * 32 MB can barely work for minimal router/AP functions, but may repeatedly " |
| + | * 64 MB may still have issues with stability, depending on your hardware and use cases | ||
| + | * 128 MB or more is recommended (in 2021) if software past basic router/AP functionality is to be used | ||
| - | **Insufficient RAM for stable operation** | + | ===== Low Flash can't load new firmware or new packages ===== |
| - | * 32MB minimum; can work quite well, but can also be borderline, depending on your usecase. | + | * 4MB is absolute |
| - | * 64MB are more comfortable to work with, and in general | + | * 4MB devices |
| + | * 8MB (or more) of Flash lets install at least a few additional software packages, | ||
| + | * 16MB Flash (minimum) is recommended for the foreseeable future (in 2021) | ||
| - | ===== Extensibility ===== | + | Most probably, you will not be able to install the following popular packages (and others) on a device with only 4MB flash: |
| - | **Barely enough Flash to accommodate LEDE firmware image** | + | |
| + | | ||
| + | | ||
| + | | ||
| - | * 4MB min (won't be able to install luci) / 8MB better (will fit luci and some other applications) | + | As the current stable 21.02 release uses kernel 5.4 that is roughly 0.5 MB larger |
| - | * 4MB can work, but are no fun to work with. >4MB will make you happier | + | |
| - | * 4MB devices can't fit anything noteworthy unless you use [[docs: | + | |
| - | * Especially in regards | + | |
| + | ===== Supportability issues ===== | ||
| - | Devices | + | It is getting harder or even impossible over time to support devices |
| - | Most probably, you will not be able to install | + | The 32 MB RAM is harder limitation than the flash size. The current Linux 5.4 barely works with a 32 MB RAM system and spikes in memory consumption can easily crash the router |
| - | | + | **OpenWrt |
| - | | + | |
| - | * 3G/4G dongle | + | |
| - | | + | |
| - | ===== Supportability | + | ===== Advice |
| - | It is getting harder or even impossible over time to support devices with low Flash + RAM. | + | If you are not an expert user of OpenWrt (that is, if you do not build your own images), you should consider |
| - | LEDE support for those devices might end somewhere in the future. | + | |
| + | **16/64 as an // | ||
| - | ===== Advice ===== | + | If a device has less than 16 MB of Flash and/or less than 64 MB of RAM, it may be unstable in basic operation under current versions of OpenWrt (21.02, 19.07). Further expect that support for the device may be dropped at any time and that security patches/ |
| - | * **new users** knowing what they want (or not), not knowing what they need, not knowing what to do -> get 8/64 | + | Previous versions of OpenWrt |
| - | * **experienced users** knowing what they want, need, and do -> try if 4/32 suits your needs; if not, get 8/64 | + | |
| - | ===== An analysis of the issue done by forum user slh ===== | ||
| - | As written in [[https:// | ||
| - | First of all, I'm not pretending to speak for the LEDE team, however looking at the plain numbers presents a quite obvious situation.\\ | + | ===== Analysis |
| - | Taking "[[https:// | + | As example, the size of the sysupgrade release image for WNDR3700v1, an ar71xx/ |
| + | |||
| + | < | ||
| + | master: | ||
| + | 21.02.0: | ||
| + | 19.07.8: | ||
| + | 18.06.8: | ||
| + | 17.01.7: | ||
| + | 15.05.1: | ||
| + | 14.07: | ||
| + | 12.09: | ||
| + | </ | ||
| + | |||
| + | Main reason is growth in size of the Linux kernel itself, but all included core packages (wifi, LuCI, etc.) also tend to grow as their features get expanded. | ||
| + | |||
| + | ==== Longer analysis of the issue done by forum user slh ==== | ||
| + | |||
| + | As written in [[https:// | ||
| + | |||
| + | First of all, I'm not pretending to speak for the LEDE team, however looking at the plain numbers presents a quite obvious situation. | ||
| + | |||
| + | Taking " | ||
| < | < | ||
| Line 63: | Line 89: | ||
| absolute firmware size......: 3735576 bytes | absolute firmware size......: 3735576 bytes | ||
| maximum usable firmware size: 3538944 bytes</ | maximum usable firmware size: 3538944 bytes</ | ||
| - | (all of these figures are for release images, including luci and a more or less identical feature set).\\ | + | (all of these figures are for release images, including luci and a more or less identical feature set). |
| - | The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB (== 4 erase blocks) free space, compared to 320 KB (== 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that' | + | The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB (== 4 erase blocks) free space, compared to 320 KB (== 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that' |
| - | Assuming pure statistics, what will the situation be in 12 or 24 months[1]?\\ | + | Assuming pure statistics, what will the situation be in 12 or 24 months[1]? |
| - | No one has yet raised the suggestion to actually remove the hardware support for affected devices from LEDE's source repository. If you look deeper, you can still find full support for the Linksys WRT-54GL (4 MB flash, 16 MB RAM) in the repo, although support for devices with just 16 MB RAM had already been discontinued with Attitude Adjustment 12.09 and despite the fact that actually building a working up-to-date firmware for this device today is quite challenging[2].\\ | + | No one has yet raised the suggestion to actually remove the hardware support for affected devices from LEDE's source repository. If you look deeper, you can still find full support for the Linksys WRT-54GL (4 MB flash, 16 MB RAM) in the repo, although support for devices with just 16 MB RAM had already been discontinued with Attitude Adjustment 12.09 and despite the fact that actually building a working up-to-date firmware for this device today is quite challenging[2]. |
| This thread merely serves as a reminder for ' | This thread merely serves as a reminder for ' | ||
| - | Advanced users will obviously be able to delay the inevitable by quite some margin - depending on their use-cases and abilities to reduce LEDE's footprint below normal system requirements.\\ | + | Advanced users will obviously be able to delay the inevitable by quite some margin - depending on their use-cases and abilities to reduce LEDE's footprint below normal system requirements. |
| - | Despite the title, the RAM size is actually a much harder limit, affecting much more than just 4 MB flash devices. If you look through the commit log, you will notice quite some efforts to get opkg to use less RAM, but it's still a problem with just 32 MB RAM (even for normal operations, before touching opkg). Likewise you already are in trouble with sysupgrade and trying to flash a (larger) 6-8 MB firmware on a device with just 32 MB RAM, unless you really clean up services and loaded kernel modules manually beforehand, there is a high risk that you'll oom during the sysupgrade and brick your device for good (requiring bootloader/ tftp assistance to recover in the best case).\\ | + | Despite the title, the RAM size is actually a much harder limit, affecting much more than just 4 MB flash devices. If you look through the commit log, you will notice quite some efforts to get opkg to use less RAM, but it's still a problem with just 32 MB RAM (even for normal operations, before touching opkg). Likewise you already are in trouble with sysupgrade and trying to flash a (larger) 6-8 MB firmware on a device with just 32 MB RAM, unless you really clean up services and loaded kernel modules manually beforehand, there is a high risk that you'll oom during the sysupgrade and brick your device for good (requiring bootloader/ tftp assistance to recover in the best case). |
| - | [1] switching from mach files to device tree (post 17.01) offers a potential to free up a little space in the kernel, but this isn't a whole lot and will probably be eaten more or less completely by upgrading to kernel 4.9+ (also keep in mind that the FDT file needs to be appended to the kernel image, which might or might not compress as well as the mach files before), so don't expect a significant positive effect from this switch.\\ | + | [1] switching from mach files to device tree (post 17.01) offers a potential to free up a little space in the kernel, but this isn't a whole lot and will probably be eaten more or less completely by upgrading to kernel 4.9+ (also keep in mind that the FDT file needs to be appended to the kernel image, which might or might not compress as well as the mach files before), so don't expect a significant positive effect from this switch. |
| - | [2] no webinterface, | + | [2] no webinterface, |
| - | [3] with LEDE's pretty new feature of device specific rootfs images, it would technically be possible to decide between installing luci or omitting it on a per device basis, e.g. based on flash sizes, but support for something like this hasn't been implemented yet and would require quite some attention (both as in source patches and tagging of device classes) from interested parties. As implemented right now, the decision is binary - either the default (release) config (including luci) fits XOR building a firmware image for the affected device fails and no firmware will be available.\\ | + | [3] with LEDE's pretty new feature of device specific rootfs images, it would technically be possible to decide between installing luci or omitting it on a per device basis, e.g. based on flash sizes, but support for something like this hasn't been implemented yet and would require quite some attention (both as in source patches and tagging of device classes) from interested parties. As implemented right now, the decision is binary - either the default (release) config (including luci) fits XOR building a firmware image for the affected device fails and no firmware will be available. |
| - | [4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn' | + | [4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn' |
| + | [[https:// | ||
| ===== The opinion of a Core LEDE developer ===== | ===== The opinion of a Core LEDE developer ===== | ||
| - | As originally written in [[https:// | + | As originally written in [[https:// |
| Just providing my rather pragmatic opinion on the topic here:\\ | Just providing my rather pragmatic opinion on the topic here:\\ | ||
| Line 102: | Line 129: | ||
| * | * | ||
| * | * | ||
| - | |||
| - | |||
| - | ===== Infoboxes ===== | ||
| - | These infoboxes can be included in other pages via the following section-includes: | ||
| - | < | ||
| - | {{section> | ||
| - | {{section> | ||
| - | </ | ||
| - | |||
| - | ==== Infobox for dataentries ==== | ||
| - | |||
| - | <WRAP center round box info 650px> | ||
| - | Not recommended for future use with LEDE due to low flash/ | ||
| - | Limitations in extensibility and stability of operation are to be expected. | ||
| - | </ | ||
| - | |||
| - | |||
| - | ==== Infobox for ToHs ==== | ||
| - | |||
| - | <WRAP round info 100%> | ||
| - | **Devices with ≤4MB flash and/or ≤32MB ram suffer from limitations in extensibility and stability of operation.** Consider this when chosing a device to buy, or when deciding to flash LEDE on your device because it is listed as supported. See [[432_warning]] for details. | ||
| - | </ | ||