> From: Simon Glass <s...@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 <tr...@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.g...@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-...@chromium.org/ > > 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