Hi Rob, On Mon, 18 Sept 2023 at 11:00, Rob Herring <r...@kernel.org> wrote: > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass <s...@chromium.org> wrote: > > > > Hi Rob, > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring <r...@kernel.org> wrote: > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis <mark.kette...@xs4all.nl> > > > wrote: > > > > > > > > > From: Jassi Brar <jassisinghb...@gmail.com> > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > Hi Simon, > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass <s...@chromium.org> wrote: > > > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > Sure, programmatically we can pass any data/info via DT, however it is > > > > > only meant to map hardware features onto data structures. > > > > > > > > > > devicetree.org landing page > > > > > "The devicetree is a data structure for describing hardware." > > > > > > > > > > devicetree-specification-v0.3.pdf Chapter-2 Line-1 > > > > > "DTSpec specifies a construct called a devicetree to describe > > > > > system hardware." > > > > > > > > But it doesn't say that it describes *only* hardware. And it does > > > > describe more than just hardware. There is /chosen to specify > > > > firmware configuration and there are several examples of device tree > > > > bindings that describe non-discoverable firmware interfaces in the > > > > Linux tree. And it has been that way since the days of IEEE 1275. > > > > There are also bindings describing things like the firmware partition > > > > layout. > > > > > > Yes. The exact title for 1275[1] is: IEEE Standard for Boot > > > (Initialization Configuration) > > > Firmware: Core Requirements and Practices > > > > > > I see "configuration" in there. However, in the OF case, it's > > > generally how firmware configured the hardware and what it discovered. > > > That's a little different than telling the OS how to configure the > > > hardware which is what we do with FDT. > > > > For the /options node it says "The properties of this node are the > > system’s configuration variables." > > > > Then there is section 7.4.4 which has a large list of options which > > don't seem to be so narrowly defined. > > > > In any case, this is not quite the point, which IMO is that we need DT > > to support firmware use cases, whether or not a 29-year-old spec > > thought of it or not. In fact it is amazing to me how forward-looking > > Open Firmware was. > > > > > Then there's stuff that's how > > > to configure Linux which we try to reject. > > > > Fair enough: Linux has user-space for that. > > Yep, the question I usually ask is who needs to configure something > and what determines the config. Changing things with sysfs is much > easier than changing the DT provided by firmware. > > > > > > > Once we get into configuration of the OS/client (including u-boot), > > > making that an ABI is a lot harder and if we use DT for that, I don't > > > think it should be an ABI. > > > > > > > > If we want to digress from the spec, we need the majority of > > > > > developers to switch sides :) which is unlikely to happen and rightly > > > > > so, imho. > > > > > > > > It isn't even clear what the spec is. There is the document you > > > > reference above, there are the yaml files at > > > > https://github.com/devicetree-org/dt-schema and then there are > > > > additional yaml files in the Linux tree. As far as I know it isn't > > > > written down anywhere that those are the only places where device tree > > > > bindings can live. > > > > > > There's not any restriction. > > > > > > My intention with dtschema schemas is to only have "spec level" > > > schemas. (Stuff we'd add to DTSpec (but don't because no one wants to > > > write specs).) Hardware specific stuff lives somewhere else. That > > > happens to be the Linux tree because that is where all the h/w support > > > is (nothing else is close (by far)). Last I checked, we've got ~3700 > > > schemas and ~1500 unconverted bindings. > > > > That scope is quite a bit narrower than I understood it to be. It > > seems to leave a significant gap between the Linux repo and yours. > > > > > > > > > Anyway, let's face it, there is some consensus among developers that > > > > what Simon has done in U-Boot is pushing the use of devicetree beyond > > > > the point where a significant fraction of developers thinks it makes > > > > sense. And I think I agree with that. But you can't beat him with > > > > the spec to make your point. > > > > > > > > Now the devicetree is cleverly constructed such that it is possible to > > > > define additional bindings without the risk of conflicting with > > > > bindings developed by other parties. In particular if U-Boot is > > > > augmenting a device tree with properties that are prefixed with > > > > "u-boot," this isn't going to hurt an operating system that uses such > > > > an augmented device tree. > > > > > > Until someone has some great idea to start using them. If the OS > > > doesn't need something, then why pass it in the first place? What > > > purpose does it serve? It's an invitation for someone somewhere to > > > start using them. > > > > > > The downside of keeping the nodes is it creates an ABI where there > > > doesn't need to be one necessarily. > > > > I'd love to get away from the idea that DT is just for the OS. We are > > trying to use it for firmware-to-firmware communication, too. The > > programs on each side of that interface may be different projects. For > > that, we do need to have a binding, otherwise we end up with series > > like this one. > > I don't think DT is just for the OS, but DT for the OS is an ABI and > other cases may not be. Or they just don't need to follow all the same > rules. Zephyr is doing their own thing for example. > > I don't think /options/u-boot is an ABI. AIUI, u-boot populates the > node and consumes it. No ABI there (or limited to SPL to u-boot > proper). I suppose a prior firmware stage could populate it, but that > doesn't scale as then the prior stage has to know details of the next > stage.
I still don't understand the distinction, or really why U-Boot (or u-boot) is different. The main reason for the /options/u-boot node is so that prior phase firmware can tell U-Boot what to do. It is similar to the /chosen node for the OS. If it is not an ABI, how can any project rely on it? It is absolutely not just U-Boot generating something for its own consumption. Where is that idea even coming from? We even have an OF_HAS_PRIOR_STAGE Kconfig option for it in U-Boot, specifically for TF-A, etc. As to the scaling, I agree. That suggests we try to make things generic, i.e. have an /options node with these sorts of generic settings. Candidates for that are console and logging controls, for example. I would prefer that to /options/u-boot, as you know. > > > > > The real problem is that some folks developed a certification program > > > > that allegedly requires schema verification and now propose adding > > > > code to U-Boot that doesn't really solve any problem. My proposed > > > > solution would be to change said certification program to allow > > > > firmware to augment the device tree with properties and nodes with > > > > compatibles that are in the namespace controlled by the firmware. > > > > > > I don't think we should decide what to do here based on said > > > certification program. It can adapt to what's decided. Probably, the > > > /option nodes will be stripped out or ignored for certification. > > > > > > I accepted u-boot options node schema into dtschema, but now have > > > second thoughts on that. Now I'm getting more u-boot specific > > > (perhaps, not clear) stuff and widevine stuff internal to a TEE. > > > > Where should these bindings go such that ARM / Linaro are not trying > > to remove them? I would be OK with moving them out somewhere else, but > > how are people supposed to deal with such fragmentation? My > > understanding was that dt-schema was an attempt to set up a neutral > > area where bindings could be accepted that were not just for > > Linux...did that change? > > No change, just not communicated I guess. And again, bindings are not > "just for Linux". They are hosted there because that is where *all* > the hardware support is (by far). But we'll probably never get past > the "Linux binding" perception no matter what we do or how many times > I say it. > > To rephrase things a bit, I'm happy to host anything that's > multi-project, not a large number of bindings, and not a > device/hardware specific binding. The device specific bindings live in > the kernel tree primarily. For any new binding (foos/#foo-cell type > ones), I want to see multiple users. Really for these, probably best > to start with them in Linux repo (or elsewhere) and then promote them > to dtschema. That gives a little flexibility in changing/abandoning > them. So now I am not sure what you are suggesting. Are you wanting bindings in many places (yours, Linux, U-Boot, TF-A, ...)? I am sure you are aware that if we put bindings in U-Boot they will not be considered as bindings at all, including by Linaro. To restate the problem, we need (and until your previous email I thought we had) a unified repo where cross-project, firmware-targeted bindings can be accepted and agreed by interested projects. > > Removing nodes and/or properties and where things live are mostly > independent discussions. SystemReady can adapt to whatever is decided > for the former. In general, IMO, when passing DT from stage N to N+1, > the N+1 stage should remove things which only apply to N+2 stage. For > example, kexec removes /chosen and recreates it for the next kernel. Sounds good. But note that the reason for that is a conflict, since the node is used for different things - i.e. the two kernels need different settings. That is quite different from the case I am talking about, where the settings either apply globally (to interested projects) or to a single project (for all boot phases of that project). In my case, I believe there is no need to remove anything. Regards, Simon PS Zephyr is absolutely doing its own thing. Apart from the fact that it doesn't even have a runtime DT, the bindings are entirely within the project. and bear little relation to Linux bindings. I was not around for that decision, but I suspect part of the rationale was that many of the MCUs which Zephyr targets are not supported by Linux. Of course, that is not fully true and I believe it will become less true with time. Then, perhaps, in 5 years it will be Zephyr's turn to think about bindings more deeply.