Hi Peter, On Wed, 30 Aug 2023 at 02:19, Peter Robinson <pbrobin...@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