ath79: move 8/32 boards to tiny subtarget

[Sven Roederer]

Hello David,

Am Freitag, 18. September 2020, 09:44:10 CEST schrieb David Bauer:
> Hello Sven,
> 
> On 9/18/20 1:27 AM, Sven Roederer wrote:
> > Adrian, David,
> > 
> > Am Mittwoch, 16. September 2020, 16:15:42 CEST schrieb David Bauer:
> >> Hi,
> >> 
> >> On 9/16/20 11:40 AM, Adrian Schmutzler wrote:
> >>>> -----Original Message-----
> >>>> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> >>>> On Behalf Of Sven Roederer
> >>>> Sent: Mittwoch, 16. September 2020 09:17
> >>>> To: openwrt-devel at lists.openwrt.org
> >>>> Subject: ath79: move 8/32 boards to tiny subtarget
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> not sure if this has been discussed before.
> >>>> I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM),
> >>>> TPLink
> >>>> WR842 v2)  for our Freifunk-project and realized that the low RAM
> >>>> situation
> >>>> requires quite different handling than the full boards (8+/64+).
> >>>> 
> >>>> I wonder if there is a reason to not move the boards, which are
> >>>> affected
> >>>> by
> >>>> the 4/32MB warning also, to the ath79-tiny target?
> >>> 
> >>> I wonder whether the tiny subtarget will actually make much difference
> >>> for
> >>> RAM issues?
> > 
> > My idea based on the fact, to have an easy way to disable certain kernel-
> > features to reduce teh kernel-size (in flash and RAM). Candidates I see
> > here are: USB-Support, additional filesystems, block-devices, ...
> > Even some devices provide USB-connectors it might be better to have less
> > OOM- crashes and reboots than installing a usb-flashdrive. In our
> > Freifunk-Firmware I've seen much less runtime-problems with a stripped
> > down kernel.
> > With having the 8/32 in tiny it would just be a config-file for the
> > low-RAM
> > boards. Having them in generic subtarget would require to build 2 kernels
> > for the same subtarget.
> > 
> >> In it's current state, it will most likely increase low-memory issues as
> >> the squashfs blocksize is 1024kB compared to the regular 256kB. Not that
> >> ath79-tiny has no target-flag for small memory set.
> > 
> > Did you miss an "e" ? "Note that ath79-tiny has ..." gives more sense to
> > me. Reading it this way, you expect the larger blocksize was choosen as
> > tradeoff between using the flash most efficient vs. RAM for the 4/32
> > boards? I've seen there is a low_mem flag for some 16MB boards defined.
> > It seems that for some config-options SMALL_FLASH and LOW-MEM are
> > conflicting.
> 
> Yes, there was an e missing.
> 
> We've experienced severe system instabilities with larger blocksizes (the
> default one for ar71xx-tiny to be precise) downstream. [0] [1]
> 
> However, In my opinion the blocksize upstream works well for people looking
> for a home router, as memory consumption is typically lower and some
> additional space is desirable there.
> 

For that reason Freifunk-Gluon and Freifunk-Berlin use the non-default value. 
Esp. for the routing-daemons these project need more RAM for apps running.

> I could also imagine the low-mem target feature and It's configuration
> implications have to be assessed as a whole, given it did not experience
> much use for a longer period of time.
> 
Indeed "LOW_MEMORY_FOOTPRINT" seems only to affedt 3 general options and one 
option of OpenSSL.

So it might be an option to :
* set LOW_MEM for 8/32 MB devies
* set LOW_MEM and SMALL_FLASH for 4/32 MB devices
* check the CONFIG-options for usefull defaults
So the tiny aubtarget can be defined as "boards with 32MB or less of RAM; some 
boards also with only 4MB of flash". This definition would essentially match 
the "4/32 warning" [1]. 

[1] - https://openwrt.org/supported_devices/432_warning

Sven

> [0] https://github.com/freifunk-gluon/gluon/issues/2032
> [1]
> https://github.com/freifunk-gluon/gluon/commit/7e8af99cf504ca1dc389f282a0c9
> 4f4a911571be
>