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 <tr...@konsulko.com> > > > > On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote: > > > > From: Moiz Imtiaz <moizimti...@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
signature.asc
Description: PGP signature
