Hi Quentin, On Wed, 5 Feb 2025 at 02:12, Quentin Schulz <foss...@0leil.net> wrote: > > From: Quentin Schulz <quentin.sch...@cherry.de> > > 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.sch...@cherry.de> > --- > 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.sch...@cherry.de> > > Regards, SImon
