From: Simon Glass sjg@chromium.org Date: Thu, 9 Sep 2021 14:08:24 -0600
Hi Simon,
Hi Tom,
On Thu, 9 Sept 2021 at 06:08, Tom Rini trini@konsulko.com wrote:
On Thu, Sep 09, 2021 at 12:52:52PM +0200, Heinrich Schuchardt wrote:
On 9/9/21 10:56 AM, Simon Glass wrote:
Hi Heinrich,
On Sat, 4 Sept 2021 at 12:08, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
It is Simon's concept of blobs in devicetrees that is borked in that it ignores QEMU and any board that gets the DT from a prior boot stage.
That's because I was completely unaware of this strange back-door approach. It would have helped a lot if someone had bothered to create
CONFIG_OF_PRIOR_STAGE is not a backdoor. And you are the DM maintainer.
some documentation for the design. Then I would have seen the problem immediately.
Anyway, it is now covered by the above series. The use of devicetree in U-Boot is very clear, I think.
I see neither a design by you nor a series that covers CONFIG_OF_PRIOR_STAGE. I have suggested that if you really want to move this blob to a devicetree you could apply an overlay tree including U-Boot specific fields to the devicetree of the prior stage. Did you yet respond to this?
Given that I feel like "u-boot,dm-spl" and "u-boot,dm-pre-reloc" are unlikely to survive upstream review, I would like to hear what you think about applying overlays, at least in general, Simon.
I would be pretty disappointed if vendor,propname could not survive upstream review, given that it is in the DT spec explicitly, and that linux, is used in Linux.
Well, the Linux DT maintainers tend to be pretty thorough in their review and will resist crappy ideas ;). I think there is merit in the way we currently do things by augmenting the standard Linux device tree with these properties. At least on platforms where U-Boot is the first bit of firmware that runs (apart from ROM code). But I suspect there would be some resistence if we proposed to add these properties directly to the upstream Linux DTs instead.
On the other hand I don't see why maintainers of firmware that runs before U-Boot that provides a DT to U-Boot through a CONFIG_OF_PRIOR_STAGE mechanism would never add "u-boot," properties to their device trees if they use U-Boot as a 2nd stage loader. I'm sure the device trees providied by m1n1 for the Apple M1 could contain additional nodes and "u-boot," properties if necessary.
To answer your question, I think it is a terrible idea and would lead to much pain and misery and eventually the failure of U-Boot to function as a useful and efficient bootloader . It moves something that I think can be easily accomplished (from a technical POV anyway) at built-time into the run-time domain. Leaving aside that devicetree overlays are arguably not supported/implemented so far as the DT spec is concerned, it adds overhead to SPL and U-Boot (particularly pre-reloc) that is likely to make the whole thing infeasible.
I still think that U-Boot TPL/SPL isn't an issue for platforms that use CONFIG_OF_PRIOR_STAGE. The QEMU example that was given is a bit artificial in that it is a configuration specifically designed for testing U-Boot SPL. Folks using a QEMU-based virtualization solution don't care about that configuration and will only use U-Boot proper.
Also, somewhat off-topic, this is the first I have ever heard of the idea of U-Boot needing to put its properties in a separate place. I tried to cover this in 'Why not have two devicetrees?' here:
https://patchwork.ozlabs.org/project/uboot/patch/20210828164630.81050-4-sjg@...
How hard do we really want to make this? If a DT is provided to U-Boot, it needs to be suitable for U-Boot.
But U-Boot must not make unreasonable demands.
The whole idea is driven from a misconception that U-Boot is just borrowing a devicetree from Linux or qemu or TF-A.
I diasagree that's a misconception. I've already explained why it isn't practical for U-Boot to have hardwired device trees for things like QEMU, Raspberry Pi or Apple M1. I also don't see what specific U-Boot cofiguration is needed for those platforms. Currently U-Boot functions just fine with on these platforms without having any "u-boot," properties in the DT they provide to U-Boot. Granted, I'm not trying to do any sort of verified/secure boot on those platforms. But any meaningful verified/secure boot implementation needs a high degree of agreement between the integrated firmware components anyway.
So to the extent that this implies that U-Boot cannot have its own properties and nodes in the devicetree;
No.
No.
No.
U-Boot uses the devicetree for its configuration and it must be supplied based on U-Boot's requirements. I will try to send another version of the devicetree doc series.
I really think this needs to be judged on a case-by-case basis. Using this as a leading principle is fine, but ruling out binary data linked into the u-boot binary itself out of principle if embedding that data into the device tree isn't practical seems counterproductive to me.
Cheers,
Mark