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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel