[PATCH v2 1/1] spl: allow loading via partition type GUID
mark.kettenis at xs4all.nl
Fri Feb 17 11:34:07 CET 2023
> 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
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
More information about the U-Boot