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

[Simon Glass]

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.

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

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

>
> [0] https://developer.arm.com/documentation/den0118/b/?lang=en
>
> Thanks
> /Ilias
> >
> > Rob

Regards,
Simon