| Message ID | 20231226094625.221671-1-sjg@chromium.org |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [v4] fdt: Allow the devicetree to come from a bloblist | expand |
On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > Standard passage provides for a bloblist to be passed from one firmware > phase to the next. That can be used to pass the devicetree along as well. > Add an option to support this. > > Tests for this will be added as part of the Universal Payload work. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > The discussion on this was not resolved and is now important due to the > bloblist series from Raymond. So I am sending it again since I believe > this is a better starting point than building on OF_BOARD I really don't like adding another option for "DT is given to us". Why isn't adding another enum to fdt_source_t sufficient, and if we have bloblist enabled, that will look for and use if found? Maybe some other code needs to be restructured and cleaned up too?
Hi Tom, On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > Standard passage provides for a bloblist to be passed from one firmware > > phase to the next. That can be used to pass the devicetree along as well. > > Add an option to support this. > > > > Tests for this will be added as part of the Universal Payload work. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > --- > > The discussion on this was not resolved and is now important due to the > > bloblist series from Raymond. So I am sending it again since I believe > > this is a better starting point than building on OF_BOARD > > I really don't like adding another option for "DT is given to us". Why > isn't adding another enum to fdt_source_t sufficient, and if we have > bloblist enabled, that will look for and use if found? Maybe some other > code needs to be restructured and cleaned up too? Same here. On top of that the bloblist has a few items in there, e.g a TPM eventlog. What are we going to do? Add a Kconfig for each item? This has been going back and forth for a while. I've lost count of how many times I repeated the same proposal, but here it goes again. We have OF_BOARD and BLOBLIST options. The bloblist and its properties are scannable at runtime. Can't we use the combination of these 2 can be used to imply we expect things from a bloblist. If we want to be stricter in the future and explicitly expect the DT from a bloblist, we could add a Kconfig option failing the boot if that's missing. Thanks /Ilias > > -- > Tom
Hi Tom, On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > Standard passage provides for a bloblist to be passed from one firmware > > phase to the next. That can be used to pass the devicetree along as well. > > Add an option to support this. > > > > Tests for this will be added as part of the Universal Payload work. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > --- > > The discussion on this was not resolved and is now important due to the > > bloblist series from Raymond. So I am sending it again since I believe > > this is a better starting point than building on OF_BOARD > > I really don't like adding another option for "DT is given to us". Why > isn't adding another enum to fdt_source_t sufficient That is added by this patch, but... >, and if we have > bloblist enabled, that will look for and use if found? ...this is the question. I would like to be able to enable bloblist without *requiring* the DT to come from there, hence the separate Kconfig option. > Maybe some other > code needs to be restructured and cleaned up too? Possibly, but I really am not keen on this board-specific solution. I believe Ilias & I agreed that OF_BOARD should fade away, so I don't like adding another thing onto it. Regards, Simon
Hi Ilias, On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Tom, > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > phase to the next. That can be used to pass the devicetree along as well. > > > Add an option to support this. > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > --- > > > The discussion on this was not resolved and is now important due to the > > > bloblist series from Raymond. So I am sending it again since I believe > > > this is a better starting point than building on OF_BOARD > > > > I really don't like adding another option for "DT is given to us". Why > > isn't adding another enum to fdt_source_t sufficient, and if we have > > bloblist enabled, that will look for and use if found? Maybe some other > > code needs to be restructured and cleaned up too? > > Same here. On top of that the bloblist has a few items in there, e.g a > TPM eventlog. What are we going to do? Add a Kconfig for each item? No, but that is just a straw man. The DT is special and U-Boot reports where it comes from. > > This has been going back and forth for a while. I've lost count of how > many times I repeated the same proposal, but here it goes again. We > have OF_BOARD and BLOBLIST options. The bloblist and its properties > are scannable at runtime. Can't we use the combination of these 2 can > be used to imply we expect things from a bloblist. If we want to be > stricter in the future and explicitly expect the DT from a bloblist, > we could add a Kconfig option failing the boot if that's missing. I would like to have that Kconfig option now, not later. In my mind, the boot must be deterministic, so that if OF_BLOBLIST is enabled, the DT must come from there, or it is an error. Also, repeating it doesn't make the proposal good. We agreed that OF_BOARD would eventually go away, so building on top of it is not setting us up for the future. Regards, Simon
On Wed, Dec 27, 2023 at 05:48:42PM +0000, Simon Glass wrote: > Hi Tom, > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > phase to the next. That can be used to pass the devicetree along as well. > > > Add an option to support this. > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > --- > > > The discussion on this was not resolved and is now important due to the > > > bloblist series from Raymond. So I am sending it again since I believe > > > this is a better starting point than building on OF_BOARD > > > > I really don't like adding another option for "DT is given to us". Why > > isn't adding another enum to fdt_source_t sufficient > > That is added by this patch, but... > > >, and if we have > > bloblist enabled, that will look for and use if found? > > ...this is the question. I would like to be able to enable bloblist > without *requiring* the DT to come from there, hence the separate > Kconfig option. > > > Maybe some other > > code needs to be restructured and cleaned up too? > > Possibly, but I really am not keen on this board-specific solution. I > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > like adding another thing onto it. I think you're missing something then. It should not be board specific to just find the dtb via bloblist, without a new CONFIG. Whatever is stopping that is what needs to be refactored and then you can just extend fdt_source_t without a new CONFIG option.
On Wed, Dec 27, 2023 at 05:48:44PM +0000, Simon Glass wrote: > Hi Ilias, > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Tom, > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > Add an option to support this. > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > --- > > > > The discussion on this was not resolved and is now important due to the > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > this is a better starting point than building on OF_BOARD > > > > > > I really don't like adding another option for "DT is given to us". Why > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > bloblist enabled, that will look for and use if found? Maybe some other > > > code needs to be restructured and cleaned up too? > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > No, but that is just a straw man. The DT is special and U-Boot reports > where it comes from. > > > > > This has been going back and forth for a while. I've lost count of how > > many times I repeated the same proposal, but here it goes again. We > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > are scannable at runtime. Can't we use the combination of these 2 can > > be used to imply we expect things from a bloblist. If we want to be > > stricter in the future and explicitly expect the DT from a bloblist, > > we could add a Kconfig option failing the boot if that's missing. > > I would like to have that Kconfig option now, not later. In my mind, > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > DT must come from there, or it is an error. Determinism doesn't require a CONFIG option, it just requires an if/else tree where we say what the "correct" priority list should be and then set a flag so that we can tell the user where we found it too. This also means that we can get whatever is going to use this mechanism to migrate over, and have less of a chicken-and-egg type of problem. > Also, repeating it doesn't make the proposal good. We agreed that > OF_BOARD would eventually go away, so building on top of it is not > setting us up for the future. I wonder if OF_BOARD will ever go away, and I'm not convinced it will either. Unless you just mean re-naming it and making a few ad-hoc standards more easily re-usable, which also will need to happen regardless.
On Wed, 27 Dec 2023 at 19:48, Simon Glass <sjg@chromium.org> wrote: > > Hi Ilias, > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > <ilias.apalodimas@linaro.org> wrote: > > > > Hi Tom, > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > Add an option to support this. > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > --- > > > > The discussion on this was not resolved and is now important due to the > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > this is a better starting point than building on OF_BOARD > > > > > > I really don't like adding another option for "DT is given to us". Why > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > bloblist enabled, that will look for and use if found? Maybe some other > > > code needs to be restructured and cleaned up too? > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > No, but that is just a straw man. The DT is special and U-Boot reports > where it comes from. The story is identical to the EventLog. It's 'special' as well and U-Boot has to pick it up, otherwise the hardware and the EventLog will end up with different values > > > > > This has been going back and forth for a while. I've lost count of how > > many times I repeated the same proposal, but here it goes again. We > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > are scannable at runtime. Can't we use the combination of these 2 can > > be used to imply we expect things from a bloblist. If we want to be > > stricter in the future and explicitly expect the DT from a bloblist, > > we could add a Kconfig option failing the boot if that's missing. > > I would like to have that Kconfig option now, not later. In my mind, > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > DT must come from there, or it is an error. And how is what I proposed not deterministic? What prevents us from adding that Kconfig option now? The only difference is that by default, U-Boot will try bloblist -> board-specific method unless a Kconfig option prevents the fallback. I've been working with vendors and helping them implement the firmware handoff spec in their proprietary bootloaders and Raymond contributed the implementation for TF-A. At the same time, I am pretty sure vendors will need time to implement this properly. I don't see how adding an implicit Kconfig option will help them push this forward. IOW I prefer U-Boot to *always* scan for a bloblist as the first discovery DT method (unless the DT comes bundled with U-Boot), rather than expecting users to turn a Kconfig knob. > > Also, repeating it doesn't make the proposal good. We agreed that > OF_BOARD would eventually go away, so building on top of it is not > setting us up for the future. No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going away. The only thing I suggested was to rename it [...] [0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsNTFqtbg@mail.gmail.com/ Thanks /Ilias
Hi Tom, [...] > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > where it comes from. > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > many times I repeated the same proposal, but here it goes again. We > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > are scannable at runtime. Can't we use the combination of these 2 can > > > be used to imply we expect things from a bloblist. If we want to be > > > stricter in the future and explicitly expect the DT from a bloblist, > > > we could add a Kconfig option failing the boot if that's missing. > > > > I would like to have that Kconfig option now, not later. In my mind, > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > DT must come from there, or it is an error. > > Determinism doesn't require a CONFIG option, it just requires an if/else > tree where we say what the "correct" priority list should be and then > set a flag so that we can tell the user where we found it too. This also > means that we can get whatever is going to use this mechanism to > migrate over, and have less of a chicken-and-egg type of problem. > > > Also, repeating it doesn't make the proposal good. We agreed that > > OF_BOARD would eventually go away, so building on top of it is not > > setting us up for the future. > > I wonder if OF_BOARD will ever go away, and I'm not convinced it will > either. It won't :) -- ever. You will still have hardware that reads it from an EEPROM for example, or something like that. People usually keep the first-stage bootloaders simple, so adding more drivers to read something is usually deferred to later, richer bootloaders, unless necessary > Unless you just mean re-naming it and making a few ad-hoc > standards more easily re-usable, which also will need to happen > regardless. Yes, that was what I initially suggested. Thanks /Ilias > > -- > Tom
Hi Ilias, On Thu, Dec 28, 2023 at 6:53 AM Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > On Wed, 27 Dec 2023 at 19:48, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Ilias, > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: > > > > > > Hi Tom, > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > Add an option to support this. > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > --- > > > > > The discussion on this was not resolved and is now important due to the > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > bloblist enabled, that will look for and use if found? Maybe some other > > > > code needs to be restructured and cleaned up too? > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > where it comes from. > > The story is identical to the EventLog. It's 'special' as well and > U-Boot has to pick it up, otherwise the hardware and the EventLog will > end up with different values Why are you talking about event log? Let's stick to the topic at hand. > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > many times I repeated the same proposal, but here it goes again. We > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > are scannable at runtime. Can't we use the combination of these 2 can > > > be used to imply we expect things from a bloblist. If we want to be > > > stricter in the future and explicitly expect the DT from a bloblist, > > > we could add a Kconfig option failing the boot if that's missing. > > > > I would like to have that Kconfig option now, not later. In my mind, > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > DT must come from there, or it is an error. > > And how is what I proposed not deterministic? What prevents us from > adding that Kconfig option now? > The only difference is that by default, U-Boot will try bloblist -> > board-specific method unless a Kconfig option prevents the fallback. > I've been working with vendors and helping them implement the firmware > handoff spec in their proprietary bootloaders and Raymond contributed > the implementation for TF-A. At the same time, I am pretty sure > vendors will need time to implement this properly. I don't see how > adding an implicit Kconfig option will help them push this forward. > > IOW I prefer U-Boot to *always* scan for a bloblist as the first > discovery DT method (unless the DT comes bundled with U-Boot), rather > than expecting users to turn a Kconfig knob. It is the 'unless the DT comes bundled with U-Boot' which I am talking about, but I now have a better understanding of the problem here. I don't want CONFIG_BLOBLIST to mean that the DT comes from a bloblist. Simply put, I want to be able to use the U-Boot DT during development, without needing to rebuild some prior stage or update some other project. So I would like the use of bloblist to be behind an OF_BLOBLIST option. From Tom's email and your other reply, it seems that we could all live with an OF_BLOBLIST option to enable DT-in-bloblist, making it optional but default 'y'? > > > > > Also, repeating it doesn't make the proposal good. We agreed that > > OF_BOARD would eventually go away, so building on top of it is not > > setting us up for the future. > > No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going > away. The only thing I suggested was to rename it Well I'm just not sure what is going on. Use of bloblist should not require board-specific code. It should be a generic mechanism, in fdtdec_setup() There are too many cooks in this kitchen right now, I'll try another spin of my patch. > > [...] > > [0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsNTFqtbg@mail.gmail.com/ > Regards, Simon
Hi Tom, On Wed, Dec 27, 2023 at 8:06 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Dec 27, 2023 at 05:48:42PM +0000, Simon Glass wrote: > > Hi Tom, > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > Add an option to support this. > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > --- > > > > The discussion on this was not resolved and is now important due to the > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > this is a better starting point than building on OF_BOARD > > > > > > I really don't like adding another option for "DT is given to us". Why > > > isn't adding another enum to fdt_source_t sufficient > > > > That is added by this patch, but... > > > > >, and if we have > > > bloblist enabled, that will look for and use if found? > > > > ...this is the question. I would like to be able to enable bloblist > > without *requiring* the DT to come from there, hence the separate > > Kconfig option. > > > > > Maybe some other > > > code needs to be restructured and cleaned up too? > > > > Possibly, but I really am not keen on this board-specific solution. I > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > like adding another thing onto it. > > I think you're missing something then. It should not be board specific > to just find the dtb via bloblist, without a new CONFIG. Yes, that is what I am looking for. > Whatever is > stopping that is what needs to be refactored and then you can just > extend fdt_source_t without a new CONFIG option. OK, but I need a way to turn it off, at least for development. [merging in the other thread:] On Wed, Dec 27, 2023 at 8:11 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Dec 27, 2023 at 05:48:44PM +0000, Simon Glass wrote: > > Hi Ilias, > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > <ilias.apalodimas@linaro.org> wrote: > > > > > > Hi Tom, > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > Add an option to support this. > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > --- > > > > > The discussion on this was not resolved and is now important due to the > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > bloblist enabled, that will look for and use if found? Maybe some other > > > > code needs to be restructured and cleaned up too? > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > where it comes from. > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > many times I repeated the same proposal, but here it goes again. We > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > are scannable at runtime. Can't we use the combination of these 2 can > > > be used to imply we expect things from a bloblist. If we want to be > > > stricter in the future and explicitly expect the DT from a bloblist, > > > we could add a Kconfig option failing the boot if that's missing. > > > > I would like to have that Kconfig option now, not later. In my mind, > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > DT must come from there, or it is an error. > > Determinism doesn't require a CONFIG option, it just requires an if/else > tree where we say what the "correct" priority list should be and then > set a flag so that we can tell the user where we found it too. This also > means that we can get whatever is going to use this mechanism to > migrate over, and have less of a chicken-and-egg type of problem. OK I think I understand what is going on here. We need a way to enable OF_BLOBLIST while still allowing the prior stage to NOT provide a bloblist, at least for a transition period (= forever, I suspect, but that's another discussion). How about if OF_BLOBLIST enables the option, but we allow a fallback to OF_BOARD if the DT is not there? > > > Also, repeating it doesn't make the proposal good. We agreed that > > OF_BOARD would eventually go away, so building on top of it is not > > setting us up for the future. > > I wonder if OF_BOARD will ever go away, and I'm not convinced it will > either. Unless you just mean re-naming it and making a few ad-hoc > standards more easily re-usable, which also will need to happen > regardless. Regards, Simon
On Thu, Dec 28, 2023 at 01:37:39PM +0000, Simon Glass wrote: > Hi Tom, > > > On Wed, Dec 27, 2023 at 8:06 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Dec 27, 2023 at 05:48:42PM +0000, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > Add an option to support this. > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > --- > > > > > The discussion on this was not resolved and is now important due to the > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > isn't adding another enum to fdt_source_t sufficient > > > > > > That is added by this patch, but... > > > > > > >, and if we have > > > > bloblist enabled, that will look for and use if found? > > > > > > ...this is the question. I would like to be able to enable bloblist > > > without *requiring* the DT to come from there, hence the separate > > > Kconfig option. > > > > > > > Maybe some other > > > > code needs to be restructured and cleaned up too? > > > > > > Possibly, but I really am not keen on this board-specific solution. I > > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > > like adding another thing onto it. > > > > I think you're missing something then. It should not be board specific > > to just find the dtb via bloblist, without a new CONFIG. > > Yes, that is what I am looking for. > > > Whatever is > > stopping that is what needs to be refactored and then you can just > > extend fdt_source_t without a new CONFIG option. > > OK, but I need a way to turn it off, at least for development. > > [merging in the other thread:] > > On Wed, Dec 27, 2023 at 8:11 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Dec 27, 2023 at 05:48:44PM +0000, Simon Glass wrote: > > > Hi Ilias, > > > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > > <ilias.apalodimas@linaro.org> wrote: > > > > > > > > Hi Tom, > > > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > > Add an option to support this. > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > --- > > > > > > The discussion on this was not resolved and is now important due to the > > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > > bloblist enabled, that will look for and use if found? Maybe some other > > > > > code needs to be restructured and cleaned up too? > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > where it comes from. > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > many times I repeated the same proposal, but here it goes again. We > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > be used to imply we expect things from a bloblist. If we want to be > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > DT must come from there, or it is an error. > > > > Determinism doesn't require a CONFIG option, it just requires an if/else > > tree where we say what the "correct" priority list should be and then > > set a flag so that we can tell the user where we found it too. This also > > means that we can get whatever is going to use this mechanism to > > migrate over, and have less of a chicken-and-egg type of problem. > > OK I think I understand what is going on here. We need a way to enable > OF_BLOBLIST while still allowing the prior stage to NOT provide a > bloblist, at least for a transition period (= forever, I suspect, but > that's another discussion). > > How about if OF_BLOBLIST enables the option, but we allow a fallback > to OF_BOARD if the DT is not there? Oh, OK, so your use case is development. Why don't we just make OF_EMBEDDED be the first clause in the if/else (and yes, if (IS_ENABLED(CONFIG_OF_EMBEDDED) :)) and move on still not needing a knob for "bloblist has it"?
[...] > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > where it comes from. > > > > The story is identical to the EventLog. It's 'special' as well and > > U-Boot has to pick it up, otherwise the hardware and the EventLog will > > end up with different values > > Why are you talking about event log? Let's stick to the topic at hand. We are. The reason I bring this up is pretty obvious. It has identical properties to the DT, and I *dont* want a Kconfig option to enable or disable it. > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > many times I repeated the same proposal, but here it goes again. We > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > be used to imply we expect things from a bloblist. If we want to be > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > DT must come from there, or it is an error. > > > > And how is what I proposed not deterministic? What prevents us from > > adding that Kconfig option now? > > The only difference is that by default, U-Boot will try bloblist -> > > board-specific method unless a Kconfig option prevents the fallback. > > I've been working with vendors and helping them implement the firmware > > handoff spec in their proprietary bootloaders and Raymond contributed > > the implementation for TF-A. At the same time, I am pretty sure > > vendors will need time to implement this properly. I don't see how > > adding an implicit Kconfig option will help them push this forward. > > > > IOW I prefer U-Boot to *always* scan for a bloblist as the first > > discovery DT method (unless the DT comes bundled with U-Boot), rather > > than expecting users to turn a Kconfig knob. > > It is the 'unless the DT comes bundled with U-Boot' which I am talking > about, but I now have a better understanding of the problem here. > > I don't want CONFIG_BLOBLIST to mean that the DT comes from a > bloblist. But it doesn't mean that. It means 'try to scan the bloblist for a DT first'. > Simply put, I want to be able to use the U-Boot DT during > development, without needing to rebuild some prior stage or update > some other project. So I would like the use of bloblist to be behind > an OF_BLOBLIST option. That's easy instead of OF_BOARD use OF_EMBED or OF_SEPARATE? > > From Tom's email and your other reply, it seems that we could all live > with an OF_BLOBLIST option to enable DT-in-bloblist, making it > optional but default 'y'? > > > > > > > > > Also, repeating it doesn't make the proposal good. We agreed that > > > OF_BOARD would eventually go away, so building on top of it is not > > > setting us up for the future. > > > > No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going > > away. The only thing I suggested was to rename it > > Well I'm just not sure what is going on. Use of bloblist should not > require board-specific code. It should be a generic mechanism, in > fdtdec_setup() It doesn't, we never asked for that. There's even code in a previous iteration from me showing exactly what I had in mind. We always said scan for a bloblist if OF_BOARD is selected, in priority, and if you don't find a DT try a board-specific method (and add a Kconfig option to fail the boot if required). > > There are too many cooks in this kitchen right now, I'll try another > spin of my patch. I really don't like another OF_XXXXXXX for determining where the DT comes from, but I've explained my opinion way too many times. I'll let you and Tom decide on this Thanks /Ilias > > > > > [...] > > > > [0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsNTFqtbg@mail.gmail.com/ > > > > Regards, > Simon
Hi Ilias, On Thu, Dec 28, 2023 at 1:58 PM Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > [...] > > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > where it comes from. > > > > > > The story is identical to the EventLog. It's 'special' as well and > > > U-Boot has to pick it up, otherwise the hardware and the EventLog will > > > end up with different values > > > > Why are you talking about event log? Let's stick to the topic at hand. > > We are. The reason I bring this up is pretty obvious. It has identical > properties to the DT, and I *dont* want a Kconfig option to enable or > disable it. It is completely different to the devicetree. I don't even know how to respond to this, or what properties might be common between a devicetree and a TPL log. > > > > > > > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > > DT must come from there, or it is an error. > > > > > > And how is what I proposed not deterministic? What prevents us from > > > adding that Kconfig option now? > > > The only difference is that by default, U-Boot will try bloblist -> > > > board-specific method unless a Kconfig option prevents the fallback. > > > I've been working with vendors and helping them implement the firmware > > > handoff spec in their proprietary bootloaders and Raymond contributed > > > the implementation for TF-A. At the same time, I am pretty sure > > > vendors will need time to implement this properly. I don't see how > > > adding an implicit Kconfig option will help them push this forward. > > > > > > IOW I prefer U-Boot to *always* scan for a bloblist as the first > > > discovery DT method (unless the DT comes bundled with U-Boot), rather > > > than expecting users to turn a Kconfig knob. > > > > It is the 'unless the DT comes bundled with U-Boot' which I am talking > > about, but I now have a better understanding of the problem here. > > > > I don't want CONFIG_BLOBLIST to mean that the DT comes from a > > bloblist. > > But it doesn't mean that. It means 'try to scan the bloblist for a DT first'. I'm OK with that and it is how the v5 patch works. > > > Simply put, I want to be able to use the U-Boot DT during > > development, without needing to rebuild some prior stage or update > > some other project. So I would like the use of bloblist to be behind > > an OF_BLOBLIST option. > > That's easy instead of OF_BOARD use OF_EMBED or OF_SEPARATE? OF_EMBED doesn't help - things have moved on a lot from those days (e.g. Binman) OF_SEPARATE is already enabled > > > > > From Tom's email and your other reply, it seems that we could all live > > with an OF_BLOBLIST option to enable DT-in-bloblist, making it > > optional but default 'y'? > > > > > > > > > > > > > Also, repeating it doesn't make the proposal good. We agreed that > > > > OF_BOARD would eventually go away, so building on top of it is not > > > > setting us up for the future. > > > > > > No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going > > > away. The only thing I suggested was to rename it > > > > Well I'm just not sure what is going on. Use of bloblist should not > > require board-specific code. It should be a generic mechanism, in > > fdtdec_setup() > > It doesn't, we never asked for that. There's even code in a previous > iteration from me showing exactly what I had in mind. We always said > scan for a bloblist if OF_BOARD is selected, in priority, and if you > don't find a DT try a board-specific method (and add a Kconfig option > to fail the boot if required). > > > > > There are too many cooks in this kitchen right now, I'll try another > > spin of my patch. > > I really don't like another OF_XXXXXXX for determining where the DT > comes from, but I've explained my opinion way too many times. I'll > let you and Tom decide on this I sent a v5 patch which I believe provides what we both want, so PTAL. [..] > > > [0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsNTFqtbg@mail.gmail.com/ Regards, Simon
Hi Tom, On Thu, Dec 28, 2023 at 1:48 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 28, 2023 at 01:37:39PM +0000, Simon Glass wrote: > > Hi Tom, > > > > > > On Wed, Dec 27, 2023 at 8:06 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Dec 27, 2023 at 05:48:42PM +0000, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > > Add an option to support this. > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > --- > > > > > > The discussion on this was not resolved and is now important due to the > > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > isn't adding another enum to fdt_source_t sufficient > > > > > > > > That is added by this patch, but... > > > > > > > > >, and if we have > > > > > bloblist enabled, that will look for and use if found? > > > > > > > > ...this is the question. I would like to be able to enable bloblist > > > > without *requiring* the DT to come from there, hence the separate > > > > Kconfig option. > > > > > > > > > Maybe some other > > > > > code needs to be restructured and cleaned up too? > > > > > > > > Possibly, but I really am not keen on this board-specific solution. I > > > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > > > like adding another thing onto it. > > > > > > I think you're missing something then. It should not be board specific > > > to just find the dtb via bloblist, without a new CONFIG. > > > > Yes, that is what I am looking for. > > > > > Whatever is > > > stopping that is what needs to be refactored and then you can just > > > extend fdt_source_t without a new CONFIG option. > > > > OK, but I need a way to turn it off, at least for development. > > > > [merging in the other thread:] > > > > On Wed, Dec 27, 2023 at 8:11 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Dec 27, 2023 at 05:48:44PM +0000, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > > > <ilias.apalodimas@linaro.org> wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > > > Add an option to support this. > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > --- > > > > > > > The discussion on this was not resolved and is now important due to the > > > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > > > bloblist enabled, that will look for and use if found? Maybe some other > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > where it comes from. > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > > DT must come from there, or it is an error. > > > > > > Determinism doesn't require a CONFIG option, it just requires an if/else > > > tree where we say what the "correct" priority list should be and then > > > set a flag so that we can tell the user where we found it too. This also > > > means that we can get whatever is going to use this mechanism to > > > migrate over, and have less of a chicken-and-egg type of problem. > > > > OK I think I understand what is going on here. We need a way to enable > > OF_BLOBLIST while still allowing the prior stage to NOT provide a > > bloblist, at least for a transition period (= forever, I suspect, but > > that's another discussion). > > > > How about if OF_BLOBLIST enables the option, but we allow a fallback > > to OF_BOARD if the DT is not there? > > Oh, OK, so your use case is development. Why don't we just make > OF_EMBEDDED be the first clause in the if/else (and yes, if > (IS_ENABLED(CONFIG_OF_EMBEDDED) :)) and move on still not needing a knob > for "bloblist has it"? Because OF_EMBED doesn't work with binman, and takes a lot of different code paths, etc. It is somewhat useful when loading U-Boot using a debugger, but that is about it. I sent a v5 that I hope does what is needed. Regards, Simon
On Thu, Dec 28, 2023 at 03:09:45PM +0000, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 1:48 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 28, 2023 at 01:37:39PM +0000, Simon Glass wrote: > > > Hi Tom, > > > > > > > > > On Wed, Dec 27, 2023 at 8:06 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Dec 27, 2023 at 05:48:42PM +0000, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > > > Add an option to support this. > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > --- > > > > > > > The discussion on this was not resolved and is now important due to the > > > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > > isn't adding another enum to fdt_source_t sufficient > > > > > > > > > > That is added by this patch, but... > > > > > > > > > > >, and if we have > > > > > > bloblist enabled, that will look for and use if found? > > > > > > > > > > ...this is the question. I would like to be able to enable bloblist > > > > > without *requiring* the DT to come from there, hence the separate > > > > > Kconfig option. > > > > > > > > > > > Maybe some other > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > Possibly, but I really am not keen on this board-specific solution. I > > > > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > > > > like adding another thing onto it. > > > > > > > > I think you're missing something then. It should not be board specific > > > > to just find the dtb via bloblist, without a new CONFIG. > > > > > > Yes, that is what I am looking for. > > > > > > > Whatever is > > > > stopping that is what needs to be refactored and then you can just > > > > extend fdt_source_t without a new CONFIG option. > > > > > > OK, but I need a way to turn it off, at least for development. > > > > > > [merging in the other thread:] > > > > > > On Wed, Dec 27, 2023 at 8:11 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Wed, Dec 27, 2023 at 05:48:44PM +0000, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > > > > <ilias.apalodimas@linaro.org> wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +0000, Simon Glass wrote: > > > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one firmware > > > > > > > > phase to the next. That can be used to pass the devicetree along as well. > > > > > > > > Add an option to support this. > > > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > > --- > > > > > > > > The discussion on this was not resolved and is now important due to the > > > > > > > > bloblist series from Raymond. So I am sending it again since I believe > > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > > > > bloblist enabled, that will look for and use if found? Maybe some other > > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > > where it comes from. > > > > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > > > DT must come from there, or it is an error. > > > > > > > > Determinism doesn't require a CONFIG option, it just requires an if/else > > > > tree where we say what the "correct" priority list should be and then > > > > set a flag so that we can tell the user where we found it too. This also > > > > means that we can get whatever is going to use this mechanism to > > > > migrate over, and have less of a chicken-and-egg type of problem. > > > > > > OK I think I understand what is going on here. We need a way to enable > > > OF_BLOBLIST while still allowing the prior stage to NOT provide a > > > bloblist, at least for a transition period (= forever, I suspect, but > > > that's another discussion). > > > > > > How about if OF_BLOBLIST enables the option, but we allow a fallback > > > to OF_BOARD if the DT is not there? > > > > Oh, OK, so your use case is development. Why don't we just make > > OF_EMBEDDED be the first clause in the if/else (and yes, if > > (IS_ENABLED(CONFIG_OF_EMBEDDED) :)) and move on still not needing a knob > > for "bloblist has it"? > > Because OF_EMBED doesn't work with binman, and takes a lot of > different code paths, etc. It is somewhat useful when loading U-Boot > using a debugger, but that is about it. > > I sent a v5 that I hope does what is needed. It sounds like binman needs to be fixed to just handle the case of not needing to do something with the device tree, since it's already embedded? I'll look again at v5, but since you sent it out while we were still talking about v4 and only just now understanding what your use case is, I don't think it's right, still. As you've said your use case is development and needing to ensure you get the device tree you want (because you're modifying it), and OF_EMBED is supposed to be used only for that exact use case, that's how we should solve this problem.
diff --git a/common/bloblist.c b/common/bloblist.c index a22f6c12b0c..b07ede11cfe 100644 --- a/common/bloblist.c +++ b/common/bloblist.c @@ -48,6 +48,7 @@ static struct tag_name { { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" }, { BLOBLISTT_SMBIOS_TABLES, "SMBIOS tables for x86" }, { BLOBLISTT_VBOOT_CTX, "Chrome OS vboot context" }, + { BLOBLISTT_CONTROL_FDT, "Control FDT" }, /* BLOBLISTT_PROJECT_AREA */ { BLOBLISTT_U_BOOT_SPL_HANDOFF, "SPL hand-off" }, diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index cbb65c9b177..56e00090166 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -108,6 +108,9 @@ If CONFIG_OF_BOARD is defined, a board-specific routine will provide the devicetree at runtime, for example if an earlier bootloader stage creates it and passes it to U-Boot. +If CONFIG_OF_BLOBLIST is defined, the devicetree comes from a bloblist passed +from a previous stage. + If CONFIG_SANDBOX is defined, then it will be read from a file on startup. Use the -d flag to U-Boot to specify the file to read, -D for the default and -T for the test devicetree, used to run sandbox unit tests. diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..2d02bccf4fc 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -105,6 +105,14 @@ config OF_EMBED endchoice +config OF_BLOBLIST + bool "DTB is provided by a bloblist" + help + Select this to read the devicetree from the bloblist. This allows + using a bloblist to transfer the devicetree between U-Boot phases. + The devicetree is stored in the bloblist by an early phase so that + U-Boot can read it. + config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" default y if SANDBOX || OF_HAS_PRIOR_STAGE diff --git a/include/bloblist.h b/include/bloblist.h index 080cc46a126..e16d122f4fb 100644 --- a/include/bloblist.h +++ b/include/bloblist.h @@ -103,6 +103,11 @@ enum bloblist_tag_t { BLOBLISTT_ACPI_TABLES = 0x104, /* ACPI tables for x86 */ BLOBLISTT_SMBIOS_TABLES = 0x105, /* SMBIOS tables for x86 */ BLOBLISTT_VBOOT_CTX = 0x106, /* Chromium OS verified boot context */ + /* + * Devicetree for use by firmware. On some platforms this is passed to + * the OS also + */ + BLOBLISTT_CONTROL_FDT = 0x107, /* * Project-specific tags are permitted here. Projects can be open source diff --git a/include/fdtdec.h b/include/fdtdec.h index bd1149f46d0..1888c464561 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -72,7 +72,7 @@ struct bd_info; * U-Boot is packaged as an ELF file, e.g. for debugging purposes * @FDTSRC_ENV: Provided by the fdtcontroladdr environment variable. This should * be used for debugging/development only - * @FDTSRC_NONE: No devicetree at all + * @FDTSRC_BLOBLIST: Provided by a bloblist from an earlier phase */ enum fdt_source_t { FDTSRC_SEPARATE, @@ -80,6 +80,7 @@ enum fdt_source_t { FDTSRC_BOARD, FDTSRC_EMBED, FDTSRC_ENV, + FDTSRC_BLOBLIST, }; /* diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 4016bf3c113..6bd4a0c03a4 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -7,6 +7,10 @@ */ #ifndef USE_HOSTCC + +#define LOG_CATEGORY LOGC_DT + +#include <bloblist.h> #include <boot_fit.h> #include <display_options.h> #include <dm.h> @@ -86,6 +90,7 @@ static const char *const fdt_src_name[] = { [FDTSRC_BOARD] = "board", [FDTSRC_EMBED] = "embed", [FDTSRC_ENV] = "env", + [FDTSRC_BLOBLIST] = "bloblist", }; const char *fdtdec_get_srcname(void) @@ -1665,20 +1670,35 @@ int fdtdec_setup(void) int ret; /* The devicetree is typically appended to U-Boot */ - if (IS_ENABLED(CONFIG_OF_SEPARATE)) { - gd->fdt_blob = fdt_find_separate(); - gd->fdt_src = FDTSRC_SEPARATE; - } else { /* embed dtb in ELF file for testing / development */ - gd->fdt_blob = dtb_dt_embedded(); - gd->fdt_src = FDTSRC_EMBED; - } - - /* Allow the board to override the fdt address. */ - if (IS_ENABLED(CONFIG_OF_BOARD)) { - gd->fdt_blob = board_fdt_blob_setup(&ret); + if (CONFIG_IS_ENABLED(OF_BLOBLIST)) { + ret = bloblist_maybe_init(); if (ret) return ret; - gd->fdt_src = FDTSRC_BOARD; + gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0); + if (!gd->fdt_blob) { + printf("Not FDT found in bloblist\n"); + bloblist_show_list(); + return -ENOENT; + } + gd->fdt_src = FDTSRC_BLOBLIST; + bloblist_show_list(); + log_debug("Devicetree is in bloblist at %p\n", gd->fdt_blob); + } else { + if (IS_ENABLED(CONFIG_OF_SEPARATE)) { + gd->fdt_blob = fdt_find_separate(); + gd->fdt_src = FDTSRC_SEPARATE; + } else { /* embed dtb in ELF file for testing / development */ + gd->fdt_blob = dtb_dt_embedded(); + gd->fdt_src = FDTSRC_EMBED; + } + + /* Allow the board to override the fdt address. */ + if (IS_ENABLED(CONFIG_OF_BOARD)) { + gd->fdt_blob = board_fdt_blob_setup(&ret); + if (ret) + return ret; + gd->fdt_src = FDTSRC_BOARD; + } } /* Allow the early environment to override the fdt address */
Standard passage provides for a bloblist to be passed from one firmware phase to the next. That can be used to pass the devicetree along as well. Add an option to support this. Tests for this will be added as part of the Universal Payload work. Signed-off-by: Simon Glass <sjg@chromium.org> --- The discussion on this was not resolved and is now important due to the bloblist series from Raymond. So I am sending it again since I believe this is a better starting point than building on OF_BOARD Changes in v4: - Rebase to -next common/bloblist.c | 1 + doc/develop/devicetree/control.rst | 3 ++ dts/Kconfig | 8 ++++++ include/bloblist.h | 5 ++++ include/fdtdec.h | 3 +- lib/fdtdec.c | 44 ++++++++++++++++++++++-------- 6 files changed, 51 insertions(+), 13 deletions(-)