On July 10, 2025 thus sayeth Judith Mendez:
> This removes support from booting from UDA when in eMMC boot.
>
> When user selects eMMC boot [0], that is, boot from eMMC boot0 or
> boot1 HW partitions, we should not boot from eMMC UDA. The current
> logic confuses the end user and mixes two different boot modes.
>
> The logic was added for AM62A/AM62P with commit: 3b7893145e36, but
If we end up respinning this we should probably use the standard
'commit: <sha> "(<msg>)"' syntax.
> this is not a clean solution and fix will come later for falcon boot.
>
> Logic was also added for AM62X with commit: 664593464634, but this
> logic is incorrect according to TRM [0] under Primary Boot Mode Selection
> for 'eMMC Boot'.
>
> Fixes: 3b7893145e36 ("mach-k3: add eMMC FS boot support for am62[ap]")
> Fixes: 664593464634 ("arm: mach-k3: am625: Relax emmc boot condition")
> Signed-off-by: Judith Mendez <j...@ti.com>
> ---
> arch/arm/mach-k3/am62ax/am62a7_init.c | 4 ----
> arch/arm/mach-k3/am62px/am62p5_init.c | 4 ----
> arch/arm/mach-k3/am62x/am625_init.c | 4 ----
> 3 files changed, 12 deletions(-)
>
> diff --git a/arch/arm/mach-k3/am62ax/am62a7_init.c
> b/arch/arm/mach-k3/am62ax/am62a7_init.c
> index edd43a1d78d..1d8644bd073 100644
> --- a/arch/arm/mach-k3/am62ax/am62a7_init.c
> +++ b/arch/arm/mach-k3/am62ax/am62a7_init.c
> @@ -217,10 +217,6 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
> boot_device)
>
> switch (bootmode) {
> case BOOT_DEVICE_EMMC:
> - if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT))
> - return MMCSD_MODE_EMMCBOOT;
> - if (IS_ENABLED(CONFIG_SPL_FS_FAT) ||
> IS_ENABLED(CONFIG_SPL_FS_EXT4))
> - return MMCSD_MODE_FS;
If we're booting from what ROM calls eMMC boot, which ROM has the
limitation where we can only boot from MMC0 in 8bit 1v8 and in RAW mode.
So I see the need to soften this requirement.
> return MMCSD_MODE_EMMCBOOT;
> case BOOT_DEVICE_MMC:
But it also has what they call MMC/SD mode which gives us the option of
booting from both MMC0 and MMC1 and in RAW or FS mode by setting the
PORT and RAW pins which we can read in the WKUP_CTRL_MMR0. And can give
us the same configuration as the previous boot mode.
I agree if we know the next phases of boot won't fit in the boot
partition we should be using this bootmode.
But I know this takes away some functionality after people have already
had their boards made and who cannot realistically change their bootmode
pins. I wonder if we should mark this as __weak so people can override
this in the board/ directory if needed?
~Bryan
