jffs2 / eCos

jffs2 / eCos

[Bob Koninckx]

Hi all

I successfully included jffs2 in my powerpc based system. The fileio1
test runs sucessfully. I am now trying to flash an initial version of
the filesystem to be used by my application.

The block size of my flash is 128kBytes. I made the filesystem image
with the following command

mkfs.jffs2 -v --big-endian -e 0x20000 -r ./jffs2root -o jffs2root.img -p

First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
even succeed in this case. Apparently some magic number that needed to
be 1985 was read as 8519. Some endianness problem I suppose.

After upgrading to version 1.35, the filesystem can be mounted. Files
and directories appear to be present (the same fileio1 test still runs
sucessfull and lists what should be present). Opening a file on this
system seems to succeed (fopen returns a FILE * anyway). However, when I
try to _read_ from the file, I get EIO errors.

Has anybody successfully used mkfs.jffs2 for making a filesystem image
for a powerpc target system running eCos ? Am I doing something obvious
wrong ?

Thanks, Bob

PS1. I am not subscribed to the jffs2 mailing list, please reply to my
personal address
PS2. The host system I am using is a PIII running RH linux 8.0

-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx at mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------

jffs2 / eCos

[Jörn Engel]

On Sun, 30 March 2003 22:49:40 +0200, Bob Koninckx wrote:
> 
> I successfully included jffs2 in my powerpc based system. The fileio1
> test runs sucessfully. I am now trying to flash an initial version of
> the filesystem to be used by my application.
> 
> The block size of my flash is 128kBytes. I made the filesystem image
> with the following command
> 
> mkfs.jffs2 -v --big-endian -e 0x20000 -r ./jffs2root -o jffs2root.img -p
> 
> First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
> even succeed in this case. Apparently some magic number that needed to
> be 1985 was read as 8519. Some endianness problem I suppose.

You forgot -b (big endian), it seems.

> After upgrading to version 1.35, the filesystem can be mounted. Files
> and directories appear to be present (the same fileio1 test still runs
> sucessfull and lists what should be present). Opening a file on this
> system seems to succeed (fopen returns a FILE * anyway). However, when I
> try to _read_ from the file, I get EIO errors.

This is strange. You still forgot -b but can mount it?

J?rn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf 

jffs2 / eCos

[Bob Koninckx]

On Sun, 2003-03-30 at 23:22, J?rn Engel wrote:
> On Sun, 30 March 2003 22:49:40 +0200, Bob Koninckx wrote:
> > 
> > I successfully included jffs2 in my powerpc based system. The fileio1
> > test runs sucessfully. I am now trying to flash an initial version of
> > the filesystem to be used by my application.
> > 
> > The block size of my flash is 128kBytes. I made the filesystem image
> > with the following command
> > 
> > mkfs.jffs2 -v --big-endian -e 0x20000 -r ./jffs2root -o jffs2root.img -p
> > 
> > First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
> > even succeed in this case. Apparently some magic number that needed to
> > be 1985 was read as 8519. Some endianness problem I suppose.
> 
> You forgot -b (big endian), it seems.


I _did_ specify --big-endian. That has the same effect doesn't it ?


> 
> > After upgrading to version 1.35, the filesystem can be mounted. Files
> > and directories appear to be present (the same fileio1 test still runs
> > sucessfull and lists what should be present). Opening a file on this
> > system seems to succeed (fopen returns a FILE * anyway). However, when I
> > try to _read_ from the file, I get EIO errors.
> 
> This is strange. You still forgot -b but can mount it?
> 
> J?rn
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx at mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------

jffs2 / eCos

[Jörn Engel]

