Quoth António Silva: > From 0xC0000000 to 0xC01FFFFF there is one flash chip > From 0xC0200000 to 0xC03FFFFF nothing is mapped > From 0xC0400000 to 0xC0600000 there is another flash chip (exact same > model as the previous one) [...] > However, I was expecting that by specifying 0x800000 as the address > range, both chips could be used has two different mtd devices by > specifying two mtdparts in the kernel boot parameters, or even as a > single large partition which could then be mounted with jffs2 or other > appropriate filesystem. In fact, using the mentioned range and without > specifying any parts, the chips are correctly detected and I am able > to do a flawless eraseall operation to both flashes, however, I obtain > errors when I try to write the flash like this one:
The total address range between those two chips is 0x600000, so why would you be writing 0x800000? And this does seem like a dodgy way to be doing things. > JFFS2 error: (48) __jffs2_dbg_prewrite_paranoia_check: argh, about to > write node to 0x7e000c on flash, but there are data already there. The > first corrupted byte is at 0x7e0050 offset. That's off the end of your second flash chip, so I'm not surprised it's not happy. You can't pass JFFS2 an MTD partition that includes non-flash memory and expect it to actually work. > My question is: is this "expectable"? I've been trying to understand > the mtd code (I am using the 20070130 dist) , specially the physmap > code, and it seems to me that the current physmap.c cannot do this > because it can only handle one device. Am I right? Can someone please > comment on this? You should probably write your own mapping driver (they're trivial to write) which creates devices for each separate chip. You can then use the append layer to merge them into a single MTD device if you want to. You can even write the code so that the merged MTD device is the only one assigned a minor number (and visible to outside code). _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
