On 01/09/2012 12:55 PM, Simon Glass wrote:
...
>> + debug("board_mmc_init: init eMMC\n");
>> + /* init dev 0, eMMC chip, with 4-bit bus */
>> + /* The board has an 8-bit bus, but 8-bit doesn't work yet */
>> + tegra2_mmc_init(0, 4, -1, -1);
>
> Yes - I will see if I can do a patch to enable 8-bit.
BTW, I briefly looked at this quite a while back when I first started
looking at U-Boot. I filed an internal bug to investigate this further
at some later time. The notes are below:
MMC devices can have a 1-, 4-, or 8-bit data bus. Support for 8-bit data
buses is currently not fully implemented in mainline(Denx) U-Boot. This
is mostly an issue with the MMC core, and not Tegra-specific. The
following potential issues exist:
1)
drivers/mmc/tegra2_mmc.c:tegra2_mmc_init() contains:
if (bus_width == 8)
mmc->host_caps = MMC_MODE_8BIT;
else
mmc->host_caps = MMC_MODE_4BIT;
I /think/ this should be rewritten as:
if (bus_width == 8)
mmc->host_caps = MMC_MODE_8BIT;
if (bus_width >= 4)
mmc->host_caps = MMC_MODE_4BIT;
... thus allowing both caps to be set at once.
2)
drivers/mmc/mmc.c:mmc_change_freq() contains the following for v4 cards:
mmc->card_caps |= MMC_MODE_4BIT;
Nothing ever performs:
mmc->card_caps |= MMC_MODE_8BIT;
... so 8-bit mode can never be active.
I note that ChromeOS's U-Boot replaces the above code with:
if(mmc->host_caps & MMC_MODE_8BIT)
mmc->card_caps |= MMC_MODE_8BIT;
else
mmc->card_caps |= MMC_MODE_4BIT;
which implies that the 8-bit and 4-bit mode flags are meant to be
mutually exclusive, which seems a little odd; our controller could do
either just fine...
3)
drivers/mmc/mmc.c:mmc_startup() contains:
if (mmc->card_caps & MMC_MODE_4BIT) {
// setup for 4-bit mode
} else if (mmc->card_caps & MMC_MODE_8BIT) {
// setup for 8-bit mode
}
which oddly checks for 4-bit mode first, so if both 4- and 8-bit mode
are allowed, 4-bit wins.
4)
If you look at the Linux kernel MMC driver, there's a lot more to
selecting between 1-, 4-, and 8-bit mode. Specifically:
a) You're supposed to try 8-bit mode, test it and see if it works. If
that fails, fall back to trying 4-bit mode, then fall back to 1-bit
mode. U-Boot currently just picks one, doesn't fully test it, and if it
fails, you're done.
b) You're supposed to test the card works correctly after selecting a
bus width using a special bus-width test command.
c) The Linux kernel at least also executes commands to switch the card
between various power modes that the card reports it needs for different
bus speeds and widths. I don't think U-Boot does this anywhere.
(a) and (b) are also supported by the following document from the MMC
association:
http://read.pudn.com/downloads153/doc/project/671834/MMC
SD/AN_MMCA050419.pdf
I hacked a fix for (1), (2), and (3) above and tested Seaboard's
internal eMMC. While data transfer appeared to still operated correctly,
I didn't observe any difference in transfer speed. I don't know if this
is due to (4) above, or some other issue. However, I did observe a
nearly 2x speedup going from 4- to 8-bit mode when running the Linux kernel.
So, quite a lot of further investigation/work needed here.
--
nvpublic
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
