Micro SD card writes very slow


I cannot get my BBB to use the external micro SD card with decent speeds. I have set up Angstrom on a Sandisk 16GB Class 10. With a USB card reader on Windows I get read speeds of 15-20MB/s and write speeds of 8MB/s. Under Angstrom, hdparm -t returns

/dev/mmcblk0: (SD card)
Timing buffered disk reads: 18 MB in 3.29 seconds = 5.47 MB/sec

/dev/mmcblk1: (internal EMMC)
Timing buffered disk reads: 50 MB in 3.06 seconds = 16.34 MB/sec

I did not find out how to benchmark the write speed without losing data, but from copying a few files it is <1 MB/sec for the micro SD card. Also, it appears that Linux uses write caching on the SD card, and when it decides to flush the buffer it can stall for several seconds due to the slow write speed. What is going on?

I did not find out how to benchmark the write speed without losing data, but from copying a few files it is <1 MB/sec for the micro SD card. Also, it appears that Linux uses write caching on the SD card, and when it decides to flush the buffer it can stall for several seconds due to the slow write speed. What is going on?

You can pipe some data with dd


Remember, eMMC access is 8bit, uSD card access is 4bit. This is a hardware limitation as far as I know.

I too was wondering about the slow access to the microSD card, so I did some testing, and got some surprising results:

I used dd to measure speed, using:

dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync;rm test

dd bs=1M count=512 if=/dev/mmcblk0 of=/dev/null
…or some slight variation as needed.

Internal eMMC:
Read: 18 MB/s
Write: 3.1 MB/s

Sandisk Ultra MicroSDHC 32GB Class 10 / UHS Class 1 (SDSDQUA-032G-U46A):
Read: 5.6 MB/s
Write: 3.1 MB/s

Testing done with newest Angstrom demo image. I got more or less the same results with Debian.

The exact same card in a Raspberry Pi B (512MB) using the SD-adapter supplied with the Sandisk MicroSD card:
Read: 21.0 MB/s

Write: 9.1 MB/s

(And for good measure I tested the same card in a USB3 reader on a PC and got 39.3/11.0 read/write)

Looking at the schematic for the BBB and the RPi, it seems that the SD slots on both are hooked up to the cpu more or less identically.

It may be a hardware limitation, but it doesn’t seem to be 8 vs. 4 bit.

One would think that the BBB should be superior to, or at least on par with the RPi in that regard. Some misconfiguration of the io registers maybe???

Did some reading, and I am pretty sure that there is something fishy with the uSD slot.

To get a clearer picture of what is going on, I wanted to find out if the eMMC is performing at spec.

The datasheet for the Micron eMMC part says that it should be capable of 30MB/s read and 6.6MB/s write. It also states that the part supports DDR mode, which the AM335x parts does not. I’m not sure how non-DDR access affects the speed, but we are getting about half, and we also need to consider real-world overhead from the file-system etc., so that’s probably ok, I don’t know.

The eMMC part is connected to MMC1 on the MPU using the full 8 bit, while the uSD slot is connected to MMC0 at 4 bits.

I then found the Technical Reference Manual for the MPU (document spruh73i.pdf from Texas Instruments) to find out what we should expect from the MMC0 port at 4 bits.

On page 3869 it states:

Clock support

– 96-MHz functional clock source input

– up to 384Mbit/sec (48MByte/sec) in MMC mode 8-bit data transfer

– up to 192Mbit/sec (24MByte/sec) in High-Speed SD mode 4-bit data transfer
– up to 24Mbit/sec (3MByte/sec) in Default SD mode 1-bit data transfer

That means it should be possible to reach far better speeds (up to 24 MB/s) from a fast uSD card than we are getting now.

MMC0 and MMC1 ports are independently configured, so I believe it is entirely possible that some register needs to be configured to reach maximum speed.

Now I just need to learn how to read and write those registers. :slight_smile:

The uSD card is 4bit versus the eMMC’s 8bit datawidth . …

Ok, sorry I stated the obvious going by what you wrote there ( sorry did not read the whole post first). Anyway, going by what I’ve seen said on these groups, I would not expect too much work in the area of “fixing” this.

  1. you can boot from the eMMC.
  2. you can netboot. ( possible to get 11.9MB/s reads, and 11.1MB/s writes )
  3. you can boot from a USB device.( for me ~20MB/s writes, ~10.6MB/s reads )

