TEMLIB now supports SD and MMCplus cards as mass storage, in addition to CompactFLASHs.

The SP605 board has a few I/O pins on the J17 header which can be used to plug a SD/MMC

The connector on the photo was salvaged from a broken digital camera, they can be bought on eBay, or taken from a cheap USB adapter (or a discarded adapter not compatible with SDHC cards…)
There are not enough signals on the J17 connector for the card detect and the write protect switches: Detection is achieved by sending commands and waiting for a reply, write protection is ignored.

Before using this adapter, the J46 jumper “SPI Select” must be removed.

The Xilinx SystemACE chip is obsolete and slow, and, even with fast CompactFLASH cards, we can only reach around 3.6MB/s for reads. This interface is faster.

It is also possible to use both simultaneously.

SD and MMC

In its current form, the controller supports several card types:

• SD cards which are not too old and support high speed transfers.
  Any 1GB or 2GB card will probably work.
• SDHC cards
• MMCplus/MMCmobile cards.
• Mini/MicroSD cards, using an appropriate connector or adapter.

I do not know whether SDXC cards are compatible. Likely.
Plain MMC cards with 7 contacts, as the 16MB Canon card above, are not supported.
Most small SD cards (128MB for example) will probably not work, because the clock frequency is too high.

History

First was the MMC card which was developed by SANDISK and SIEMENS, as an alternative to floppy disks. One can still find 64kB to 8MB SIEMENS SIMATIC MMC cards at insane prices.

The SD standard was created as a derivate of MMC with several additions:

• The write protect switch. Just mechanical, no electrical connection inside the card.
• Wider data bus : 4bits instead of 1bit
• Higher frequency mode : 50MHz instead of 25MHz
• Data protection, for copyrighted material.

All these enhancements were eventually also included in the MMCplus standard, which offers 1bit, 4bits and even 8bits interfaces (with additional contacts), a 52MHz mode and other pointless DRM extensions.

The SD cards are also a bit thicker to allow packaged chips on both sides of the PCB. Various reduced size formats were developed since then: MiniSD, MicroSD, MMCmobile,…
The latest UtraHighSpeed-II SD cards also have extra contacts. But they are not the same as MMCplus ones.

The MMC standard is now managed by JEDEC, and is still active mostly as soldered eMMC memory modules inside tablets, phones, not as removable media. There is also the new UFS (Universal Flash Storage, no less) which is an enhanced, faster eMMC.
SD cards are defined by the SD cartel, which sells licences for the brand and rights to manufacture compatible cards and hosts.

The legal situation around SD and MMC is difficult to understand:

• The native SD protocol is arguably not free.
• The MMC standard is said to be free in all modes: 1bits, 4bits, 8bits, high freq…
• The (slow) SPI mode is said to be free for SD cards. It was present in MMC cards. It is considered as obsolete in the current eMMC standard.

So what is the problem?

• SD and MMC cards need different initialisation sequences in the native, fast mode. After that, read and write operations are identical, in 1bits and 4bits mode. The command format, encoding, CRC is kept from MMC.
• It is not possible to initialise an SD card in its native mode without using the specific SD commands, incompatible with MMC cards.
• Likewise, MMCplus cards do not support the SD initialisation commands.
• In SPI mode, SD cards are compatible with the MMC commands and initialisation sequence.
• It is impossible to go from the SPI to the native mode without cutting the power supply and starting over.

How can one ask for license for a mere (deliberately incompatible) initialisation sequence?
Why is the CMD1 initialisation command for MMC recognised in SPI mode in SD cards but ignored in their native mode?

Meanies.

MMC cards are described in several SanDisk patents, particularly US6279114 and US6901457, but the patents mostly focus on voltage negotiation and the idea of connecting several cards in parallel, not on protocol details. High speed cards now mandate point to point connections anyway.

The situation with filesystems is quite disturbing as well. Cards are addressed as plain hard disks and can be reformatted with any filesystem, but the SD association mandates FAT for SD and SDHC and the newly patented and closed Microsoft EXFAT format for SDXC cards.
While there are protocol differences between SD and SDHC, to support a larger sector count, the only difference between SDHC and SDXC is about software, the filesystem, and Microsoft’s software patents.
The original FAT filesystem was free as long as long names weren’t used: Digital cameras use short names for picture files.
The MMC protocol is used in soldered eMMC modules in phones, tablets. When used for Android, these modules are not formatted with FAT/exFAT.
But when the device also includes a SD or MicroSD port, FAT patents cave in.

In our design, initialisation is done through software, by OpenBIOS, bit-banging frames, probing registers. Properly detecting and initialising SD, SDHC and MMCplus cards requires many operations.
Because the SD/MMC protocol is stupid in many many ways.

Reading and Writing

After initialisation, read and write commands are hardcoded and generated by the SCSI emulation microcode: Once it is initialised, disk emulation requires no software assistance.

There are two ways of reading and writing sectors in SD/MMC cards: one by one, or as a sequence of consecutive sectors.
And the sequential mode is much faster.
And, as filesystems groups sectors as blocks/clusters, for example 4kB = 8 sectors, sectors are seldom accessed individually.
And SCSI commands have a “sector count” parameter so that it is possible to use the sequential mode.
So this is what we use. Always. Even when sectors are sought one by one.

Note that continuous transmissions are halted after the last sector on the card has been read (OUT_OF_RANGE condition).

Here are the read multiple and write multiple commands:

Read
Once the read multiple command has been received, the card continuously sends back data until stopped with the STOP_SEQUENCE command. We send it after the last needed sector has been completely received.

Write
Once the write multiple command has been received, the card waits for data. After each sector, the card may indicate that it is busy by tying low the DATA0 line.

Here, we send the stop command between data transfers, the card may then activate the busy : DATA0=0 state, as writes may be delayed until several sectors are buffered.

SD/MMC cards are much faster in sequential mode: Whole sectors are stored in internal buffers before or after being read from or written to flash memory.

• For reads, doing consecutive accesses enables for the SD/MMC card to fetch sector N+1 while the sector N is being transferred over the bus.
• For writes, flash block size is larger than disk sectors. To change a single sector, the memory may need to erase an entire block then copy all the sectors around the modified one into the erased area. By writing several sectors at once, erase time is shared, and writes can be done in the background while following sectors are transferred.

With a 25MHz clock, the typical read access time is something like:
5500 cycles for the first access + 1100 cycles × sector count.
= 220µs + 44µs × sector count
Raising clock frequency would reduce the serialisation time, more than the initial seek time.
With 8 sectors blocks, the SD/MMC interface is twice faster than SystemACE’s CompactFLASH.

I may try later to use a faster clock, asynchronous from the SCSI clock, which is a bit more complex (the SystemACE interface is already like that, with a 32MHz clock and a clock domain crossing FIFO for reads).

There are huge variations in SD card performances, particularly when they are used as boot disks, with many random small read and write accesses. CompactFLASH cards performance seems more consistent.
Even though we use a modest 25MHz clock, high performance SD cards should be preferred (the kind that boasts 40MB/s, 60MB/s, UHS or “HD video record” in silver letters on the blister pack)

(A final note : From early 64kB MMC cards to recent 256GB SDXC and µSDXC cards, capacity was multiplied by several millions !)