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

[Simon Glass]

Hi Peter,

On Wed, 30 Aug 2023 at 02:19, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> > > > > > 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

But that is built into U-Boot. How can it be controlled by another
previous progress in the firmware stack?

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

I think I tried to answer your question but we are not on the same
page. Please don't say that DT is just for hardware, since that is a
sore point with me. It helf back U-Boot for many years, to no useful
purpose.

Perhaps you could restate the question?

Also, why are you trying to keep things out of the DT?

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

There is:

1. whether the serial device is enabled in the DT
2. whether it emits character or not

Often we always want 1, in case we need to emit something. But for 2
we want to control it with a global setting that applies to all
programs in the firmware flow.

Another example would be a framebuffer address, where we want to
provide it in the DT so that all programs can use the same one.


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