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

Sat Sep 18 15:24:07 CEST 2021

On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:42, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote:
> > > 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.
> >
> > Right.  I am talking about U-Boot applying an overlay to a provided by
> > prior stage device tree.  In the above example of Pi, the prior stage
> > has an option already to apply an overlay before-hand, yes.  But that's
> > not going to be the case for all platforms.
> 
> There is no need for the prior stage to apply an overlay though. It
> just needs to provide the correct devicetree with the U-Boot
> properties.

Well, it depends on what upstream is and how it handles things.  The
case where U-Boot is optional in the boot chain, like Pi, is perhaps
more common than we would like to admit, and at least Pi, and possibly
other cases also have a mechanism for applying overlays to the generated
device tree, in order to pass it to the kernel (or, U-Boot).

I'd almost say that if for no reason other than to make examples for
vboot, and other things too, available on Pi (as nearly everyone has one
in/on their desk), it's important to do so.  It's the most common
reference platform.

> I'm going to send a binding for the config node upstream and see what happens.

OK, please make sure to CC me, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210918/20befa20/attachment.sig>