[PATCH] Add 'bootsource' /chosen property

Thu Feb 20 16:54:55 CET 2025

On 2/20/25 4:22 PM, Daniel Golle wrote:
> On Thu, Feb 20, 2025 at 04:04:27PM +0100, Quentin Schulz wrote:
>> Hi Daniel,
>>
>> On 2/15/25 4:13 PM, Daniel Golle wrote:
>>> Hi Quentin,
>>>
>>> On 10 February 2025 16:25:23 UTC, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>>>> [...]
>>>> 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.
>>>
>>> We are doing something quite similar downsream at openwrt.org for MediaTek router SoCs, see for example:
>>>
>>> https://github.com/openwrt/openwrt/blob/main/package/boot/uboot-mediatek/patches/310-mt7988-select-rootdisk.patch
>>>
>>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4.dtsi#L32
>>>
>>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/files-6.6/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-emmc.dtso#L60
>>>
>>>
>>> Of course we could use the standard "bootsource" property instead, but having a way to reference the volume or partition used as rootfs instead of just passing a referencd to a physical device is advantagous...
>>>
>>
>> If I understood correctly, your prebuilt DT would have
>>
>> / {
>>      chosen {
>>          rootdisk-emmc = <&rootfs_in_emmc>;
>>          rootdisk-nor = <&rootfs_in_nor>;
>>          rootdisk-sd = <&rootfs_in_sd>;
>>          rootdisk-spim-nand = <&rootfs_in_ubi>;
>>      };
>> };
>>
>> and then at runtime you would populate /chosen/rootdisk property with the
>> "rootdisk-<medium>" string with <medium> matching whatever the BootROM
>> reports. I assume the goal is to somehow make sure that the rootfs is loaded
>> from the same storage medium as the one used by the BootROM to load the
>> first stage bootloader?
>>
>> Can you confirm I did get that right?
> 
> Yes, that's more or less correct. It's to point Linux to the device or
> partition of the uImage from which U-Boot has loaded the Linux kernel.
> 
> Note that for OpenWrt we prefer to store the uImage.FIT inside a raw
> block or flash partition, or UBI volume, rather than as a file inside a
> filesystem.
> 
> This information is then used for two things:
> 
>   - Mount the root filesystem
>     We use a read-only squashfs which is part of the uImage.FIT, it essentially
>     has the same purpose of an initramfs on other distributions, but mounting
>     squashfs is much faster then decompressing the whole initramfs at once, and
>     it doesn't need to remain in RAM permanently.
> 
>   - Know where an updated uImage.FIT should be written to.
> 

OK, so everything in a FIT image and you store the location and storage 
medium where it was loaded from so that you can update it. Makes sense.

I guess we could have bootstd/bootmeths populate another property that 
specifies which medium and partition was used to load the kernel/FDT and 
initramfs. I don't have much experience with that aside from 
extlinux.conf and that wouldn't be appropriate I believe especially if 
you used root=PARTLABEL= or a UUID in your kernel command line as there 
could be multiple ones with the same there (e.g. we have the exact same 
image you can flash on SD card and eMMC and the probe order isn't 
deterministic in the kernel I believe).

Don't want to get sidetracked too far though, I don't think it is 
incompatible with or related to /chosen/bootsource usage?

>>
>> I was specifically NOT aiming /chosen/bootsource to represent the storage
>> medium used to load the kernel or rootfs, but rather the medium that was
>> used by the BootROM to load the first stage of the bootloader that is
>> user-flashable/uploadable.
>>
>> You could very well decide to load/mount your rootfs from SD even if the
>> BootROM loaded the first stage bootloader from SPI-NOR. This property is
>> about representing the latter, not the former and not merging the meaning of
>> both into one.
> 
> Of course, especially for general purpose Linux which would not fit into
> NOR flash that's the only option.
> 
> In case of OpenWrt we usually do want to load kernel (and rootfs) from
> the same device also used by the BootROM for booting. OpenWrt can easily
> fit onto 16 MiB of NOR flash, including bootloader, EEPROM for MAC
> addresses and WiFi calibration as well as some megabytes for user data.
> 

We (Cherry/Theobroma) have some modified behavior for bootstd to favor 
booting from the same storage medium as U-Boot proper (so NOT 
necessarily what is reported by /chosen/bootsource) instead of 
defaulting to boot from SD card first and then eMMC. See 
https://elixir.bootlin.com/u-boot/v2025.01/source/board/theobroma-systems/common/common.c#L11. 
So I very much understand your usecase :)

FYI, U-Boot SPL favors for loading U-Boot proper the same storage medium 
as was used by the BootROM (so that would be the same as reported by 
/chosen/bootsource here!) and this is modeled with the "same-as-spl" 
string in /chosen/u-boot,spl-boot-order property. I was thinking of 
adding a "same-as-proper" boot target for bootstd so I can remove my 
custom setup_boottargets. This was also somehow asked by at least one 
person over IRC some months ago, so maybe I'm not the only one with this 
usecase :) Haven't spent time looking into it and I may never have time 
to do so, take this as a brain dump here :)

> To satisfy both needs, I reckon we would need to formally introduce an
> OpenWrt boot-method to U-Boot, and then U-Boot could leave a mark in
> /chosen where the uImage.FIT was loaded from, independently of the
> BootROM which may differ?
> 

Yes, I don't think both could or should be represented by the same property.

To sum up, specifically for U-Boot:

BootROM loading VPL/TPL/SPL -> /chosen/bootsource (what this patch is 
suggesting)
VPL loading SPL -> don't know, haven't checked the VBE series yet :( 
maybe Simon has something in mind?
SPL loading U-Boot proper -> /chosen/u-boot,spl-boot-device
U-Boot proper loading kernel/fit/... -> nothing at the moment

Forgot to thank you for sharing what OpenWRT does :)

Cheers,
Quentin