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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

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

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

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