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