The original Beagleboards were fitted with a full-size SD/MMC card reader with full connectivity for 13-pin MMC cards that feature an 8-bit data bus. The Beagleboard SRM notes that the upper 4 bits of this bus are supplied by the VDD_SIM rail and explains that this means that 8-bit cards must operate with both VMMC1 and VDD_SIM at 1.8V. This makes the upper 4 bits almost useless, because cards that are both 8-bit and dual voltage seem to very rare. All the 8-bit cards I’ve managed to find are 3V only.
So I wonder, is it really true that the upper 4 bits can only be used at 1.8V? I notice that the TPS65950 is quite capable of driving VDD_SIM at 3V. There are two instances of the PBIAS cell and the extended-drain I/O cell in the OMAP35xx, which suggests there are 2 blocks of I/O pins that can operate at either 1.8V or 3V. Spruf98b clearly shows PBIAS0 is connected to MMC/SD/SDIO1, As far as I can see, it doesn’t say what PBIAS1 is for, but surely it’s meant for DAT4-DAT7? The SUPPLYHIGH bits in CONTROL_PBIAS_LITE are currently reading as 1 (3V) for PBIAS0 and 0 (1.8V) for PBIAS1 for me.
I’m too nervous to try changing VDD_SIM to 3V to see if it changes CONTROL_PBIAS_LITE.PBIASLITESUPPLYHIGH1 to confirm this theory, in case I damage something. Should I be?
Ben
I have never tried this myslef and i have no plans to. Feel free to change
whatever you like. But if it is damaged then most likley there will be a
charge for fixing the processor. One note, however, the TPS65950 is not
the determining factor. It is the processoer and what it can take. Be sure
and check that datasheet as well.
Gerald
Thanks Gerald. I hadn’t spotted the other datasheet before (sprs507f) and it does say one or two things about that power line, which it calls vdds_mmc1a. It claims to be dual-voltage 1.8V/3.0V, so I decided to take the risk. Getting the TPS to output 3V was indeed reflected in the CONTROL_PBIAS_LITE register as I expected, and also meant that the MMC bus test commands (CMD19/CMD14) started working in 8-bit configuration.
For the record, I found I had to program two registers in the TPS65950 to get the status in CONTROL_PBIAS_LITE to change: VSIM_DEDICATED to 0x05 and VSIM_DEV_GRP to 0x2E (chosen to match VMMC1_DEV_GRP).
It’s just a shame that after that effort, I’m not seeing any appreciable increase in data transfer speed. It’s stuck at around 7 MB/s even for reads, even though I’ve now got an 8-bit bus at 48 MHz which theoretically could allow 48 MB/s. I guess the bottlenecks are elsewhere…
Ben
Well, unless the SW sets up the pins and uses them, they won't provide
much. And I don't know of any SD cards that have 8bit interfaces on them.
This is really intended as for use an SDIO interface, such as cameras,
where 8bits are provided.
Gerald
What MMC card are you using? The card could very well be the problem
if throughput is what you're after. Find a faster one 
You could use flashbench [1] to test a few different MMC cards to find a
faster one, but that does require buying a bunch of cards (or finding
people who already own them). Sadly, MMC isn't very popular, and even
Linaro's list of flash devices [2] doesn't appear to contain many (if
any?). A search through the flashbench-results mailing list might find
a few here and there [3].
[1]: http://git.linaro.org/gitweb?p=people/arnd/flashbench.git
[2]:
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
[3]: http://lists.linaro.org/pipermail/flashbench-results/
Have you verified that the full 8 bit bus is actually functioning
during reads and writes with a logic analyzer?
-Andrew
I should maybe explain, I’m writing my own SD/MMC driver (hence why I’m not just using the Linux one) so it’s up to me to ensure all the pins are used if possible. I’m fairly confident all the pins are now in use - previously the bus test came back with the upper nibble of each byte set to 0xF, and if I ignored that result and wrote to the card anyway, the upper nibble of each byte written to the card was zero. That seems consistent with half the data pins being non-operational to me.
The 8-bit cards I’ve been testing with are Integral and Transcend branded MMCplus and MMCmobile cards. They’re only 0.5 and 1 MB capacity - I haven’t been able to find any larger ones on sale anywhere despite press releases suggesting they were under development. I find it hard to understand what’s going on in the MMC world, since they’re still busy producing updates to the specification, including 200 MHz versions of the bus, and yet the cards themselves seem very hard to obtain. MMCmicro cards seem to be even rarer, I could only find one of those.
I wasn’t aware of flashbench before - there are some interesting numbers there, but I think they’re only really testing write speeds. I knew there were limitations caused by the wear levelling algorithms used by the cards, so my own speed tests were done using contiguous 30 MB blocks, which should provide a best-case figure. I expected to see speeds of under 10 MB/s for writing (after all, that’s what the speed class of cards is measuring) but what really surprised me was the fact that read speeds were barely any faster. I would have thought that reading would only need to be limited by the bus speed, but that doesn’t seem to be true, and is a bit disappointing. I have gathered a selection of 20 or 30 cards for testing purposes, and although I haven’t speed-tested them all yet, the best read figures I’ve seen so far really was only 7 MB/s. This is even true for the one UHS-I SD card I tried (albeit in 3V signalling High Speed mode), which you’d really expect to go at least somewhere above 12.5 MB/s, or what was the point of using a faster bus?
I should maybe explain, I'm writing my own SD/MMC driver (hence why I'm not
just using the Linux one) so it's up to me to ensure all the pins are used
if possible.
Sorry, didn't notice your email domain, now I understand.
The 8-bit cards I've been testing with are Integral and Transcend branded
MMCplus and MMCmobile cards. They're only 0.5 and 1 MB capacity - I haven't
been able to find any larger ones on sale anywhere despite press releases
suggesting they were under development. I find it hard to understand what's
going on in the MMC world, since they're still busy producing updates to
the specification, including 200 MHz versions of the bus, and yet the cards
themselves seem very hard to obtain. MMCmicro cards seem to be even rarer,
I could only find one of those.
0.5 and 1 MB or GB capacities?
I assume most effort for MMC is directed at eMMC these days. That's
where the capacity seems to be (many mfg making > 16GB eMMC devices).
That's also where the speed is needed. Sadly, the eMMC side of things
has its own fun market where you have to buy huge quantities of parts
to even talk to a sales rep.
I wasn't aware of flashbench before - there are some interesting numbers
there, but I think they're only really testing write speeds. I knew there
were limitations caused by the wear levelling algorithms used by the cards,
so my own speed tests were done using contiguous 30 MB blocks, which should
provide a best-case figure. I expected to see speeds of under 10 MB/s for
writing (after all, that's what the speed class of cards is measuring) but
what really surprised me was the fact that read speeds were barely any
faster. I would have thought that reading would only need to be limited by
the bus speed, but that doesn't seem to be true, and is a bit
disappointing. I have gathered a selection of 20 or 30 cards for testing
purposes, and although I haven't speed-tested them all yet, the best read
figures I've seen so far really was only 7 MB/s. This is even true for the
one UHS-I SD card I tried (albeit in 3V signalling High Speed mode), which
you'd really expect to go at least somewhere above 12.5 MB/s, or what was
the point of using a faster bus?
The controller between the bus and the flash is the weak point. That's
where the cost savings can be had, so that's where the manufacturers
can skimp. Don't know what to say beyond that. In my personal
experience with SD cards, I've seen read and write speeds are generally
about the same, which does seem odd now that you mention it.
-Andrew
0.5 and 1 MB or GB capacities?
Oops, yes of course I meant 0.5 and 1 GB! 
I assume most effort for MMC is directed at eMMC these days. That’s
where the capacity seems to be (many mfg making > 16GB eMMC devices).
That’s also where the speed is needed. Sadly, the eMMC side of things
has its own fun market where you have to buy huge quantities of parts
to even talk to a sales rep.
Presumably we’re talking about the on-board storage for mass market mobile devices here?
Ben
Yes. eMMC is MMC device in a BGA (ball grid array) package.
Like SanDisk iNAND [1] or Samsung [2] devices.
[1]: http://sandisk.com/business-solutions/inand-embedded-flash-drives
[2]:
http://www.samsung.com/global/business/semiconductor/product/flash-emmc/catalogue
Some really neat controllers are supposedly found inside those type
devices. That's what I think is driving the increase to 200MHz for
MMC, those things can actually use that speed. They're basically moving
to use desktop solid state disk controllers but with an MMC interface
rather than SATA.
-Andrew