Fwd: Re: JFFS XConfig

Fwd: Re: JFFS XConfig

[David Mackay]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

>  Thanks for the advice David, however it appears
still not to be
> available with CONFID_MTD enabled. However JFFS is
available!

Er, check if it's also dependent on
CONFIG_EXPERIMENTAL.

Thanks David, Jorn,

It is indeed dependant upon CONFIG_EXPERIMENTAL.
However it appears to fail on build at the network
driver stage with JFFS2 enabled. I have not yet pinned
down exactly why. At this stage i have stuc with JFFS
which should suffice for our immediate needs.

> use your CF drive as backing store for the faked MTD
device.

Is there any documentation available on this
proceedure?

We also are intending to use a 16M CF, what do people
suggest we should do about partitioning. I know that
due to garbage collection it is ineffiecient to
partition such a small device, however i had intended
to mount most of the file system as RO for write
protection. Any comments would be welcome.

Thanks for any help, David

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[-- Attachment #2: Type: message/rfc822, Size: 1223 bytes --]

From: David Woodhouse <dwmw2@infradead.org>
To: "David Mackay" <monitoreurope@yahoo.co.uk>
Subject: Re: JFFS XConfig
Date: Mon, 28 Jan 2002 16:51:17 +0000


monitoreurope@yahoo.co.uk said:
>  Thanks for the advice David, however it appears still not to be
> available with CONFID_MTD enabled. However JFFS is available!

Er, check if it's also dependent on CONFIG_EXPERIMENTAL.

--
dwmw2

Re: Fwd: Re: JFFS XConfig

[David Woodhouse]

monitoreurope@yahoo.co.uk said:
>  It is indeed dependant upon CONFIG_EXPERIMENTAL. However it appears
> to fail on build at the network driver stage with JFFS2 enabled. I
> have not yet pinned down exactly why. At this stage i have stuc with
> JFFS which should suffice for our immediate needs.

Turn the #include "zlib.c" in drivers/net/ppp_deflate.c to #include "zlib.h"
instead. This is fixed properly in 2.5.3, and we should backport that fix 
to 2.4.


>  Is there any documentation available on this proceedure? 

Read the list archives - ISTR there was some discussion of this recently.

--
dwmw2

debugging strategies for jffs2

[Adam Wozniak]

I'm trying to debug what I think might be a problem in jffs2 code.

Is it safe for me to create a new jffs2 image by randomly shuffling
the erase blocks in an existing jffs2 image?

Should that work?

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: debugging strategies for jffs2

[David Woodhouse]

adam.wozniak@comdev.cc said:
> I'm trying to debug what I think might be a problem in jffs2 code.
> Is it safe for me to create a new jffs2 image by randomly shuffling
> the erase blocks in an existing jffs2 image?

> Should that work? 

Yes, it should. The code treats all erase blocks entirely separately. 
So much so, in fact, that I'm surprised you think it would be enlightening 
to do so. 

--
dwmw2

Re: debugging strategies for jffs2

[Adam Wozniak]

David Woodhouse wrote:
> 
> adam.wozniak@comdev.cc said:
> > I'm trying to debug what I think might be a problem in jffs2 code.
> > Is it safe for me to create a new jffs2 image by randomly shuffling
> > the erase blocks in an existing jffs2 image?
> 
> > Should that work?
> 
> Yes, it should. The code treats all erase blocks entirely separately.
> So much so, in fact, that I'm surprised you think it would be enlightening
> to do so.


scan.c, 495
                        return -0; 

Was that intentional?

-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: debugging strategies for jffs2

[David Woodhouse]

adam.wozniak@comdev.cc said:
>  scan.c, 495
>                         return -0; 
> Was that intentional?

Er, that looks buggered. Make it mark the node obsolete and continue 
scanning.

--
dwmw2

Re: debugging strategies for jffs2

[Adam Wozniak]

000000 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 10 4c
000010 00 00 1c 19 00 00 81 a4 00 00 00 00 00 32 d3 26
000020 00 00 0d 9d 00 00 0d 9e 00 00 0d 9e 00 00 00 00
000030 00 00 c0 00 00 00 00 00 01 00 00 00 00 00 00 00
000040 cf 8c 20 63
000044

This all by itself is enough to hose things.

The interesting bit to me is that the csize is 0x0000c000
and the dsize is 0x00000000.  Is this perhaps causing problems?

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: debugging strategies for jffs2

[Adam Wozniak]

Adam Wozniak wrote:
> 
> 000000 19 85 e0 02 00 00 00 44 a4 ef 22 3e 00 00 10 4c
> 000010 00 00 1c 19 00 00 81 a4 00 00 00 00 00 32 d3 26
> 000020 00 00 0d 9d 00 00 0d 9e 00 00 0d 9e 00 00 00 00
> 000030 00 00 c0 00 00 00 00 00 01 00 00 00 00 00 00 00
> 000040 cf 8c 20 63
> 000044
> 
> This all by itself is enough to hose things.
> 
> The interesting bit to me is that the csize is 0x0000c000
> and the dsize is 0x00000000.  Is this perhaps causing problems?
> 

At fs/jffs2/gc.c,v 1.52, line 460:

        fill:
                ri.magic = JFFS2_MAGIC_BITMASK;
                ri.nodetype = JFFS2_NODETYPE_INODE;
                ri.totlen = sizeof(ri);
                ri.hdr_crc = crc32(0, &ri, sizeof(struct
jffs2_unknown_node)-4);
 
                ri.ino = inode->i_ino;
                ri.version = ++f->highest_version;
                ri.offset = start;
                ri.csize = end - start;
                ri.dsize = 0;
                ri.compr = JFFS2_COMPR_ZERO;

This seems backwards to me.  Shouldn't ri.dsize = end-start and ri.csize
= 0 ???

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: debugging strategies for jffs2

[David Woodhouse]

adam.wozniak@comdev.cc said:
> > The interesting bit to me is that the csize is 0x0000c000
> > and the dsize is 0x00000000.  Is this perhaps causing problems?
> 
> At fs/jffs2/gc.c,v 1.52, line 460:
>         fill:
>                 ri.magic = JFFS2_MAGIC_BITMASK;
>                 ri.nodetype = JFFS2_NODETYPE_INODE;
>                 ri.totlen = sizeof(ri);
>                 ri.hdr_crc = crc32(0, &ri, sizeof(struct jffs2_unknown_node)-4);
>                   ri.ino = inode->i_ino;
>                 ri.version = ++f->highest_version;
>                 ri.offset = start;
>                 ri.csize = end - start;
>                 ri.dsize = 0;
>                 ri.compr = JFFS2_COMPR_ZERO;

> This seems backwards to me.  Shouldn't ri.dsize = end-start and
> ri.csize = 0 ??? 

Eep, yes that would probably do it. Well spotted. That obviously wasn't one 
of my more coherent days :)

