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

[Ilias Apalodimas]

Hi Simon,

On Thu, 7 Sept 2023 at 15:23, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > Hi Rob,
> >
> > [...]
> >
> > > > > > > >
> > > > > > > > What is the point of removing them? Instead, we should make sure that
> > > > > > > > we upstream the bindings and encourage SoC vendors to sync them. If we
> > > > > > > > remove them, no one will bother and U-Boot just becomes a dumping
> > > > > > > > ground.
> > > > > > >
> > > > > > > Well things like the binman entries in DT are U-Boot specific and not
> > > > > > > useful for HW related descriptions or for Linux or another OS being
> > > > > > > able to deal with HW so arguably we're already a dumping ground to
> > > > > > > some degree for not defining hardware.
> > > > > >
> > > > > > I have started the process to upstream the binman bindings.
> > > > >
> > > > > I don't think they should be in DT at all, they don't describe
> > > > > anything to do with hardware, or generally even the runtime of a
> > > > > device, they don't even describe the boot/runtime state of the
> > > > > firmware, they describe build time, so I don't see what that has to do
> > > > > with device tree? Can you explain that? To me those sorts of things
> > > > > should live in a build time style config file.
> > >
> > > For the record, I tend to agree.
> > >
> >
> > +1
> >
> > > > I beg to differ. Devicetree is more than just hardware and always has
> > > > been. See, for example the /chosen and /options nodes.
> > >
> > > There are exceptions...
> > >
> >
> > We've been this over and over again and frankly it gets a bit annoying.
> > It's called *DEVICE* tree for a reason.  As Rob pointed out there are
> > exceptions, but those made a lot of sense.  Having arbitrary internal ABI
> > stuff of various projects in the schema just defeats the definition of a
> > spec.
>
> Our efforts should not just be about internal ABI, but working to
> provide a consistent configuration system for all firmware elements.

And that's what the firmware handoff was all about.
I get what you are trying to do here.  I am just aware of any other
project apart from U-Boot which uses DT for it's own configuration.
So trying to standardize some bindings that are useful to all projects
that use DT is fine. Trying to *enforce* them to use it for config
isn't IMHO.

>
> We cannot have it both ways, i.e. refusing to accept non-hardware
> bindings and then complaining that U-Boot does not pass schema
> validation. Devicetree should be a shared resource, not just for the
> use of Linux.

It's not for the use of Linux, I've wasted enough time repeating that
and so has Rob.  Please go back to previous emails and read the
arguments.

> We already have reserved-memory, flash layout and other
> things which don't relate to hardware. I would love to somehome get
> past this fundamental discussion which seems to come up every time we
> get close to making progress

Most of the nodes we already have were used across projects and made
sense to all of them. U-Boot might need to reserve some memory and so
does linux etc etc.
Some other nodes make nosense at all to and they just serve internal
ABI implementation details.  I can't possibly fathom how these would
be justifiable.  On top of all that, there's a huge danger here.  How
are you planning on separating arbitrary entries from various
projects?

What I am afraid is going to happen here is simple.  If a project
doesn't use DT to configure itself and wants to provide a DT to
U-Boot, then are you going to say "Can you please inject various DT
nodes in the tree because U-Boot *needs* them and they are now part of
the spec"?  Anyway, it's not up to me to decide here, I am just saying
what makes sense to me.

>
> >
> > > > We need run-time configuration here, since we cannot know at build
> > > > time what we will be asked to do by a previous firmware phase.
> > >
> > > Really, I don't want to have to care about the binman binding. If it is
> > > u-boot specific, then it should stay in u-boot. I took /options/u-boot/,
> > > but now I'm starting to have second thoughts on that being in dtschema
> > > if it is going to be continually and frequently extended. Validating it
> > > in SR does little. If a vendor is abusing /options/u-boot/ in some way
> > > they could just as easily remove the node in their u-boot fork to pass.
> > > SR is certainly not going to require the node be there.
> > >
> > > On A/B updates, that really doesn't seem like a u-boot specific problem
> > > to me. No one wants A/B updates in EDK2 or anything else?
> >
> > A/B updates might be implemented in EDK2 or any other bootloader that
> > chooses to implement it.  The metadata information a bootloader needs
> > to implement it are documented here [0].  Those metadata are not part of
> > the DT.  If they were it would make sense to add them on the schema.  The
> > DT entry we are using though serves a different purpose.  It tells the
> > bootloader the location of the metadata (iow where can I read them from the
> > disk).  Since bootloaders have a different way of storing their
> > configuration, I don't think this needs to be in the spec.  EDK2 for
> > example doesn't always use a DT and I don't think they'll ever use it to
> > store configuration information.
>
> In another thread with Rob involved, we are trying to provide bindings
> for EDK2 to use.
>
> Whatever the efforts of those trying to fragment the firmware
> industry, there are efforts to bring it together with a consistent
> configuration story. Ultimately I believe these will have to prevail,
> as the complexity increases.


Regards
/Ilias