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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4894 bytes --]

On Sat, Sep 18, 2021 at 03:27:48AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > 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.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
> 
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.

The need to filter the DT down for SPL tends to be because we don't
otherwise have enough initialized memory to retrieve / work with / etc
the DT.  That can't be true if some other stage is handing us something.

> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
> 
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.

I'm trying to not belabor the point here, since you've said you'll post
some bindings for review, but it's not _our_ device tree.  That breaks
the whole blasted point of having "a" device tree, rather than everyone
having their own device tree.  So figuring out a good path forward for
verified boot is something that'll require a little more thinking quite
possibly and explaining how you do it on something again modern and
potentially hardware-assisted.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]