[Buildroot] [RFC/next v2 1/2] package/rpi-firmware: rework boot/config file handling
ps.report at gmx.net
Mon Mar 8 22:14:54 UTC 2021
On Mon, 8 Mar 2021 22:55:41 +0100, "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:
> Peter, All,
> 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.
> > - change rpi-firmware config handling from rpi-variant/rpi-flavour
> > choices to bootcode.bin, pi-default/-extended/-cut-down and
> > pi4-/default/-extended/-cut-down selection
> > - add BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE option to select installable
> > config.txt file
> > - remove config.txt modify code/handling from raspberry post-image.sh
> > script
> > - add different customized config.txt files to the raspberry board
> > section
> > - change raspberry defconfigs to select appropiate rpi-firmware
> > and config.txt files
> > - change genimage-raspberrypi4.cfg/genimage-raspberrypi4-64.cfg to
> > use start4.elf and fixup4.dat
> > With this changes a better support for custom use-cases should
> > be possible, specially multi-target SD cards as suggested by
> > Stefan Agner ().
> >  http://lists.busybox.net/pipermail/buildroot/2021-February/303318.html
> > Signed-off-by: Peter Seiderer <ps.report at gmx.net>
> So I have started looking at this patch, and although I think it is
> going in the right direction, there are two things I am not very happy
> I'm not saying they would be definite blockers, just that I'd like we
> think a bit more about it.
> So, the first thing that bugs me, are all the varions config.txt files
> that are mostly identical, except of a few tweaks:
> - dtoverlay=miniuart-bt or not
> - arm_64bit=1 or not
> And the arm_64bit=1 can be automatically added when Buildroot is
> configured for BR2_aarch64=y anyway.
> And of course, a single outlier, the qt5we example, that has
> Still, that makes me nervous to mostly duplicate all those config.txt...
> The second thing leaves me thinking is the new config option that
> points to the config.txt to use. My first reaction was 'hell-no, this
> belongs to the post-image script and we should have it passed with
> But them this means that the rpi post-image script diverges from the
> others; the few others I've had a look at are just callinggenimage
> without amy preparation whatsoever. The rpi one is already diverging, as
> it creates a temporary empty rootpath (commit ee47fea5781) and currently
> has a few options that none of the others have.
> Getting rid of the existing options --miniuart, --aarch64, et al. is a
> nice thing, because it helps get it more inline with the others...
> But still, I am not too fond of this new BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE
> And really, both issues are really just me wondering if we can't do
> 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
> 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
...but back to the direction of trying to being smart..., which can work for
90% of the buildroot defconfig cases, but will not work for the rest of the
buildroot ones (one at the moment) and not for customized ones (none dtoverlay
extensions, multi-bootable SD-Cards, ...)...
> Yann E. MORIN.
More information about the buildroot