HI Stephen, On Mon, Jan 9, 2012 at 12:04 PM, Stephen Warren <swar...@nvidia.com> wrote: > 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:
I committed a few patches to our tree a week or two ago - got a reduction from about 120ms to 70ms in kernel load time. Will see what I can do. Thank you for the notes. > > 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 Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot