[RFC] Adding bootsource and reset-source* to /chosen

[Quentin Schulz]

Hi all,

In U-Boot, there are multiple stages which can be loaded from different 
media each. On Rockchip SoCs, it mostly goes this way, SoC BootROM loads 
from a medium (storage or over USB) and executes the TPL (or SPL if no 
TPL supported), the TPL goes back to BootROM and reads the SPL from the 
same medium and executes it. The SPL will favor the same medium for 
loading the U-Boot FIT image (containing TF-A BL31, OP-TEE OS BL32 and 
U-Boot proper image), but in case it fails, falls back to other possible 
media. In U-Boot we have the storage medium used for loading the U-Boot 
FIT image stored in the DTB under /chosen/u-boot,spl-boot-device 
property. But we do not have a property for the medium the BootROM 
loaded the TPL (or SPL) from. This could be useful information. For 
example, I have some CI where I want to check whether the BootROM loaded 
the TPL from the expected location (important when checking that they 
all work and don't depend on a bootloader flashed in a fallback medium 
for example). Another usecase could be to detect whenever one loads the 
TPL from USB (not a USB stick, some USB transfer; see rockusb for 
Rockchip for example) and decide to do something else in U-Boot or the 
OS depending on that (could be starting DFU for flashing the device, or 
fastboot for loading the rest of the system).

Barebox currently does that by setting /chosen/bootsource to the full 
path of the device the BootROM says it booted from, but that isn't part 
of the DT spec so before I add support in U-Boot for that, I'm asking 
whether that's fine or if we should correct course in Barebox and use 
another name and/or location.

I've also been made aware of other "sources" that are added to the 
/chosen node in Barebox, reset-source, reset-source-instance and 
reset-source-device. I am not entirely sure what those exactly are for 
BUT it seems that this is of interest to U-Boot as well since we do try 
to report a reset cause as read from the CPU for Rockchip SoCs, c.f. 
https://elixir.bootlin.com/u-boot/v2024.10/source/arch/arm/mach-rockchip/cpu-info.c#L14. 
I believe /chosen/reset-source would be the reason, e.g. "POR", "RST", 
"WDG", "WKE", "THERM", etc. /chosen/reset-source-device contains the 
node path to the device that triggered that, that could be useful in the 
event there are more than one thermal trip point (e.g. CPU or GPU), or 
more than one hardware watchdog (I for example have a system with 
potentially 4: SoC, PMIC, 2 separate in an external MCU). I guess 
/chosen/reset-source-instance is for HW blocks that expose the same 
reset but from two different sources which aren't modeled in Device 
Tree. Again, this would be useful for the bootloader or OS to decide to 
do something else based on the reset cause (e.g. have data on why some 
devices reboot in the field, e.g. because of thermals, power loss, 
brownout, etc..).

I'm reaching out to the devicetree-spec community before I add code in 
U-Boot to implement this so we don't add unnecessary backward 
compatibility code, were the properties or locations to be modified to 
match the spec.

Does anyone disagree with adding this to the spec? Does anyone have 
another suggestion for the naming or location of the properties?

Would you prefer a patch to the spec and discuss "code" directly there?

Cheers,
Quentin