Strange kernel crashes when probing intel strata flash
Lukas Heiniger
lh_mail at gmx.net
Wed Oct 27 09:55:09 EDT 2004
Hi all
We're facing strange problems with our intel strata flash. In some cases
the kernel crashes while probing the flash (see oops message below). The
crash occurs in cfi_probe_chip() around
cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL);
(http://lxr.linux.no/source/drivers/mtd/chips/cfi_probe.c?v=2.6.8.1;a=arm#L85)
The strange thing is that the crashes do not occur randomly. The
behaviour seems to change only if we use our bootloader to download
something new to the flash (kernel, rootfs etc). I.e. after a download
the kernel either always crashes at the point mentioned or it always
boots correctly. Yes, this sounds like a bootloader issue, but what
permanent change could a bootloader make, that would cause the kernel to
crash?
The other strange thing is, that inserting printks for debugging into
cfi_send_gen_cmd() seems to be a reliable remedy. A kernel with a printk
inserted before map_write() in cfi_send_gen_cmd() never crashed up to
now. Even a mdelay(100) works. Timing issue, you might say. But then,
why do we have phases where the kernel boots happily without any printk
until we do the next flash download via bootloader?
Also, the 0xF0 command which is the first commmand to be sent to the
flash, is not documented in the datasheet. I guess it's required by
other flash types. Could it be that this command puts our flash into an
undefined state under certain circumstances?
Thanks in advance
Lukas
System setup:
Bootloader: U-Boot 1.0.0
Kernel: Linux-2.6.9-rc4
Controller: Hynix HMS30C7202
Flash: 2 x Intel 28F128J3, 16MB, 16Bit, Interleave = 1
--
Internal error: Oops: 0 [#1]
CPU: 0
pc : [<c011dc58>] lr : [<c011dbd8>] Not tainted
sp : c027becc ip : 00000000 fp : c027bf28
r10: c027bf30 r9 : 00000055 r8 : 00000000
r7 : 00000002 r6 : c01c45f0 r5 : 00000001 r4 : 00000002
r3 : c1880000 r2 : 00000098 r1 : 00000002 r0 : 00000001
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: 217F Table: 4000401D DAC: 0000001D
Stack: (0xc027becc to 0xc027c000)
bec0: 00000020 c01fa577 00000010 00000000
0000001e
bee0: c027bf24 00000002 c027befc c027bf24 c027befc 00000098 000000ff
000000f0
bf00: 00000001 00000002 00000000 c0016fd0 c01c45f0 c027bf30 c01c458c
c027bf90
bf20: c027bf2c c0123a28 c011d9d8 0000075d 00000000 00000000 00000001
00000001
bf40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bf60: 00000000 00000000 c01c4574 c01a16dc c01c45f0 c0016fd0 00000000
00000000
bf80: c01c46e8 c027bfac c027bf94 c011c9bc c01239b8 c027a000 00000000
c01c45f0
bfa0: c027bfd4 c027bfb0 c0013470 c011c974 c027a000 c0016fa4 00000001
c0016fd0
bfc0: 00000000 00000000 c027bff4 c027bfd8 c0018150 c00133f4 00000000
00000000
bfe0: 00000000 00000000 00000000 c027bff8 c002f534 c00180b0 e92ddff0
e24cb004
Backtrace:
[<c011d9c8>] ($a+0x0/0x87c) from [<c0123a28>] ($a+0x80/0x2f4)
[<c01239a8>] ($a+0x0/0x2f4) from [<c011c9bc>] ($a+0x58/0xc8)
[<c011c964>] ($a+0x0/0xc8) from [<c0013470>] ($a+0x8c/0x13c)
r6 = C01C45F0 r5 = 00000000 r4 = C027A000
[<c00133e4>] ($a+0x0/0x13c) from [<c0018150>] ($a+0xb0/0x1e8)
[<c00180a0>] ($a+0x0/0x1e8) from [<c002f534>] (do_exit+0x0/0xc7c)
r7 = 00000000 r6 = 00000000 r5 = 00000000 r4 = 00000000
Code: 07c32009 0a000006 e3530002 0596300c (018320b9)
>>LR; c011dbd8 <cfi_probe_chip+210/cb4>
>>PC; c011dc58 <cfi_probe_chip+290/cb4> <=====
Code; c011dc48 <cfi_probe_chip+280/cb4>
00000000 <_PC>:
Code; c011dc48 <cfi_probe_chip+280/cb4>
0: 07c32009 streqb r2, [r3, r9]
Code; c011dc4c <cfi_probe_chip+284/cb4>
4: 0a000006 beq 24 <_PC+0x24>
Code; c011dc50 <cfi_probe_chip+288/cb4>
8: e3530002 cmp r3, #2 ; 0x2
Code; c011dc54 <cfi_probe_chip+28c/cb4>
c: 0596300c ldreq r3, [r6, #12]
Code; c011dc58 <cfi_probe_chip+290/cb4>
10: 018320b9 streqh r2, [r3, r9]
More information about the linux-mtd
mailing list