Ticket #93 (closed defect: fixed)
test 4GB microSD card compatibility
| Reported by: | laforge@… | Owned by: | drzeus-bugzilla@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | kernel | Version: | current svn head |
| Severity: | normal | Keywords: | |
| Cc: | buglog@…, pavel@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
those cards are new, and we don't know whether the linux mmc stack can deal with
them.
Change History
comment:2 Changed 6 years ago by laforge@…
I have added that patch from 2.6.21-rcX mainline to rev. 1237 of our patchset.
Still waiting for a card to verify this...
comment:4 Changed 6 years ago by stefan@…
It seems more and more shops have this cards now. We should give it another try
to obtain such a card.
comment:5 Changed 6 years ago by stefan@…
- Owner changed from laforge@… to drzeus-bugzilla@…
Reassigned to Pierre Ossman, SD/MMC kernel maintainer. Once he is able to get a
card he will test it.
comment:7 Changed 6 years ago by pavel@…
Hmm, Bv4 machine here works ok (after some complains in syslog) with provided
128MB card, but errors out with A-data 2GB microSD card :-(.
comment:8 Changed 6 years ago by pavel@…
(Actually, even with provided 128MB sdcard, I got errors after streaming 40MB of
data over scp).
comment:10 Changed 6 years ago by drzeus-bugzilla@…
Do you have a dmesg so we can see what the error is?
comment:11 Changed 6 years ago by pavel@…
Do you have a dmesg so we can see what the error is?
Hmm, it now says:
<4>adc_read: entering (pcf=c07dac00, channel=0, data2=00000000)
<4>pcf50606_irq: entering(irq=60, pcf=c07dac00): scheduling work
<4>pcf50606_work: INT1=0x40 INT2=0x00 INT3=0x01:SECOND ADCRDY
<4>adc_read: returning 647 0
<4>mapped channel 0 to 0
<7>mmc_set_power(power_mode=0, vdd=0
<6>s3c2410-sdi s3c2410-sdi: powered down.
<7>mmc_set_power(power_mode=1, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 0kHz (requested: 0kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<6>s3c2410-sdi s3c2410-sdi: initialisation done.
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 99kHz (requested: 98kHz).
<7>mmc_set_power(power_mode=0, vdd=0
<6>s3c2410-sdi s3c2410-sdi: powered down.
<4>adc_read: entering (pcf=c07dac00, channel=0, data2=00000000)
<4>pcf50606_irq: entering(irq=60, pcf=c07dac00): scheduling work
<4>pcf50606_work: INT1=0x40 INT2=0x00 INT3=0x01:SECOND ADCRDY
<4>adc_read: returning 647 0
root@fic-gta01:/lib/modules/2.6.21.1-moko10/kernel$
...but I'm pretty sure I seen scarier messages before...? Kernel is
may-19 one from .../tmp/deploy, this is generated while modprobing the
hci module.
comment:12 Changed 6 years ago by pavel@…
Successful attempt (on phase1 openmoko, with original kernel) looks like:
<6>Freeing init memory: 108K <7>mmc_set_power(power_mode=1, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 0kHz (requested: 0kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20 <6>s3c2410-sdi s3c2410-sdi: running at
130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 130kHz (requested: 129kHz).
<7>mmc_set_power(power_mode=2, vdd=20 <6>s3c2410-sdi s3c2410-sdi: running at
130kHz (requested: 129kHz).
<4>mmc0: Problem switching card into high-speed mode!
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 16625kHz (requested: 25000kHz).
<7>mmc_set_power(power_mode=2, vdd=20
<6>s3c2410-sdi s3c2410-sdi: running at 16625kHz (requested: 25000kHz).
<6>mmcblk0: mmc0:e624 SU128 123008KiB
<6> mmcblk0: p1
<7>PM: Removing info for No Bus:vcs1
<7>PM: Removing info for No Bus:vcsa1
<7>PM: Removing info for No Bus:vcs1
<7>PM: Removing info for No Bus:vcsa1
<7>PM: Removing info for No Bus:vcs1
<7>PM: Removing info for No Bus:vcsa1
<7>PM: Removing info for No Bus:vcs1
<7>PM: Removing info for No Bus:vcsa1
<7>PM: Removing info for No Bus:vcs1 <7>PM: Removing info for No Bus:vcsa1
<6>yaffs: dev is 266338304 name is "mmcblk0"
<4>yaffs: Attempting MTD mount on 254.0, "mmcblk0"
<6>yaffs: dev is 266338304 name is "mmcblk0"
<4>yaffs: Attempting MTD mount on 254.0, "mmcblk0"
comment:13 Changed 6 years ago by pavel@…
...but if I actually try to _use_ the 128MB card in phase 1 openmoko, I get:
<4>adc_read: returning 660 0
<3>s3c2410-sdi s3c2410-sdi: unfinished write - pio_count:[1024] pio_words:[0]
<3>mmcblk0: error 4 transferring data
<4>end_request: I/O error, dev mmcblk0, sector 162187
<3>s3c2410-sdi s3c2410-sdi: mci_setup_data() transfer stillin progress.
<3>mmcblk0: error 3 transferring data
<4>end_request: I/O error, dev mmcblk0, sector 148075
<3>Buffer I/O error on device mmcblk0p1, logical block 73989
<4>lost page write due to I/O error on mmcblk0p1
<4>IO error syncing ext2 inode [mmcblk0p1:0000484b]
(scp streaming files to the card)
comment:14 Changed 6 years ago by pavel@…
<3>s3c2410-sdi s3c2410-sdi: unfinished write - pio_count:[1024] pio_words:[0]
<3>mmcblk0: error 4 transferring data
<4>end_request: I/O error, dev mmcblk0, sector 177327
<3>s3c2410-sdi s3c2410-sdi: mci_setup_data() transfer stillin progress.
<3>mmcblk0: error 3 transferring data
<4>end_request: I/O error, dev mmcblk0, sector 148077
<3>Buffer I/O error on device mmcblk0p1, logical block 73990
<4>lost page write due to I/O error on mmcblk0p1
<4>IO error syncing ext2 inode [mmcblk0p1:00004852]
...another problem from the same scp. Interesting, logical blocks are near each
other?
Anyway the cards works okay in usb reader.
comment:15 Changed 6 years ago by drzeus-bugzilla@…
Looks like a controller/driver problem. I haven't had time to get intimate with
it yet, but I'll look closer at this as I do.
comment:16 Changed 6 years ago by stefan@…
I finally was able to get a 4GB microSDHC card from sandisk.
Correct size was found:
/dev/mmcblk0p1 3.8G 32.0k 3.8G 0% /media/card
That's the same I get with the card inside the usb reader delivered with the card.
Coping around a 6MB file 600 times to use up most of the space showed up the
following in dmesg:
<3>s3c2410-sdi s3c2410-sdi: unfinished write - pio_count:[2048] pio_words:[0]
<3>mmcblk0: error 4 transferring data
No IO errors on the shell.
Kernel was: Linux fic-gta01 2.6.21.5-moko10 #1 PREEMPT Tue Aug 14 21:54:17 CEST
2007 armv4tl unknown
comment:17 Changed 6 years ago by laforge@…
please add to http://wiki.openmoko.org/wiki/Supported_microSD_cards
also, please verify the data consistency after having seen that write bug. Just
add a file compare to your test script. Also, please re-test using
signifnicantly bigger files (256MB at least) since they should exceed the RAM
size of the system to make sure they cannot be cached...
comment:18 Changed 6 years ago by gnu@…
If you are able to access the card at all, then you have SDHC support in the
kernel. (SDHC cards use a different initialization sequence so that trying to
access them from non-SDHC drivers will fail immediately rather than returning
garbled results from trying to read big filesystems.) After initialization, the
only difference in SDHC I/O commands is that the former byte-address of an SD
read or write has become a block-address in SDHC.
Sounds like there's still some bug in the driver -- but probably not SDHC
related. One possible way to isolate it might be to see if you can reproduce it
by writing the output of a deterministic sequence (whether it's 1, 2, 3, ... or
the output of rand() or whatever) that's calculated by the CPU rather than read
from another I/O interface. If SD fails on those writes (or worse -- if it
doesn't fail but the data doesn't read back identical later) then you have an
SD-only problem. If that works, but scp or wget to SD fails, then maybe you
have a bus contention problem or something like that.
comment:19 Changed 6 years ago by stefan@…
Transfer a 800MB file over scp gives a lot more errors in dmesg and scp shows an
IO error after transfer.
This really looks more like a general s3cmci driver problem already noted in:
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=677
comment:20 Changed 6 years ago by stefan@…
- Status changed from assigned to closed
- Resolution set to fixed
After #677 got fixed I have no more problems.
I copied an 800MB file from the host via usbnet to the card, copied it two times
more on the card and finally transfered one of the copies back to the host and
tested on differences with cmp(1). Files were identically. :)
I also had a look at dmesg for s3cmci errors, but none showed up.
So SDHC support works fine. I'll update the table in the wiki accordingly.
comment:21 Changed 5 years ago by anonymous
Milestone Phase 2 deleted

Generell support for SDHC was added to the kernel:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fba68bd2dab1ac99af3c5a963ec9581cfa9f1725
We need to test real cards anyway.