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

[Judith Mendez]

Hi Andrew,

On 7/17/25 12:12 PM, Andrew Davis wrote:
> On 7/17/25 11:02 AM, Bryan Brattlof wrote:
>> 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.
>>
> 
> Core issue is we assume all boot stages are stored on the same boot
> media. Usually this is a good assumption, and without it we would
> have to hard-code where the next boot stage is located at compile
> time. The big exception being the eMMC BOOT partition which is not
> big enough for all stages, so at some point we have to switch
> (usually to the eMMC's UDA partition), but *when* we switch is
> not clear. It could be after R5 SPL, or A53 SPL, or after
> U-Boot proper (only kernel/rootfs need stored on UDA).
> 
> The logic we have in U-Boot now is that you pick when you want to
> switch by disabling CONFIG_SUPPORT_EMMC_BOOT for the stage before
> the stage on the UDA FS partition. But this is confusing, forces
> FS mode, and only works if you don't switch between the two
> A53 stages.
> 
> Some better way to configure when to switch would be useful,
> and not just for eMMC, for instance I test R5 SPL by loading test
> builds over UART, but I want the next stages that I'm not testing
> to be loaded from the SD card, could we make a simple way to encode
> this without overwriting spl_boot_device()?

The goal of this patch was to clean up code due to questions we
get asked: I am booting with eMMC boot, but why is the wrong
image used, eMMC boot doesn't boot from UDA, why is the code returning
MMCSD_MODE_FS, etc... What you are suggesting is to further enhance
the feature that we have atm. If the end-user selects eMMC boot
based-off the TRM boot mode pins and with some flags or bits, we
can select not only MMCSD boot from UDA, but other boot modes, won't
this make the issue worse???

~ Judith