Hi Folks Last week a conversation started on the ecos maintainers list about eCosCentric contributing their NAND flash framework. The emails are archived at:
http://ecos.sourceware.org/ml/ecos-maintainers/2009-05/ and take a look at the thread NAND & YAFFS, started by Ross Younger. We now have two NAND frameworks for integration consideration. Putting the political situation to one side for a moment, i've started reviewing the documentation for eCosCentrics code. This documentation can be found at: http://bugs.ecos.sourceware.org/attachment.cgi?id=723 The code itself is not yet available. Those of you interesting in doing a side by side comparison with Rutger Hofman's NAND framework, you can find his documentation at: http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/nand-flash-doc-r595/io-nand-flash.html and the code is available from: http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/ I started a technical discussion about eCosCentrics partitioning concept, however the ecos-maintainers list was not the right place for it. So now i'm moving to ecos-discuss. On Sat, May 16, 2009 at 01:51:17PM +0100, Ross Younger wrote: > Hi Andrew, > >> Im having trouble getting my head around partitions. >> >> If i understand the documentation correctly, the only thing the >> concept does it prevent a buggy filesystem or application reading data >> from a different partition than it "opened" with >> cyg_nand_get_partition(). The partition has zero affect on addressing. >> >> Am i missing something? What else are partitions good for? > > Partitions may be a bit of a misleading term for it, but it's the best I > could come up with. It seems quite common for boards (both dev boards, > and deployed products) to have a single NAND device or array, carved up > into two (or more) separate filesystems. As you observe, addressing is > completely unaffected, and this is based on my observations of other > devices; I added in the boundary enforcement purely out of paranoia. So i guess there is no way to not compile it either? You have to go from a flash device to a partition, so there is no easy way to remove this functionality to save code space... So it could be considered as bloat? > Also, having the partition information in one place means that > filesystems can read out their limits from it, rather than having to be > configured separately. Well, this sounds nice in theory, but there is no API call for this. The documentation does not list a way to discover how many partitions a device has. There is no way to find out a name for the partition. There is no way to discover the size of a partition, what the first and last page is etc... How does this also fit with redboot? You probably want a command in redboot to list the partitions. You want to be able to mount a filesystem from one of these partitions and then load the linux kernel and maybe the ramfs into memory. How does redboot get to know the size of the partition, etc. In fact, for NOR systems, it is redboot which performs the partitioning, using the fis commands. The partition table is stored in the fis configuration block. The flashdev layer can then either use the fis block, or can be configured with cdl about partitions. How does this fit with Linux? mtd can also use the fis configuration block so allowing linux to discover the partition information for NOR devices. How is linux supposed to get the partition information out of the eCos HAL for NAND devices? By the time mtd gets around to wanting this information, i guess the Linux kernel has destroyed the in memory eCos/Redboot context information, so the HAL partition information is no longer available. My current feeling is that this partition concept does not belong in the NAND core. It probably belongs in an optional layer above the NAND flash. However, that is just my fist feelings. It seems to me this partition idea has not yet been fully thought out and needs further work. Maybe it is time for eCosCentric to post to ecos-devel a design document for the partition concept and APIs as an RFC? Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
