Peter Grayson | 1 Mar 2005 03:14

Can you really write a jffs2 image with nandwrite?

I am using a PowerPC 405 based Linux system running 2.6.10 kernel with
CVS head of mtd patched in. The board has a 256MB Samsung NAND flash
part with 2048 byte page size, 64 spare bytes per page, and 64 pages per
eraseblock (128kB eraseblock).

I want to use jffs2 partitions on this flash part. I can mount an empty
partition with jffs2 and that works well, but I have been unable to
weild mkfs.jffs2 and nandwrite to successfully write jffs2 images to
flash.

>From reading the mkfs.jffs2 code, it seems that mkfs.jffs2 has no
concept of out-of-bounds data. Consequently, it appears that the
nandwrite expects to find out-of-bounds data immediately after the in-
bounds data for every page. I have looked at the bits of the jffs2 image
produced by mkfs.jffs2 and I can see that it does not really produce out
of bounds data.

Below is the mkfs.jffs2 command line I am using. I have tried many other
combinations of options, but they do not yield appreciably different
results.

mkfs.jffs2
 	--pagesize=2048 \
	--eraseblock=128 \
	--pad \
	--output=image.jffs2 \
	--compression-mode none \
	--no-cleanmarkers \
	--big-endian \
	--squash \
(Continue reading)

Thomas Gleixner | 1 Mar 2005 03:47
Picon

Re: Can you really write a jffs2 image with nandwrite?

On Mon, 2005-02-28 at 19:14 -0700, Peter Grayson wrote:
> From reading the mkfs.jffs2 code, it seems that mkfs.jffs2 has no
> concept of out-of-bounds data. Consequently, it appears that the
> nandwrite expects to find out-of-bounds data immediately after the in-
> bounds data for every page. I have looked at the bits of the jffs2 image
> produced by mkfs.jffs2 and I can see that it does not really produce out
> of bounds data.

nandwrite does not expect oob data for jffs2 images.

> Below is the mkfs.jffs2 command line I am using. I have tried many other
> combinations of options, but they do not yield appreciably different
> results.
> 
> mkfs.jffs2
>  	--pagesize=2048 \
> 	--eraseblock=128 \
			
This one if definitely wrong. You meant 128kiB or 131072. 
	
> 	--pad \
> 	--output=image.jffs2 \
> 	--compression-mode none \

Why do you switch off compression ?

> 	--no-cleanmarkers \
> 	--big-endian \
> 	--squash \
> 	--verbose \
(Continue reading)

Andrew Victor | 1 Mar 2005 09:54

Re: SPI DataFlash interfacing using 2.4.26

hi Narinder,

>          Did anyone on the group sucessfully interfaced a JFFS2 
> partition on SPI DataFlash on Atmel's AT91RM9200 DK using  kernel 2.4.26 
> ? I have been able to mount the partition but read/write was giving CRC 
> errors.

I'm running JFFS2-on-DataFlash successfully on 2.4.27-vrs1.

1) You will need to download the latest CVS version of the MTD/JFFS2
code from cvs.infradead.org (see http://www.linux-mtd.infradead.org/ for
instructions).

2) Read the INSTALL file and then run the ./patchin.sh script

3) There are some incompatibilities with 2.4 kernels, but they're not
difficult to fix.  This might help:
http://lists.infradead.org/pipermail/linux-mtd/2004-December/011039.html

4) Configure your kernel and enable "JFFS2 write-buffering support"
under Filesystems->JFFS2.

Regards,
  Andrew Victor

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

(Continue reading)

Martin Egholm Nielsen | 1 Mar 2005 13:07
Picon

Cannot remove child "XXX", ino #13, because it doesn't exist

Hi there,

After removing a directory containing a lot of files, I get lots of the 
following messages on reboot (one for each of the files I removed):

Cannot remove child "file10.txt", ino #13, because it doesn't exist

It keeps returning even after rebooting...

How much should be put into this?
And how to "fix" it...

BR,
  Martin Egholm

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Artem B. Bityuckiy | 1 Mar 2005 17:28
Favicon

JFFS3 and RAM consumprion reincarnated

Hello,

I'd like to continue the JFFS3 RAM consumption discussion.
Please, take a glimpse at 
http://lists.infradead.org/pipermail/linux-mtd/2005-January/011671.html 
and follow the conversation 
athttp://lists.infradead.org/pipermail/linux-mtd/2005-January/011716.html 
to refresh your memory.

Well, I suppose the reader knows what are Summary and ICP. If no, follow 
the links above.

We've stopped on the design like this: each inode has ICP which is stored 
on flash. The ICP is being outdated by GC and users. Since it is 
inefficient to rewrite new inode every time, we won't rewrite it but add 
node_ref instead. Sometimes we'll flush ICP and free node_refs.

Example:
1. We have inode X with 10 nodes (node 1, node 2, ... node 10) and ICP 
node which describes them. So far so good. On iget() call we read ICP and 
have the inode built.

2. Suppose GC has moved node 1 of our inode. Its position has been 
changed, so the relating ICP entry is obsolete now. In this case JFFS3 
does not rewrite new ICP. Instesd, it allocates node_ref for node 1 and 
keeps it in-core.
Now, on iget() call, we read ICP and the node 1's node_ref and this is 
sufficient to build our inode.

