On 2/17/23 11:34, Mark Kettenis wrote:
Date: Fri, 17 Feb 2023 07:55:58 +0100 From: Heinrich Schuchardt heinrich.schuchardt@canonical.com
I'm not sure, but at some point this is all going to get out of hand. Already we have these options:
common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION common/spl/Kconfig:config SYS_MMCSD_FS_BOOT_PARTITION common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_KERNEL_SECTOR common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_ARGS_SECTOR common/spl/Kconfig:config SYS_MMCSD_RAW_MODE_ARGS_SECTORS
That is just for MMC raw mode.
For environment we have SYS_MMC_ENV_DEV and _PART. If you look around you'll see loads of these options.
I see that rockchip uses u-boot,spl-boot-order as a way to determine the boot order. This makes it configurable without rebuilding U-Boot...although I don't think we need to make the MMC stuff configurable, since I am assuming that the boot ROM determines at least some of it...?
This patch is about SPL loading main U-Boot. So the boot ROM is not involved.
But in that case we surely want to have a single board and SoC independent partition GUID?
No. I want to create one installation image which runs on multiple boards, e.g.
part 1, GUID 8300, /boot part 2, GUID 8300, / part 15, GUID EF00, /boot/efi part 20, GUID SPL 1, SPL for board 1 part 21, GUID U-Boot 2, U-Boot for board 1 ... part 127, GUID SPL 54, SPL for board 54 part 128, GUID U-Boot 54, U-Boot for board 54
It seems that the whole thing is crying out for a bit of organisation and a proper schema.
The discussion was about hard-coding the values vs configuration.
OS distributions should have enough flexibility to deliver an installation image with U-Boot for multiple boards on the same medium. For the build process it is preferable to use different configurations instead of patching source code per U-Boot which might be required if hard-coded values for partition GUIDs in the device-trees are used.
Well, yes, but it would be even more helpful to have a single well-known partition GUID such that the OS partitioning tools can recognize the U-Boot partition. If you make it configurable and every contributed board uses a different GUID that will be impractical.
The OS partitioning tools simply shouldn't touch partitions with GUIDs that they don't know.
Best regards
Heinrich
I think Tom's approach is right. The U-Boot documentation should give guidance on how new boards should find U-Boot SPL and main U-Boot.
Best regards
Heinrich