Re: [PATCH v2 1/1] spl: allow loading via partition type GUID

[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

>>> 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
>>