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

[Mark Kettenis]

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

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

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