Re: [Yaffs] bit error rates --> a vendor speaks

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Artem B. Bityutskiy
Date:  
To: Josh Boyer
CC: Vitaly Wool, yaffs, Charles Manning, linux-mtd, tglx
Subject: Re: [Yaffs] bit error rates --> a vendor speaks
Artem B. Bityutskiy wrote:
> But this does not mean that we should remove OOB support. Again, the
> right (IMO, of couse) way is to make several levels of generalization.
>
> Just off the top of my head:
>
> 1. MTD level: a generic flash model with nothion of eraseblock, a
> mimimal I/O unit, read and write operations, nothing else. This level is
> for properly designed software.
>
> 2. NAND flash level: here you have OOB access. Work in terms of NAND
> pages, etc. Here YAFFS could be happy.
>
> 3. We could also have a DataFlash layer, where DataFlash guys could make
> use of their blocks and sectores, use features note visible from the
> topmost generic MTD layer.

We can put that this way:

The topmost layer is MTD which provides a uniform and generic way to
access all flash devices: NOR, NAND, AG-AND, DataFlash, OneNAND, ECC-ed
NORs, and "whataver the hack". Here you don't even notice the divverence
between them.

Below this MTD layer we could have a NOR layer (generalizes all NOR
flashes), NAND layer (generalizes all NAND flashes), DataFlash layer
(generalizes all DataFlash flashes) and so on. YAFFS could then work
with NAND layer, not with MTD layer, because it is NAND-oriented.

Again, this is a question of proper MTD layering, and just saying that
we don't support OOB is a lazy way to solve problems, IMO.

--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.