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

[Heinrich Schuchardt]

On 2/19/23 20:52, Mark Kettenis wrote:
>> Date: Fri, 17 Feb 2023 12:06:40 +0100
>> From: Heinrich Schuchardt <heinrich.schuchardt at 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 at 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
>>>>
>>
>>