Ticket #1743 (closed defect: fixed)
Intenso SDHC 4GB gives glamo errors
| Reported by: | beni | Owned by: | openmoko-devel |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | unknown | Version: | |
| Severity: | major | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
Inserting an 4GB Intenso SDHC card into the microSD slot and with current u-boot and kernel gives glamo i/o errors.
Tested images: FSO (Milestone-II) and 2007.2 (used daily build from Aug, 2), both with provided kernel (2.6.24)
Attachments
Change History
comment:1 Changed 5 years ago by beni
(Please update http://wiki.openmoko.org/wiki/Supported_microSD_cards, if issue researched)
comment:2 Changed 5 years ago by andy
mmcblk0: mmc0:b368 SD 3931136KiB
mmcblk0:
<6>glamo-mci glamo-mci.0: Error after cmd: 0x8310
This looks like what you would get if we timed out too soon for the card, ie, the card is slow. The status shows "no data" timeout but also "data ready".
If you know how to adapt the U-Boot environment, please give this a try with a slower SD Card clock, from the kernel commandline
glamo_mci.sd_max_clk=10000000
comment:3 Changed 5 years ago by beni
i will give this a try, but dont know how to set that setting.
What steps must be performed?
comment:4 Changed 5 years ago by andy
You need to edit U-Boot environment, exactly what to do depends on how you are set up. If you don't have a debug board, you need to use minicom with /dev/ttyACM0 when in U-Boot.
Once you are in and at the U-Boot prompt, you need to adapt probably "bootargs" environment var to have glamo_mci.sd_max_clk=10000000 on it too. Use
printenv
to see the existing settings, then like
setenv bootargs glamo_mci.sd_max_clk=10000000 <original text>
then
boot
to boot. Confirm your setting was seen by the kernel by
cat /proc/cmdline
comment:5 follow-up: ↓ 6 Changed 5 years ago by beni
Ok, thank you very much.
I did the following:
--- USB console ---
GTA02v5 # setenv bootargs glamo_mci.sd_max_clk=10000000 ${bootargs_base} ${mtdparts}; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000
After pressing [ENTER] the freerunner booted.
Checking the commandline from ssh-connect gives:
root@beni_om-gta02v5:~# cat /proc/cmdline
glamo_mci.sd_max_clk=10000000 rootfstype=jffs2 root=/dev/mtdblock6 console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs)
The card is then mounted successfully and read-/writable.
Is there something else that can be done.
Performance:
root@beni_om-gta02v5:~# date +"%s"; dd if=/dev/zero of=/media/card/bigfile count=200 bs=1M; date +"%s"
1217863771
200+0 records in
200+0 records out
1217863876
=> 1.90 MB/sec
comment:6 in reply to: ↑ 5 Changed 5 years ago by andy
Replying to beni:
Ok, thank you very much.
I did the following:
--- USB console ---
GTA02v5 # setenv bootargs glamo_mci.sd_max_clk=10000000 ${bootargs_base} ${mtdparts}; nand read.e 0x32000000 kernel 0x200000; bootm 0x32000000
Nice work -- one thing though you have to protect the ; with backslash escaping, and the $ too. That'll be why it booted on pressing enter, it took the ; as command separator and finished the setenv after the first ; then did the other commands in order.
If you confirm you have the escaping right, you can use
saveenv
command to store the changed environment in NAND, then you don't need to do this each boot.
AFAIK slowing the SD CLK is the only way to impact this timeout issue for the slow cards, because we already max out the timeout allowed by the Glamo internal register. Since it counts SD Card clocks we can work around slow absolute card performance by slowing the clock.
comment:7 Changed 5 years ago by beni
I added a new menu option to boot with reduced clock, so i am able to boot with both default and modified state:
setenv menu_9 Boot with reduced SD clock: setenv bootargs glamo_mci.sd_max_clk=10000000 \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel 0x200000\; bootm 0x32000000
This gives:
root@beni_om-gta02v5:~# cat /proc/cmdline
glamo_mci.sd_max_clk=10000000 rootfstype=jffs2 root=/dev/mtdblock6 console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs)
Writing speed is:
root@beni_om-gta02v5:~# date +%s; dd if=/dev/zero of=/media/card/bigfile count=200 bs=1M; date +%s;
1217866226
200+0 records in
200+0 records out
1217866331
=> 1.904761904761904762
Reading speed is:
root@beni_om-gta02v5:~# date +%s; dd if=/media/card/bigfile of=/dev/null count=200 bs=1M; date +%s;
1217866403
200+0 records in
200+0 records out
1217866494
=> 2.197802197802197802
Where did you got the number of 10000000 from?
Other numbers to test?
comment:8 Changed 5 years ago by andy
The numbers that are meaningful here are 50MHz divided by some integer. 10MHz is /5 then. The default is 16.6MHz (/3). So you could also try 12500000 (/4).
comment:9 Changed 5 years ago by beni
- Status changed from new to in_testing
Performance with 12500000 is slightly better (as assumed):
root@beni_om-gta02v5:~# date +%s; dd if=/dev/zero of=/media/card/bigfile count=200 bs=1M; date +%s;
write:
1217873218
200+0 records in
200+0 records out
1217873315
=> 2.061855670103092783 MB/s
read:
root@beni_om-gta02v5:~# date +%s; dd if=/media/card/bigfile of=/dev/null count=200 bs=1M; date +%s;
1217873423
200+0 records in
200+0 records out
1217873500
=> 2.597402597402597403 MB/s
Its slow but it works.
comment:10 Changed 5 years ago by beni
- Status changed from in_testing to closed
- Resolution set to fixed
comment:11 Changed 5 years ago by rhk
So will this be/is this included in the kernel or if one faces this, he needs to fix it on his device?
comment:12 Changed 5 years ago by beni
It is currently not included and must be fixed manually by providing kernel start parameters.
Please may one of the devs comment on this if it will be implemented in the kernel.
comment:13 Changed 5 years ago by andy
I had a thought we can reload the timeout after the packet transfer is set up, but I don't have much clue if the Glamo accepts this immediately and I can't really test it either, except to see it doesn't trash communication with a shipped card. I'll give it a go later.
comment:14 Changed 5 years ago by montgoss
- Status changed from closed to reopened
- Resolution fixed deleted
- Severity changed from normal to major
This fix sort of works one time. But my SD card comes back mounted at
/media/mmcblk1p2 instead of /media/mmcblk0p2 and /media/mmcblk1p1
instead of /media/card.
The next time it resumed, it deleted the partition table like it used to.
Here's the last part of the dmesg output:
modem wakeup interrupt s3c2440-i2c s3c2440-i2c: slave address 0x10 s3c2440-i2c s3c2440-i2c: bus frequency set to 390 KHz gta02_udc_command(1) s3c2440-nand s3c2440-nand: Tacls=3, 30ns Twrph0=7 70ns, Twrph1=3 30ns not changing prescaler of PWM 3, since it's shared with timer4 (clock tick) timer_usec_ticks = 7864 timer tcon=00599109, tcnt a2c1, tcfg 00000200,00002000, usec 00001eb8 mmc_set_power(power_mode=1, vdd=20 SD power -> 3200mV glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x8120 usb0: full speed config #1: 500 mA, Ethernet Gadget, using CDC Ethernet mmc0: card d555 removed MMC: killing requests for dead queue mmc_set_power(power_mode=0, vdd=0 glamo-mci glamo-mci.0: glamo_mci_set_ios: power down. mmc_set_power(power_mode=1, vdd=20 SD power -> 3200mV glamo-mci glamo-mci.0: powered (vdd = 20) clk: 0kHz div=255 (req: 0kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 20) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 glamo-mci glamo-mci.0: Error after cmd: 0x120 glamo-mci glamo-mci.0: Error after cmd: 0x8120 mmc_set_power(power_mode=2, vdd=15 SD power -> 2700mV soc-audio soc-audio: scheduling resume work PM: Finishing wakeup. Restarting tasks ... <6>soc-audio soc-audio: starting resume work done. soc-audio soc-audio: resume work completed glamo-mci glamo-mci.0: powered (vdd = 15) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 195kHz div=255 (req: 195kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 10000kHz div=4 (req: 10000kHz). Bus width=0 glamo-mci glamo-mci.0: powered (vdd = 15) clk: 10000kHz div=4 (req: 10000kHz). Bus width=2 mmc0: new high speed SDHC card at address d555 mmcblk0: mmc0:d555 SU08G 7977472KiB mmcblk0: unknown partition table EXT3-fs error (device mmcblk0): ext3_check_descriptors: Block bitmap for group 0 not in group (block 3802999490)! EXT3-fs: group descriptors corrupted! mapped channel 10 to 2 Alignment trap: phone-kit (1962) PC=0x0001214c Instr=0xe5970008 Address=0xbefdf4bf FSR 0x013
comment:15 Changed 5 years ago by andy
This is a different issue.
This original bug was about failure to recognize a slow card at all, the slower sd clock workaround manages that.
Separately, there is a problem with Linux suspend / resume making trouble with SD Cards some or all of the time. That problem is also experienced by Eee PC and OLPC. Changing SD Clock won't impact it AFAIK. But I dunno why you reopened this bug instead of opening a new one since the symptoms are entirely different.
comment:16 Changed 5 years ago by montgoss
- Status changed from reopened to closed
- Resolution set to fixed
Guess I thought it was the same issue since the email thread talking about the partition table issue had mentions of this ticket. I'll go ahead and open a new ticket if you think that's cleaner.
comment:17 Changed 5 years ago by andy
Folks on this bug might be interested to try a patch that should be in the kernels tomorrow
http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=9e7ba57b104e9293f746342b7450b10d5fa0c4cd
comment:18 Changed 3 years ago by skliarie
I have an Sandisk 8GB MicroSDHC card that usually works ok, but once I start to fill it faster than certain speed, the SDHC locks up hard and following error appears in dmesg:
<6>[ 9479.220000] glamo-mci glamo-mci.0: Error after cmd: 0x4120
<3>[ 9479.220000] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x400900
The kernel is provided by the android-on-freerunner week-2009-44 (cat /proc/version):
Linux version 2.6.29-rc3-mokodev (serdar@…) (gcc version 4.2.1) #1 PREEMPT Sat Oct 24 16:06:35 CEST 2009
Is my problem related to this bug?
Is there a way to change the kernel glamo_mci.sd_max_clk variable using a /sys or /proc entry?
comment:19 Changed 3 years ago by skliarie
I did "dmesg | grep glamo" and attached the result to this email.
I also tried to do
cd /sys/module/glamo_mci/parameters/
echo 10000000 > sd_max_clk
echo 3 > sd_drive
But still got the following after "cat /dev/zero > /sdcard/zero":
<6>[ 255.795000] glamo-mci glamo-mci.0: Error after cmd: 0xc120
<3>[ 255.795000] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x400900
I then tried to do
echo 5000000 > sd_max_clk
and got no more sdcard errors! The write speed was acceptable 2.800 MBytes/s.
Is there a way for the kernel to automatically detect such "slow" cards as I have and adjust the clock rate correspondingly?
comment:20 Changed 3 years ago by skliarie
The "echo 5000000 > sd_max_clk" worked for me when the card was mostly empty. Once I started filling it up, is started locking up again. I then emptied the SD and now it takes much more writes to lock up the card (but it still locks up eventually).
I guess this has something to do with nature of SD media that needs to move blocks around so it would be able to erase a full block.
Can the bug be reopened (I don't have permissions to do that) or should I open a new bug?

dmesg log with intenso SDHC 4 GB in place