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. > ``stdout-path`` O ``<string>`` A string that specifies the full path to the > node representing the device to be used for > boot console output. If the character ":" is > > --- > base-commit: 5688e1c0b961d2ca5a32e3b624a9f4a9b433184f > change-id: 20250205-bootsource-84df255e9e6c > > Best regards, > -- > Quentin Schulz <quentin.schulz@xxxxxxxxx> > > Regards, SImon
