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