Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Niklas Cassel via buildroot <buildroot@buildroot.org>]

On Tue, Sep 03, 2024 at 03:10:19PM +0200, Fiona Klute wrote:
> Am 03.09.24 um 13:08 schrieb Niklas Cassel:
> > On Sat, Aug 31, 2024 at 09:01:26PM +0200, Fiona Klute via buildroot wrote:
> > > From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> > > 
> > > The new config deviates from the existing
> > > configs/raspberrypicm4io_64_defconfig only as far as necessary to
> > > demonstrate booting through U-Boot instead of having the firmware load
> > > the kernel directly. The sample boot script loads the kernel from the
> > > rootfs and uses the device tree provided by the firmware.
> > > 
> > > Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
> > > ---
> > > The config I'm usually using is a bit different, including using a
> > > mainline kernel (which seems strongly preferable to me), but for
> > > defconfig maintenance staying close to the other RPi defconfigs is
> > > probably easiest.
> > > 
> > >   board/raspberrypi/boot.scr.in                 |  9 +++
> > >   .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
> > >   board/raspberrypi/readme.txt                  |  4 ++
> > >   configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
> > >   4 files changed, 96 insertions(+)
> > >   create mode 100644 board/raspberrypi/boot.scr.in
> > >   create mode 100644 board/raspberrypi/config_cm4io_64bit_uboot.txt
> > >   create mode 100644 configs/raspberrypicm4io_64_uboot_defconfig
> > > 
> > > diff --git a/board/raspberrypi/boot.scr.in b/board/raspberrypi/boot.scr.in
> > > new file mode 100644
> > > index 0000000000..a5c986ef99
> > > --- /dev/null
> > > +++ b/board/raspberrypi/boot.scr.in
> > > @@ -0,0 +1,9 @@
> > > +# Please note that this is only a sample, we recommend you to change
> > > +# it to fit your needs. You should override this file using
> > > +# BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE.
> > > +
> > > +# load kernel from the root partition
> > > +load mmc 0:2 ${kernel_addr_r} boot/Image
> > > +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
> > > +# boot using the FDT provided by firmware
> > > +booti ${kernel_addr_r} - ${fdt_addr}
> > 
> > Hello Fiona,
> > 
> > While I'm not a u-boot expert, I am slightly surprised to see a new
> > buildroot defconfig use boot.scr instead of extlinux.conf.
> > 
> > extlinux.conf is the default configuration format in u-boot:
> > https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L69-L71
> > 
> > Even though boot.scr still seems to be supported for backwards-compatibility:
> > https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L367-L368
> > 
> > See e.g. this buildroot commit that converted rock5b from boot.scr to
> > extlinux.conf:
> > https://github.com/buildroot/buildroot/commit/b7dbdd3d775b8e94664c6f37b11afc8a6a352e35
> > 
> > I don't see anthing exotic in your boot.scr that wouldn't work with
> > extlinux.conf.
> 
> AFAIK things like configuring watchdogs and handling A/B boot slot
> selection (with RAUC integration) aren't possible with extlinux.conf,
> and a menu isn't going to be much help in a headless system. If there is
> a better way than boot.scr to handle those I'd very much like to read
> about it.

My point was just that the boot.scr.in that you have above could easily be
replaced by a extlinux.conf instead.

I hear your argument that certain features (like watchdog an A/B boot slot)
is not possible with extlinux.conf.

But if you want your example to be minimal... isn't extlinux.conf enough/
exactly what you want? (extlinux.conf is definitely simpler for a beginner
to understand, compared to a boot.scr or a .its file.)

Your comment in boot.scr.in itself says that if you want something more fancy,
you should provide your own config.

Anyway, I'm just providing a suggestion. Feel free to ignore :)

Another suggestion is for your new defconfig to use the upstream kernel
instead of the downstream kernel. A person running u-boot has already taken
the step to use the "upstream" way of booting. It is far more likely that
such a person also wants to use the upstream kernel (rather than the
downstream kernel).


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot