[Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files

[Yann E. MORIN <yann.morin.1998@free.fr>]

Peter, Stefan, All,

On 2021-02-13 18:05 +0100, Peter Seiderer spake thusly:
> On Mon,  8 Feb 2021 14:13:49 +0100, Stefan Agner <stefan@agner.ch> wrote:
> > Add a new config option to allow a specific list of firmware files to be
> > deployed. This is useful if the system needs to decide at runtime which
> > firmware to use.
[--SNIP--]
> Seems the rpi-firmware package tries to be too smart here and to workaround
> the smart logic is getting more and more complicated

Agreed.

> (and your patch is
> something orthogonal to the latest changes applied, see [1] for resulting
> commit and [2] ff. for discussion) and the package logic is to much focused
> to do the right thing for exactly one determined target platform...,
> neglecting the multi-target enabled SD card use case (or other custom
> use cases)...

Well, that is what Buildroot is mostly: build a rootfs for one specific
hardware which "global purpose" does not change over the course of the
life of that hardware, and for the rpi case, that meant the GPU firmware
would not change.

So that's how the rpi-firmware came to be, and how I (amongst others)
tried to steer it so far.

And indeed that does not account for devices where the purpose may
change without re-flashing a new version.

> Maybe the best would be to reduce the rpi-firmware package to a selectable
> list of (verbatim) installed firmware files and an editable/customized
> config.txt (as already via the post-image.sh script) or go another step
> further and provide customized config.txt files per raspberry pi defconfig
> (as most buildroot/rpi user will need a customized version anyway e.g.
> to enable custom dtoverlays as vc4-kms-v3d-pi4) and drop the post-image.sh
> script?

I think that we should just simply copy over all the firmware files for
the selected variant (0/1/2/3 vs. 4), and just have a static config.txt
that just boots the default firmware. Then, for people who want to use
another firmware will have to provide their own post-image script
(either as a replacement for the bundeld one, or as an additional one)
to further tweak config.txt to boot the firmware they need and/or remove
those firmwares they do not want.

This makes the rpi-firmware more in-line with the basic mantra of
Buildroot, which is basically also the mantra of Buildroot: provide a
basic bootable setup that just brings up the board to a shell (and
optionally a very few other stuff) and let the user customise that.

So in the end, although this would probably go against my initial
thinking (to provide one-purpose setup), I will welcome such a
simplification.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'