On Mon, 31 March 2003 08:26:37 +0200, Bob Koninckx wrote:
> On Sun, 2003-03-30 at 23:22, J?rn Engel wrote:
> > On Sun, 30 March 2003 22:49:40 +0200, Bob Koninckx wrote:
> > > 
> > > I successfully included jffs2 in my powerpc based system. The fileio1
> > > test runs sucessfully. I am now trying to flash an initial version of
> > > the filesystem to be used by my application.
> > > 
> > > The block size of my flash is 128kBytes. I made the filesystem image
> > > with the following command
> > > 
> > > mkfs.jffs2 -v --big-endian -e 0x20000 -r ./jffs2root -o jffs2root.img -p
> > > 
> > > First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
> > > even succeed in this case. Apparently some magic number that needed to
> > > be 1985 was read as 8519. Some endianness problem I suppose.
> > 
> > You forgot -b (big endian), it seems.
> 
> 
> I _did_ specify --big-endian. That has the same effect doesn't it ?

It should. But then again, I'd have to check the code to see that it's
smarter than me. :)

> > > After upgrading to version 1.35, the filesystem can be mounted. Files
> > > and directories appear to be present (the same fileio1 test still runs
> > > sucessfull and lists what should be present). Opening a file on this
> > > system seems to succeed (fopen returns a FILE * anyway). However, when I
> > > try to _read_ from the file, I get EIO errors.
> > 
> > This is strange. You still forgot -b but can mount it?

Even stranger now. Jffs2 on powerpc work just fine for me (unter
linux), mkfs.jffs2 on i386 host included.

J?rn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike

jffs2 / eCos

[David Woodhouse]

On Sun, 2003-03-30 at 21:49, Bob Koninckx wrote:
> First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
> even succeed in this case. Apparently some magic number that needed to
> be 1985 was read as 8519. Some endianness problem I suppose.

We broke the endianness support in mkfs.jffs2...

> After upgrading to version 1.35, the filesystem can be mounted.

... then we fixed it :)

>  Files
> and directories appear to be present (the same fileio1 test still runs
> sucessfull and lists what should be present). Opening a file on this
> system seems to succeed (fopen returns a FILE * anyway). However, when I
> try to _read_ from the file, I get EIO errors.

Compile with CONFIG_JFFS2_FS_DEBUG set to 1 (in os-ecos.h iirc). Show
the error messages you get before it gives you EIO.

> Has anybody successfully used mkfs.jffs2 for making a filesystem image
> for a powerpc target system running eCos ? Am I doing something obvious
> wrong ?

You're doing nothing obviously wrong. The endianness support in
mkfs.jffs2 was temporarily broken, but that led to the failure to mount
which you first saw -- it shouldn't be related to the latter problem.

-- 
dwmw2

[ECOS] Re: jffs2 / eCos

[Bob Koninckx]

Ok, I think I've come closer :)

Apparently, it has to do with the check


} else if (frag->ofs < offset && (offset & (PAGE_CACHE_SIZE-1)) != 0) {
  D1(printk(KERN_NOTICE "Eep. Overlap in ino #%u fraglist. frag->ofs =
          0x%08x, offset = 0x%08x\n",
          f->inocache->ino, frag->ofs, offset));
  D1(jffs2_print_frag_list(f));
  memset(buf, 0, end - offset);
  return -EIO;
} else if (!frag->node) {


in read.c / function jffs2_read_inode_range

The ecos libc buffers only 256 bytes of data, PAGE_CACHE SIZE is defined
to be 4kB. The first access consequently succeeds, the second one fails
...

I suppose all that needs to be done (for eCos) is make the
PAGE_CACHE_SIZE definition agree with the eCos libc BUFSIZ definition. I
am not sure though.

Bob


On Mon, 2003-03-31 at 09:17, David Woodhouse wrote:
> On Sun, 2003-03-30 at 21:49, Bob Koninckx wrote:
> > First I tried mkfs.jffs2 version 1.32. Mounting the filesystem did not
> > even succeed in this case. Apparently some magic number that needed to
> > be 1985 was read as 8519. Some endianness problem I suppose.
> 
> We broke the endianness support in mkfs.jffs2...
> 
> > After upgrading to version 1.35, the filesystem can be mounted.
> 
> ... then we fixed it :)
> 
> >  Files
> > and directories appear to be present (the same fileio1 test still runs
> > sucessfull and lists what should be present). Opening a file on this
> > system seems to succeed (fopen returns a FILE * anyway). However, when I
> > try to _read_ from the file, I get EIO errors.
> 
> Compile with CONFIG_JFFS2_FS_DEBUG set to 1 (in os-ecos.h iirc). Show
> the error messages you get before it gives you EIO.
> 
> > Has anybody successfully used mkfs.jffs2 for making a filesystem image
> > for a powerpc target system running eCos ? Am I doing something obvious
> > wrong ?
> 
> You're doing nothing obviously wrong. The endianness support in
> mkfs.jffs2 was temporarily broken, but that led to the failure to mount
> which you first saw -- it shouldn't be related to the latter problem.
> 
> -- 
> dwmw2
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx at mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------

