Hi Quentin, On Thu, 20 Feb 2025 at 08:55, Quentin Schulz <quentin.sch...@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.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 :)
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
