This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
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
parent CYGPKG_IO_FLASH_NAND
active_if CYGPKG_IO_FLASH_NAND
so that they are correctly placed into the CDL tree and only active when appropriate.
io/flash_nand/ + common/ + controller/ + chip/
devs/flash/bfin/ + nfc/ + ez_kit_bf548/nand/ (+ ez_kit_bf548/nor/ for the NOR flash also on this board)
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_page_read() cyg_nand_block_erase() cyg_nand_bad_block_...() cyg_nand_chip_select(nand, chip_number) cyg_nand_init()
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?
files make any sense? The NOR devices don't do this?
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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |