Pull request for efi-2021-10-rc4

[Mark Kettenis]

> 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.

> 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