jffs2 / eCos

[David Woodhouse]

Please don't reply to cross-posts which have travelled via the eCos
list. The gratuitous and redundant noise which that list adds to the
Subject line is not welcome here.

Also, please don't top-post (except for editorial comments such as this
one and the one above :)

On Mon, 2003-03-31 at 21:29, Bob Koninckx wrote:
> Ok, I think I've come closer :)
> 
> Apparently, it has to do with the check
> 
> 
> } else if (frag->ofs < offset && (offset & (PAGE_CACHE_SIZE-1)) != 0) {
>   D1(printk(KERN_NOTICE "Eep. Overlap in ino #%u fraglist. frag->ofs =
>           0x%08x, offset = 0x%08x\n",
>           f->inocache->ino, frag->ofs, offset));
>   D1(jffs2_print_frag_list(f));
>   memset(buf, 0, end - offset);
>   return -EIO;
> } else if (!frag->node) {
> 
> 
> in read.c / function jffs2_read_inode_range
> 
> The ecos libc buffers only 256 bytes of data, PAGE_CACHE SIZE is defined
> to be 4kB. The first access consequently succeeds, the second one fail

Hmmm. I could have sworn I'd already fixed that -- doesn't seem like it
though.

> I suppose all that needs to be done (for eCos) is make the
> PAGE_CACHE_SIZE definition agree with the eCos libc BUFSIZ definition. I
> am not sure though.

No because that would mean we never write a node with more than BUFSIZ
(256 bytes) of data payload, which would mean we take up a lot more
space on the medium for any given file -- more node headers and worse
compression.

We should just fix jffs2_read_inode_range() to handle reads which don't
start at the beginning of a node. It's not hard.

-- 
dwmw2

Re: jffs2 / eCos

[Bob Koninckx]

On Tue, 2003-04-01 at 00:47, David Woodhouse wrote:
> Please don't reply to cross-posts which have travelled via the eCos
> list. The gratuitous and redundant noise which that list adds to the
> Subject line is not welcome here.

Sorry about that. Won't happen again ...

> 
> Also, please don't top-post (except for editorial comments such as this
> one and the one above :)

I am learning fast

