Hi Tom, [...]
> > > > > > > > > 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 > > > > > > "just not aware" did you mean? > > > > Yep, sorry! > > > > > > > > > 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. > > > > > > Right, it's not just for Linux, but Linux is where most of the > > > exceptions to the "ONLY HARDWARE" rule got in, because they also make > > > sense. > > > > Exactly. > > > > > And the overarching point Simon keeps trying to make I believe > > > can be boiled down to that too. There are things that one does not have > > > a (reasonable) choice about how to do things with when interacting with > > > the hunk of melted sand on your desk and that information needs to go > > > somewhere. > > > > DT is a big hammer indeed, but that doesn't mean we always need to use > > it. I never disagreed with adding nodes that make sense and will be > > useful for others. For example, the internal Driver model > > configuration options used to enable a device early etc etc are > > probably useful to more projects. On the other hand, if U-Boot is > > indeed the only project using DT for its internal configuration why > > should we care? > > > > For example, let's imagine you build TF-A, and TF-A is configured and > > bundled with a device tree that gets passed along to U-Boot (using > > OF_BOARD). Why on earth should TF-A be aware of internal DM > > implementation details and build a device tree containing > > u-boot,dm-pre-reloc, u-boot,dm-spl, dm-tpl, and every other > > non-upstreamed nodes we have? > > I don't think this is a clear example, sorry. "dm-pre-reloc" etc are > the bootph things now that you say could be useful. So they're an > example of how (now that things are more receptive) we need to look at > what U-Boot has that doesn't pass validation and see "does this make > sense, today" or not. > The point here is a bit different though. We need this in U-Boot *because* we use the DT to configure things. They are useful information, but unless another bootloader uses the same config method, U-Boot is the only consumer. If we could split those nodes in an internal u-boot .dtsi file that would be much much cleaner. But IIRC we'll have problems with patching DTs in TPL/SPL with limited memory. > I guess I'm confused as to why it's a theoretical problem for TF-A to > pass along /binman/ but not a problem to pass along > /soc/.../snvs/.../linux,snvs_pwrkey on i.MX8. _Sometimes_ internals It's the same problem and I don't think it's ok for TF-A to pass those as either. > just need to be there. That also does not mean every single should be > there. > > > Another example would be the public key that we shoehorn on the DT. > > In commit ddf67daac39d ("efi_capsule: Move signature from DTB to > > .rodata") I tried to get rid of that because since I was aware of the > > dt-schema conformance and honestly having the capsule public portion > > of the key there makes little sense. Unfortunately, that got reverted > > in commit 47a25e81d35c8 with a bogus commit message as well. So again > > imagine building TF-A, which is a first-stage bootloader and has no > > understanding of UEFI whatsoever, asking the TF-A project to start > > injecting public keys around that has no idea why or how they will be > > used. > > > > Can you imagine how the device tree would look like in a couple of > > years from now if we allow *every* project to add its own special > > config needs in there? So perhaps we should take a step back, agree > > that some level of config is needed, identify the common options, and > > add that to the spec instead of dumping everything that doesn't fit > > somewhere else in there. > > Part of the problem here and now with capsule update stuff seems to be > that, well, I don't know what the heck we should do. It's a "lovely" > specification defined feature and so I honestly don't know how much > leeway we have for how we can and can't represent and implement the > portions that are left up to the implementation or board specific. Heinrich and I can help on that. In short, the capsule update chapter doesn't define where the key should be stored. It should obviously be on a tamper resistant medium and it has a specific format, but that's as far as the spec would go. > I don't see why TF-A would inject something that should have been present > already? And/or ... I am not following you here. The public key is unique per class of devices. If someone builds TF-A and decides to provide a DTB though that, you then need to, unpack the TF-A binary when you build U-Boot, amend it and repack it via binman. On top of that, those binaries will probably be signed, so the repacking exercise becomes pretty painful. > > > > > > 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? > > > > > > I think in some ways this is the whole point of at least what I'm asking > > > for. It's fine to say "Here is the mechanism to remove nodes / > > > properties from the device tree". BUT adding entries to that list MUST > > > document where someone tried to upstream and explain that this is > > > something that belongs in the device tree because it is useful to > > > everyone. We never disagreed on that. I already said that the FWU link Sughosh sent in the cover letter should be added on a doc. But that's irrelevant to 'hard NAKing' patches [0]. It's also the complete opposite of what we are discussing here, since AFAICT you are fine with the removal mechanism as long as the nodes-to-be-removed are documented properly and there has been an upstream effort of those beforehand. > > > > And we don't disagree on that either. That's why the link to the FWU > > discussion was there (although it should have been in a doc and not in > > a mail). I am not arguing against adding nodes, I am arguing that we > > shouldn't rush them and that there's zero chance that we manage to > > upstream everything and keep some level of sanity on the spec. > > So, since U-Boot is currently using the DT for its own configuration > > needs, not having the ability to provide a DT that conforms to the > > spec and hope that we can upstream everything will just delay all of > > SystemReady 2.0 conformance efforts (and is unrealistic IMHO). > > The first problem is how does the capsule update specification specify > handling the stuff that we put in the FWU nodes that we then need to > delete? > It doesn't. The A/B update support is not part of the spec. FWU and the A/B updates are designed on top of the EFI spec to provide an easy way to do firmware updates without bricking the board while at the same time provide rollback protection. > The second problem is that I don't want the discussion link to just be > in the cover letter, I want it in the tree, in documentation and heck, > an unused-by-the-compiler parameter in the macro that adds a node to > delete that is the rST file that documents the "we tried, it was > rejected, this still makes sense" or whatever is appropriate as to why > we're deleting the node. Cheaters shall cheat here, yes, but upstream > will have a record of trying. Again, we never disagreed on that [0] https://lore.kernel.org/u-boot/capnjgz3aexw4vfo-a8wyge0od5eznoua7ta1qp71bcw51qa...@mail.gmail.com/ Thanks /Ilias > > -- > Tom