jffs2 on DOC
dwmw2 at infradead.org
Sat Dec 1 04:32:23 EST 2001
brown at osdsun1.nrl.navy.mil said:
> But first, I'm just trying to get jffs2 running on the entire, raw DOC
> device, without an NFTL boot partition. The problem I'm having
> initially is that jffs2 is getting short reads from the doc2000
This is just a symptom of the fact that the doc2000 driver wasn't written
to be a proper generic MTD driver, so I cut some corners. You should modify
the doc2k code to play nicely, doing longer reads/writes/erases etc.
> So my question is, what is the intended semantics of read(),
> read_ecc(), write(), and write_ecc()? I can't seem to find any
> clients of read_ecc() or write_ecc(), so I can't figure out why a
> client would need access to the ecc buffer.
The NFTL code needs it - currently, it writes the 512 byte data block, then
does a second write to write the contents of the ECC buffer, generated by
the first write.
> If I'm reading the code right, it won't work correctly if the start
> of the write is not block-aligned. The DOC driver will do ECC on
> writes no matter which interface you use (write() or write_ecc()), but
> again it requires a full-block write for proper operation. This is
> all very confusing.
NAND flash chips have restrictions on the number of times you can write to
any given 512-byte page between erases. That number can apparently be as
low as 1 write cycle to the main data area, and 2 write cycles to the spare
So you _have_ to write the whole 512 bytes at a time, because otherwise you
can't fill the rest without erasing the whole erase block and starting
JFFS2 will need modification to deal with this - probably by caching the
512-byte page which is pending, then writing it out in one go. This way, we
have the added bonus that we can make use of the hardware ECC which the
DiskOnChip and some SmartMedia hardware is capable of, which is limited to
JFFS2 will also need some other mods for operation on NAND flash, but the
above is the main task.
More information about the linux-mtd