> 
> On Mon, 2003-03-31 at 21:29, Bob Koninckx wrote:
> > Ok, I think I've come closer :)
> > 
> > Apparently, it has to do with the check
> > 
> > 
> > } else if (frag->ofs < offset && (offset & (PAGE_CACHE_SIZE-1)) != 0) {
> >   D1(printk(KERN_NOTICE "Eep. Overlap in ino #%u fraglist. frag->ofs =
> >           0x%08x, offset = 0x%08x\n",
> >           f->inocache->ino, frag->ofs, offset));
> >   D1(jffs2_print_frag_list(f));
> >   memset(buf, 0, end - offset);
> >   return -EIO;
> > } else if (!frag->node) {
> > 
> > 
> > in read.c / function jffs2_read_inode_range
> > 
> > The ecos libc buffers only 256 bytes of data, PAGE_CACHE SIZE is defined
> > to be 4kB. The first access consequently succeeds, the second one fail
> 
> Hmmm. I could have sworn I'd already fixed that -- doesn't seem like it
> though.
> 
> > I suppose all that needs to be done (for eCos) is make the
> > PAGE_CACHE_SIZE definition agree with the eCos libc BUFSIZ definition. I
> > am not sure though.
> 
> No because that would mean we never write a node with more than BUFSIZ
> (256 bytes) of data payload, which would mean we take up a lot more
> space on the medium for any given file -- more node headers and worse
> compression.
> 
> We should just fix jffs2_read_inode_range() to handle reads which don't
> start at the beginning of a node. It's not hard.

I removed the above mentioned check and now it _appears_ to work
correctly. Is this all that needs to be done ? Are there similar issues
when writing to the filesys ?

Bob

> 
> -- 
> dwmw2
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven       
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------

Re: jffs2 / eCos

[David Woodhouse]

On Wed, 2003-04-02 at 08:48, Bob Koninckx wrote:
> > We should just fix jffs2_read_inode_range() to handle reads which don't
> > start at the beginning of a node. It's not hard.
> 
> I removed the above mentioned check and now it _appears_ to work
> correctly. Is this all that needs to be done ?

Can you show me the patch or resulting code? 

> Are there similar issues when writing to the filesys ?

No, writing should be fine -- but you really do want to try to ensure
that you don't get writes split up into 256-byte chunks, since that'll
waste space on the file system (till it gets GC'd and merged).
 
-- 
dwmw2

Re: jffs2 / eCos

[Bob Koninckx]

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

On Wed, 2003-04-02 at 10:20, David Woodhouse wrote:
> On Wed, 2003-04-02 at 08:48, Bob Koninckx wrote:
> > > We should just fix jffs2_read_inode_range() to handle reads which don't
> > > start at the beginning of a node. It's not hard.
> > 
> > I removed the above mentioned check and now it _appears_ to work
> > correctly. Is this all that needs to be done ?
> 
> Can you show me the patch or resulting code? 


Just commented the lines containing the test out. Anyway, if you want a
patch to see it for yourself... :-)


> 
> > Are there similar issues when writing to the filesys ?
> 
> No, writing should be fine -- but you really do want to try to ensure
> that you don't get writes split up into 256-byte chunks, since that'll
> waste space on the file system (till it gets GC'd and merged).


Certainly won't be before the week-end. You don't have by any chance any
(standard) test cases, do you ? Any suggestions to seriously test it
(apart from creating a file that is larger than 256 bytes and checking
with the debugger that no "holes" are left)

Thanks for looking after this so far anyway,

Bob

>  
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------

[-- Attachment #2: jffs.patch --]
[-- Type: text/plain, Size: 1395 bytes --]

? jffs.patch
Index: read.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/read.c,v
retrieving revision 1.3
diff -u -5 -r1.3 read.c
--- read.c	5 Feb 2003 00:00:40 -0000	1.3
+++ read.c	2 Apr 2003 19:18:14 -0000
@@ -175,16 +175,16 @@
 			D1(printk(KERN_DEBUG "Filling non-frag hole from %d-%d\n", offset, offset+holesize));
 			memset(buf, 0, holesize);
 			buf += holesize;
 			offset += holesize;
 			continue;
-		} else if (frag->ofs < offset && (offset & (PAGE_CACHE_SIZE-1)) != 0) {
-			D1(printk(KERN_NOTICE "Eep. Overlap in ino #%u fraglist. frag->ofs = 0x%08x, offset = 0x%08x\n",
-				  f->inocache->ino, frag->ofs, offset));
-			D1(jffs2_print_frag_list(f));
-			memset(buf, 0, end - offset);
-			return -EIO;
+//		} else if (frag->ofs < offset && (offset & (PAGE_CACHE_SIZE-1)) != 0) {
+//			D1(printk(KERN_NOTICE "Eep. Overlap in ino #%u fraglist. frag->ofs = 0x%08x, offset = 0x%08x\n",
+//				  f->inocache->ino, frag->ofs, offset));
+//			D1(jffs2_print_frag_list(f));
+//			memset(buf, 0, end - offset);
+//			return -EIO;
 		} else if (!frag->node) {
 			uint32_t holeend = min(end, frag->ofs + frag->size);
 			D1(printk(KERN_DEBUG "Filling frag hole from %d-%d (frag 0x%x 0x%x)\n", offset, holeend, frag->ofs, frag->ofs + frag->size));
 			memset(buf, 0, holeend - offset);
 			buf += holeend - offset;