Ticket #1743 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

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

dmesg.log (14.0 KB) - added by beni 6 years ago.
dmesg log with intenso SDHC 4 GB in place
dmesg_grep_glamo.log (2.0 KB) - added by skliarie 5 years ago.
Sandisk 8GB

Change History

Changed 6 years ago by beni

dmesg log with intenso SDHC 4 GB in place

comment:1 Changed 6 years ago by beni

(Please update http://wiki.openmoko.org/wiki/Supported_microSD_cards, if issue researched)

comment:2 Changed 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 years ago by beni

  • Status changed from in_testing to closed
  • Resolution set to fixed

comment:11 Changed 6 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 6 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 6 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 6 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 6 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 6 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 6 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 5 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 5 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?

Changed 5 years ago by skliarie

Sandisk 8GB

comment:20 Changed 5 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?

comment:21 Changed 5 years ago by skliarie

I have opened separate bug #2322 on the issue I have with the 8GB SanDisk? card.

Note: See TracTickets for help on using tickets.