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

[Peter Robinson]

> > > > > 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.
> > >
> > > I beg to differ. Devicetree is more than just hardware and always has
> > > been. See, for example the /chosen and /options nodes.
> >
> > Can you give me an example of "options" as grep doesn't give me a
> > single one in the kernel tree? I think we can just agree to disagree
> > here.
>
> See here: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml

All of those options look to me like they would work just fine in a
.env file like you've added board/raspberrypi/rpi/rpi.env

> I don't mind disagreeing, so long as it doesn't result in any
> restrictions on using devicetree in firmware. But it is very important
> to the success of firmware that we can make full use of the
> devicetree.

That statement doesn't make sense, of course the firmware makes full
use of the DT because it needs it to instantiate the HW. You don't
actually answer my question though.

> > > 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.
> >
> > Can you provide an example as to how that is used during runtime? Do
> > you mean runtime during the build process or runtime on the device?
>
> I mean runtime on the device. An example is that we might want to
> control whether the serial UART is enabled, without having to rebuild
> each program in the firmware stack.

That is describing the HW though, such as whether a serial port is
enabled or not, it's not how the binman pieces you're adding to DT are
used during runtime which is the question I was asking.

> >
> > > >
> > > > > Perhaps we should use the issue tracker[1] to follow progress on all
> > > > > of this. We need to clean it up.
> > > > >
> > > > > >
> > > > > > > Instead of this, how about working on bringing the DT validation into
> > > > > > > U-Boot so we can see what state things are in?
> > > > > > >
> > > > > > > Please send the bindings for Linaro's recent series (which I suspect
> > > > > > > are motivating this series) so we can start the process.
> > > > >
> > > > > Regards,
> > > > > Simon
> > > > >
> > > > > [1] https://source.denx.de/u-boot/u-boot/-/issues
> > >
> > > Regards,
> > > Simon
>
> Regards,
> Simon