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?
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.
However, I could see a BootROM being able to report from which partition
and controller it loaded the first stage bootloader, and then it'd make
sense to have that in /chosen, either as part of /chosen/bootsource or
an additional property like /chosen/bootsource-partition.
Cheers,
Quentin
