I have a BB -xM Rev B, serial no 4510xM751, which does not write
reliably to some brands of micro SD cards. BB can read from all the
cards fine but when the kernel needs to write to the card I get the
following errors, as shown by the following command.
[ 248.255889] mmcblk0: error -110 sending read/write command,
response 0x900, card status 0xe00
[ 259.867248] mmcblk0: error -110 transferring data, sector 752, nr
1, card status 0xe00
[ 276.210662] mmcblk0: error -110 transferring data, sector 2609, nr
1, card status 0xe00
[ 292.283935] mmcblk0: error -110 transferring data, sector 760, nr
1, card status 0xe00
[ 308.020874] mmcblk0: error -110 transferring data, sector 3801, nr
1, card status 0xe00
The only card that works OK is a Kingston Micro SDHC 4GB class 4
card.
The following cards produce the type of errors shown above.
PNY Micro SDHC 4GB class 4
ADATA Micro SDHC 4GB class 6
The test was done with the "xM TEST 20100820" image on each card.
All the cards work fine in an USB adapter on the desk top computer.
Any thoughts if this is a REV B type of problem, maybe a timing glitch
or something.
Thanks
Carl
There are no external components on the -xM to support the Sd card interface. It is straight out of the processor. One other aspect is that the voltage is 3.0V, which is at the lower end of the SD card specification.
I would look to the SW piece of the puzzle. Like, reading the card to determine the proper speed and timing for each card type in the SW and adjusting the timing accordingly.
Gerald
Thank you for the feedback, looked at the schematic and as you said
it is a simple circuit for the SD card interface. Did find some talk
about problems back in June about software changes in the mmci-omap-hs
driver on the Omap Processor Linux development list, so maybe this is
related. Do not know if the validation test kernel has the
corrections in its driver. Maybe some of the software kernel chaps
will have some thoughts on the subject and suggestions.
Thought the change in processor might have required a change in
trace routing which may have effected things, which is why I thought
of the hardware side first. Do you know if the -xM board is using the
SPI mode or native mode for communication with the SD card?
Guess it is time to start learning how SD cards interface works in
more detail.
Cheers
Carl
To my knowledge, the Uboot code is hard coded to a set frequency, Hence my response as it relates to looking at the SW as the issue. I am not sure as to the state of the Kernel. But, if it can’t read the card reliably, then the Kernel would have issues booting and potentially other issues as well, like possibly corruption of the SD card during a write process.
The processor uses the SPI mode in the internal ROM if I remember correctly. I believe it switches to the 4 bit mode after the UBoot comes up, but I may be wrong.
You could switch to the latest demo kernel and repeat the tests. You could also try other versions of the kernel with you know set of cards and see what results you get then.
I have 64 original Beagleboards used in my Manufacturing Testers. I encountered the same problem with RiDATA “Lightning Series” 2GB SD cards with the original BeagleBoard a month ago. I bought a bunch of them. The failure rate on read is higher than 50%. I tested the RiDATA cards on camera and PC. They work perfectly fine. Finally, I gave up and bought a bunch of SandDisk Ultra II cards to replace them. They are much faster to write to. I have been using PNY “OPTIMA” 60X 2GB. They are very slow on write. But, these SD cards are only used to store the kernel and rootfs. So, my suggestion is to use SandDisk cards.
The Linux MMC driver is fine. I use the second MMC bus on the Beagleboard to test my company’s product.
Gerald
My first tests where made with the Angstrom demo image, Android
image and an Ubuntu image using the procedure outlined in an article
on "Booting linux on the Beagle -xM" on the IBM developer web site.
The Android image just got to the boot splash screen, Ubuntu got to
the setup scripts but could not save the add new user information and
the script finally failed after a few attempts to create the new user,
and the Angstrom demo would get to the desktop on the first boot of a
fresh image and could play the movie via the short cut, but would then
fail to get to the desktop most of the time on the next boot cycles.
Next I got the serial port connected and working, and could see
after the Angstrom demo got to the desktop, that write errors started
to occur. I then logged in via the serial port and did some write
tests using the vi editor. but the results where not repeatable but
suggested it might be file type related. That is when I downloaded
the validation image and loaded that on the cards as it would be
running completely in ram for any testing of the cards.
Then I started to use dd to write larger files and saw that the
write failures happened on all the file types, dos, ext2 and ext3
partitions. A few days later found a Kingston card and it ran the
demo image with no write errors on the serial port and also passed the
dd write test of larger files with no write errors.
So after seeing no posting of this type of error on the message
board, I made a posting of my results as I did not know if it was just
my board, or my setup, or this production run of boards, or a general
xM problem. As the only problems I could see on the board where
related to creating the image on the SD card or power supply related
when trying to power xM from a USB cable. Since I am using a 4 amp
power supply and all my images could boot the kernel, I seemed to have
a new type of fault.
I have ordered some other brands of 4 Gig cards so I will have a
larger selection, to see if the ones that are failing have a common
feature.
Since I do not have access to a storage scope, I will not be able to
add information about the electrical signals going or coming from the
board related to the SDHC card, or check supply voltage to the
different SD cards during the write cycle.
At least I know at this point the Kingston cards do work for me, but
I have this itch about why the other brands of cards I have do not.
Also it would be nice if they could add a SD card test script to the
validation image, to test the sd card and also give you an idea of the
write/read speed of the brand of card you where using.
Cheers
Carl
I just RMA'ed an xM because it could not reliably read the kernel to
boot from any SD card I have (and I have quite a few brands).
The replacement xM works perfectly with all of the cards that I have tried.
This of course isn't conclusively a hw issue, since the linux driver
timer could possible be marginal, but it does at least raise some
suspicion that there might be some hw issues.
I just ordered a bunch of cards to go back and run them through a few boards including the ones you sent back. I would like to see the UBoot and all Kernel actually read the card to determine the proper speed. I am not sure this is the case today. There is also a question I have as to wheter or not the volatge is being set to 3V or 3.15V. It needs to be set to 3.15V to give more margin.
The SDA specify voltage from 3.0 to 3.6. I think 3.3V will be appropriate. If the SD VCC is configurable, why not 3.3V? I think the SandDisk cards are ultra user friendly. I have a bunch of RiDATA “Lightning Series” 2GB card that has very high failure rate (60%) on some Beagleboards. After I figured out those “failure cards” are perfectly good on PC and cameras, I found good deals and bought 50 SandDisk Ultra II 2GB cards instead. Previously, I used PNY OPTIMA 60X cards; but they are ultra slow to write to.
I think 3.15V will fix the problem. It is because some of the RiDATA cards that I have work okay. I initially bought 2 RiDATA cards to test them first. They both work okay on my “desktop” Beagleboard. Then, I bought 48 more. Problem followed… So, I think 3.0V is indeed marginal.
I believe that there may be an additional issue with the OMAP hsmmc
driver's computation of dto (the data timeout value). I've been able
to make most cards that don't work function with an increase in the
calculated dto value.
There's a thread on the linux-omap list discussing this.
Note that I too believe that 3.15V would be a good idea, I just don't
think that is the only issue.
Steve
I think you are right, feels like the driver is making some wrong
calculations based on what it is getting from the sd cards, and some
cards can work with it and others can not.
Will check out the linux-omap list.
Carl
However I still have 2 cards which will not work reliably on my OMAP
systems: a SanDisk 4GB Class 4 card and and an ADATA 4GB Class 6 card.
Both cards work properly on my desktop system using a SanDisk USB
dongle, which powers the cards at 3.43 V.
An interesting experiment would be to hack up a board to supply 3.3V
to the card to see whether that fixes the issue. I'm not willing to
sacrifice a board to the cause though
I need to know where the screw mount holes are located. I looked in the users guide, but no diagram has actual hole locations. Can someone point me to a good diagram for this?
