Hi all.

Is it possible to have the physmap module to map and use more than one
flash device in a specified address range?
In my current board I have the following address setup:

>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)

Currently, if I only use one chip and configure physmap with
0xC0000000 as the initial address and 0x200000 as the range, I am able
to use the flash (erase it, mount/unmounting it with jffs2, create,
delete and modify files) without any problems.

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:

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.

I got this error by making an erase all, then mount, then create a
file with some content, then unmount, then mount (the file is gone now
:( ), then create a new file.

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?

To solve this problem, I could make two copies of physmap.c and supply
to each of them their respective start address and range (and then
compile, of course). I guess that would solve my problem... But is
this a common practice, or a best practice?

Thanks in advance for any help.

--
Best regards
António Silva
_______________________________________________
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

Reply via email to