I've fixed it in v1.61 and v1.52.2.1 (on jffs2-2_4-branch) now - don't chuck
your filesystem away though, I'll implement a workaround and ask you to test
it.

--
dwmw2

Re: debugging strategies for jffs2

[Adam Wozniak]

David Woodhouse wrote:
> 
> adam.wozniak@comdev.cc said:
> > > The interesting bit to me is that the csize is 0x0000c000
> > > and the dsize is 0x00000000.  Is this perhaps causing problems?
> >
> > At fs/jffs2/gc.c,v 1.52, line 460:
> >         fill:
> >                 ri.magic = JFFS2_MAGIC_BITMASK;
> >                 ri.nodetype = JFFS2_NODETYPE_INODE;
> >                 ri.totlen = sizeof(ri);
> >                 ri.hdr_crc = crc32(0, &ri, sizeof(struct jffs2_unknown_node)-4);
> >                   ri.ino = inode->i_ino;
> >                 ri.version = ++f->highest_version;
> >                 ri.offset = start;
> >                 ri.csize = end - start;
> >                 ri.dsize = 0;
> >                 ri.compr = JFFS2_COMPR_ZERO;
> 
> > This seems backwards to me.  Shouldn't ri.dsize = end-start and
> > ri.csize = 0 ???
> 
> Eep, yes that would probably do it. Well spotted. That obviously wasn't one
> of my more coherent days :)
> 
> I've fixed it in v1.61 and v1.52.2.1 (on jffs2-2_4-branch) now - don't chuck
> your filesystem away though, I'll implement a workaround and ask you to test
> it.

