Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Rob, On Thu, 21 Sept 2023 at 07:59, Rob Herring wrote: > > On Tue, Sep 19, 2023 at 3:26 PM Simon Glass wrote: > > > > Hi Rob, > > > > On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > > > > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > > > > > Hi Rob, > > > > > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Jassi Brar > > > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass > > > > > > > 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. >
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Tue, Sep 19, 2023 at 3:26 PM Simon Glass wrote: > > Hi Rob, > > On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Jassi Brar > > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass > > > > > > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Tue, Sep 19, 2023 at 02:25:49PM -0600, Simon Glass wrote: > Hi Rob, > > On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Jassi Brar > > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass > > > > > > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Rob, On Mon, 18 Sept 2023 at 11:00, Rob Herring wrote: > > On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > > > Hi Rob, > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > > wrote: > > > > > > > > > From: Jassi Brar > > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > > > Hi Simon, > > > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Thu, Sep 14, 2023 at 5:42 PM Simon Glass wrote: > > Hi Rob, > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis > > wrote: > > > > > > > From: Jassi Brar > > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > > > Hi Simon, > > > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
+CC Jose who's maintaining the metadata spec from Arm side. On Fri, 15 Sept 2023 at 02:38, Tom Rini wrote: > > On Thu, Sep 14, 2023 at 04:41:43PM -0600, Simon Glass wrote: > > Hi Rob, > > > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > [snip] > > > 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? > > Well, part of the problem here is that I've been talking with Ilias more > about what's intended here and the fwu-* stuff that Rob rejected is > indeed not right. We should drop it and replace it with something that > really addresses the underlying problem (which is how do you know > how/where to find some GUIDs) and I think we think it's something that > can be shared between projects too and so be easier to convince Rob that > the next form of it is right (or the right direction). Tom, I gave the discussion we had last night a bit of thought (thanks for that) and talked with Jose. The spec as is written right now recommends a GPT-based partition. It then has various GPT UUIDs that indicate where to find the metadata as well as the various firmware banks that participate in the whole scheme. If you have that GPT, then the only thing you really need is to find the metadata UUID and handle the various banks. However, the synquacer which boots from a NOR has no GPT. What that fwu node entry does, in order to abstract the rest of the implementation, is map UUIIDs <-> offset + length. That way the core code still thinks it's trying to discover UUIDs but the eventual reads/writes end up on a NOR. That box boots via SCP [0] , which has no understanding of device trees, instead they hardcode the UUIDS, offsets etc for the Synquacer. But if they ever wanted to switch over having that information would come in handy. Jose and I discussed this a bit. I'll backpaddle and have someone look into upstreaming the fwu part. There are a few changes required, since we already have some MTD information in the DT and those entries would make more sense there instead of inventing a new node, but we can discuss this when the patches are sent. Once those are sent, we can add a recommendation on the spec, pointing to that DT entry for any future early stage boot loaders that want to implement it, pointing to the DT entry. That only solves a fraction of the problem though. Other nodes, like the EFI public key etc. still need to be removed. [0] https://github.com/ARM-software/SCP-firmware Thanks /Ilias > > -- > Tom
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Thu, Sep 14, 2023 at 04:41:43PM -0600, Simon Glass wrote: > Hi Rob, > > On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: [snip] > > 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? Well, part of the problem here is that I've been talking with Ilias more about what's intended here and the fwu-* stuff that Rob rejected is indeed not right. We should drop it and replace it with something that really addresses the underlying problem (which is how do you know how/where to find some GUIDs) and I think we think it's something that can be shared between projects too and so be easier to convince Rob that the next form of it is right (or the right direction). -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Rob, On Wed, 13 Sept 2023 at 16:39, Rob Herring wrote: > > On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis wrote: > > > > > From: Jassi Brar > > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > > > Hi Simon, > > > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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. > > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Fri, Sep 8, 2023 at 1:06 PM Mark Kettenis wrote: > > > From: Jassi Brar > > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > > > Hi Simon, > > > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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. Then there's stuff that's how to configure Linux which we try to reject. 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. > 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. > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Fri, Sep 08, 2023 at 06:28:14PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > On Fri, 8 Sept 2023 at 17:54, Tom Rini wrote: > > > > On Fri, Sep 08, 2023 at 01:13:42PM +0300, Ilias Apalodimas wrote: > > > Hi Simon, > > > > > > On Thu, 7 Sept 2023 at 15:23, Simon Glass wrote: > > > > > > > > Hi Ilias, > > > > > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > 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 > > > > "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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
> From: Jassi Brar > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > Hi Simon, > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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. > 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. 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. 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. Cheers, Mark
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Tom,
On Fri, 8 Sept 2023 at 17:54, Tom Rini wrote:
>
> On Fri, Sep 08, 2023 at 01:13:42PM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > On Thu, 7 Sept 2023 at 15:23, Simon Glass wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas
> > > 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
>
> "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?
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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Fri, Sep 08, 2023 at 01:13:42PM +0300, Ilias Apalodimas wrote: > Hi Simon, > > On Thu, 7 Sept 2023 at 15:23, Simon Glass wrote: > > > > Hi Ilias, > > > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > 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 "just not aware" did you mean? > 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. 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. > > 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. > 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. What's the difference between that and "If a project
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Fri, Sep 08, 2023 at 09:37:12AM -0500, Jassi Brar wrote: > Hi Simon, > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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." > > 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's the same language-lawyering that's been going on since device trees moved from the neat thing Apple-based PowerPC platforms provided (and extended), and then got ad-hoc'd to support other PowerPC platforms, and then was used to solve "Linus is sick of the patch conflicts on ARM" problems. And everyone is tired of talking about the exceptions to "it must be hardware" because if your software isn't where the software-burned-into-the-hardware wants it to be, the hardware won't work and so on. -- Tom p.s. Yes, I know Apple didn't invent device trees either. signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Simon, On Thu, Sep 7, 2023 at 3:08 PM Simon Glass 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." 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. regards.
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Simon, On Thu, 7 Sept 2023 at 15:23, Simon Glass wrote: > > Hi Ilias, > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Ilias, On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas 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. 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. 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. > > > > 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. > > [0] https://developer.arm.com/documentation/den0118/b/?lang=en > > Thanks > /Ilias > > > > Rob Regards, Simon
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Thu, Sep 07, 2023 at 01:30:01AM +0200, Heinrich Schuchardt wrote: [snip] > The missing piece is validation of the U-Boot internal device-trees > against a schema in the U-Boot CI. This should be possible even if some > of the schema yaml files are maintained inside the U-Boot repo. Dropping Rob since I don't think he cares about this part. Yes, what we need is some help in re-syncing our Kbuild (and Kconfig, but..) logic with the kernel as it's stuck at v4.20 still and all of the parts that make running the validation targets would be much easier (free) if we were in sync or much closer at least. It would be much appreciated if Linaro or Canonical or one of the other companies doing U-Boot work could get someone to focus on this task. It would help with a number of things, this included. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On 9/7/23 00:04, Tom Rini wrote: On Wed, Sep 06, 2023 at 09:21:39AM -0500, Rob Herring wrote: On Mon, Aug 28, 2023 at 04:09:29PM -0600, Simon Glass wrote: Hi Peter, On Mon, 28 Aug 2023 at 14:29, Peter Robinson wrote: On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: Hi Peter, On Mon, 28 Aug 2023 at 10:37, Peter Robinson wrote: On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: Hi, On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: Provide a way for removing certain devicetree nodes and/or properties from the devicetree. This is needed to purge certain nodes and properties which may be relevant only in U-Boot. Such nodes and properties are then removed from the devicetree before it is passed to the kernel. This ensures that the devicetree passed to the OS does not contain any non-compliant nodes and properties. The removal of the nodes and properties is being done through an EVT_FT_FIXUP handler. I am not sure if the removal code needs to be behind any Kconfig symbol. I have only build tested this on sandbox, and tested on qemu arm64 virt platform. This being a RFC, I have not put this through a CI run. Sughosh Ganu (5): dt: Provide a way to remove non-compliant nodes and properties fwu: Add the fwu-mdata node for removal from devicetree capsule: Add the capsule-key property for removal from devicetree bootefi: Call the EVT_FT_FIXUP event handler doc: Add a document for non-compliant DT node/property removal cmd/bootefi.c | 18 + .../devicetree/dt_non_compliant_purge.rst | 64 drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ include/dt-structs.h | 11 +++ lib/Makefile | 1 + lib/dt_purge.c| 73 +++ lib/efi_loader/efi_capsule.c | 7 ++ 7 files changed, 179 insertions(+) create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst create mode 100644 lib/dt_purge.c 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. 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 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. The missing piece is validation of the U-Boot internal device-trees against a schema in the U-Boot CI. This should be possible even if some of the schema yaml files are maintained inside the U-Boot repo. Best regards Heinrich It's going to continue to be a "fun" tight-rope to walk. No one wants an easy way for vendors to cheat the requirements which is why in some other parts of this thread (you may or may not have been on, I don't recall, sorry) I've been trying to make it clear that the removal mechanism should be both a slight pain to add to, and at least wrt upstream, clear that effort was made to upstream things. Cheaters are going to cheat and they could just chain a bunch of "fdt rm" together to do it today.
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Wed, Sep 06, 2023 at 09:21:39AM -0500, Rob Herring wrote: > On Mon, Aug 28, 2023 at 04:09:29PM -0600, Simon Glass wrote: > > Hi Peter, > > > > On Mon, 28 Aug 2023 at 14:29, Peter Robinson wrote: > > > > > > On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: > > > > > > > > Hi Peter, > > > > > > > > On Mon, 28 Aug 2023 at 10:37, Peter Robinson > > > > wrote: > > > > > > > > > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Provide a way for removing certain devicetree nodes and/or > > > > > > > properties > > > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > > > properties are then removed from the devicetree before it is > > > > > > > passed to > > > > > > > the kernel. This ensures that the devicetree passed to the OS > > > > > > > does not > > > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to > > > > > > > be > > > > > > > behind any Kconfig symbol. > > > > > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > > > virt platform. This being a RFC, I have not put this through a CI > > > > > > > run. > > > > > > > > > > > > > > Sughosh Ganu (5): > > > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > > > capsule: Add the capsule-key property for removal from > > > > > > > devicetree > > > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > > > > > > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > > > include/dt-structs.h | 11 +++ > > > > > > > lib/Makefile | 1 + > > > > > > > lib/dt_purge.c| 73 > > > > > > > +++ > > > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > > > 7 files changed, 179 insertions(+) > > > > > > > create mode 100644 > > > > > > > doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > > > > > 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. > > > 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 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. It's going to continue to be a "fun" tight-rope to walk. No one wants an easy way for vendors to cheat the requirements which is why in some other parts of this thread (you may or may not have been on, I don't recall, sorry) I've been trying to make it clear that the removal mechanism should be both a slight pain to add to, and at
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Wed, Sep 06, 2023 at 09:21:39AM -0500, Rob Herring wrote: [snip] > 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? This specific case goes back to: https://lore.kernel.org/u-boot/20230410232112.72778-1-jaswinder.si...@linaro.org/ But I believe Sughosh and Ilias are basically the people who are in charge of the code at this point? So perhaps a step here is some advice on whatever they need to redo/rethink to get something that is acceptable. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Rob, On Wed, 6 Sept 2023 at 08:21, Rob Herring wrote: > > On Mon, Aug 28, 2023 at 04:09:29PM -0600, Simon Glass wrote: > > Hi Peter, > > > > On Mon, 28 Aug 2023 at 14:29, Peter Robinson wrote: > > > > > > On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: > > > > > > > > Hi Peter, > > > > > > > > On Mon, 28 Aug 2023 at 10:37, Peter Robinson > > > > wrote: > > > > > > > > > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Provide a way for removing certain devicetree nodes and/or > > > > > > > properties > > > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > > > properties are then removed from the devicetree before it is > > > > > > > passed to > > > > > > > the kernel. This ensures that the devicetree passed to the OS > > > > > > > does not > > > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to > > > > > > > be > > > > > > > behind any Kconfig symbol. > > > > > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > > > virt platform. This being a RFC, I have not put this through a CI > > > > > > > run. > > > > > > > > > > > > > > Sughosh Ganu (5): > > > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > > > capsule: Add the capsule-key property for removal from > > > > > > > devicetree > > > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > > > > > > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > > > include/dt-structs.h | 11 +++ > > > > > > > lib/Makefile | 1 + > > > > > > > lib/dt_purge.c| 73 > > > > > > > +++ > > > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > > > 7 files changed, 179 insertions(+) > > > > > > > create mode 100644 > > > > > > > doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > > > > > 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. > > > 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... I wish we could stop having this discussion entirely...to me the devicetree is all that firmware has to handle its configuration, both within projects and across project boundaries. There is no user space, no filesystem, etc. > > > 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 don't believe it is U-Boot-specific since it describes the system firmware as a whole. It collects things from multiple projects and we want to know where they ended up, so we can do firmware update, etc. > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Mon, Aug 28, 2023 at 04:09:29PM -0600, Simon Glass wrote: > Hi Peter, > > On Mon, 28 Aug 2023 at 14:29, Peter Robinson wrote: > > > > On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: > > > > > > Hi Peter, > > > > > > On Mon, 28 Aug 2023 at 10:37, Peter Robinson wrote: > > > > > > > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > > > > > > > Provide a way for removing certain devicetree nodes and/or > > > > > > properties > > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > > properties are then removed from the devicetree before it is passed > > > > > > to > > > > > > the kernel. This ensures that the devicetree passed to the OS does > > > > > > not > > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > > > > behind any Kconfig symbol. > > > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > > virt platform. This being a RFC, I have not put this through a CI > > > > > > run. > > > > > > > > > > > > Sughosh Ganu (5): > > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > > capsule: Add the capsule-key property for removal from devicetree > > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > > include/dt-structs.h | 11 +++ > > > > > > lib/Makefile | 1 + > > > > > > lib/dt_purge.c| 73 > > > > > > +++ > > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > > 7 files changed, 179 insertions(+) > > > > > > create mode 100644 > > > > > > doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > > > 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. > 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 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? Rob
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Peter, On Wed, 30 Aug 2023 at 02:19, Peter Robinson 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
> > > > > 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 > 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. > > > 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. > > > > > > > > > > > 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 > > Regards, > Simon
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Peter, On Tue, 29 Aug 2023 at 04:33, Peter Robinson wrote: > > > > > > > > Provide a way for removing certain devicetree nodes and/or > > > > > > > properties > > > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > > > properties are then removed from the devicetree before it is > > > > > > > passed to > > > > > > > the kernel. This ensures that the devicetree passed to the OS > > > > > > > does not > > > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to > > > > > > > be > > > > > > > behind any Kconfig symbol. > > > > > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > > > virt platform. This being a RFC, I have not put this through a CI > > > > > > > run. > > > > > > > > > > > > > > Sughosh Ganu (5): > > > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > > > capsule: Add the capsule-key property for removal from > > > > > > > devicetree > > > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > > > > > > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > > > include/dt-structs.h | 11 +++ > > > > > > > lib/Makefile | 1 + > > > > > > > lib/dt_purge.c| 73 > > > > > > > +++ > > > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > > > 7 files changed, 179 insertions(+) > > > > > > > create mode 100644 > > > > > > > doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > > > > > 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. > > > > 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 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. > > 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. > > > > > > > > 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 Regards, Simon
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
> > > > > > Provide a way for removing certain devicetree nodes and/or > > > > > > properties > > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > > properties are then removed from the devicetree before it is passed > > > > > > to > > > > > > the kernel. This ensures that the devicetree passed to the OS does > > > > > > not > > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > > > > behind any Kconfig symbol. > > > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > > virt platform. This being a RFC, I have not put this through a CI > > > > > > run. > > > > > > > > > > > > Sughosh Ganu (5): > > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > > capsule: Add the capsule-key property for removal from devicetree > > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > > include/dt-structs.h | 11 +++ > > > > > > lib/Makefile | 1 + > > > > > > lib/dt_purge.c| 73 > > > > > > +++ > > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > > 7 files changed, 179 insertions(+) > > > > > > create mode 100644 > > > > > > doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > > > 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. > > 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. > 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? > > > > > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Peter, On Mon, 28 Aug 2023 at 14:29, Peter Robinson wrote: > > On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: > > > > Hi Peter, > > > > On Mon, 28 Aug 2023 at 10:37, Peter Robinson wrote: > > > > > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > > wrote: > > > > > > > > > > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > > > > from the devicetree. This is needed to purge certain nodes and > > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > > properties are then removed from the devicetree before it is passed to > > > > > the kernel. This ensures that the devicetree passed to the OS does not > > > > > contain any non-compliant nodes and properties. > > > > > > > > > > The removal of the nodes and properties is being done through an > > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > > > behind any Kconfig symbol. > > > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > > virt platform. This being a RFC, I have not put this through a CI run. > > > > > > > > > > Sughosh Ganu (5): > > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > > capsule: Add the capsule-key property for removal from devicetree > > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > > > cmd/bootefi.c | 18 + > > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > > include/dt-structs.h | 11 +++ > > > > > lib/Makefile | 1 + > > > > > lib/dt_purge.c| 73 > > > > > +++ > > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > > 7 files changed, 179 insertions(+) > > > > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > > > > create mode 100644 lib/dt_purge.c > > > > > > > > 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. I beg to differ. Devicetree is more than just hardware and always has been. See, for example the /chosen and /options nodes. 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. > > > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Mon, Aug 28, 2023 at 6:54 PM Simon Glass wrote: > > Hi Peter, > > On Mon, 28 Aug 2023 at 10:37, Peter Robinson wrote: > > > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > > > Hi, > > > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu > > > wrote: > > > > > > > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > > > from the devicetree. This is needed to purge certain nodes and > > > > properties which may be relevant only in U-Boot. Such nodes and > > > > properties are then removed from the devicetree before it is passed to > > > > the kernel. This ensures that the devicetree passed to the OS does not > > > > contain any non-compliant nodes and properties. > > > > > > > > The removal of the nodes and properties is being done through an > > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > > behind any Kconfig symbol. > > > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > > virt platform. This being a RFC, I have not put this through a CI run. > > > > > > > > Sughosh Ganu (5): > > > > dt: Provide a way to remove non-compliant nodes and properties > > > > fwu: Add the fwu-mdata node for removal from devicetree > > > > capsule: Add the capsule-key property for removal from devicetree > > > > bootefi: Call the EVT_FT_FIXUP event handler > > > > doc: Add a document for non-compliant DT node/property removal > > > > > > > > cmd/bootefi.c | 18 + > > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > > include/dt-structs.h | 11 +++ > > > > lib/Makefile | 1 + > > > > lib/dt_purge.c| 73 +++ > > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > > 7 files changed, 179 insertions(+) > > > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > > > create mode 100644 lib/dt_purge.c > > > > > > 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. > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Mon, Aug 28, 2023 at 10:19:55AM -0600, Simon Glass wrote: > Hi, > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > from the devicetree. This is needed to purge certain nodes and > > properties which may be relevant only in U-Boot. Such nodes and > > properties are then removed from the devicetree before it is passed to > > the kernel. This ensures that the devicetree passed to the OS does not > > contain any non-compliant nodes and properties. > > > > The removal of the nodes and properties is being done through an > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > behind any Kconfig symbol. > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > virt platform. This being a RFC, I have not put this through a CI run. > > > > Sughosh Ganu (5): > > dt: Provide a way to remove non-compliant nodes and properties > > fwu: Add the fwu-mdata node for removal from devicetree > > capsule: Add the capsule-key property for removal from devicetree > > bootefi: Call the EVT_FT_FIXUP event handler > > doc: Add a document for non-compliant DT node/property removal > > > > cmd/bootefi.c | 18 + > > .../devicetree/dt_non_compliant_purge.rst | 64 > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > include/dt-structs.h | 11 +++ > > lib/Makefile | 1 + > > lib/dt_purge.c| 73 +++ > > lib/efi_loader/efi_capsule.c | 7 ++ > > 7 files changed, 179 insertions(+) > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > create mode 100644 lib/dt_purge.c > > 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. It's about having a defined process to remove them, rather than an ad-hoc process like one can do today to remove them. And it's about having control over the situation rather than dismissing it, as vendor can already say they used $this version of the software for validation, so patches-on-top aren't out of the question. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi Peter, On Mon, 28 Aug 2023 at 10:37, Peter Robinson wrote: > > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > Hi, > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: > > > > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > > from the devicetree. This is needed to purge certain nodes and > > > properties which may be relevant only in U-Boot. Such nodes and > > > properties are then removed from the devicetree before it is passed to > > > the kernel. This ensures that the devicetree passed to the OS does not > > > contain any non-compliant nodes and properties. > > > > > > The removal of the nodes and properties is being done through an > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > behind any Kconfig symbol. > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > virt platform. This being a RFC, I have not put this through a CI run. > > > > > > Sughosh Ganu (5): > > > dt: Provide a way to remove non-compliant nodes and properties > > > fwu: Add the fwu-mdata node for removal from devicetree > > > capsule: Add the capsule-key property for removal from devicetree > > > bootefi: Call the EVT_FT_FIXUP event handler > > > doc: Add a document for non-compliant DT node/property removal > > > > > > cmd/bootefi.c | 18 + > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > include/dt-structs.h | 11 +++ > > > lib/Makefile | 1 + > > > lib/dt_purge.c| 73 +++ > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > 7 files changed, 179 insertions(+) > > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > > create mode 100644 lib/dt_purge.c > > > > 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. 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Mon, Aug 28, 2023 at 05:37:45PM +0100, Peter Robinson wrote: > On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > > > Hi, > > > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: > > > > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > > from the devicetree. This is needed to purge certain nodes and > > > properties which may be relevant only in U-Boot. Such nodes and > > > properties are then removed from the devicetree before it is passed to > > > the kernel. This ensures that the devicetree passed to the OS does not > > > contain any non-compliant nodes and properties. > > > > > > The removal of the nodes and properties is being done through an > > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > > behind any Kconfig symbol. > > > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > > virt platform. This being a RFC, I have not put this through a CI run. > > > > > > Sughosh Ganu (5): > > > dt: Provide a way to remove non-compliant nodes and properties > > > fwu: Add the fwu-mdata node for removal from devicetree > > > capsule: Add the capsule-key property for removal from devicetree > > > bootefi: Call the EVT_FT_FIXUP event handler > > > doc: Add a document for non-compliant DT node/property removal > > > > > > cmd/bootefi.c | 18 + > > > .../devicetree/dt_non_compliant_purge.rst | 64 > > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > > include/dt-structs.h | 11 +++ > > > lib/Makefile | 1 + > > > lib/dt_purge.c| 73 +++ > > > lib/efi_loader/efi_capsule.c | 7 ++ > > > 7 files changed, 179 insertions(+) > > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > > create mode 100644 lib/dt_purge.c > > > > 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. It's about validation and Simon is literally in the process of having the binman bindings upstreamed. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Mon, Aug 28, 2023 at 5:20 PM Simon Glass wrote: > > Hi, > > On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: > > > > > > Provide a way for removing certain devicetree nodes and/or properties > > from the devicetree. This is needed to purge certain nodes and > > properties which may be relevant only in U-Boot. Such nodes and > > properties are then removed from the devicetree before it is passed to > > the kernel. This ensures that the devicetree passed to the OS does not > > contain any non-compliant nodes and properties. > > > > The removal of the nodes and properties is being done through an > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > behind any Kconfig symbol. > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > virt platform. This being a RFC, I have not put this through a CI run. > > > > Sughosh Ganu (5): > > dt: Provide a way to remove non-compliant nodes and properties > > fwu: Add the fwu-mdata node for removal from devicetree > > capsule: Add the capsule-key property for removal from devicetree > > bootefi: Call the EVT_FT_FIXUP event handler > > doc: Add a document for non-compliant DT node/property removal > > > > cmd/bootefi.c | 18 + > > .../devicetree/dt_non_compliant_purge.rst | 64 > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > include/dt-structs.h | 11 +++ > > lib/Makefile | 1 + > > lib/dt_purge.c| 73 +++ > > lib/efi_loader/efi_capsule.c | 7 ++ > > 7 files changed, 179 insertions(+) > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > create mode 100644 lib/dt_purge.c > > 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. > 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
Hi, On Sat, 26 Aug 2023 at 03:07, Sughosh Ganu wrote: > > > Provide a way for removing certain devicetree nodes and/or properties > from the devicetree. This is needed to purge certain nodes and > properties which may be relevant only in U-Boot. Such nodes and > properties are then removed from the devicetree before it is passed to > the kernel. This ensures that the devicetree passed to the OS does not > contain any non-compliant nodes and properties. > > The removal of the nodes and properties is being done through an > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > behind any Kconfig symbol. > > I have only build tested this on sandbox, and tested on qemu arm64 > virt platform. This being a RFC, I have not put this through a CI run. > > Sughosh Ganu (5): > dt: Provide a way to remove non-compliant nodes and properties > fwu: Add the fwu-mdata node for removal from devicetree > capsule: Add the capsule-key property for removal from devicetree > bootefi: Call the EVT_FT_FIXUP event handler > doc: Add a document for non-compliant DT node/property removal > > cmd/bootefi.c | 18 + > .../devicetree/dt_non_compliant_purge.rst | 64 > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > include/dt-structs.h | 11 +++ > lib/Makefile | 1 + > lib/dt_purge.c| 73 +++ > lib/efi_loader/efi_capsule.c | 7 ++ > 7 files changed, 179 insertions(+) > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > create mode 100644 lib/dt_purge.c 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. 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
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On Sat, 26 Aug 2023 at 15:36, Heinrich Schuchardt wrote: > > On 8/26/23 11:06, Sughosh Ganu wrote: > > > > Provide a way for removing certain devicetree nodes and/or properties > > from the devicetree. This is needed to purge certain nodes and > > properties which may be relevant only in U-Boot. Such nodes and > > properties are then removed from the devicetree before it is passed to > > the kernel. This ensures that the devicetree passed to the OS does not > > contain any non-compliant nodes and properties. > > > > The removal of the nodes and properties is being done through an > > EVT_FT_FIXUP handler. I am not sure if the removal code needs to be > > behind any Kconfig symbol. > > > > I have only build tested this on sandbox, and tested on qemu arm64 > > virt platform. This being a RFC, I have not put this through a CI run. > > We should have a test for the new functionality. E.g. add some > superfluous properties and nodes to arch/sandbox/dts/test.dts, delete > them via the DT_PURGE macro, and check that the device-tree passed to an > EFI binary does not contain these properties and nodes. Yes, I plan to have a test in the non-RFC version. I was thinking of adding a command and then using that to test the functionality. -sughosh > > Best regards > > Heinrich > > > > > Sughosh Ganu (5): > >dt: Provide a way to remove non-compliant nodes and properties > >fwu: Add the fwu-mdata node for removal from devicetree > >capsule: Add the capsule-key property for removal from devicetree > >bootefi: Call the EVT_FT_FIXUP event handler > >doc: Add a document for non-compliant DT node/property removal > > > > cmd/bootefi.c | 18 + > > .../devicetree/dt_non_compliant_purge.rst | 64 > > drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ > > include/dt-structs.h | 11 +++ > > lib/Makefile | 1 + > > lib/dt_purge.c| 73 +++ > > lib/efi_loader/efi_capsule.c | 7 ++ > > 7 files changed, 179 insertions(+) > > create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst > > create mode 100644 lib/dt_purge.c > >
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
On 8/26/23 11:06, Sughosh Ganu wrote: Provide a way for removing certain devicetree nodes and/or properties from the devicetree. This is needed to purge certain nodes and properties which may be relevant only in U-Boot. Such nodes and properties are then removed from the devicetree before it is passed to the kernel. This ensures that the devicetree passed to the OS does not contain any non-compliant nodes and properties. The removal of the nodes and properties is being done through an EVT_FT_FIXUP handler. I am not sure if the removal code needs to be behind any Kconfig symbol. I have only build tested this on sandbox, and tested on qemu arm64 virt platform. This being a RFC, I have not put this through a CI run. We should have a test for the new functionality. E.g. add some superfluous properties and nodes to arch/sandbox/dts/test.dts, delete them via the DT_PURGE macro, and check that the device-tree passed to an EFI binary does not contain these properties and nodes. Best regards Heinrich Sughosh Ganu (5): dt: Provide a way to remove non-compliant nodes and properties fwu: Add the fwu-mdata node for removal from devicetree capsule: Add the capsule-key property for removal from devicetree bootefi: Call the EVT_FT_FIXUP event handler doc: Add a document for non-compliant DT node/property removal cmd/bootefi.c | 18 + .../devicetree/dt_non_compliant_purge.rst | 64 drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ include/dt-structs.h | 11 +++ lib/Makefile | 1 + lib/dt_purge.c| 73 +++ lib/efi_loader/efi_capsule.c | 7 ++ 7 files changed, 179 insertions(+) create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst create mode 100644 lib/dt_purge.c
[RFC PATCH 0/5] Allow for removal of DT nodes and properties
Provide a way for removing certain devicetree nodes and/or properties from the devicetree. This is needed to purge certain nodes and properties which may be relevant only in U-Boot. Such nodes and properties are then removed from the devicetree before it is passed to the kernel. This ensures that the devicetree passed to the OS does not contain any non-compliant nodes and properties. The removal of the nodes and properties is being done through an EVT_FT_FIXUP handler. I am not sure if the removal code needs to be behind any Kconfig symbol. I have only build tested this on sandbox, and tested on qemu arm64 virt platform. This being a RFC, I have not put this through a CI run. Sughosh Ganu (5): dt: Provide a way to remove non-compliant nodes and properties fwu: Add the fwu-mdata node for removal from devicetree capsule: Add the capsule-key property for removal from devicetree bootefi: Call the EVT_FT_FIXUP event handler doc: Add a document for non-compliant DT node/property removal cmd/bootefi.c | 18 + .../devicetree/dt_non_compliant_purge.rst | 64 drivers/fwu-mdata/fwu-mdata-uclass.c | 5 ++ include/dt-structs.h | 11 +++ lib/Makefile | 1 + lib/dt_purge.c| 73 +++ lib/efi_loader/efi_capsule.c | 7 ++ 7 files changed, 179 insertions(+) create mode 100644 doc/develop/devicetree/dt_non_compliant_purge.rst create mode 100644 lib/dt_purge.c -- 2.34.1
