public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Peter Grayson <pgrayson@realmsys.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: Can you really write a jffs2 image with nandwrite?
Date: Tue, 01 Mar 2005 11:11:51 -0700	[thread overview]
Message-ID: <1109700711.5043.53.camel@pgrayson1.realmsys.com> (raw)
In-Reply-To: <1109645229.3805.11.camel@tglx.tec.linutronix.de>

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 \
> > 	--output=image.jffs2 \
> > 	--compression-mode none \
> 
> Why do you switch off compression ?

I have made images both ways -- in this case I was looking at hex dumps
of images and sans compression the dumps were a little more human-
readable. In the end, I do want to use compression.

> 
> > 	--no-cleanmarkers \
> > 	--big-endian \
> > 	--squash \
> > 	--verbose \
> > 	--root=$ROOT_DIR
> > 
> > When I try using this image with "nandwrite -j", the image appears to be
> > written successfully, but when I try to mount the new filesystem, mount
> > fails with the following error message:
> > 
> >   mount: Mounting /dev/mtdblock0 on /mnt failed: Invalid argument
> 
> Did you ?
> mount -t jffs2 /dev/mtdblock0 /mnt

Yes.

> 
> > If I try to use "nandwrite -j -o", nandwrite complains about the image
> > not being aligned:
> 
> JFFS2 has no oob data. nandwrite -j is correct.
> 
> > Is there something obvious I am missing? I have read the FAQ at:
> > 
> >   http://www.linux-mtd.infradead.org/tech/faq.html
> 
> I'm happy that somebody actually read it :)
> 
> > so I know that the working theory is that this should work, but it is
> > not working for me. Has anyone else had a similar experience?
> 
> Before using nandwrite please erase the flash with 
> flash_eraseall -j /dev/mtd0 .
> 

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
2) flash_eraseall -j /dev/mtd0
3) nandwrite /dev/mtd0 image.jffs2

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.

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.

Thanks for the help, this definitely got me jumpstarted.

  reply	other threads:[~2005-03-01 18:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-01  2:14 Can you really write a jffs2 image with nandwrite? Peter Grayson
2005-03-01  2:47 ` Thomas Gleixner
2005-03-01 18:11   ` Peter Grayson [this message]
2005-03-01 19:16     ` Thomas Gleixner
2005-03-01 20:47       ` Peter Grayson
2005-03-02  9:57         ` Artem B. Bityuckiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109700711.5043.53.camel@pgrayson1.realmsys.com \
    --to=pgrayson@realmsys.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox