Reading or writing jffs2 - how?

Hi there,

I have tried to create a jffs2-image of the linux-filesystem I wish to use, and then write it to my flash using "nand write.jffs2 100000 0 $(filesize)". But with no luck...
Then I began to investigate the fundamental "ls" and "nand erase" commands, but neither there did I have any success. Below is a trace of what I've tried in order to get something working.

In section 2, I'd expect the nand to be mountable from Linux - but's it's not.
In section 3, I'd expect the filesystem to be ls'ed correct from u-boot
- but it's not...

Can someone tell me if there is something I've misunderstood?

********************************
********** 1 U-Boot ************
********************************
U-Boot 1.1.2 (Nov 27 2004 - 11:50:10)
CPU: IBM PowerPC 405EP Rev. B at 333.333 MHz (PLB=111, OPB=55, EBC=37 MHz)

==== 8< 8< 8< ====

NAND:Probing@0xff400000
64 MB

==== 8< 8< 8< ====

=> nand erase clean

NAND erase: device 0 offset 0, size 67108864 ... OK

=> ls
Scanning JFFS2 FS: done.
=>

*******************************
********** 2 Linux ************
*******************************

# cat /proc/mtd

dev: size erasesize name
mtd0: 04000000 00004000 "Trampoline Nand Flash (128 MB)"

# mount -t jffs2 /dev/mtdblock0 mnt/nand0

jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) instead
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes empty_blocks 1325, bad_blocks 4, c->nr_blocks 2048
mount: Mounting /dev/mtdblock0 on /mnt/nand0 failed: Invalid argument

# eraseall /dev/mtd0

Erasingnand_erase: attempt to erase a bad block at p 16 Kibyte @ 400age 0x00000020
0 -- 0 % complenand_erase: attempt to erase te.
eraseall: /a bad block at page 0x00000040
dev/mtd0: MTD Ernand_erase: attempt to erasase failure: Inpe a bad block at page 0x00000060
nand_erase: attempt to erase a bad blo
Erasing 16 Kibck at page 0x00000080
yte @ 8000 -- 0nand_erase: attempt to er % complete.
erase a bad block at page 0x000000a0
aseall: /dev/mtd0: MTD Erase fainalure: Input/outpnd_erase: attempt to erase a b
ad block at page 0x000000c0
ut error
Erasinand_erng 16 Kibyte @ case: attempt to erase a bad block at page 0x000000e0
000 -- 0 % complete.
eraseall: /dev/mtd0: MTD Erase failure: Input/output error Erasing 16 Kibyte @ 10000 -- 0 % complete.
eraseall: /dev/mtd0: MTD Erase failure: Input/output error Erasing 16 Kibyte @ 14000 -- 0 % complete.
eraseall: /dev/mtd0: MTD Erase failure: Input/output error Erasing 16 Kibyte @ 18000 -- 0 % complete.
eraseall: /dev/mtd0: MTD Erase failure: Input/output error Erasing 16 Kibyte @ 1c000 -- 0 % complete.
eraseall: /dev/mtd0: MTD Erase failure: Input/output error Erased 65536 Kibyte @ 0 -- 100% complete.

# mount -t jffs2 /dev/mtdblock0 /mnt/nand0/

jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) instead

# touch /mnt/nand0/testfile
# mkdir /mnt/nand0/testdir
# umount /mnt/nand0

jffs2: No clean, dirty _or_ erasable blocks to GC from! Where are they all?
jffs2: Couldn't find erase block to garbage collect!

# mount -t jffs2 /dev/mtdblock0 /mnt/nand0/

jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) instead

# ls -l /mnt/nand0/
drwxr-xr-x    2 0        0               0 Feb  8 05:59 testdir
-rw-r--r--    1 0        0               0 Feb  8 05:59 testfile

********************************
********** 3 U-Boot ************
********************************

=> ls
Scanning JFFS2 FS: done.
=>

Best regards,
Martin Egholm

Hi Martin,

Which Linux kernel with which mtd code version?

Use -j (--jffs2) in the future.

Might be caused be eraseall without -j ignoring bad blocks but I'm not sure.

Thats just a warning and can be ignored - iirc it means the unmount triggered a garbage collection which found nothing to collect.

This should definitely work (it worked for me on 8xx and 4xx in the past).

Check the mtd code in your Linux version - many improvements related to NAND went in there not long ago.

Cheers
Detlev

In God we trust.  All others we monitor
                       -- NSA motto

Hi Martin,

Are you really sure, your NAND gets accessed correctly both under U-Boot and Linux? Can you erase / write / readback some data under U-Boot by hand?

