SD Card performance in R-Pi onboard slot

[Larry_Adlard]

Now comes the BUT. When you load Xwindows (startx) the mouse and keyboard don't work any more

You also need to update /lib/modules/3.1.9+ on the Pi when you rev the kernel. They're at:
https://github.com/raspberrypi/firmware ... er/modules

Thanks Jim.
Have updated joydev and evdev and that has cleared the complaints about the symbol table lookup.

Unfortunately, "sudo modprobe evdev" now says it has an invalid argument so progress, but not yet a solution.

It's liberating to be able to mess around like this on a small system that you can easily replace. You learn so much but I've come to the limit of time I can spend on it for the moment so I'll keep a watching brief for a while. Thanks to everyone who replied to the various topics I asked about.

[lb]

I did a small survey of various SD/MMC cards of all ages, manufacturers, capacities and speeds I could get a hold off. In total I tested 21 cards. The short version: all of these cards worked fine with the patched kernel. Several of the tested cards previously had reliability issues with the "vanilla" Raspberry Pi kernel 3.1.9.

Here's the long version:

The testing procedure is as follows: I boot the Pi with NFS root, and then unmount /boot. With this setup, I can hotswap SD cards as much as I like. Then, for each card, I check repeatedly (3x at least) that insertion is properly detected and that the card is setup without any errors. A simple performance test with "hdparm -t /dev/mmcblk0" follows. After that, I mount the card, copy some test files to it, copy them back, and then delete them. Unmounting and removing the card completes the test.

Here's a detailed list of cards that I tested. Caveats in braces.

Photo 1-9
1. Samsung 8 GB class 6 MicroSD (no issues)
2. Samsung 8 GB class 6 SDHC (no issues)
3. hama 4 GB class 2 SD (no issues)
4. Panasonic 2 GB class 4 SD (no issues)
5. noname 1 GB SD (no issues)
6. extrememory 1 GB premium SD (no issues)
7. Canon 16 MB MMC (card removal not detected reliably, otherwise no issues)
8. Canon 8 MB SD (no issues)
9. noname 2 GB class 2 MicroSD (no issues) (not on the photo, I use that one in my camera)

Photo 10-12
10. Toshiba 16 GB class 4 SDHC (no issues)
11. Sandisk 32 GB class 4 SDHC (no issues)
12. Samsung 32 GB class 10 SDHC (card removal not detected reliably, otherwise no issues)

Photo 13-15
13. Sandisk 1 GB MicroSD (no issues)
14. Nokia 4 GB class 4 MicroSD (no issues)
15. Kingston 1 GB SD (no issues)

Photo 16-19
16. noname 32 MB MMC (card removal not detected reliably, otherwise no issues)
17. extrememory 512 MB SD (no issues)
18. noname 2 GB SD (no issues)
19. Sandisk 2 GB class 2 SD (no issues)

Photo 20-21
20. Kingston 2 GB SD (no issues)
21. noname 4 GB class 4 MicroSD (no issues)

Some general caveats:
- Card removal detection has some issues. That's no surprise because the card detection pin of the socket isn't used by the driver. This is not an issue for most users, but still should be fixed.
- Sandisk's MicroSD->SD adapters do not work reliably with the Pi. I tried two of them, and both produced unreliable results, with timeout errors, read errors, etc. Everything worked just fine with a Samsung adapter. Maybe it's a slight mechanical contact problem?

[sraue]

It might be better to communicate with Chris Boot (https://github.com/bootc). He is working on an upstreamable version of the kernel which is likely to be the one future tree R-Pi uses
(and is used in OpenELEC testbuilds).

Hi,

the last days/weeks we use bootc's kernel in OpenELEC. Actually 3.2.19 with a revert of a problematic patch (see https://github.com/bootc/linux/commit/6 ... f26c5322f6) , which causes a non booting sd-card here (it needs several minutes until the driver is loaded).

after switching to kernel 3.2 we have got a much faster sdcard speed:

kernel 3.1: around 4MB/s read/ 4MB/s write
kernel 3.2: around 7-8MB/s read, 7-8MB/s write

now i have tried to port the patches from https://github.com/grigorig/rpi-linux/c ... rf-cleanup to bootc's kernel and i have seen many (nearly all) of the patches are included in kernel 3.2 vanilla and the reverted patch in bootc's repo. The patch now is very small. Also this now explains why bootc's kernel is already much faster.

all whats left after the port to kernel 3.2 are the enabling of the "highspeed" sdcard card stuff and some timing changes. after running the kernel my sdcard here again dont boots. so i have changed all timing changes back to bootc's original so only the highspeed stuff was left in the patch. Now the SD-card works again with this result:

read: around 15.5MB/s
write: around 11-15MB/s

i dont know if all is ok in my patch, but the result looks like http://pastebin.com/FCs89DVE (note the changed timings to the original) and we have doubled the transferrates again (3-4 times faster then the original kernel)

Stephan

[lb]

What timings do you refer to? The only I can think of is eMMC clock, which MUST be reduced to 50 MHz in config.txt. Don't try to overclock - it won't work. The default clock of 80 MHz is unfortunately anything but ideal. Anyway, just make sure that the real eMMC clock and the eMMC clock configured in the kernel driver match!

EDIT: I see you also changed the timeout values and poll intervals. These changes shouldn't be needed.

[selsinork]

all whats left after the port to kernel 3.2 are the enabling of the "highspeed" sdcard card stuff and some timing changes. after running the kernel my sdcard here again dont boots. so i have changed all timing changes back to bootc's original so only the highspeed stuff was left in the patch.

did you add

Code: Select all

init_emmc_clock=50000000 

into /boot/config.txt ?

There's a working port of a slightly earlier version of the patchset onto bootc's 3.2.19 available from https://github.com/selsinork/linux but you really have to add the line to the config.txt for it to work properly.

This define in the code:

Code: Select all

#define BCM2708_EMMC_CLOCK_FREQ 100000000

should match the init_emmc_clock= line in config.txt otherwise the divisors won't be calculated properly.

I also had to add https://github.com/selsinork/linux/comm ... 567bca8a9d otherwise the kernel would try to switch to 1.8v, fail and then get stuck in a loop trying different frequencies without success.

21MB/s read, 11MB/s write on a sandisk ultra 4GB class 6 for me with this kernel

[dom]

@lb
Thanks for the test results. I've done some testing myself:
I've tested 9 different cards. 7 working, 2 not working on current kernel.
Two class 6, 2 without class, and 5 class 4.
One non-working (class 4) continues to not work.
One non-working (class 6) now works.
All working ones continue to work.
The two class 6 ones now have hdparm -t of 17.7MB/s and 19.5MB/s
The others are all now between 10-12 MB/s
Before the patch all cards were between 4 and 5MB/s

Looks promising. I'm keen to hear others' results.

[arkhanist]

My sandisk ultra 16GB class 6 [30Mb/s] goes from 4.5 MB/s with hdparm -t with the updated stock kernel to 20.1MB/s with lb's 20120611 + emmc clock in config.txt.

I get similar results with my transcend 16GB class 6 that I nicked from my camera - from 4.2MB/s or so up to 20.5MB/s.

My sandisk ultra won't even boot with Chris' linux-image-3.2.19-rpi1+_3_armel.deb (no config.txt) - I get the 'switching to 1.8V signalling voltage failed' plus mmc0 error -110.

Will do some proper testing tomorrow; just finished redoing my ubuntu 12.04 dual-boot ready for cross-compilation. Hopefully will be able to test Chris' kernel on the 16GB transcend plus all three on a couple of microsd cards once I fish out my micro-to-sdhc adapter; it's a transcend IIRC so will give an extra data-point for that.

If I get time I'll try merging in the minimal patchset into Chris Boot's kernel and see how it goes.

[reggie]

Might be useful to pull more information off the cards, so we can see what type of cards are being used. Of course I appreciate that they might say class 6, uhs, 150x etc.

What information would be useful for the driver writers to debug efficiently?

What tests could everyone do to check their cards speeds? We're currently only testing read speeds aren't we with hdparm -tT?

What are realistic expectations for a given card? For instance, a card might not improve it's speed much but it doesn't mean the patches aren't working, the card could just be that slow.

I was thinking that the csd register might give us some useful information? the tran_speed bits define the clock speed of the card, you can get the csd register by doing the following at the command line:
cat /sys/class/mmc_host/mmc0/mmc*/csd

it will return a hex string. The tran_speed bits are the 4th byte from the left. For an SD card it will read either 32 (25Mhz default speed) or 5a (50Mhz high speed), for an sdhc or sdxc it will read 32,5a, 0b (100Mhz), 2b (200Mhz). UHS50 Card will read 0B (100Mhz), for both SDR50 and DDR50 modes. UHS104 Card will read the trans_speed bits as 2B (200Mhz).

If you would like to know more you can read this document:
https://www.sdcard.org/downloads/pls/si ... 100518.pdf

I've tested one card fully with lb's earlier patches:
Kingston, micro SDHC 4GB class 4, C04G

the CSD register returned 32 for the tran_speed bits so 25Mhz, my speed went from the uibiquitous 4.4MB/s to 10.5MB/s, I'm probably not going to get any better out of this card, as it's a 'default speed' card according to the tran_speed bits which means a theoretical limit of 12.5MB/s but will in reality be less with overheads.

[lb]

There's an import caveat to the CSD register's TRANS_SPEED value, and if you look closely it's also mentioned in the SD specifications: the reported value depends on the current transfer mode of the card. As far as I know, the CSD register is retrieved and saved for the /sys interface while the card is initialized, so TRANS_SPEED should always read 0x32.

The supported transfer modes need to be queried with CMD6, but the response of that is not exposed in the sysfs interface. (But again, the returned value depends on a current state, the signalling voltage, so a card should never report any of the new UHS modes on the Pi.)

EDIT:
debugfs offers a few more bits of information: mount it with "mount -t debugfs none /sys/kernel/debug". Now, you'll see some additional control files in /sys/kernel/debug/mmc0, for instance /sys/kernel/debug/mmc0/ios:

clock: 50000000 Hz
vdd: 17 (2.9 ~ 3.0 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)

[superg]

Just tested my SD card, speed increased x4.5 times!
Card is SanDisk Extreme SDHC UHS-I (32Gb)
(in case, someone need this info) Card serial: SDSDX-032G-X46

Some tests:
sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 164 MB in 2.00 seconds = 81.92 MB/sec
Timing buffered disk reads: 60 MB in 3.05 seconds = 19.66 MB/sec

sudo hdparm -tT --direct /dev/mmcblk0
/dev/mmcblk0:
Timing O_DIRECT cached reads: 44 MB in 2.08 seconds = 21.18 MB/sec
Timing O_DIRECT disk reads: 64 MB in 3.00 seconds = 21.32 MB/sec

dd if=/dev/zero of=test.raw bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 26.667 s, 20.1 MB/s

Thank you for our patches!

[selsinork]

What tests could everyone do to check their cards speeds? We're currently only testing read speeds aren't we with hdparm -tT?

Yes, but at a very simplistic level if you see more than the previous ~4-5MB/s then we know the patches work, at least to some degree. If you see ~20MB/s we're getting to the maximum the controller can support at 3.3v, it likely also suggests that it's working reliably.
When your speed falls into 5 < x < 20 then you have some questions:
1. card being mis-identified or mis-configured
2. mmc: errors in the log
3. card is just slow

read test for 20MB/s is simple, quick and anyone can do it. Debugging the other stuff can be more tricky, especially if people are not confident with linux.
What we need right now is much wider testing on lots of different cards, so the simple read test is enough and should identify if there's any major issues fairly quickly.

What are realistic expectations for a given card?

IMHO, that's a different question. First lets deal with getting the controller running at it's maximum potential, given the current hw limits. Once that's done and stable the bottleneck will be the card. Then people can go off and benchmark 4K write speeds or whatever they like.

I was thinking that the csd register might give us some useful information?

I was thinking more about the CID, there's some potentially interesting stuff in there like the actual manufacturer id which could be different from the label on the outside. Even if that's only the silicon vendor it might let us find a pattern where Sandisk cards with a Samsung controller are good but a TI controller are less. I couldn't fnd a list of the manufacturer ids, but even as an opaque unique number it might be useful.
There's also supposedly a manufacturing date which might let us tell that a particular card manufactured in April 2012 has problems, but other date codes are good.

The tran_speed bits are the 4th byte from the left.

My class 10 / UHS-1 card returns 32, as does every other card I've tried.

[johnc]

Hi,
I'm a linux noob, but I'd like to try this kernel. I note that a previous post by lb has stated that the modules (/lib/modules/3.1.9+) need to be updated so that the new kernel image will work. A link was provided to a github repository containing the firmware and I've downloaded the associated tarball.

How do I update the modules?

I have mounted the SD card in a PC running ubuntu and I can read/write to the /lib/modules/3.1.9+ directory. Should I delete the existing file-tree and replace with the downloaded versions?
A set of consise instructions would be welcome.

Thanks.

[pjc123]

It would help greatly if people running these benchmark tests could include part numbers of the SD cards they are testing so that we can make informed decisions on our next SD card purchase.

[superg]

Hi,
I'm a linux noob, but I'd like to try this kernel. I note that a previous post by lb has stated that the modules (/lib/modules/3.1.9+) need to be updated so that the new kernel image will work. A link was provided to a github repository containing the firmware and I've downloaded the associated tarball.
Thanks.

You should use rpi-update script, which is automated way to update kernel + modules. If you aren't able to boot with your card, you can just replace kernel.img with updated version, to boot off your SD card, and then use update-rpi script to update kernel and modules correctly.
See following link: https://github.com/Hexxeh/rpi-update

[dom]

I've accepted lb's pull request, and rebuilt the firmware in github, and updated Hexxeh's repo.
An rpi-update should now give you improved sdcard speed. init_emmc_clock now defaults to 50Mhz, so config.txt entry is not required.

Please update and report back on success or failures.

[bootc]

init_emmc_clock now defaults to 50Mhz, so config.txt entry is not required.

Is there a way the kernel can query such things as clocks? Strikes me if people update the firmware but not the kernel you'll have a lot of non-booting Raspberry Pis...

[dom]

Is there a way the kernel can query such things as clocks? Strikes me if people update the firmware but not the kernel you'll have a lot of non-booting Raspberry Pis...

Unfortunately no. I did make it clear in the firmware commit.
I guess the device tree mods will help in the future.
I've been meaning to a add a mailbox based get/set property machanism that could handle this (and also cope with changing clocks from ARM).
It's been requested by non-linux systems (e.g. RISCOS).

[lb]

A firmware update w/o kernel update shouldn't be harmful. SD access will be slow due to the low clock, but that's all. The other way around won't work, though.

bootc, by the way I ported the cleaned up patchset to the 3.2.19 kernel, it's available from https://github.com/grigorig/rpi-linux/t ... 2.19-sdhci. For some reason I can't make a pull request to your branch. Github is a bit stupid.

[texy]

I've accepted lb's pull request, and rebuilt the firmware in github, and updated Hexxeh's repo.
An rpi-update should now give you improved sdcard speed. init_emmc_clock now defaults to 50Mhz, so config.txt entry is not required.

Please update and report back on success or failures.

How does this fit in with the new wheezy download put out to the masses to try?
Do they work in conjunction?
Will I be able to download rpi wheezy, then run rpi-update, and all will be up to date (with my rtl8188cus nano wifi working as well!) ?

Texy

[asb]

How does this fit in with the new wheezy download put out to the masses to try?
Do they work in conjunction?
Will I be able to download rpi wheezy, then run rpi-update, and all will be up to date (with my rtl8188cus nano wifi working as well!) ?

It should be safe to do rpi-update. However, the wheezy image now has the firmware packaged as .debs meaning you will be able to apt-get update && apt-get upgrade. I'll refresh the packages later today so everyone can just do that (slight kink in the upgrade process to work out, as dpkg doesn't like the /boot partition is FAT). In the future I should think it will make sense to have a bleeding-edge apt source that is automatically updated every time the firmware github repo is updated.

[oztrailrider]

I just did a firmware update and tested with a Sandisk 4GB Ultra Class 6 (advertised read speed of 30MB/sec). I used to consistently get read speeds of 4.44MB/sec when running hdparm -tT on this card. Since the firmware update I am now getting 19.5MB/sec so changes seem to have improved things by more than 4x . I will make sure to report any issues that arise with the new changes. A big thanks to all who have worked on the improvements.

[Killerbee]

I just did a firmware update and tested with a Sandisk 4GB Ultra Class 6 (advertised read speed of 30MB/sec). I used to consistently get read speeds of 4.44MB/sec when running hdparm -tT on this card. Since the firmware update I am now getting 19.5MB/sec so changes seem to have improved things by more than 4x . I will make sure to report any issues that arise with the new changes. A big thanks to all who have worked on the improvements.

Maybe a stupid question but what was your bootime before and after?

[theHetman]

I've just tested both a Kingston 8GB class 6 and a Lexar 8GB class 6. Both work and both now give read/write speeds that compare well with other tests that I've done on those cards on Windows desktops and laptops. (~18MB/s read / ~14MB/s write for the Kingston and ~19MB/s read / ~9MB/s write for the Lexar).

I have some 4GB class 4 Transcend cards that I will test in the future.

[theHetman]

Maybe a stupid question but what was your bootime before and after?

Not a stupid question as I was wondering myself. The answer is that it helps a little. Boot times have gone down from about 24 sec to around 18 sec.

[AndrewS]

It should be safe to do rpi-update. However, the wheezy image now has the firmware packaged as .debs meaning you will be able to apt-get update && apt-get upgrade.

If the firmware can now be updated by rpi-update or by apt-get, will apt-get get confused/upset if the two are intermixed, i.e. if you apt-get the firmware and then later on rpi-update overwrites it?
Would it make sense to tweak rpi-update to just print "use apt-get instead" if it detects that the firmware .deb is installed