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