Cheers
Detlev

The only use I can find for vi is editing the emacs sources while
porting them to a new machine.
                                        -- Larry Campbell

Hi Detlev,

I'm sure it works under Linux - there I can both write and read - boot and use the flash-data again. No problems.

Under u-boot I've just tried the following:

=============== 8< 8< 8< 8< ===============

=> md.b 100000

00100000: 7f a3 eb 78 38 a0 00 00 4b ff fa b1 7c 7f 1b 78 ...x8...K...|..x
00100010: 3d 40 c0 18 39 2a 14 60 81 69 00 08 39 6b ff ff [email protected]*.`.i..9k..
00100020: 91 69 00 08 2c 0b 00 00 40 82 00 10 80 0a 14 60 .i..,... at ......`
00100030: 2c 00 00 00 40 82 00 0c 7f e3 fb 78 4b ff fe a0 ,... at ......xK...

=> nand write 100000 0 40

NAND write: device 0 offset 0, size 64 ... Warning block writes should be at lea
st 512 bytes and start on a 512 byte boundry
64 bytes written: OK

=> nand read 200000 0 40

NAND read: device 0 offset 0, size 64 ... Warning block writes should be at leas
t 512 bytes and start on a 512 byte boundry
64 bytes read: OK

=> md.b 200000

00200000: 7f a3 eb 78 38 a0 00 00 4b ff fa b1 7c 7f 1b 78 ...x8...K...|..x
00200010: 3d 40 c0 18 39 2a 14 60 81 69 00 08 39 6b ff ff [email protected]*.`.i..9k..
00200020: 91 69 00 08 2c 0b 00 00 40 82 00 10 80 0a 14 60 .i..,... at ......`
00200030: 2c 00 00 00 40 82 00 0c 7f e3 fb 78 4b ff fe a0 ,... at ......xK...

=>

=============== 8< 8< 8< 8< ===============

In short: the giberish-data present at memory 0x100000 is written to flash, and reread again to memory at 0x200000. The flash does still contain the data after reboot.

Next, I tried reading the data from my Linux:

# dd if=/dev/mtd0 of=/ftp/dump bs=8 count=8

=== /ftp/dump contains: ===

00000000: 7fa3 eb78 38a0 0000 4bff fab1 7c7f 1b78  ...x8...K...|..x
00000010: 3d40 c018 392a 1460 8169 0008 396b ffff  [email protected]*.`.i..9k..
00000020: 9169 0008 2c0b 0000 4082 0010 800a 1460  .i..,... at ......`
00000030: 2c00 0000 4082 000c 7fe3 fb78 4bff fea0  ,... at ......xK...

Hence, the same data is available from Linux at the beginning at the device.

That made me wonder... Aaaaand, then I tried mounting the flash-root-filesystem under Linux after what I thought would have corrupted it (the above writing of giberish to the system). And the root-filesystem still worked!
Hence, I tried dumping the entire flash to a file. And I discovered that the filesystem-data was positioned@the "end" of the flash... That may be the reason that "ls" in u-boot does not work with the image in flash - or what?

Best regards,
Martin Egholm

Hi Detlev,

I'm sure it works under Linux - there I can both write and read - boot and use the flash-data again. No problems.

Under u-boot I've just tried the following:

=============== 8< 8< 8< 8< ===============

=> md.b 100000

00100000: 7f a3 eb 78 38 a0 00 00 4b ff fa b1 7c 7f 1b 78 ...x8...K...|..x
00100010: 3d 40 c0 18 39 2a 14 60 81 69 00 08 39 6b ff ff [email protected]*.`.i..9k..
00100020: 91 69 00 08 2c 0b 00 00 40 82 00 10 80 0a 14 60 .i..,... at ......`
00100030: 2c 00 00 00 40 82 00 0c 7f e3 fb 78 4b ff fe a0 ,... at ......xK...

=> nand write 100000 0 40

NAND write: device 0 offset 0, size 64 ... Warning block writes should be at lea
st 512 bytes and start on a 512 byte boundry
64 bytes written: OK

=> nand read 200000 0 40

NAND read: device 0 offset 0, size 64 ... Warning block writes should be at leas
t 512 bytes and start on a 512 byte boundry
64 bytes read: OK

=> md.b 200000

00200000: 7f a3 eb 78 38 a0 00 00 4b ff fa b1 7c 7f 1b 78 ...x8...K...|..x
00200010: 3d 40 c0 18 39 2a 14 60 81 69 00 08 39 6b ff ff [email protected]*.`.i..9k..
00200020: 91 69 00 08 2c 0b 00 00 40 82 00 10 80 0a 14 60 .i..,... at ......`
00200030: 2c 00 00 00 40 82 00 0c 7f e3 fb 78 4b ff fe a0 ,... at ......xK...

