Hi Simon,
On 2/6/25 1:33 PM, Simon Glass wrote:
Hi Quentin,
On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss+dt@xxxxxxxxx> wrote:
From: Quentin Schulz <quentin.schulz@xxxxxxxxx>
Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...
This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).
It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.
This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.
Signed-off-by: Quentin Schulz <quentin.schulz@xxxxxxxxx>
---
Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...
This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).
It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.
This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.
Note that this property is already set by Barebox and I'm planning on
adding it to U-Boot as well, specifically for Rockchip SoCs.
I have some doubts about the wording, especially in the case of
hypervisors or chained boot programs. I'm not entirely sure what would
make the most sense to put in the property for those scenario.
---
source/chapter3-devicenodes.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -456,6 +456,9 @@ time. It shall be a child of the root node.
the client program. The value could
potentially be a null string if no boot
arguments are required.
+ ``bootsource`` O ``<string>`` A string that specifies the full path to the
+ node representing the device the BootROM used
+ to load the initial boot program.
Could/shoud this be a phandle instead? It might be more efficient.
In terms of size in DTB, phandle vs string probably much more efficient yes.
From user's perspective, I'm not too sure?
/aliases does use full paths for example.
Having a full path allows for easy consumption, just cat
/proc/device-tree/chosen/bootsource and you'll have the actual path.
Otherwise, we'd need a special tool for that I guess since it'll return
the phandle number and then you have to traverse the tree to find which
node has that phandle number?
Also, I could imagine some scenario where:
- a boot source would not be available in DT yet (though we probably
shouldn't write it in /chosen/bootsource since we wouldn't know the
proper path to it), e.g. USB loading, this is usually done via a
proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
Rockchip) but no USB support yet in boot program or kernel (that was the
case for a long time for RK3588 for example and I still have at least
one device without the USB node described yet).
- a boot source would be available in EL3 but not EL2, so does not make
necessarily make sense to have it in kernel DTB for example. If it's not
there, can't have a phandle.
- a boot source supported only in boot program's DTB and not kernel's
DTB, we probably still want to provide it to kernel's DTB even if it's
not a device node in it.
- a boot source doesn't necessarily have a label (though we could use a
full-path phandle I believe &{/some/path@1f000} probably works). That is
not uncommon for SPI flashes for example.
And additional argument for full-path: Barebox already uses that.
Cheers,
Quentin
