ath79: move 8/32 boards to tiny subtarget

[Sven Roederer]

Am Sonntag, 20. September 2020, 15:32:52 CEST schrieb Sven Roederer:
> > Actually, this narrows down to a question that struck me several times
> > already:
> > 
> > Now, that 4 MB flash devices are not "supported" anymore, how should we
> > deal with the "tiny" subtargets:
> > 
> > 1. We keep the tiny subtargets configured for low flash, so people still
> > trying to build 4 MB flash devices still can use this. (This will also
> > benefit a few devices with kernel size restrictions; however, this is a
> > much smaller set than in earlier times; most of these devices have
> > dual-stage bootloaders now or died anyway).
> > 
> > 2. We convert the tiny targets to low-memory targets; this will improve
> > the
> > situation for a few devices (like you mentioned), but will make it much
> > harder to still build the 4M flash devices without major changes. Apart
> > from ath79, I don't know whether this would make sense for other targets
> > like the old subtargets on ramips. This poses the risk of having some
> > targets low-mem and some small-flash, which I'd like to avoid.
> > Additionally, we will have to change back from low-mem to small-flash
> > again
> > when we start to hit limits with the 8M devices.
> > 
> > 3. Though not intended by this conversation, the third option is obviously
> > to just ignore all 4M or 32M devices from now on (as actually announced by
> > the 4/32 warning), and design the tiny targets based on the requirements
> > of
> > the 8M devices that will start to become a "problem" soon (either due to
> > kernel size restrictions or because of small rootfs). Actually, we already
> > went into this direction by using wpad-basic-wolfssl on tiny targets as
> > well.
> 
> Adrian,
> 
> thanks for reminding that 4/32 have be planned to phase out after 19.07. 
> This will or have to be done in the near future.
> Reading  your points my quick idea was: "Moving the 4/32 and 8/32 to the
> tiny- target for 20.xx and removing this target after 20.xx bramch-off".
> This shows clearly for 20.xx what will happen soon and the user can prepare
> for this finally. The code can possibly also cahnged to take more advantage
> of "low_mem" and "small_flash" flags for the "next 8/64 round".
> regarding yout concerns that mixing 4/32 and 8/32 will make some more
> devices not usable I think like: this will break probably some 4/32 on
> tiny, but will make some 8/32 more usable. As the 4/32 warning is around
> fror some years now, nobody should be really surprised that the boards
> "dying" and that the 4/32 boards dying before the 8/32.
> 
> Best Sven

An alternative might be to consolidate all Low_Mem and Small_Flash boards to 
tiny for 20.xx and set them to source-only after branching 20.xx.

Sven