On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sat, 18 Sep 2021 03:27:48 -0600
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.
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.