[PATCH] mach-k3: am62*: am62*_init: Prohibit boot from UDA w/ eMMC boot

[Bryan Brattlof]

On July 17, 2025 thus sayeth Bryan Brattlof:
> 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 <jm at 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.
> 

Wait no this is wrong. I think I should point out that this bootmode 
only works in UDA mode. MMC/SD mode can be configured to use RAW offsets 
or a FS to find the binary, but will not look in the boot partitions.

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

I still tend to agree we don't really want to modify the boodmode for 
the next phase but with falcon mode and how massive U-Boot can be 
sometimes. I don't think we can get away from this unless we let 
individual boards modify this for their own need.

~Bryan