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