> Date: Fri, 17 Feb 2023 07:55:58 +0100 > From: Heinrich Schuchardt <heinrich.schucha...@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 >