Hi Simon, On Thu, 7 Sept 2023 at 15:23, Simon Glass <s...@chromium.org> wrote: > > Hi Ilias, > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > <ilias.apalodi...@linaro.org> wrote: > > > > Hi Rob, > > > > [...] > > > > > > > > > > > > > > > > > > What is the point of removing them? Instead, we should make > > > > > > > > sure that > > > > > > > > we upstream the bindings and encourage SoC vendors to sync > > > > > > > > them. If we > > > > > > > > remove them, no one will bother and U-Boot just becomes a > > > > > > > > dumping > > > > > > > > ground. > > > > > > > > > > > > > > Well things like the binman entries in DT are U-Boot specific and > > > > > > > not > > > > > > > useful for HW related descriptions or for Linux or another OS > > > > > > > being > > > > > > > able to deal with HW so arguably we're already a dumping ground to > > > > > > > some degree for not defining hardware. > > > > > > > > > > > > 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. > > > > > > For the record, I tend to agree. > > > > > > > +1 > > > > > > I beg to differ. Devicetree is more than just hardware and always has > > > > been. See, for example the /chosen and /options nodes. > > > > > > There are exceptions... > > > > > > > We've been this over and over again and frankly it gets a bit annoying. > > It's called *DEVICE* tree for a reason. As Rob pointed out there are > > exceptions, but those made a lot of sense. Having arbitrary internal ABI > > stuff of various projects in the schema just defeats the definition of a > > spec. > > Our efforts should not just be about internal ABI, but working to > provide a consistent configuration system for all firmware elements.
And that's what the firmware handoff was all about. I get what you are trying to do here. I am just aware of any other project apart from U-Boot which uses DT for it's own configuration. So trying to standardize some bindings that are useful to all projects that use DT is fine. Trying to *enforce* them to use it for config isn't IMHO. > > We cannot have it both ways, i.e. refusing to accept non-hardware > bindings and then complaining that U-Boot does not pass schema > validation. Devicetree should be a shared resource, not just for the > use of Linux. It's not for the use of Linux, I've wasted enough time repeating that and so has Rob. Please go back to previous emails and read the arguments. > We already have reserved-memory, flash layout and other > things which don't relate to hardware. I would love to somehome get > past this fundamental discussion which seems to come up every time we > get close to making progress Most of the nodes we already have were used across projects and made sense to all of them. U-Boot might need to reserve some memory and so does linux etc etc. Some other nodes make nosense at all to and they just serve internal ABI implementation details. I can't possibly fathom how these would be justifiable. On top of all that, there's a huge danger here. How are you planning on separating arbitrary entries from various projects? What I am afraid is going to happen here is simple. If a project doesn't use DT to configure itself and wants to provide a DT to U-Boot, then are you going to say "Can you please inject various DT nodes in the tree because U-Boot *needs* them and they are now part of the spec"? Anyway, it's not up to me to decide here, I am just saying what makes sense to me. > > > > > > > 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. > > > > > > Really, I don't want to have to care about the binman binding. If it is > > > u-boot specific, then it should stay in u-boot. I took /options/u-boot/, > > > but now I'm starting to have second thoughts on that being in dtschema > > > if it is going to be continually and frequently extended. Validating it > > > in SR does little. If a vendor is abusing /options/u-boot/ in some way > > > they could just as easily remove the node in their u-boot fork to pass. > > > SR is certainly not going to require the node be there. > > > > > > On A/B updates, that really doesn't seem like a u-boot specific problem > > > to me. No one wants A/B updates in EDK2 or anything else? > > > > A/B updates might be implemented in EDK2 or any other bootloader that > > chooses to implement it. The metadata information a bootloader needs > > to implement it are documented here [0]. Those metadata are not part of > > the DT. If they were it would make sense to add them on the schema. The > > DT entry we are using though serves a different purpose. It tells the > > bootloader the location of the metadata (iow where can I read them from the > > disk). Since bootloaders have a different way of storing their > > configuration, I don't think this needs to be in the spec. EDK2 for > > example doesn't always use a DT and I don't think they'll ever use it to > > store configuration information. > > In another thread with Rob involved, we are trying to provide bindings > for EDK2 to use. > > Whatever the efforts of those trying to fragment the firmware > industry, there are efforts to bring it together with a consistent > configuration story. Ultimately I believe these will have to prevail, > as the complexity increases. Regards /Ilias