[PATCH 1/4] arm: mach-k3: Fix MMC macros

[Judith Mendez]

Hi Andrew,

On 9/17/25 11:48 AM, Andrew Davis wrote:
> On 9/17/25 11:06 AM, Judith Mendez wrote:
>> On 9/16/25 10:41 PM, Anshul Dalal wrote:
>>> Hi Judith,
>>>
>>> On Wed Sep 17, 2025 at 4:05 AM IST, Judith Mendez wrote:
>>>> Hi Andrew, Anshul,
>>>>
>>>> On 9/16/25 11:22 AM, Andrew Davis wrote:
>>>>> On 9/11/25 9:59 AM, Judith Mendez wrote:
>>>>>> Hi Anshul,
>>>>>>
>>>>>> On 9/11/25 12:11 AM, Anshul Dalal wrote:
>>>>>>> On Thu Sep 11, 2025 at 3:15 AM IST, Judith Mendez wrote:
>>>>>>>> For all K3 SoC's eMMC boot and MMCSD boot modes are supported. The
>>>>>>>> macros
>>>>>>>> however, mix MMC device with the two bootmodes. Decouple the two 
>>>>>>>> types
>>>>>>>> of macros so that bootmodes can be identified with:
>>>>>>>> - BOOT_DEVICE_MMCSD
>>>>>>>> - BOOT_DEVICE_EMMC
>>>>>>>> according to devstat parsed boot mode values and on-board devices
>>>>>>>> can be
>>>>>>>> identified with:
>>>>>>>> - BOOT_DEVICE_MMC1
>>>>>>>> - BOOT_DEVICE_MMC2
>>>>>>>> - BOOT_DEVICE_MMC2_2
>>>>>>>> according to arbitrary numbers mainly used to differentiate between
>>>>>>>> eMMC
>>>>>>>> and SD card.
>>>>>>>>
>>>>>>>> Signed-off-by: Judith Mendez <jm at ti.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> I guess the confusion here is how we are calling boot modes from 
>>>>>>> devstat
>>>>>>> as well as the boot device as BOOT_DEVICE_*. Perhaps we should 
>>>>>>> rename
>>>>>>> the former to DEVSTAT_BOOT_MODE_* or something along those lines.
>>>>>>>
>>>>>>> That would make the difference between a boot *mode* and a boot 
>>>>>>> *device*
>>>>>>> more clear, DEVSTAT_BOOT_MODE_MMCSD or DEVSTATE_BOOT_MODE_EMMC would
>>>>>>> distinguish between SD or EMMC boot modes with BOOT_DEVICE_MMC*
>>>>>>> indicating the MMC port used.
>>>>>>>
>>>>>>> This would also allow use to only have the respective
>>>>>>> DEVSTAT_BOOT_MODE_* defined in each soc's headers with BOOT_DEVICE_*
>>>>>>> coming from arch/arm/include/asm/spl.h.
>>>>>>
>>>>>>
>>>>>> Right, I guess if
>>>>>>
>>>>>> BOOT_DEVICE_MMCSD
>>>>>> BOOT_DEVICE_EMMC
>>>>>>
>>>>>> Is still not clear enough, it would be a good idea to use:
>>>>>> DEVSTAT_BOOT_MODE_MMCSD
>>>>>> DEVSTAT_BOOT_MODE_EMMC
>>>>>>
>>>>>> Its only a real problem for MMC since we have the confusion with eMMC
>>>>>> boot and MMCSD boot and we mix the two as a result in
>>>>>> spl_mmc_boot_mode() and spl_boot_device().
>>>>>>
>>>>>>
>>>>>> Its not really an issue for other boot modes to warrant renaming 
>>>>>> all the
>>>>>> bootmodes, but I would like to make these macros as clear as 
>>>>>> possible in
>>>>>> this series since I plan to refactor spl_mmc_boot_mode() next.
>>>>>>
>>>>>> So lets hear if any one else has a strong opinion on this before
>>>>>> deciding on:
>>>>>>
>>>>>> DEVSTAT_BOOT_MODE_MMCSD
>>>>>> DEVSTAT_BOOT_MODE_EMMC
>>>>>
>>>>> This looks like the correct way to label these as they are the content
>>>>> of the DEVSTAT register, this would also keep them from being confused
>>>>> with the U-Boot internal definitions for BOOT_MODE_* and 
>>>>> BOOT_DEVICE_*.
>>>>>
>>>>> But you should do it for all the DEVSTAT register defines, not just
>>>>> MMC and not just for Sitara, do it for all our K3 boards. It should
>>>>> be a simple rename patch to start. Then you can work to detangle
>>>>> "mode" from "device" for the MMC case as you are doing here.
>>>>
>>>> I take it back, seems like this cannot be done, u-boot source requires
>>>> all the macros:
>>>> BOOT_DEVICE_SPI
>>>> BOOT_DEVICE_RAM
>>>> BOOT_DEVICE_UART
>>>> etc...
>>>>
>>>> in order to even build.
>>>>
>>>> Simply renaming the macros to style:
>>>> DEVSTAT_BOOT_MODE_SPI
>>>> DEVSTAT_BOOT_MODE_RAM
>>>> DEVSTAT_BOOT_MODE_UART
>>>>
>>>> will not work without creating a duplicate:
>>>> #define BOOT_DEVICE_SPI        DEVSTAT_BOOT_MODE_SPI
>>>> #define BOOT_DEVICE_RAM        DEVSTAT_BOOT_MODE_RAM
>>>> #define BOOT_DEVICE_UART    DEVSTAT_BOOT_MODE_UART
>>>> or similar logic
>>>>
>>>> So basically we would be doubling the size of all spl.h files.
>>>>
>>>> In reality there is only confusion with MMC device/bootmodes,
>>>> we do not to rename every single boot modes/boot device since
>>>> there is no real confusion there.
>>>>
>>>
>>> Correct me if I'm wrong here but BOOT_DEVICE_* should only be used
>>> within the common u-boot source. Our job is to just the return the
>>> correct macro from the SoC's boot.c file and ensure they are all unique
>>> values.
>>>
>>> If that's true, can we make use of BOOT_DEVICE_* defines from
>>> arch/arm/include/asm/spl.h?
>>>
>>> That should avoid duplication since we would just rename the existing
>>> BOOT_DEVICE_* macros to DEVSTAT_BOOT_MODE_* in our board's spl.h while
>>> relying on BOOT_DEVICE_* from arm's spl.h.
>>
>> Then we come back in a circle to the first real problem which is
>> untangling MMC bootmodes from MMC boot devices.
>>
>> Why are we trying to refactor all the MMC_DEVICE_* ? There is no
>> real problem for those bootmodes / boot devices since boot device =
>> boot mode for those. It is only a real problem for MMC since boot device
>> DOES NOT equal boot mode for MMC.
>>
> 
> Boot mode does not equal boot device, even though we sometimes
> mix the two. For example, a UART boot "device" implies a ymodem
> boot "mode". Our ROM also conflates the two concepts as most
> boot devices support one mode each. U-Boot is more flexible and
> "device" is split from "mode".
> 
> Our DEVSTAT register gives us the combination, not just the
> "device". So the defines that we use to match against content
> of the DEVSTAT register should not be same as those returned
> by spl_boot_device() and other U-Boot functions for "device".
> They should have their own definitions.

True. Ok, will split the two for k3 then.

~ Judith