> -----Original Message-----
> From: yaffs-bounces@lists.aleph1.co.uk [mailto:yaffs-
> bounces@lists.aleph1.co.uk] On Behalf Of Jens Rudberg
> Sent: Tuesday, 22 June 2010 12:58 AM
> To: yaffs@lists.aleph1.co.uk
> Subject: [Yaffs] NAND chip internal cache and Multi-page read/writes
>
> Hi All,
> We are using Yaffs2 in a project and have implemented the "direct"
> interface for the Analog blackfin 52x and a Micron NAND Flash.
> The nand memory we use have an internal single page cache and implements
> a few nice features:
> - Internal data move: Read (00h + 35h), Program (85h + 10h)
I think page-to-page copy is generally frowned upon - because, as the data isn't ECCed as it's copied, you can end up accumulating errors over time.
> - Program page cache mode: (80h + 15h) + (last write in sequence
> terminated with a 10h)
>From my brief glance at the ONFI spec, there shouldn't need to be much filesystem support needed for this - it's just a program command that lets you keep sending data before the first page is guaranteed to have hit Flash. In that case, it would surely only require your NAND driver to return "OK" early to Yaffs, hope for more data to write, and send 10h if it doesn't get it?
> - Page read cache mode (random & sequential)
>
> However with the current Direct interface it's hard to make use of those
> nice features.
> Have anyone extended the Yaffs2 direct interface to make use of similar
> features?
>
I see what you mean here - you'd either need to do your own lookahead and try and guess what pages Yaffs will want next, or somehow get Yaffs to tell you what pages it will want a little bit in advance of actually asking for them.
Even though my device doesn't have cached read mode, this would be useful for me, too - the hardware wouldn't have to sit idle waiting for the CPU to finish with the last page it read, and the CPU wouldn't have to wait for the hardware to decode the next page after it's done with the last one...
J
(text/plain)