=>

=============== 8< 8< 8< 8< ===============

In short: the giberish-data present at memory 0x100000 is written to flash, and reread again to memory at 0x200000. The flash does still contain the data after reboot.

Next, I tried reading the data from my Linux:

# dd if=/dev/mtd0 of=/ftp/dump bs=8 count=8

=== /ftp/dump contains: ===

00000000: 7fa3 eb78 38a0 0000 4bff fab1 7c7f 1b78  ...x8...K...|..x
00000010: 3d40 c018 392a 1460 8169 0008 396b ffff  [email protected]*.`.i..9k..
00000020: 9169 0008 2c0b 0000 4082 0010 800a 1460  .i..,... at ......`
00000030: 2c00 0000 4082 000c 7fe3 fb78 4bff fea0  ,... at ......xK...

Hence, the same data is available from Linux at the beginning at the device.

That made me wonder... Aaaaand, then I tried mounting the flash-root-filesystem under Linux after what I thought would have corrupted it (the above writing of giberish to the system). And the root-filesystem still worked!
Hence, I tried dumping the entire flash to a file. And I discovered that the filesystem-data was positioned@the "end" of the flash... That may be the reason that "ls" in u-boot does not work with the image in flash - or what?

Best regards,
Martin Egholm

Hi Detlev,

The problem has been solved...
The reason that "ls" didn't work from u-boot, was that the boards' u-boot config-file included an erroneous nand-size:

#define CONFIG_JFFS2_NAND_SIZE 64*1024*1024

My board had only one configuration-file associated, but multiple nand-size configurations.

The jffs2-image problems were related to the endianess problems of mkfs.jffs2:

http://lists.infradead.org/pipermail/linux-mtd/2004-January/009091.html

Thanks for all,
Martin

Hi Martin,

Yes, I was about to check the options available in U-Boot and ask you to verify those but you beat me to it.

Another reason for using our ELDK - it has a working mkfs.jff2 ;)

Cheers
Detlev

He who can properly define and divide is to be considered a god.
                                        -- Plato

Hi Detlev,

:-)

Noo?! I used mkfs.jffs2 from ELDK 3.0:

# mkfs.jffs2 --version
mkfs.jffs2 revision 1.25

# which mkfs.jffs2
/usr/local/eldk/usr/bin/mkfs.jffs2

# cat /usr/local/eldk/version
ELDK version 3.0
ppc_4xx: Build 2004-02-16

But ofcourse, I guess the above error blocked u-boot from putting the correct image in the nand...

BR,
Martin Egholm

Dear Martin,

Of course Detlev means: use the latest and greates ELDK - i. e. release 3.1

-> mkfs.jffs2 --version
mkfs.jffs2: revision 1.42

That's too old:

---------------------
PatchSet 342
Date: 2004/06/16 11:57:35
Author: wd
Branch: HEAD
Tag: (none)
Log:
Use mtd-snapshot-20040608 to get a more recent version of mkfs.jffs2 as needed for NAND flash support.

Members:

        cpkgs.lst:1.42->1.43 
        tarballs.lst:1.37->1.38 
        cross_rpms/mtd_utils/SOURCES/mtd_utils-jffs2.patch:1.1->1.2 
        cross_rpms/mtd_utils/SPECS/mtd_utils.spec:1.1->1.2 

---------------------

Indeed.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I like your game but we have to change the rules."

Hi Wolfgang,

But of course he does :-)
Cannot connect to ftp://ftp.leo.org/, though. Connection refused...

I'll try fetching it - then everybody's going to get happy...

Thanks,
Martin

Yes, LEO's FTP server has been broken for sevcaral months now.

HTTP access works, though. And there are other mirrors: see
http://www.denx.de/twiki/bin/view/DULG/ELDKAvailability

:-)

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The perversity of nature is nowhere better demonstrated by  the  fact
that,  when  exposed to the same atmosphere, bread becomes hard while
crackers become soft.

Ohh... Someone should update the wiki-doc:
http://www.denx.de/twiki/bin/view/DULG/ELDKDownloadPowerPC

Super!
Martin

Hi Martin,

Yes, I think that failure cannot be attributed to an endianness problem in the mkfs.jffs in the ELDK which works.

Cheers
Detlev

Progress in  mathematics comes from  repeated acts of generalization.
If mathematics is anything, it is the art of chosing the most elegant
generalization for some abstract pattern.  Thus esthetics is central.
                                     -- Douglas Hofstadter