Hi Peter,
On Wed, 30 Aug 2023 at 02:19, Peter Robinson pbrobinson@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/optio...
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
Regards, Simon