Hi Matt,
I'm using 1.2.0 on an AT91RM9200, along with linux 2.6.20-2 w/ patches from Maxim.
I'm looking for info on how compatible the JFFS2 stuff is between u-boot and linux.
If that weren't the case what use would it be? ;)
When I mount a partition (I have JFFS2 debugging turned on in the kernel), I get two kinds of error messages:
OR
I'm wondering if anyone can point me to what I'm doing wrong.
I am definitely not the guru on this, but I have a few suggestions.
First off, the JFFS2 (not NAND) cleanmarkers really were implemented to circumvent strange problems with NOR flash not being erased completely, so JFFS2 writes them _after_ erasing a sector. In the NAND implementation the designers use the out of band area of NAND to store the cleanmarkers (don't ask me if they are technically needed anymore). So one potential problem is if you include cleanmarkers without specifying "-n" to mkfs.jffs2 as this really produces output for NOR flash - because the mkfs.jffs2 output does not include the OOB area as such.
Some more theory. You can always check the contents of your NAND directly from U-Boot with "nand dump 0" for the first page for example.
As you observed correctly, if you do a "nand erase clean", you will write JFFS2 cleanmarkers in the OOB area of the NAND. You can check this with the "nand dump" command. The cleanmarkers start with "19 85" (big endian). Cf. jffs2_unknown_node in jffs2.h the next two bytes are a node type and then we have a __u32 "totlen" field.
So now lets look at your output:
"jffs2_check_nand_cleanmarker(): Cleanmarker node not detected in block at X" "OOB at X was ...." (lots of FF)
Ok, probably you did a "nand erase" without clean and then this is to be expected - but should only be a warning as JFFS2 will fix the situation on the fly IIRC.
But this is interesting:
"jffs2_check_nand_cleanmarker(): Cleanmarker node not detected in block at X" "OOB at X was ...." (lots of data, not all FF) "CLEANMARKER node found at X has totlen 0xc != normal 0x0"
The "not all FF" probably is the cleanmarker from U-Boot which is always 8 Bytes in U-Boot for NAND flash if I read current sources correctly.
So the interesting part is to find out why the kernel sees 0xc bytes here and expects 0. If you find that out you should see mnore clearly :)
Best wishes Detlev