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

[Tom Rini <trini@konsulko.com>]

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

On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
> > Date: Sat, 11 Sep 2021 17:05:45 -0400
> > From: Tom Rini <trini@konsulko.com>
> > 
> > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis 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.
> > 
> > In this case, doesn't the Pi firmware pass along apply overlays and
> > construct the device tree it's going to pass along, so in this case you
> > would want to make an "overlay" for the Pi firmware to apply and pass
> > along to U-Boot, that includes the required information?
> 
> yes, that might work.  The overlay can be specified in the config.txt file.
> 
> I think truly verified boot is impossible on the Pi though, as u-boot
> and the overlay file will need to be stored on the uSD card of the Pi.
> But that applies to the scenario where the public key is stored in the
> device tree embedded in u-boot itself as well.

Yes, a more general problem is that some platforms are really only
proof-of-concept useful.  If you can't start with the ROM, you're going
to be limited.


-- 
Tom

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