Here's the workaround I came up with:
in scan.c:

                /* FIXME: Why do we believe totlen? */
                DIRTY_SPACE(4);
                *ofs += 4;
                return 0;
        }
 
        // TODO WOZ FIXED
 
        /* older code confused dsize and csize in some cases, fix that
here */
        if (ri.dsize == 0 && ri.compr == JFFS2_COMPR_ZERO)
        {
                ri.dsize = ri.csize;
                ri.csize = 0;
                ri.node_crc = crc32(0, &ri, sizeof(ri)-8);
        }
 
        if (ri.csize) {
                /* Check data CRC too */
                unsigned char *dbuf;
                __u32 crc;

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: debugging strategies for jffs2

[David Woodhouse]

adam.wozniak@comdev.cc said:
>  Here's the workaround I came up with: in scan.c:

Yeah - with a couple more elsewhere too...

Index: nodelist.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodelist.c,v
retrieving revision 1.36
diff -u -r1.36 nodelist.c
--- nodelist.c	2002/01/09 16:52:59	1.36
+++ nodelist.c	2002/02/01 23:29:35
@@ -240,7 +240,12 @@
 			}
 			tn->version = node.i.version;
 			tn->fn->ofs = node.i.offset;
-			tn->fn->size = node.i.dsize;
+			/* There was a bug where we wrote hole nodes out with
+			   csize/dsize swapped. Deal with it */
+			if (node.i.compr == JFFS2_COMPR_ZERO && !node.i.dsize && node.i.csize)
+				tn->fn->size = node.i.csize;
+			else // normal case...
+				tn->fn->size = node.i.dsize;
 			tn->fn->raw = ref;
 			D1(printk(KERN_DEBUG "dnode @%08x: ver %u, offset %04x, dsize %04x\n", ref->flash_offset &~3, node.i.version, node.i.offset, node.i.dsize));
 			jffs2_add_tn_to_list(tn, &ret_tn);
Index: read.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/read.c,v
retrieving revision 1.19
diff -u -r1.19 read.c
--- read.c	2002/01/14 23:30:26	1.19
+++ read.c	2002/02/01 23:29:35
@@ -74,6 +74,12 @@
 		ret = -EIO;
 		goto out_ri;
 	}
+	/* There was a bug where we wrote hole nodes out with csize/dsize
+	   swapped. Deal with it */
+	if (ri->compr == JFFS2_COMPR_ZERO && !ri->dsize && ri->csize) {
+		ri->dsize = ri->csize;
+		ri->csize = 0;
+	}
 
 	D1(if(ofs + len > ri->dsize) {
 		printk(KERN_WARNING "jffs2_read_dnode() asked for %d bytes at %d from %d-byte node\n", len, ofs, ri->dsize);
Index: scan.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/scan.c,v
retrieving revision 1.57
diff -u -r1.57 scan.c
--- scan.c	2002/01/09 13:25:58	1.57
+++ scan.c	2002/02/01 23:29:35
@@ -443,6 +443,12 @@
 		*ofs += 4;
 		return 0;
 	}
+	/* There was a bug where we wrote hole nodes out with csize/dsize
+	   swapped. Deal with it */
+	if (ri.compr == JFFS2_COMPR_ZERO && !ri.dsize && ri.csize) {
+		ri.dsize = ri.csize;
+		ri.csize = 0;
+	}
 
 	if (ri.csize) {
 		/* Check data CRC too */
@@ -473,7 +479,7 @@
 			       *ofs, ri.data_crc, crc);
 			DIRTY_SPACE(PAD(ri.totlen));
 			*ofs += PAD(ri.totlen);
-			return -0;
+			return 0;
 		}
 	}
 

