Pull request for efi-2021-10-rc4

[François Ozog]

On Thu, 9 Sept 2021 at 23:22, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:

> > From: Simon Glass <sjg at 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 at 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 at 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@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.ozog at linaro.org | Skype: ffozog