On Mon, May 05, 2025 at 05:34:22PM +0200, Quentin Schulz wrote: > From: Quentin Schulz <[email protected]> > > 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. > > In cases where a boot program is split into multiple stages (like > U-Boot), it only represents the device that was used to load the very > first stage (in case of U-Boot, VPL/TPL/SPL whichever is executed first) > and not any of the later stages (in case of U-Boot, TPL/SPL/proper) or > any client program. They may match, but they may not and this property > is meant to only represent the device used for loading the very first > stage. > > I have a board running U-Boot which currently has 9 boot scenarios > (eMMC/SD/SPI-NOR for the first stage, eMMC/SD/SPI-NOR for the next > stages; not counting USB loading yet, which would make it a few more). I > cannot force the BootROM of this board to select a specific device aside > from erasing the other media. > The only way to identify which device was used for the first stage is to > parse U-Boot first stage console output or add some custom logic for my > board. To validate that a new version of the bootloader works, including > the fallback mechanisms, I need to make sure the BootROM loads the first > stage from the expected device otherwise I may have false positives. > This would be useful for automated testing. > > I could also very well see this being used to identify where the first > stage of the boot program is stored (which may differ from where the > later stages are! that's the case for U-Boot proper for example!) to be > able to update it from a client program. > > Note that Barebox has been using this property for a while already, with > this very content[1]. > > This is chosen as a string so that it matches other properties in > /chosen (e.g. stdout-path) as well as allows for extending it, in case > one needs to provide additional information (e.g. HW boot partition for > eMMC, a specific disk on an AHCI controller, a specific USB device on > a USB bus, etc.). > > [1] > https://lore.kernel.org/u-boot/[email protected]/ > > Signed-off-by: Quentin Schulz <[email protected]> > --- > 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. > --- > Changes in v2: > - added usecases, non-usecases and increased verbosity of the definition > of the property name as requested by Simon, > - Link to v1: > https://lore.kernel.org/r/[email protected] > --- > source/chapter3-devicenodes.rst | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+)
Applied, thanks. Rob
