On 2/19/23 20:52, Mark Kettenis wrote:
Date: Fri, 17 Feb 2023 12:06:40 +0100 From: Heinrich Schuchardt heinrich.schuchardt@canonical.com
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
Interesting idea. However, if you rely on the SoC bootrom to boot from a partition with a specific GUID, you probably can't have separate SPL partitions for each board; you'd just have one for each SoC. And that in turn means that you can't really have a separate U-Boot partition for each board unless you have board-detection code in SPL. But in that case you'd probably be better off with putting that board detection code in U-Boot itself and bundle U-Boot together with the supported board device trees in a FIT.
You are right in that GUID based SPL selection and board detection code will probably have to be combined. For the same SoC selecting a board specific device-tree may work in many cases.
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.
Well, that makes it hard to "recycle" disks that have been partitioned before. Partition tools will have the ability to delete partitions to make that possible. In that case it is useful for users to be able to determine the purpose of a partition.
By the way, you probably should set Bit 0 in the partition table entry Attributes field for these partitions to indicate that a partition should not be deleted.
It was you who suggested to hard code a GUID for firmware that would get special treatment. My suggestion is simply that that special treatment can be given to all unknown GUIDs.
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