Anologeously, if another nodes are moved, we just allocate more node_refs.
(Continue reading)

Peter Grayson | 1 Mar 2005 19:11

Re: Can you really write a jffs2 image with nandwrite?

On Tue, 2005-03-01 at 03:47 +0100, Thomas Gleixner wrote:
> On Mon, 2005-02-28 at 19:14 -0700, Peter Grayson wrote:
> > From reading the mkfs.jffs2 code, it seems that mkfs.jffs2 has no
> > concept of out-of-bounds data. Consequently, it appears that the
> > nandwrite expects to find out-of-bounds data immediately after the in-
> > bounds data for every page. I have looked at the bits of the jffs2 image
> > produced by mkfs.jffs2 and I can see that it does not really produce out
> > of bounds data.
> 
> nandwrite does not expect oob data for jffs2 images.

But it appears nandwrite can accept oob data. It does have the --oob
option and when this option is set nandwrite reads the oob data from the
image and does an ioctl() to the mtd character device to write it.

> 
> > Below is the mkfs.jffs2 command line I am using. I have tried many other
> > combinations of options, but they do not yield appreciably different
> > results.
> > 
> > mkfs.jffs2
> >  	--pagesize=2048 \
> > 	--eraseblock=128 \
> 			
> This one if definitely wrong. You meant 128kiB or 131072. 

mkfs.jffs2 interprets "128" as "128KiB", but I should be more explicit.

> 	
> > 	--pad \
(Continue reading)

Thomas Gleixner | 1 Mar 2005 20:16
Picon

Re: Can you really write a jffs2 image with nandwrite?

On Tue, 2005-03-01 at 11:11 -0700, Peter Grayson wrote:
> > nandwrite does not expect oob data for jffs2 images.
> 
> But it appears nandwrite can accept oob data. It does have the --oob
> option and when this option is set nandwrite reads the oob data from the
> image and does an ioctl() to the mtd character device to write it.

Yes it can, but JFFS2 images contain no oob data

> With mkfs.jffs2, I had some confusion about the pagesize option. I was
> thinking that it corresponded to the NAND pagesize, but that is not
> correct, it sets the jffs2 filesystem page size.

Oops, missed that one.

> With nandwrite, the -j option causes things to not work. This was a
> great stumbling block for me. It proved to be critical to _not_ use the
> -j (or -o) option with nandwrite. This is in direct conflict with
> instructions in the FAQ.

Could you please correct the FAQ and add the steps you took and send a
patch ?

tglx

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

(Continue reading)

Peter Grayson | 1 Mar 2005 21:47

Re: Can you really write a jffs2 image with nandwrite?

> Could you please correct the FAQ and add the steps you took and send a
> patch ?

Attached
Attachment (faq.patch): text/x-patch, 8 KiB
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Artem B. Bityuckiy | 2 Mar 2005 10:57
Favicon

Re: Can you really write a jffs2 image with nandwrite?

Peter Grayson wrote:
 > This was definitely useful. I am now able to write images with
> nandwrite. Here are the magic steps I am taking:
> 
> 
> 1) mkfs.jffs2 \
> 	--eraseblock=128KiB \
> 	--pad \
> 	--output=image.jffs2 \
> 	--compression-mode=priority \
> 	--no-cleanmarkers \
> 	--big-endian \
> 	--squash \
> 	--verbose \
> 	--root=$ROOT_DIR

Peter, if you don't want to have problems in future, please use --pad=2048 
option instead of --pad. The latter is only acceptable in case of NOR 
flash. This is fairly confusing and we definitely have to either notice 
this in the mks.jffs2 help output or just hack mkfs.jffs2 code and assume 
--pad=Page Size by default for NANDs. You're welcome to do either of this 
and to send your patch :-).

Please, refer to 
http://lists.infradead.org/pipermail/linux-mtd/2004-December/011051.html 
for more details. HTH.

--
Best Regards,
Artem B. Bityuckiy,
(Continue reading)

Martin Egholm Nielsen | 2 Mar 2005 15:13
Picon

Re: Cannot remove child "XXX", ino #13, because it doesn't exist

Hi again,

> After removing a directory containing a lot of files, I get lots of the 
> following messages on reboot (one for each of the files I removed):

> Cannot remove child "file10.txt", ino #13, because it doesn't exist

> It keeps returning even after rebooting...
Some more information:

The problem arose after creating a directory in my JFFS2 NAND fs, and 
creating some 1000 (small) files in it. After rebooting I removed the 
entire directory, and at the next reboot I got the error.

I'm running a 2.4.20 kernel but with mtd updated.

I didn't do the mtd update myself - this was handled by my board/linux 
vendor, but scanning the mtd-directory structure I found that the newest 
file in the structure seems to be "drivers/mtd/nand/s3c2410.c" from 
2004-10-12:

$Id: s3c2410.c,v 1.5 2004/10/12 10:10:15 bjd Exp $

The remainder of the files are dated somewhat similar...

Maybe this can clarify some things?

BR,
  Martin Egholm

(Continue reading)


Gmane