[microblaze-uclinux] MTD and JFFS with BigEndian uClinux systems

[Brettschneider Falk <fbrettschneider@xxxxxxxxxxxxxxxxx>]

Hi,
reading
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2003/08/msg00
017.html
I get a deja vu.

I see the same effects in my current trials to use jffs2 on top of a MTD
driver (physmap.c/cfi_cmdset_0002.c).
Firstly, it found the wrong filesystem signature (wrong bitmask, found
0x2003 instead of 0x1985). But 2003 is the neighboured word to 1985 in the
dword in the flash memory.
I recognized it is due a global 16bit-word order read problem. The chip
driver writes from a BigEndian memory in 16bit steps to a LitteEndian flash
memory, but the map driver reads in 32bit steps (due the use of memcpy() in
..._copy_from()), and in my opinion, this only does work for LittleEndian
uClinux platforms but not for the BigEndian-based microblaze. The 32bit read
access to the flash splits it in 2 16bit read accesses but they result in
the wrong word order (because of the transition from LittleEndian flash to
BigEndian microblaze).
Next I fixed that problem by not using microblazes memcpy() for reading and
writing, I use a slightly tweaked copy of it. I had a proper mount now but
further fixes in the chip driver's write function were necessary. The word
order during writing byte arrays must be fixed there too. Now it nearly
works, just some CRC failures after I copied files in the jffs2 file system
and remount actions. It seems to me the byte copying in memcpy's head and
tail also mixes up some byte...

My suspicion is noone ever has successfully get a jffs2 filesystem work on
the microblaze, maybe except just for booting a read-only kernel image from
it, but not for real file copy/move/delete actions. Is this true?

Cheers, F@lk
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/