[PATCH] mvebu: cortexa9: fix missing wpad and iwinfo in images

[Bjørn Mork]

Petr Štetiar <ynezz at true.cz> writes:
> Adrian Schmutzler <mail at adrianschmutzler.de> [2021-02-13 15:49:17]:
>
>> > Seem like I need to prepare v2 as although I now have wpad/iwinfo in the
>> > image, I'm still missing ath10 and ath9k wireless modules...
>> 
>> Is this about initramfs or why does it have to be DEFAULT_PACKAGES here?
>
> why do you think, that initramfs should be treated differently then any other
> images? I for example find it weird, that one target has usable initramfs and
> other doesn't.

The problem is that the current build system does not support building
more than one initramfs per device, and there are often reasons why the
size of this image has to be restricted.

The initramfs might have to fit in a limited kernel partition.  Or it
might be uploaded using a stock firmware applying image size
restrictions.  Or a large image is simply inconvenient if all you want
is to boot it once to sysupgrade to the real OpenWrt install.

IMHO it would be very useful to be able to build more than one
initramfs, with a different set of packages.  This way you could hae
both an stock/bootloader flashable initramfs and a larger initramfs with
all the packages necessary for full hardware support.

This is what I made a feeble attempt to implement here:
https://patchwork.ozlabs.org/project/openwrt/list/?series=172128&state=*

But it became a bit too complicated for me...  So it's pretty dead
unless someone more familiar with the OpenWrt build system picks up the
idea.  And most likely rewrite it all..

Note that my use case required a severely size limited initramfs. And
when I started looking at this I found other devices having similar
requirements for installation.  See for example the
Build/ubnt-erx-factory-image rule in target/
linux/ramips/image/mt7621.mk

(This is why there hasn't been a buildbot generated ER-X factory image
in quite a while. Or ever?)

We need a way to build different initramfs images.  I just don't know
how to do that.

> Those images can be used for many use cases, not only for
> installation of OpenWrt, but also for debugging and/or testing etc. Those
> images simply avoids trashing of the underlying storage medium.

Sure.  But to do so you do need to build different initramfs images for
the size restricted use cases.  Otherwise I'm afraid the size
restrictions must have priority, since they affect the ability to
install OpenWrt on the device.

Run testing a RAM loaded initramfs is a developer use case.  And
although less convenient, developers can be asked to tune and build
their own initramfs.  You can't ask a first time OpenWrt user to do that
to get a flashable initramfs.




Bjørn