FW: Why CFI_DEVICETYPE_X8 in cfi_send_gen_cmd()?
xiaogeng_jin at agilent.com
xiaogeng_jin at agilent.com
Thu Feb 26 13:08:33 EST 2004
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. ???
More information about the linux-mtd