Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

[Shawn Jin]

Hi,

In cfi_cmdset_0002.c, there is a piece of comment stating that the
CFI_DEVICETYPE_X8 is needed even when cfi->device_type !=
CFI_DEVICETYPE_X8. Why is it the case?

In my case, two Am29PL320D chips are interleaved and each works in 32-bit
mode. So the buswidth is 64 bits. When CFI_DEVICETYPE_x8 is used in either
erase_oneblock() or write_oneword(), the command address generated is not
right. For example, to erase a block, the following commands are generated:
    Addr: 0xff002aaa  Data: 0x000000aa000000aa
    Addr: 0xff001554  Data: 0x0000005500000055
I found out that the cfi->addr_unlock1(2) are set to 0x1555 (0xaaa) because
of CFI_DEVICETYPE_X32 in cfi_cmdset_0002().

According to the datasheet of Am29PL320D
(http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24075.pdf),
the correct addresses should be 0xff002aa8 (555 << 3) and 0xff001550 (2aa
<< 3).

So I replaced CFI_DEVICETYPE_X8 with cfi->device_type in both
do_erase_oneblock() and do_write_oneword(). I tested and found that erase
can succeed but write still fails.

Any ideas or explanations?

Thanks,
-Shawn.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

[David Vrabel]

Shawn Jin wrote:
> 
> In cfi_cmdset_0002.c, there is a piece of comment stating that the
> CFI_DEVICETYPE_X8 is needed even when cfi->device_type !=
> CFI_DEVICETYPE_X8. Why is it the case?

It appears to be to handle the case of x16 chips in x8 mode.  In such a 
case the device width is 2, interleave is 1 and buswidth is 1. 
Therefore, cfi_build_cmd_addr() will not generate the correct unlock 
addresses. (i.e., there's no integral solution to 0xaaa = addr * 
device_width (2) * interleave (1) which is the required unlock address.)

Not sure how to handle all possible arrangements of chips.

Dev. width | interleave  | buswidth |   addr1 |   addr2
-------------------------------------------------------
2          | 1           | 2        |   0xaaa |   0x554
2          | 1           | 1        |   0xaaa |   0x555
4          | 2           | 8        |  0x2aa8 |  0x1550

(addr1 and addr2 are byte addresses -- the AMD datasheets typically 
gives word addresses)

> So I replaced CFI_DEVICETYPE_X8 with cfi->device_type in both
> do_erase_oneblock() and do_write_oneword(). I tested and found that erase
> can succeed but write still fails.

Maybe you're using do_write_buffer(..) instead? There's a comment near 
it that says it may well be broken for interleaved chips, though.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

[David Woodhouse]

On Wed, 2004-02-25 at 11:08 +0000, David Vrabel wrote:
> Shawn Jin wrote:
> > 
> > In cfi_cmdset_0002.c, there is a piece of comment stating that the
> > CFI_DEVICETYPE_X8 is needed even when cfi->device_type !=
> > CFI_DEVICETYPE_X8. Why is it the case?

Because you're using it in this case to shift the unlock address. But
the unlock address was _already_ shifted, because of way the table in
jedec_probe.c works. It already gives you different unlock addresses
according to the device type, and they are _already_ shifted. You're
given a byte-address by the table and that's why you use it as one.

I suspect we could ditch the multiple entries in the table and revert to
using only one 'uaddr', and shifting it with the device type as you 
(er, he) suggest.


-- 
dwmw2

Re: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

[David Vrabel]

> Could you please explain why the cfi->addr_unlock1 is 0x1555 in the
> case of CFI_DEVICETYPE_X32?

Nope. I can't.  No 32 bit chips here.  It looks wrong to me though.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/