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.sch...@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
