On Thu, 9 Sept 2021 at 23:22, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
> > 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. > +1 Let's also take the example of PSCI interface. This may be offered by SCP firmware sitting on an external micro-controller or by OP-TEE Trusted Application or intercepted by Qemu. Let's assume the piece of code offering the PSCI interface change and offer a new version of API. Current situation in most boards: you have to sync up all projects (TFA, OP-TEE, U-Boot, Linux) with that new information. The forward and backward compatibilities are a problem. Desired situation: a single authoritative entity (TFA? U-Boot?) is using a platform specific way to sense the offered API and conduit and injects it in the DT. > > > 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 > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog