My situation has improved. I've been tracking the mainline and orion kernels and currently run a merged tree (I merge the extra changes from orion into mainline). Previously, I was seeing -110 errors on all my cards and no cards would work with the MMC enabled u-boot either. A few days ago, I opened my plug and fiddled with the connector from the debug board (with the SD slot) to the main board. Now I find that all my cards (SD, SDHC, MMC, MMCplus) work in linux! And the SD and SDHC cards work in u-boot too (no luck with MMC - I'm not sure u-boot actually implements the different protocol).

So, if you're seeing -110 errors even with the latest kernel, then it might be worth opening it up and making sure the connection is good.

Wow, thanks philipl for the tip.I was fighting with SD cards and sheevaplug for weeks.I tried with 3 different SD cards (SD ans SDHC), and kernels (mainline, orion, different patches etc). I had -110 errors every time.

As you proposed, I opened the sheevaplug, and plugged it again : boom, all SD cards are detected by the kernel and can be mounted readwrite (I'm currently using mainline 2.6.30-rc6 with mvsdio patch).That's great news, because I still thought I had a software problem.On the other hand, the behavior is quite strange : If I close the plug again (with the 4 screws), the -110 errors are back. It looks like it only works if the sheevaplug is opened.Could it be due to the red push-button inside the plug? Maybe it's pushed when the plug is closed...Or maybe it's due to the heat of the power supply next to it?

1) I started off with 100% failure and saw -110 errors continually when I inserted any card.2) I opened the plug up and fiddled with the connector3) I am using a bleeding edge git tree - the very latest Linus git merged with the very latest orion tree. The latest orion tree includes a couple of SD related patches that are no where else. These might be important.4) I use a custom (module-less) kernel (config attached),5) When I boot from powered-off to this kernel, it will handle all of my SD and MMC cards. I did dd reads of 128MB from all of them with no problems6) The mmc enabled u-boot can init and read my SD and SDHC cards, but not my MMC cards.

So, everything seems great. Now here's the weird part.

7) I tried running the ARMedSlack installer which is stock mainline 2.6.30-rc6 and it failed with the errors that you get without the delay patch from the orion tree. Ok, that's expected. I then applied the ARMedSlack config (also attached) to my git tree and built a custom kernel and booted into the installer. I now got the errors doing reads (detection is ok) that many other people have reported. This happens consistently.9) If I reboot into my working kernel, I get the same errors - I have to hard power off to get back to reliable operation.

Assuming that something insane isn't going on here, some difference between my custom config and the configs that most people use (including the ARMedSlack installer) could be to blame for the errors. I will continue to investigate.

More info. I now strongly suspect that even when it works correctly, it will stop working after a reboot (as opposed to pulling the power). I saw errors with my good kernel after doing that. So, you have to pull the power and start from a cold boot for it to work.

As Philipl said, it seems that the SD cards stop working after a soft reboot (even with the sheevaplug opened).I tried that with a 2.6.30-rc6 patched kernel, and a recent uBoot with SD support, through the installer alpha-5 (http://plugcomputer.org/plugforum/index.php?topic=323.0)

1) There are separate hardware and software problems here. Before I opened it up and fiddled the connector, I had no success under any conditions.

2) The best kernel to use is the very latest orion git tree. You could merge this with mainline but orion is already rc6++ if not quite rc7 yet.

3) From a cold boot, all my cards work reliably.

4) From a soft reboot, I get errors reading the card when I use my SDHC card. One of older slower SD cards continues to run reliably. This seems to reflect the common situation reported where some basic cards work and the fancier ones don't.

5) So, something happening in the reset process is mucking up the hardware. And whatever it is, the kernel init is not enough to fix it. Very odd.

1) Same fact : before I opened the plug, I never managed to have any SD card work. I have tested 3 different cards : a brand new Crucial SDHC 8Gb, an old Canon SD 32Mb, and an old Panasonic SD 256Mb.

2) I tested several different kernels, including orion and mainline, but none of them worked before I opened the plug. Currently, I use a mainline kernel, with patches coming from orion (especially the mvsdio one)

3) Same thing : from a cold boot (with the plug opened), all my cards work reliably when I boot on NAND. I currently don't manage to boot directly from SD (I mean, use a rootfs from SD, even if the kernel is on NAND), but it's probably another problem

4) From a soft reboot, that depends : sometimes it works, sometimes it does not. I did not notice any difference between SD and SDHC card, but I did not have enough time to make complete tests

5) What I can say, it's that a cold reboot (unplug / replug) is always safe. A soft reboot sometimes leads to -110 errors, or undetected cards

for the record, I have a SheevaPlug running Gentoo off of a 4GB SDHC card. (I am adding a 500 GB hard drive for data, but plan to keep the operating system within the confines of the card so I can copy the card for other plugs.) I have added some additional packages, but the 63% utilization may be larger by 1-2% more.

Using a 4 GB Lexar SDHC card (part # LSD4GBASBNA Rev A) I installed Gentoo linux-2.6.32-rc1(9/28/2008) with a few extras described in the ARM Install Handbook and ended up with: