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+jsN...
Regards, Simon