4 AM29LV800B's in 16-bit mode?

Thayne Harbaugh tharbaugh at lnxi.com
Tue Jun 3 14:01:52 EDT 2003


On Mon, 2003-06-02 at 14:32, carolyn.j.smith at exgate.tek.com wrote:
> My board (Wind River's SBC8240) has 4 AM29LV800B chips in 16-bit mode
> (verified that BYTE# is high using a scope) with buswidth 64 bits for a
> total of 4 MB.
> 
> I am using the "jedec_probe" code. With the buswidth set to 8, the chips are
> not detected at all. 
>
> With the buswidth set to 4, the chips are recognized as long as I modify the
> unlock addresses to be MTD_UADDR_DONT_CARE instead of

Obviously not the desired buswidth of 8.

Some chips will ID without the unlock sequence, but the unlock sequence
is still required for other functionality.

> MTD_UADDR_0x0AAA_0x0555 and MTD_UADDR_0x0555_0x02AA but erasing the
> resulting device fails in do_erase_oneblock. 

Erase fails because the correct unlock addresses are required for
destructive functions (erase/write).

> 
> Any suggestions?

I think what is happening is that the unlock addresses are not being
intelligently "guessed" by jedec_probe_chip().  I have been slowly
rewriting all of jedec_probe.c as is needed and I have long anticipated
that the unlock addresses seeds are a poor way of dealing with a known
list of flash parts.  I think now is the time that this piece of code is
fixed.

This is what you can do to test my hypothesis:

At the top of jedec_probe_chip() is a FIXME comment about the unlock
address seeds.  Completely remove the "switch(cfi->device_type) { ... }"
statement and replace it with "cfi->addr_unlock1 = 0x0555;
cfi->addr_unlock2 = 0x02AA;"

That effectively hard-codes the correct unlock address for your chips. 
If that fixes the problem then I'll send you a patch that is more
generic that doesn't break other chips.

> Carolyn
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20030603/6e651763/attachment.bin 


More information about the linux-mtd mailing list