jffs2 with sync burst mode

Artem B. Bityuckiy dedekind at infradead.org
Thu Mar 10 11:21:22 EST 2005


> 00435660: 0000 0000 0000 0000 b882 2ec7 8519 01e0  ................
> 00435670: 3c00 0000 c001 e8b0 fb00 0000 1300 0000  <...............
            ^
            node length
> 00435680: 0d01 0000 9400 0000 1408 0000 55ff 2d7c  ............U.-|
                                ^
                                name length
> 00435690: a9c7 cf9f 6c69 6270 7468 7265 6164 2d30  ....libpthread-0
            ^^^^ ^^^^
            Name CRC
> 004356a0: 2e39 2e32 362e 736f 8519 02c0 a906 0000  .9.26.so........
> 004356b0: 4a1e 6fb8 0d01 0000 0200 0000 a481 0000  J.o.............
> 004356c0: 0000 0000 0010 0000 9400 0000 9400 0000  ................
Where has this dump come from?

This dump looks good:
* the length of node is 0x3c
* the length of the name is 0x14
* the name CRC - don't know, didn't calculate.

Looks like JFFS2 really reads messed data from flash and I think this 
isn't JFFS2'd failure.

I'd suggest to hack the write function and after each write read the data 
that has just been written again and check it has is the same as the 
original data. This check might be done either on MTD layer or on JFFS2 
layer.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




More information about the linux-mtd mailing list