[PATCH] Add 'bootsource' /chosen property

[Simon Glass]

Hi Quentin,

On Thu, 20 Feb 2025 at 08:55, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> 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 :)

Thanks for all the details. It seems fine to me. Perhaps you could
copy some of the text above into your binding so there is more detail?

Regards,
Simon