JEDEC probing redux

Joshua Wise joshua at joshuawise.com
Sat Nov 15 01:09:38 EST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, the never-ending search for the working flash chip on the iPAQ h1910. I 
think I know what the problem is now, but I'd like someone else to confirm my 
theory ...

But first, some background. On the iPAQ h1910, we have an LV400BT chip (id 
0001/22B9) that we probe by JEDEC. The chip expects unlock addresses of 
0x555/0x2AA in word mode.

However, HP had to throw a twist in - they shifted the address lines over one. 
A1 on the CPU is connected to A0 on the flash chip, etcetera, so we have to 
left-shift the unlock addresses. I added code to jedec_probe.c to do that in 
a retry loop not unlike what we do to find the actual unlock addresses, and 
it seemed to detect the chip. However, jedec_match() seems to be failing, as 
I'm actually left-shifting the unlock addresses in the CFI structure. (IE, 
jedec_match() expects unlock addresses 0x555 0x2AA for this chip, but it's 
seeing 0xAAA 0x554.)

I'm thinking two things here: 1) I'm assuming that the unlock address verify 
is just paranoia. Can I nuke that? (Will it break anyone's board?) and 2) Is 
there a better way to say that we should be left-shifting all the unlock 
addresses over?

In the mean time, I'll nuke the unlock address verify in jedec_match, and see 
if that solves my problem.

/joshua

(For those who want my evidence, it follows. I've forced the JEDEC code to 
only probe the uaddr_idx that I'm looking for right now, just to save debug 
output. Lines beginning with --- denote my commentary.)

<5>iPAQ flash: probing 16-bit flash bus, window=c4851000 with JEDEC.
<5>uaddr_idx ok, go go go!
- --- Alright, our uaddr_idx is ok. We start probing now.
<7>cfi_send_gen_cmd: writing 00F0 at 00000000
<7>cfi_send_gen_cmd: writing 00FF at 00000000
<7>cfi_send_gen_cmd: writing 00AA at 00000555
<7>cfi_send_gen_cmd: writing 0055 at 000002AA
<7>cfi_send_gen_cmd: writing 0090 at 00000555
- --- This is my instrumentation, fwiw. I found it helpful.
- --- These would be correct addresses if the chip was straight-through.
- --- But it isn't, so later, we left-shift ....
<6>Search for id:(75 ea00) interleave(1) type(2)
<7>cfi_send_gen_cmd: writing 00F0 at 00000000
<7>cfi_send_gen_cmd: writing 00FF at 00000000
<7>cfi_send_gen_cmd: writing 00AA at 00000AAA
<7>cfi_send_gen_cmd: writing 0055 at 00000554
<7>cfi_send_gen_cmd: writing 0090 at 00000AAA
- --- These are what I've really got to write.
<6>Search for id:(01 22b9) interleave(1) type(2)
- --- And what do you know, it worked.
<6>MTD jedec_match(): Check fit 0x00000000 + 0x00080000 = 0x00080000
<6>MTD jedec_match(): check unlock addrs 0x0aaa 0x0554
<6>MTD jedec_match(): 0x0555 0x02aa did not match
- --- ... At least until jedec_match() puked.

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/tcMiPn9tWOqA4LMRAsboAJwNPmh8KBSs9429JwZdQ6KK4NjGLgCdH/qk
OaCN+d/HAgsmpv7cfIAqxLY=
=KjwV
-----END PGP SIGNATURE-----




More information about the linux-mtd mailing list