[RFC PATCH 0/5] Allow for removal of DT nodes and properties

[Ilias Apalodimas]

+CC Jose who's maintaining the metadata spec from Arm side.

On Fri, 15 Sept 2023 at 02:38, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Sep 14, 2023 at 04:41:43PM -0600, Simon Glass wrote:
> > Hi Rob,
> >
> > On Wed, 13 Sept 2023 at 16:39, Rob Herring <robh at kernel.org> wrote:
> [snip]
> > > I don't think we should decide what to do here based on said
> > > certification program. It can adapt to what's decided. Probably, the
> > > /option nodes will be stripped out or ignored for certification.
> > >
> > > I accepted u-boot options node schema into dtschema, but now have
> > > second thoughts on that. Now I'm getting more u-boot specific
> > > (perhaps, not clear) stuff and widevine stuff internal to a TEE.
> >
> > Where should these bindings go such that ARM / Linaro are not trying
> > to remove them? I would be OK with moving them out somewhere else, but
> > how are people supposed to deal with such fragmentation? My
> > understanding was that dt-schema was an attempt to set up a neutral
> > area where bindings could be accepted that were not just for
> > Linux...did that change?
>
> Well, part of the problem here is that I've been talking with Ilias more
> about what's intended here and the fwu-* stuff that Rob rejected is
> indeed not right.  We should drop it and replace it with something that
> really addresses the underlying problem (which is how do you know
> how/where to find some GUIDs) and I think we think it's something that
> can be shared between projects too and so be easier to convince Rob that
> the next form of it is right (or the right direction).

Tom, I gave the discussion we had last night a bit of thought (thanks
for that) and talked with Jose.
The spec as is written right now recommends a GPT-based partition.  It
then has various GPT UUIDs that indicate where to find the metadata as
well as the various firmware banks that participate in the whole
scheme.  If you have that GPT, then the only thing you really need is
to find the metadata UUID and handle the various banks.

However,  the synquacer which boots from a NOR has no GPT.  What that
fwu node entry does, in order to abstract the rest of the
implementation, is map UUIIDs <-> offset + length.  That way the core
code still thinks it's trying to discover UUIDs but the eventual
reads/writes end up on a NOR.
That box boots via SCP [0] , which has no understanding of device
trees, instead they hardcode the UUIDS, offsets etc for the Synquacer.
But if they ever wanted to switch over having that information would
come in handy.

Jose and I discussed this a bit.  I'll backpaddle and have someone
look into upstreaming the fwu part.  There are a few changes required,
since we already have some MTD information in the DT and those entries
would make more sense there instead of inventing a new node, but we
can discuss this when the patches are sent. Once those are sent, we
can add a recommendation on the spec, pointing to that DT entry for
any future early stage boot loaders that want to implement it,
pointing to the DT entry.

That only solves a fraction of the problem though.  Other nodes, like
the EFI public key etc. still need to be removed.

[0] https://github.com/ARM-software/SCP-firmware

Thanks
/Ilias
>
> --
> Tom