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

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

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.

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

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

Thanks
/Ilias
>
> Rob