jffs2 on DOC

[David Woodhouse]

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
> driver. 

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 
data area.

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
again. 

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
512-byte blocks.

JFFS2 will also need some other mods for operation on NAND flash, but the 
above is the main task.

--
dwmw2