Hi Quentin,
On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.sch...@cherry.de> wrote:
>
> 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...@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.
> >
>
> 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.
Well I'm not sure what we are defining here and which programs will use it.
I don't really like the idea of mentioning a boot source that is not
in the device tree. In fact that's one reason why I believe it is
better to use a phandle, since it enforces that. The RK3588 things you
mention sound like things the vendor should fix from day one, if it
matters.
If the boot-source device is not in the 'kernel' DTB, then why have
the boot source there? What use could it be? This seems like having an
alias to something that doesn't exist in the tree. But it could also
be used to just have "my-silly-device" as the value, with a magic
meaning which no one can figure out.
Re not having a label, we can add one. Yes, fdtdump does not have the
schema and doesn't decode phandles, although I suppose we could teach
it some basic things, or add a new tool.
So overall, this seems like a balance between short-term convenience
and long-term confusion.
To me, the strongest argument for paths is that /aliases uses full
paths rather the phandles. I believe that was a mistake (it caused
problems in SPL as it bloats the DT), but I've not looked at what it
would take to change it now.
>
> And additional argument for full-path: Barebox already uses that.
Were there discussions with that, which could be used here?
Anyway, if this is the way you want to go, I think it would be useful
to add some of your notes above into the binding, so there are some
rules around it.
Regards,
Simon
