I've noticed in the last few days, that as 18.06-SNAPSHOT was released, that users have started experiencing issues with 4/32 devices and images. I'm starting a list of 4 MB Flash devices that have failed to upgrade or be stable with a flash of a newer firmware:
Model
Description of issues
Other Notes
Cisco Linksys Valet M10/ WRT160Nv3/E1000v1
firmware too big
@lleachii could not upgrade from 17.01.4 to 18.06-SNAPSHOT (reported in thread for WRT54GL)
Where are 18.06-Snapshots beeing released?
I cant either see in the "[SOLVED] Incorrect image file error installing to WRT54GL" thread nor in the "Can't install package luci-base on WNR2000V3 (a.k.a N150R)" thread any reports of not beeing able to install your written "18.06-SNAPSHOT" version.
Please be advised, this should be considered Beta software:
The issue is with 4/32 devices, NOT specifically 18.06. The problem is, the standard packages included in [OpenWRT] 18.06 now make the firmware larger than 4 MB on most devices. This eventual problem is alluded to on the 4_32 warning page. It began for some devices with version 17.01.
There were already similar problems with 17.01, so there is nothing new (expect it concern now a new router class). Both the firmware size and RAM memory consumption are growing steadily.
To be honest, I don't see much point in such a router list, as the challenge/unsuitability concerns practically all devices with either 32 MB RAM (the more difficult limit) or 4 MB flash.
Just a historical note, once upon the time Openwrt grew too big to run smoothly on devices with 16 MB RAM and outgrew 2 MB flash devices. If I remember right, Backfire 10.03 still worked well with 16 MB RAM, but Attitude Adjustment 12.09 started to choke with that.
Most (all) 4/32 devices should be able to still run the 4.4 LTS kernel. I realize it’s at their limit (RAM being the most limiting factor). Since this version had extended 6 years LTS that should keep them running until the hardware itself is “end of life”.
I noticed the “tiny” flag, but does that automatically keep them on an “older” kernel?? I have a few 4/32 devices myself and with the updated security patched like the “Krack” patch, they still run fine as simple AP and/or Range extender.
The alternative would be to drop support, or at least no to have the “buildbot” make automatic snapshots. Users can compile themselves from source or use “community builds”.
What’s the (semi) Long Term Plan from Lede/OpenWRT point of view? Maybe this could be added to the “warning” ?
-tiny only affects the image- and kernel configuration, not its version, that is at 4.9 for ar71xx and 4.14 for ath79. Sticking to older kernels past their expiration date is not an option.
Not sure why that would not be an option. Their expiration date should be based on the LTS dates I think.
So maybe we could combine “tiny” with the older, but still LTS kernel. Sort of make the group of 4/32 routers. Not sure if that’s “do-able” in terms of keeping all the latest patches for 3 versions (at the moment: 4.4 4.9 and 4.14). We might consider doing this since all are LTS versions.
If “Tiny” is not the proper flag, then maybe we need an additional “432” flag. Or like I said: we should decide not to continue support for those devices.
As long as 4.4 is maintained - and it still is, upstream - one could still stick with 17.01.x, as long as that keeps security updates. .5 should be around the corner as well.
I was referring to the suggestion to keep older kernels in master or the 18.06 branch, just because it's faster on lowspec devices, creating a maintenance (and security) nightmare for the development.
What is the size difference of the binary after porting it to ath79?
I can recommend to every user to change the Squashfs block size from 256 to 1024. I cant see any real-world issues, just benefits.
Nobody can tell you a exact number for difference in binary size...
You could also remove some debug info...
# CONFIG_KERNEL_CRASHLOG is not set
# CONFIG_KERNEL_DEBUG_FS is not set
# CONFIG_KERNEL_DEBUG_INFO is not set
# CONFIG_KERNEL_DEBUG_KERNEL is not set
# CONFIG_PACKAGE_MAC80211_DEBUGFS is not set
and probably... CONFIG_STRIP_KERNEL_EXPORTS=y
And probalby pppoe if you dont need it...
# CONFIG_PACKAGE_kmod-ppp is not set
# CONFIG_PACKAGE_ppp is not set
Or you solder a bigger spi flash and ram...
Did this on some of my constrained tplink wr841 devices...
I had payed for 5 x 16MB SPI flash chips only 9 € and for 5 X 64 mb ram chips 11 € from china...