[Buildroot] [RFC/next v2 1/2] package/rpi-firmware: rework boot/config file handling

[Peter Seiderer]

Hello Yann,

On Tue, 9 Mar 2021 22:29:42 +0100, "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:

> Peter, All,
>
> On 2021-03-09 21:32 +0100, Peter Seiderer spake thusly:
> > On Mon, 8 Mar 2021 23:27:53 +0100, "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> > > On 2021-03-08 23:14 +0100, Peter Seiderer spake thusly:
> > > > On Mon, 8 Mar 2021 22:55:41 +0100, "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> > > > > On 2021-02-16 21:11 +0100, Peter Seiderer spake thusly:
> > > > > > Try to be less smart (focused on the one target/one use-case),
> > > > > > instead reduce the rpi-firmware package to a selectable list
> > > > > > of (verbatim) installed firmware files.
> > > [--SNIP--]
> > > > > So, let's keep the qt5 example aside, and see what we can do. What if
> > > > > we'd go with the following:
> > > > >
> > > > >   - keep a single, generic config.txt in rpi-firmware, and install that,
> > > > >
> > > > >   - if BR2_aarch64=y, add arm_64bit=1
> > > > >
> > > > >   - add an option to rpi-firmware:
> > > > >
> > > > >     config BR2_PKG_RPI_FW_DTOVERLAY_LIST
> > > > >         string "DT overlays to load"
> > > > >         depends on BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTB_OVERLAYS
> > > > >         help
> > > > >           Space-separated list of DT overlays to be loaded from config.txt.
> > > > >
> > > > >           For example, miniuart-bt on rpi0w to restore the serial console.
> > > > >
> > > > >     and if this option is not empty, construct the list of dtoverlay and
> > > > >     add it to config.txt.
> > > > >
> > > > >   - eventually, adapt the defconfigs with that list of dtoverlays
> [--SNIP--]
> > More flexible than the possibility for a custom config.txt (mind that there
> > are overlays with parameters and more possible options besides the overlays)?
> [--SNIP--]
> > The part with 'override' feels a little bit ugly and would count for me as
> > an argument against the hard-coded logic/overlays-only approach, still
> > believing that sooner or later most/every beyond-buildroot-defconfig-only
> > user will use a hand-crafted config.txt file...
>
> OK, so here's my new proposal:
>
>   - keep your BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE, which points to a
>     default, basic one, not unlike the busybox default config:
>         default "package/rpi-firmware/config.txt"
>
>   - package/rpi-firmware/config.txt is just the common part of all the
>     config.txt you currently had in your patch
>
>   - rpi-firmware.mk will add arm_64bit=1 as needed, based on
>     BR2_aarch64=y, because that *really* is not an option.
>
>   - add BR2_PKG_RPI_FW_DTOVERLAY_LIST as I suggest above, which is not
>     empty, will be copied as is to dtoverlay
>
>   - change the defconfig files to just set:
>     BR2_PKG_RPI_FW_DTOVERLAY_LIST="miniuart-bt"
>
> That way, we get best of both worlds:
>
>   - we avoid duplication of the config.txt, and we can still customise
>     it a bit with just "easy stuff" that we need for our example
>     defconfigs,
>
>   - users can stil point to their custom, fine-tuned config.txt (in
>     which case they will probably not set BR2_PKG_RPI_FW_DTOVERLAY_LIST)

Finally found time for a new iteration of the patch set:

- fixed two bugs
- changed the firmware list handling to one-assignment style
- changed the firmware install to make-level foreach loop
- changed the dtb overlay install to make-level foreach loop

- kept the verbatim BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE option,
  as your suggestion missed one more point where the config.txt
  files diverge (aside from dtoverlay=miniuart-bt and arm_64bit=1),
  the start_file=start.elf/fixup_file=fixup.dat or start_file=start4.elf/
  fixup_file=fixup4.dat as the firmware files are now copied verbatim...,
  and still confident that the principal of taking a verbatim copy of
  a given file is more flexible than implementing some more or less smart
  logic...

Regards,
Peter


>
> Thoughts?
>
> Regards,
> Yann E. MORIN.
>