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 <j...@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. Regards, Anshul
