[PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Mon, 10 Feb 2025 at 09:25, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Simon,
>
> On 2/9/25 3:28 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.schulz at 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+dt at 0leil.net> wrote:
> >>>>
> >>>> From: Quentin Schulz <quentin.schulz at 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.schulz at 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 at 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'm not sure to understand where the confusion is wrt "what we are
> defining here"? Can you please clarify?
>
> Used by whatever and whoever wants to have some specific logic based on
> which medium the DUT was booted from, e.g. software updaters, distros or
> CI tools (labgrid in my case)? If your software is assuming the DUT is
> booted from eMMC while it is actually from SPI, you may think you're
> updating (including security fixes) the SW while you're not.

So for example, VBE includes a node which tells you which device is
used for firmware updates. If VBE is used, does it supercede this
setting?

>
> Throwing ideas right now, but this could also probably be used by
> fastboot/DFU to know which medium (e.g. MMC, SPI) to update by default
> instead of using one that defaults from the env/bin. I have no
> experience with either so maybe that's misleading.

What are you planning to use this for? Can we scope it to that, initially?

>
> > 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.
> >
>
> There is no such "full Device Tree support day one", especially for new
> arm SoCs. We still do not have USB-C support on Radxa Rock-5B (it's on
> the way but still), the introducing commit was made more than two years
> ago already. I don't understand what's being suggested here.

You mentioned that we have to use a string because it might refer to a
node not in the devicetree, e.g. we booted from USB but there is no
USB node in the devicetree. My suggestion would be to add that node,
even if it is empty.

>
> > 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
>
> Informative?

OK, but this is really what I'm getting at. You must be adding this
for a reason, perhaps many. So please can you list the actual uses
your software will make, with this value in place?

>
> > 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.
> >
>
> That's fair.
>
> > 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.
> >
>
> If you don't use the same DT for U-Boot and the kernel (which is the
> case for all Rockchip-based devices as far as I know), a label may be an
> issue, especially if you don't keep the symbols in the DTB. Because then
> you need to guarantee that label X in U-Boot matching node Y in U-Boot
> also matches node Y in the kernel and not node Z, so you need some kind
> of hardcoding/mapping somewhere in U-Boot.

Wouldn't you set it correctly when you update the /chosen node? There
is no sense in putting this property in either the U-Boot or Linux
devicetree. It needs to be added to the Linux devicetree, in the FDT
fix-ups, just before booting LInux, like we do with other things in
the /chosen node.

>
> > 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?
> >
>
> @Ahmad, any piece of history you'd like to share here maybe?
>
> What I can say from glancing at the code is that for Rockchip they do
> the following:
>
> Register a bootsource type (e.g. MMC, SPI, I2C, USB, etc...), a
> bootsource instance of that type (e.g. MMC0, SPI3, I2C7, ...). The
> mapping between what the ROM says the device is vs what it is in the DT
> is done in their Barebox-specific DT via this custom prop in /chosen:
>
> barebox,bootsource-<bootsourcetype><bootsourceinstance> = &label;  #
> à-la /aliases
>
> This gets read and resolved and then inserted as
>
> /chosen/bootsource = "/some/path"
>
> into the kernel DT.
>
> > 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.
> >
>
> I'm not sure what classifies as a rule in what I suggested, could you
> elaborate on that maybe?

Let's get the info on what you are actually going to use this (you, or
your company).

But overall, I don't really have a strong opinion on whether this
should be a string or a phandle. If we consistently used phandles
today, I would want that, but we don't, so it seems that ship has
sailed.

Regards,
Simon