Hi Norman,
Wolfgang Denk <wd <at> denx.de> writes:
In message <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471 <at>
applera.com> you wrote:
Also note that a cramfs may fail to work in case there are bad sectors in your NAND device.
Wolfgang, this might be an off topic here. I have a client requirement to have a RFS like cramfs or squashfs on NAND.
Check the available documentation on NAND devices. I found this application note to be a real eye opener[1]. Especially the section "NAND Flash is Not a Hard Drive" is a must read. Maybe you reconsider the requirement.
If I use the u-boot nand write command to write the cramfs to a MTD partition. How does nand write treat a bad block?
What part of this section from doc/README.nand is not clear to you?
nand write.jffs2 addr ofs|partition size Like `write', but blocks that are marked bad are skipped and the data is written to the next block instead. This allows writing a JFFS2 image, as long as the image is short enough to fit even after skipping the bad blocks. Compact images, such as those produced by mkfs.jffs2 should work well, but loading an image copied from another flash is going to be trouble if there are any bad block
I am thinking that if nand write skip to the next block, then I might be able to modify nand read... Or is there a better way?
What does the block layer of MTD in linux do? This is a much more interesting question. As far as I can see, this layer will not be able to handle any bad blocks.
Unless I don't see a very clever solution, putting such a filesystem on a flaky substrate like NAND really needs another layer handling the shuffling around - UBI comes to mind here, but I do not have any experiences with it (yet).
Cheers Detlev
[1] http://download.micron.com/pdf/technotes/nand/tn2917.pdf