FW: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?

[xiaogeng_jin at agilent.com]

Somehow, this email got denied. Isn't my outlook broken?

So I just forward to the list. Sorry for the duplicate emails.

> -----Original Message-----
> From: JIN,XIAOGENG (A-Americas,ex1) 
> Sent: Wednesday, February 25, 2004 4:02 PM
> To: 'David Vrabel'; linux-mtd list
> Subject: RE: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?
> 
> 
> Thank you very much for your reply. Some further questions. ;)
> 
> > > 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.)
> 
> Could you please explain why the cfi->addr_unlock1 is 0x1555 
> in the case of CFI_DEVICETYPE_X32? I got a little bit 
> confused here. For example, Am29PL320D is AMD's first 32-bit 
> flash memory. Assuming the buswidth is 4, interleave is 1, 
> and the device width is 4, 0x555 is the unlock address 
> according to the table of command definitions in the 
> datasheet. Thus the cfi->addr_unlock1 should be 0x555 not 
> 0x1555. We don't need to shift the unlock address in this 
> example. Is the reasoning correct?
> 
> > Not sure how to handle all possible arrangements of chips.
> > 
> >     Dev. width | interleave  | buswidth |   addr1 |   addr2
> >     -------------------------------------------------------
> >I.   2          | 1           | 2        |   0xaaa |   0x554
> >II.  2          | 1           | 1        |   0xaaa |   0x555
> >III. 4          | 2           | 8        |  0x2aa8 |  0x1550
> > 
> > (addr1 and addr2 are byte addresses -- the AMD datasheets typically 
> > gives word addresses)
> > 
> Hmmm...the case III cannot be handled by the current code, 
> right? Then I can just treat it as a special case.
> 
> > > 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.
> > 
> I surely use do_write_oneword() not write_buffer(). Actually 
> erase doesn't always succeed. Use the utility 'erase' coming 
> from CVS, I tested erasing multiple blocks and found that 
> only the 1st block is erased. For example, 'erase /dev/mtd1 0 
> 2' only erases the first block (512KiB). However 'erase 
> /dev/mtd1 0x80000' can erase the 2nd block in /dev/mtd1.
> 
> But write still cannot write even a word.
> 
> Is Am29PL320D so special that the current code cannot handle 
> it? I think mtd stuff is generic enough. ???
> 
> -Shawn.
>