[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