Plenty of room there for different purposes, and at least two to avoid wearing out the eMMC( or uSD ). So you could for instance setup a development environment on the BBB, and compile your life away - Just be warned, it will be painfully slow. Example compiling nodejs on the BBB took me around 2 hours. In a virtual machine( Debian ) on a windows host it took 5minutes. ← One CPU 2GB ram.

Anyhow uSD is not going to be long term reliable, this is why I think you wont see much improvement( if any ) in this area.

So, does the Linux have any say in all this? These are raw numbers, No OS timer ticks. No interruptions.No screen updates.

I suggest you write bare metal code and rerun your tests on all of this.


Robert Nelson’s Custom debian kernel as of 3.8.13-bone21 == 600-800K/s reads / writes. To uSD that is, which is a samsung 16GB class 10 uSD card.

It really depends on the media.. (and how much you pay for it..)

SanDisk Ultra 8GB (advertised 30MB/s class 10):
debian@bbb:~$ sudo hdparm -tT /dev/mmcblk0

Timing cached reads: 372 MB in 2.00 seconds = 185.64 MB/sec
Timing buffered disk reads: 16 MB in 3.00 seconds = 5.33 MB/sec

debian@bbb:~$ sudo hdparm -tT /dev/mmcblk1

Timing cached reads: 444 MB in 2.01 seconds = 221.28 MB/sec
Timing buffered disk reads: 42 MB in 3.11 seconds = 13.51 MB/se

On the beaglebone black, it is 'slower' then other mmc implementations
using the same media and a 4bit interface. Probably just the early
nature of the existing mmc code in 3.8 for this hardware... I would
test v3.12, but my Ultra's are all at home..


Robert, I did not mean that as a slight. I am perfectly happy. especially considering I have not contributed to the kernel at all, and it comes at no charge. Granted, I did not use hdparm, I used dd for ~1GB worth of data.

Anyhow . . .

william@arm:~$ sudo hdparm -tT /dev/mmcblk0

Timing cached reads: 382 MB in 2.01 seconds = 190.40 MB/sec
Timing buffered disk reads: 16 MB in 3.09 seconds = 5.18 MB/sec

Thanks to all of you for your feedback.

A few notes:

Bus-width is not the (entire) issue since Raspberry Pi can read 4x faster than BBB with the same cards, also using 4-bit access.

The controllers for the eMMC and the uSD seems to be identical except for bus-width and powercontrol. This suggests that Linux is fully capable of handling the controller.

Going bare metal may be more efficient than Linux, but again the RPi can do 4x the performance using Linux. (unfortunately docs on the RPi controller are not available)

I haven’t tested every linux distro, but performance seems to be more or less identical between different distros.

I know there are ways around the issue (eg. USB), but I think it would be a shame not to use this fantastic device to it fullest potential. It may be silly of me to try to figure this out, but hey, sometimes the journey is the reward :slight_smile:

I’ll let you know if I find a solution or a pointer to where the problem might be.

I was referring to the data you posted as it relates the hardware specification of the components in question and your assertion that those numbers could be met with a high level operating system,.

That is all I was saying. And yes, bare metal will be faster as that is all it has to do.


Maybe someone will take a look at Rasbian source code, and make adjustments ? shrug

Personally I do not really care. sd is not exactly reliable enough for production.

Sorry for not being clear about that. No, I don’t expect full 24MB/s using Linux. I was only trying to argue that nothing in the hardware specs suggests that ~5.6MB/s is the limit for read speed.

Understood. Just to be clear on my end. People read these emails and posts. I don’t want them led into the wrong direction if at all possible, Especially those that may just skim them.


I agree.

Anyway, now I’m getting somewhere… Luckily the datapins on the uSD connector are exposed while the card is inserted, so I hooked up the oscilloscope, and probed the pins while reading and writing to the uSD card:

Pin 1 (DAT2): No activity (high)
Pin 2 (CD/DAT3): No activity (high)
Pin 3 (CMD): Some activity, varying freq. around 3 KHz
Pin 4 (VDD): High
Pin 5 (CLK): Slight variation around 47 MHz
Pin 6 (VSS): Low
Pin 7 (DAT0): Lots of activity, freq. varying wildly, but mostly around 6-7MHz
Pin 8 (DAT1): No activity (high)

No observable difference between reading and writing.

Doesn’t that look like 1 bit mode?

LOL! Not luck. By design.

Yes, that does indeed sound like 1Bit mode.


Thank the designer (you, I guess?) from me, it was a really satisfying moment when I probed those pins :slight_smile:

Unfortunately I have absolutely no idea how to proceed from here. Any pointers?

It’s probably using the SPI mode, you gotta change the device driver for the sdcard i guess