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

Simon Glass sjg at chromium.org
Fri Sep 17 18:21:15 CEST 2021


Hi Tom,

On Wed, 15 Sept 2021 at 07:35, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > From: Simon Glass <sjg at 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 at xs4all.nl> wrote:
> > > >
> > > > > From: Moiz Imtiaz <moizimtiaz1 at 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.
>
> Lets be a little careful.  We don't want to have two ways to provide the
> information for a given feature.  But some configuration properties are
> certainly optional.
>
> > > 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 keep in mind that one of those long stated goals is that the device
> tree for a platform lives physically on the platform and doesn't require
> being replaced entirely at run-time with a new/different device tree.
>
> > 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.
>
> Note that in U-Boot we do have functionality to figure out and apply DT
> overlays for a platform, and it's generic enough that platforms can
> plugin their logic to detect what overlays are appropriate.  This is
> under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> this in their in-house firmware instead of using U-Boot.
>
> > > 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 that CMD_EXTENSION is about updating the tree for the next stage, and
> not ourself, yes.  But this is also the same problem that OSes have that
> lead to overlays, at least in part.  But also why it's so hard to
> support a static device tree on hardware, and have an evolving kernel.
> I'm not sure there's many / any good examples of wholly static and also
> feature complete device trees and OSes today, on a recent / semi-recent
> piece of hardware.
>
> > 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?
>
> Having gone through this thread, I wonder if U-Boot generating a device
> tree overlay (and also the keeping the source of it, before
> preprocessing if we can) isn't part of the solution here.  Heinrich had
> suggested in another thread, and Simon had strongly disagreed with
> overlays being how we perhaps solve some portions of the overall "what
> should U-Boot require of the DT?" problem.  I'm thinking that might be
> the right answer, in some cases.

Note that my objection here is adding runtime to U-Boot. If the prior
stage wants to arrange things that way, it seems OK to me. In
particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot
tree to merge with what it generates.

Regards,
Simon


More information about the U-Boot mailing list