* Re: cfi_cmdset_0020.c
2002-11-06 15:03 cfi_cmdset_0020.c J B
@ 2002-11-06 15:46 ` Jörn Engel
0 siblings, 0 replies; 2+ messages in thread
From: Jörn Engel @ 2002-11-06 15:46 UTC (permalink / raw)
To: J B; +Cc: linux-mtd
On Wed, 6 November 2002 09:03:03 -0600, J B wrote:
[one big block without structure, oh well] ;-)
The M58LW064A chips has two sizes that might be confused but are
orthogonal in semantics:
- Buffer size. When writing to flash, data is copied into a write
buffer and then written to flash by the chip itself.
- Page size. The ecc checksum is written to flash itself. This is done
for one page (8 bytes) at a time. Due to ecc, it can only be written
once before deleting the erase block again.
Writing it again would cause some some ecc bits to switch from 0 to
1, impossible for flash.
> I have a couple of questions reguarding the patch you released a while
> ago to support the M58LW064A STMicro flash chip. I noticed that you set
> the eccsize in the mtd_info structure to 8, and in your patch for jffs2,
> you used this as the size of the wbuf for writes in nor_wbuf.c. Isn't this
> value really the minimum buffer size for the flash chip?
This is the page size. In effect, it also is the minimum buffer size,
yes. And it is the granularity that ecc checksums are calculated from.
> If so, since your
> patch for jffs2 is based on NAND chips, wouldn't it make more sense to use
> the oobblock variable in the mtd_info structure to represent the size of
> the buffer?
Maybe, but you have to try really hard convincing me. You can view the
checksum as oob data, but there is no way to take a look at the data
or even change it. For NAND, as I understand it, the oob data is used
to store data in, the erasemarkers e.g.
And, the eccsize variable appeared to be unused. David didn't object,
so in effect I defined eccsize to be pagesize for NOR flashes. :-)
> There could be other reasons you used eccsize that I am
> missing and if so please forgive my ignorance ;). Also, is there a reason
> you decided to use the minimum buffer size for the wbuf?
The write buffer is a Bad Thing (tm). Try writing to flash, cut the
power, reboot and look at the messages. The last chunk of data will be
missing in 7 out of 8 cases.
The smaller the write buffer is, the better. Zero would be perfect,
but the chip does not allow us to go below 8.
> According to the
> datasheet for those chips, the buffer can hold up to 32 bytes. Wouldn't
> using the maximum buffer available make things more efficient?
32 bytes are used for writing (at least I think so, should check it
again). The write buffer is a different beast, it is the amount of
data that is held back and not written, in case your write doesn't end
on a page boundary.
The ecc chips take some time before you really understand what they
are doing. And the data cheet is not as clear, as it could be. But I
hope, this explains the most important bits to you.
Jörn
--
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein
^ permalink raw reply [flat|nested] 2+ messages in thread