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. > > 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. 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? > > 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. That definitely makes sense too.
