mx51evk: "mmc init" does not work for "fatload"

[Shawn Guo]

Ideally, "fatload" should work fine after "mmc init" is done. But it hangs like the following.

MX51EVK U-Boot > mmc init
MX51EVK U-Boot > fatload mmc 0:2 90800000 boot.scr

However, "fatload" is working fine behind "mmcinfo" like below.

MX51EVK U-Boot > mmcinfo
Device: FSL_ESDHC
Manufacturer ID: 2
OEM: 544d
Name: SD02G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1967128576
Bus Width: 4-bit
MX51EVK U-Boot > fatload mmc 0:2 90800000 boot.scr
reading boot.scr

311 bytes read
MX51EVK U-Boot >

[Shawn Guo (shawnguo)]

This may not be a real bug. There are two U_BOOT_CMD(mmc) definitions in common\cmd_mmc.c depending on CONFIG_GENERIC_MMC.

#ifndef CONFIG_GENERIC_MMC
U_BOOT_CMD(
        mmc, 3, 1, do_mmc,
        "MMC sub-system",
        "init [dev] - init MMC sub system\n"
        "mmc device [dev] - show or set current device"
);
#else /* !CONFIG_GENERIC_MMC */
U_BOOT_CMD(
        mmc, 6, 1, do_mmcops,
        "MMC sub system",
        "read <device num> addr blk# cnt\n"
        "mmc write <device num> addr blk# cnt\n"
        "mmc rescan <device num>\n"
        "mmc list - lists available devices");
#endif

The "mmc init" is only available when CONFIG_GENERIC_MMC is defined, and it calls into mmc_legacy_init(). The mx51evk implements the new MMC commands with CONFIG_GENERIC_MMC defined. In this case, "mmc rescan 0" is the right command to initialize mmc before "fatload".

MX51EVK U-Boot > mmc rescan 0
MX51EVK U-Boot > fatload mmc 0:2 90800000 boot.scr
reading boot.scr

311 bytes read
MX51EVK U-Boot >

[Loïc Minier (lool)]

Is mmc init a no-op then?

Why does mmcinfo work without mmc rescan, when fatload without mmc rescan fails?

[Shawn Guo (shawnguo)]

For CONFIG_GENERIC_MMC defined case like mx51evk, "mmc init" is a no-op. "mmc rescan" does nothing but calls mmc_init(), and "mmcinfo" also calls mmc_init() before calling print_mmcinfo(). So the key is mmc_init() needs to be called before "fatload".

[Loïc Minier (lool)]

Would it be reasonable to fail fatload and other MMC accessing commands if mmc_init() wasn't run?

[Loïc Minier (lool)]

Heck, let's just run mmc_init() if it wasn't!

[Shawn Guo (shawnguo)]

Both command "mmc read" and "mmc write" will have mmc_init() called before doing actual mmc access. It is easy to call mmc_init() in cmd_mmc.c where commands "mmc read" and "mmc write" are implemented. But it may look odd to call mmc_init() in cmd_fat.c where "fatload" is implemented.

[Loïc Minier (lool)]

Yes, that's natural; can we ensure that the low-level mmc read command checks that mmc has been initialized and fails otherwise, or does the initialization?

[Shawn Guo (shawnguo)]

I tested the following patch on mx51evk and it works for me.

From 283f367cc2efa1a9e4a884c719f05c5eb3991b6b Mon Sep 17 00:00:00 2001
From: Shawn Guo <email address hidden>
Date: Fri, 8 Oct 2010 20:06:18 +0800
Subject: [PATCH] Make sure function mmc_init() is called before mmc read/write routine

Signed-off-by: Shawn Guo <email address hidden>
---
 drivers/mmc/mmc.c | 8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index cf4ea16..726daf3 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -90,6 +90,10 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
        if (!mmc)
                return -1;

+ /* Ensure the call of mmc_init() */
+ if (!mmc->version)
+ mmc_init(mmc);
+
        blklen = mmc->write_bl_len;

        err = mmc_set_blocklen(mmc, mmc->write_bl_len);
@@ -219,6 +223,10 @@ static ulong mmc_bread(int dev_num, ulong start, lbaint_t blkcnt, void *dst)
        if (!mmc)
                return 0;

+ /* Ensure the call of mmc_init() */
+ if (!mmc->version)
+ mmc_init(mmc);
+
        /* We always do full block reads from the card */
        err = mmc_set_blocklen(mmc, mmc->read_bl_len);

[John Rigby (jcrigby)]

I don't think this is the right way to deal with this. After discussion on IRC I believe the right thing is proper mmc boot support to the default imx51 env.

[Shawn Guo (shawnguo)]

This patch it to add mmc boot support to default mx51evk env. It also cleaned some unused env like netdev, uboot and redundant env like loadaddr since CONFIG_LOADADDR already defines it.

The patch has been tested on mx51evk with auto boot from mmc.

From b1355c39b061dc85a8b0aaeb3fd12507ce673a32 Mon Sep 17 00:00:00 2001
From: Shawn Guo <email address hidden>
Date: Sat, 9 Oct 2010 14:55:33 +0800
Subject: [PATCH] Add bootcmd_mmc and make it as default bootcmd

Signed-off-by: Shawn Guo <email address hidden>
---
 include/configs/mx51evk.h | 25 +++++++++++++------------
 1 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 86a4731..634c569 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -126,18 +126,19 @@

 #define CONFIG_LOADADDR 0x90800000 /* loadaddr env var */

-#define CONFIG_EXTRA_ENV_SETTINGS \
- "netdev=eth0\0" \
- "uboot_addr=0xa0000000\0" \
- "uboot=u-boot.bin\0" \
- "loadaddr=0x90800000\0" \
- "bootargs_base=setenv bootargs console=tty "\
- "console=ttymxc0,${baudrate}\0"\
- "bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs "\
- "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0"\
- "bootcmd=run bootcmd_net\0" \
- "bootcmd_net=run bootargs_base bootargs_nfs; " \
- "tftpboot ${loadaddr} ${kernel}; bootm\0"
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "mmcdev=0\0" \
+ "mmcpart=2\0" \
+ "bootargs_base=setenv bootargs console=tty " \
+ "console=ttymxc0,${baudrate}\0" \
+ "bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs " \
+ "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+ "bootcmd_net=run bootargs_base bootargs_nfs; " \
+ "tftpboot ${loadaddr} ${kernel}; bootm\0" \
+ "bootcmd_mmc=mmc rescan ${mmcdev}; " \
+ "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} boot.scr; " \
+ "source\0" \
+ "bootcmd=run bootcmd_mmc\0"

 #define CONFIG_ARP_TIMEOUT 200UL

[John Rigby (jcrigby)]

The original bug was invalid. However the other problems mentioned are valid and the patches have been applied to mainline.