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. > > 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. [0] https://developer.arm.com/documentation/den0118/b/?lang=en Thanks /Ilias > > Rob