This is the mail archive of the
mailing list for the eCos project.
Re: Re: NAND flash driver considerations: RFC
>> I don't see there being any problem mixing up NOR and NAND drivers in
>> packages/dev/flash/ The CDL rules will prevent somebody from trying to
>> use a NAND driver with the NOR generic parts and vica-verse.
> I am not sure. NOR and NAND are really very different, not only
> internally but also in the API to higher layers.
> E.g., NAND flash file systems usually use the spare area on the flash to
> write meta-data; they handle the ECC explicitly; they are aware
> of/manage bad blocks etc. NOR flash is memory-mapped, NAND cannot be. In
> consequence, literally nothing of the io/flash/common code can be used
> for NAND flash.
Sure, but that is not an issue when we talk about what files go where
in the directory hierarchy of packages. They are all device drivers
for flash devices.
> So, if we keep NAND under flash/, we would have io/flash/common and
> io/flash/nand/common. 2nd prize in beauty contest. Then, where should
> individual controller/chip packages go? Either under devs/flash/nand/,
> so not on a level with NOR parts; or under devs/flash/, obfuscating the
> fact that they are not interested in io/flash/common but in
> io/flash/nand/common/. This all seemed not very good to me and I moved
> away from my initial, obvious idea of 'keep (NAND) flash with (NOR)
There are many different ways at looking at the packages. The CDL
language imposes a hierarchy as well which has nothing to do with the
directory hierarchy. We could have packages/io/flash_nand/current for
the common code. This is not unknown. Eg we have packages/net/tcpip
and packages/net/bsd_tcpip. The first one is no longer supported and
the second one is what everybody uses.
I don't really see that mixing up the packages is obfuscating them. We
already have two different classes of flash drivers in
packages/dev/flash. We have chip drivers and we have target board
drivers. When the flash_v2 branch gets merged in we will have another
two classes added.
What is important here is the CDL. The new packages need to have
so that they are correctly placed into the CDL tree and only active
> Well, ONFI is recent, so although many chips support most of the ONFI
> command set (e.g. page program command = 0x80), they are often not
> *completely* compliant. E.g. the chip I am working with now has a custom
> command for interrogation, which is used to get essential parameters
> like block/page size, #blocks, x8 or x16, etc. So I needed to write a
> chip-specific piece of code to handle that. We wouldn't want every
> platform to repeat the chip-specific code. That is the reason that I
> think a NAND chip device type is required.
O.K. Now i understand.
> The code for the *basic* API is something like this.
> Example: program (within) one page:
> cyg_nand_page_program(cyg_nand_t *nand,
> const void *data, size_t len,
> size_t col, size_t row,
> const void *spare, size_t spare_len)
> must implement the ONFI command sequence for page program. So, it is
> essentially implemented as follows:
> nand->cmd(nand, 0x80);
> nand->addr(nand, col, row);
> nand->program_data(nand, data, len);
> nand->goto_addr(nand, spare_offset, row);
> nand->program_data(nand, spare, spare_len);
> nand->cmd(nand, 0x10);
> nand->await_status(nand, 6);
> where the indirect calls are implemented by the specific controller.
> A minimal set of other calls would be:
> cyg_nand_chip_select(nand, chip_number)
Given this API, what does the device filenames /dev/nand0/1 have to do
with anything. How do i get from a file descriptor returned with
open() to a cyg_nand_t * nand structure? Do file descriptors and /dev/
files make any sense? The NOR devices don't do this?
> I agree with your remark above that a higher-level API is also
> desirable. For starters, if the nand chips have identical page/block
> size, spare size, bus width, etc, we need only a thin layer to hide the
> fact that there are multiple chips and possibly multiple controllers.
> This would still fully expose bad blocks, spare and ECC handling. It
> would allow YAFFS to run on one 'abstract NAND'.
> If we want to offer another layer that can hide the NAND-specific
> nasties (spare, ECC, bad blocks) from the upper layer, more thought is
> needed. ECC handling is not an issue, it can just be implemented. But
> e.g. if we would want to present all the NANDs as one contiguous area,
> one must handle blocks that go bad. One might use an indirection table
> for that, and reserve blocks as backups. Or there might be different
> solutions. How would one handle multiple writes to one page? Usually,
> these are limited, a typical allowed value is 4 before an erase is
> required. So that would require buffering, flushing, and/or relocation
> of pages. What if we want to hide the fact that there are
> pages/blocks/luns/chips? Then we must address the bytes in this abstract
> NAND, but 32bit addresses will be insufficient.
Not necessarily bytes, but by blocks. We could define a block as being
512 bytes, and use a u32 to indicate which block to access. That would
allow access to i think 2TB. For an embedded system that is quite a
lot. Is 512 sensible? I have no idea.
> So, I agree that lots of thought is required for the fancier
> higher-level APIs. But if we implement the basic API plus the extension
> of abstracting away uniform chips, I think we can serve the most
> important target: flash file systems like YAFFS.
YAFFS is interesting, but from a licensing point of view, it is
bad. It is pure GPL. We can never include it into the eCos tree. We
should also be looking at support for JFFS2, which we can and do
import into eCos. People who are using Redboot as a Linux bootloader
will want the NAND implementation to the compatible with what linux
does so that they can boot there Linux kernel out of a NAND filesystem
with JFFS2. Taking this further, UBI and UBIFS is of interest for the
Linux world, however it has the same licensing problems as YAFFS.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss