[U-Boot-Users] NAND and JFFS2

[Detlev Zundel <dzu@denx.de>]

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

-- 
Once the  implementation is  up and running,  it is still a trick to keep it
running.  In a normal,  closed implementation,  this is not a problem;  in a
system with metaobject protocols [..] there is the potential for spectacular
failure modes if certain situations are not properly anticipated.
                                       -- The Art of the Metaobject Protocol
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de