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