[RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices

Sven Roederer devel-sven at geroedel.de
Sun Dec 6 13:27:04 EST 2020


Am Sonntag, 6. Dezember 2020, 13:59:52 CET schrieb Adrian Schmutzler:
> > -----Original Message-----
> > From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Sonntag, 6. Dezember 2020 02:07
> > To: openwrt-devel at lists.openwrt.org
> > Subject: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> > 
> > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> > they work quite well for basic usage (including full LuCI).
> > On some projects with advanced features (e.g. Freifunk) the lack of RAM
> > turns them into unstable devices. Mostly caused by several OOM problems
> > per day.
> > This series tries to prolong the usage of these boards by moving them to
> > the ath79-tiny target. Indeed it makes these boards available on
> > ath79-tiny in addition to the current ath79-generic variant.
> > To improve the low RAM situation the default kernel-config for the tiny
> > sub- target will also disable some uncommon features. So the kernel image
> > becomes smaller, which results in lower flash- and RAM-footprint.
> 
> As stated in the earlier discussion, I never liked mixing low-flash ("tiny")
> and low-RAM (???) devices.
> 
> In contrast, David has made clear that this also is not possible due to
> conflicting goals for both approaches.
> 
> So, rather than mixing things up here and making it even harder to
> understand what "tiny" is supposed to be, this proposal IMO should rather
> aim at introducing a new subtarget aiming specifically at low-RAM devices.
> One could then just stop building "tiny" by default (there is only one
> device left, and I doubt people will have much benefit from prebuilt
> packages when they have to strip stuff anyway), and build the new subtarget
> _instead_ (i.e. no additional building overhead).
> 

I agree, that some of the "small_flash" defaults are probably not the optimal 
choice for 8MB-flash devices. 
A new subtarget might be an option, but is it really worth to define a new one 
for "deprecated" boards? Esp. as it's to be expected that both will vanish in 
the release following 20.xx. A new subtarget feels to me like just adding 
additional maintenance and additional confusion to the users.

Adrian, as you mentioned there is currently only one board build for ath79-
tiny at all. So it's a target that might not be interesting for the average 
user at all. For this it might be a good idea to stop now building this target 
anyway in favor of using the build ressouces more effectively. Getting more 
images for the tiny-subtarget will only change when customizing the config .

By writing this I wonder if it gives sense to add a new subtarget "deprecated" 
(to all relevant targets) to include all boards that might fall out of support 
"soon" as of limited ressources? This will be a clear statement to the users 
and even easy to determ, when a board belonge to this subtarget. As we 
currently see "tiny" was introduced for the 4/32MB boards but in the meanwhile 
should include the 8/32MB boards, too. In the "next wave" I assume 8/64MB 
boards will belong to this category in some years. Very likely the 4/32 and 
8/32 boards have become unsupportable then anyway and removed from the code-
basis.


I also ran a quick check on the usage of the "small_flash" and "low_mem" flag 
features. They are defined for some targets and used to set the "SMALL_FLASH" 
and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no other use of 
them, or did I miss something? If I'm right, the most difference between 
generic and tiny is the "config-default" file.
When there is no further use of the features, it's nor probably an option to 
think of combining both into something like "low_ressources". Based on this 
some default config-choices can be changed, like "optimize for size", 
disabling some "comfort features". As said before, a smaller binary / kernel 
will save flash-space and RAM-space, even the flash-space might not be 
relevant for all "low_ressources" boards.

Sven





More information about the openwrt-devel mailing list