On 2/19/23 20:52, Mark Kettenis wrote:
Date: Fri, 17 Feb 2023 12:06:40 +0100
From: Heinrich Schuchardt <[email protected]>
On 2/17/23 11:34, Mark Kettenis wrote:
Date: Fri, 17 Feb 2023 07:55:58 +0100
From: Heinrich Schuchardt <[email protected]>
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
