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

Mon Sep 20 17:38:24 CEST 2021

On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote:
> > From: Simon Glass <sjg at chromium.org>
> > Date: Sat, 18 Sep 2021 03:27:48 -0600
> > 
> > Hi Tom,
> > 
> > On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini at 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 at xs4all.nl> 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.
> > > > >
> > > > > > 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.
> 
> I still think that if there is some sort of prior stage firmware,
> there typically is no need for SPL.  And if there is, DRAM is probably
> set up already and there are no space constraints so using the full DT
> isn't an issue.

This isn't strictly true.  You can look at the TI Keystone 3 platforms
where there's both R5 and A72 cores and it's still an intentional
software design to use SPL at the A72 stage.  I think this is explained
in the U-Boot docs, but if not I think it has been on the mailing list,
perhaps?  But that's just an FYI really.

> > >  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.
> 
> And this is I think the root of the controversy.  IMHO, U-Boot should
> have no "hard" devicetree requirements other than the requirement that
> the device tree provides a complete enough description of the hardware
> using standardized DT bindings.
> 
> That doesn't mean you can't have something like a /config node with
> U-Boot specific options.  I'd say that would be a great way for prior
> stage firmware to control U-Boot behaviour.
> 
> But what it does mean is that none of those options can be a "hard"
> requirement in the sense that in order to have a functioning U-Boot on
> a platform you absolutely have to have U-Boot specific nodes and/or
> properties in your DT.
> 
> I guess what I'm saying/asking is, why can't we have some sort of
> middle ground here?
> 
> If there is no prior-stage firmware to speak of and U-Boot is entirely
> responsible for bootstrapping a board (the typical scenario where you
> need SPL/TPL) I don't see a problem with having a control DT that
> specifies everything.
> 
> If there is prior-stage firmware, and U-Boot proper is the canonical
> payload for that firmware on a board, adding U-Boot specific stuff to
> the DT should be no issue.  There are some obvious issues here in
> keeping DT bindings in synch between the prior-stage firmware and
> U-Boot in that case, so standardizing/upstreaming the U-Boot DT
> bindings would be helpful in this scenario.
> 
> If U-Boot is just one of many choices for the payload having U-Boot
> specific stuff in the DT may not make sense.  In that scenario you'd
> just get reasonable default behaviour (and potentially no verified
> boot).  But it should be possible to change the default behaviour
> using the U-Boot environment variables in cases where it makes sense.

I concur.  And I would just note that everyone using DT is supposed to
be using the same bindings, so the in-sync part shouldn't be a big
issue.

-- 
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/20210920/3ebbfde6/attachment.sig>