Re: Problem with U-boot | Configuration Signature not being checked while booting

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Simon Glass <sjg@chromium.org>
> Date: Wed, 15 Sep 2021 04:13:24 -0600

Hi Simon,

> Hi Mark,
> 
> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Moiz Imtiaz <moizimtiaz1@gmail.com>
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > >
> > > Hi Simon,
> > >
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > >
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > >
> > > Not sure, but seems like this is the case. I checked and there isn't any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > add the dtb and other dts dtsi
> > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > RPI4?
> >
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> >
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
> 
> >From my reading of this thread, it rather reinforces the need to
> provide a way to give U-Boot the config it needs, in the devicetree.

As long as that configuration is optional, yes, maybe.

> It seems that rpi is actually OK in this regard. If you think about
> it, it would be pretty hopeless if first-stage firmware assumed that
> it could provide a devicetree to whatever is next.

Not hopeless.  If that device tree provides a hardware description
that is complete enough to boot Linux, it should be good enough to run
U-Boot.

And yes, the Raspberry Pi has a nice way to load overlays to do
additional hardware configuration and support add-on hardware that
connects to the GPIO header on the Pi.  Replicating all this in U-Boot
would make very little sense.

> For example, if U-Boot evolves to support more devices, they could
> not be supported.

Unless the device in question has a mechanism to load device tree
overlays like the Pi, this would require a firmware update.

In practice, the device tree provided by the firmware will have more
stuff than U-Boot will ever need though.  Unless you're advocating
that U-Boot evolves into a full-fledged OS ;).

> If UEFI is used, the devicetree would have no effect, since it doesn't
> support devicetree.

That is not true.  UEFI supports device trees just fine.  All the
arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
support use device trees.  The idea that UEFI implies ACPI is a
misconception.

> So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Maybe somebody can add device tree overlay support to QEMU?