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 <tr...@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.kette...@xs4all.nl> > > > wrote: > > > > > > > > > From: Simon Glass <s...@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.kette...@xs4all.nl> 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. > > > > > > > > > > >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
signature.asc
Description: PGP signature
