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/broadcomfiles > 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.