From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237] helo=passion.cambridge.redhat.com) by pentafluge.infradead.org with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 16A6Ls-0002Ts-00 for ; Sat, 01 Dec 2001 09:22:28 +0000 From: David Woodhouse In-Reply-To: <004301c17771$1a4c1c90$d082fa84@superfortress> References: <004301c17771$1a4c1c90$d082fa84@superfortress> To: "Dan Brown" Cc: linux-mtd@lists.infradead.org Subject: Re: jffs2 on DOC Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Dec 2001 09:32:23 +0000 Message-ID: <15578.1007199143@redhat.com> Sender: linux-mtd-admin@lists.infradead.org Errors-To: linux-mtd-admin@lists.infradead.org List-Help: List-Post: List-Subscribe: , List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: brown@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