--
dwmw2

Re: debugging strategies for jffs2

[Adam Wozniak]

David Woodhouse wrote:
> 
> adam.wozniak@comdev.cc said:
> >  Here's the workaround I came up with: in scan.c:
> 
> Yeah - with a couple more elsewhere too...
> 

Ok, added those.  Things seem ok... =)

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

PATCH to help understanding

[Charles Manning]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Hi folks

I propose the following patches to mtd.h to help the understanding of these 
functions.

read_ecc() and write_ecc() use the argument eccbuff, but this is really oob 
data being passed. The oob data might contain ecc info as well as other 
stuff. With the preferred autoplacement model, this will not have ecc info in 
it. Therefore I suggest a rename on this parameter.

suspend() and resume() are surely the functions for erase suspend and erase 
resume (for those NOR devices that provide this). Perhaps I goofed here and 
these are really power control functions (which would seem rather dodgy). If 
these are really power control fns, then where does erase suspend/resume get 
exposed?

-- Charles

[-- Attachment #2: mtd.h.patch --]
[-- Type: text/x-diff, Size: 1400 bytes --]

diff -Naur oldmtd/mtd.h mtd/mtd.h
--- oldmtd/mtd.h	Fri Dec 17 16:11:34 2004
+++ mtd/mtd.h	Fri Dec 17 16:12:57 2004
@@ -102,8 +102,8 @@
 	int (*read) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf);
 	int (*write) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf);
 
-	int (*read_ecc) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf, u_char *eccbuf, struct nand_oobinfo *oobsel);
-	int (*write_ecc) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf, u_char *eccbuf, struct nand_oobinfo *oobsel);
+	int (*read_ecc) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf, u_char *oobbuf, struct nand_oobinfo *oobsel);
+	int (*write_ecc) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf, u_char *oobbuf, struct nand_oobinfo *oobsel);
 
 	int (*read_oob) (struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen, u_char *buf);
 	int (*write_oob) (struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const u_char *buf);
@@ -139,7 +139,7 @@
 	int (*lock) (struct mtd_info *mtd, loff_t ofs, size_t len);
 	int (*unlock) (struct mtd_info *mtd, loff_t ofs, size_t len);
 
-	/* Power Management functions */
+	/* Erase suspend function ???*/
 	int (*suspend) (struct mtd_info *mtd);
 	void (*resume) (struct mtd_info *mtd);
 

Re: PATCH to help understanding

[Thomas Gleixner]

On Fri, 2004-12-17 at 16:24 +1300, Charles Manning wrote:
> Hi folks
> 
> I propose the following patches to mtd.h to help the understanding of these 
> functions.
> 
> read_ecc() and write_ecc() use the argument eccbuff, but this is really oob 
> data being passed. The oob data might contain ecc info as well as other 
> stuff. With the preferred autoplacement model, this will not have ecc info in 
> it. Therefore I suggest a rename on this parameter.

Makes sense.

> suspend() and resume() are surely the functions for erase suspend and erase 
> resume (for those NOR devices that provide this). Perhaps I goofed here and 
> these are really power control functions (which would seem rather dodgy). If 
> these are really power control fns, then where does erase suspend/resume get 
> exposed?

Those are PM functions. The sole purpose of suspend is to disable the
access to the chip until resume is called, so you can power down safely.
I will add those to the NAND driver for completeness.

Erase suspend/resume is nowhere exposed. It is handled inside the chip
family drivers. For NAND we removed the erase suspend because it does
not work on all chips and the erase time is short anyway so it's not
worth the extra trouble.

tglx