On 2/17/23 11:34, Mark Kettenis wrote:
Date: Fri, 17 Feb 2023 07:55:58 +0100
From: Heinrich Schuchardt <heinrich.schucha...@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
