cramfs and mtd

cramfs and mtd

[Bjorn Wesen]

When using cramfs directly on a ROM chip like below.. can we make
cramfs/inode.c talk to mtd to find a chip maybe instead of using direct
pointers like I do in my small patch below ? That is, would it mess up
inode.c to the degree that it would not be accepted in the mainline kernel
? :) Or is there a better way to do this ?

(Yes of course - JFFS2 - but except that, then :)

/BW

--- inode.c     2001/04/02 12:48:08     1.1.1.3
+++ inode.c     2001/04/04 14:57:00     1.9
@@ -22,6 +22,8 @@

 #include "cramfs.h"

+#define CRAMFS_AS_IMAGE 
+ 
 static struct super_operations cramfs_ops;
 static struct inode_operations cramfs_dir_inode_operations;
 static struct file_operations cramfs_directory_operations;
@@ -97,6 +99,29 @@
  * Returns a pointer to a buffer containing at least LEN bytes of
  * filesystem starting at byte offset OFFSET into the filesystem.
  */
+ 
+#ifdef CRAMFS_AS_IMAGE
+
+/* Normally, cramfs_read reads from offset and len bytes on a block
device.
+ * But if we have an attached image piggybacked on the end of the kernel
+ * (a la krom/romfs) we can use this trivial routine.
+ */
+
+extern unsigned char *romfs_start;  /* set in head.S during boot */
+extern unsigned int romfs_length;   /* dito */
+  
+/*
+ * Returns a pointer to a buffer containing at least LEN bytes of
+ * filesystem starting at byte offset OFFSET into the filesystem.
+ */
+static inline void *cramfs_read(struct super_block *sb, unsigned int
offset, unsigned int len)
+{
+       return romfs_start + offset;
+}
+
+#else /* CRAMFS_AS_IMAGE */
+
 static void *cramfs_read(struct super_block *sb, unsigned int offset,
unsigned int len)
 {
        struct buffer_head * bh_array[BLKS_PER_BUF];
@@ -146,6 +171,7 @@
        return read_buffers[buffer] + offset;
 }

+#endif

 static struct super_block * cramfs_read_super(struct super_block *sb,
void *data, int silent)
 {





To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: cramfs and mtd

[David Woodhouse]

bjorn.wesen@axis.com said:
> When using cramfs directly on a ROM chip like below.. can we make
> cramfs/inode.c talk to mtd to find a chip maybe instead of using
> direct pointers like I do in my small patch below ? That is, would it
> mess up inode.c to the degree that it would not be accepted in the
> mainline kernel ? :) Or is there a better way to do this ? 

See the evil hack in jffs and jffs2 which uses the minor number of the 
mtdblock device to get a handle on the underlying MTD device. Copy that and 
then use the MTD device directly for read/write.

The real advantage of cramfs-on-mtd comes when you can set 
CONFIG_BLK_DEV=n, though - which means the above evil hack is no longer 
possible. We need to remove FS_REQUIRES_DEV from JFFS{,2} and pass the name 
or number of the MTD device as a mount option instead. If you're doing the 
same thing for cramfs, it's probably better to copy the cramfs code to a 
new filesystem (cmtdfs?) and hack it there. 

There are also vague plans to provide an 'xipfs', which has page-aligned 
data, for the benefit of those with more flash space than sense.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

mkfs.jffs2 again

[Joakim Tjernlund]

If I run mkfs.jffs2 on my PC(rh 7) I get this
when I mount it on my RPX(PPC860) board:
sh-2.03# mount -t jffs2 /dev/mtdblock0 mtdblock0/
mtdblock_open
ok
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x8519 inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004:
0x4400 inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008:
0x1dfb inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c:
0x0100 inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010:
0x0100 inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014:
0xed41 inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0xf4de inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024:
0x9bde inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000028:
0x9bde inst
ead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000040:
0xfc56 inst
ead
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
JFFS2: Erase block at 0x00008000 is not formatted. It will be erased
JFFS2: Erase block at 0x00010000 is not formatted. It will be erased
JFFS2: Erase block at 0x00018000 is not formatted. It will be erased
JFFS2: Erase block at 0x00020000 is not formatted. It will be erased
JFFS2: Erase block at 0x00028000 is not formatted. It will be erased
JFFS2: Erase block at 0x00030000 is not formatted. It will be erased
JFFS2: Erase block at 0x00038000 is not formatted. It will be erased

Then if I run mkfs.jffs2 on my RPX board I only get a few:
JFFS2: Erase block at 0x00000800 is not formatted. It will be erased

which I think is normal.


Can this be an big/little endian issue?



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mkfs.jffs2 again

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead

You ran mkfs.jffs2 on a little-endian machine and tried to mount the 
resulting filesystem on a big-endian machine. You have two options:

 1. Don't do that.
 2. Give me a patch for mkfs.jffs2 which does byteswapping when asked.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: mkfs.jffs2 again

[Joakim Tjernlund]

That figures :-)

I will give it a try (hopefully) next week. Any hints?

    Jocke

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Thursday, April 19, 2001 15:53
To: joakim.tjernlund@lumentis.se
Cc: mtd@infradead.org
Subject: Re: mkfs.jffs2 again 

joakim.tjernlund@lumentis.se said:
> Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead

You ran mkfs.jffs2 on a little-endian machine and tried to mount the 
resulting filesystem on a big-endian machine. You have two options:

 1. Don't do that.
 2. Give me a patch for mkfs.jffs2 which does byteswapping when asked.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

> If it's really just being slow, then maybe you're going to need one or two
> of the features on the wishlist implemented - checkpointing and
> prepopulating inodes on mount.
> --
> dwmw2

Yes, please, please :-)

           Jocke



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
>  Yes, please, please :-) 

That was a 'you need these' not a 'I'll give you these'. 

I'm happy to give you pointers if you want to implement them.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

> Joakim.Tjernlund@lumentis.se said:
> >  Yes, please, please :-) 
> 
> That was a 'you need these' not a 'I'll give you these'. 

Well, I figured that, but I could not resist asking anyway :-) 

> 
> I'm happy to give you pointers if you want to implement them.

I am not skilled enought in kernel/JFFS programming yet nor do I have
the time ATM. Perhaps we can discuss this later?

In the mean time I would appriciate any pointers to fix the endian 
problems in mkfs.jffs2 and how to disable compression in JFFS2(can that 
be done with mkfs.jffs2?). 

     Jocke




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> In the mean time I would appriciate any pointers to fix the endian
> problems in mkfs.jffs2 and how to disable compression in JFFS2(can
> that  be done with mkfs.jffs2?).

David Schleef gave me patches to do byteswapping the other day. I requested 
some cleanups but his code was perfectly usable as it was.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

> Joakim.Tjernlund@lumentis.se said:
> > In the mean time I would appriciate any pointers to fix the endian
> > problems in mkfs.jffs2 and how to disable compression in JFFS2(can
> > that  be done with mkfs.jffs2?).
>
> David Schleef gave me patches to do byteswapping the other day. I
requested
> some cleanups but his code was perfectly usable as it was.

Sure would like to lay my hands on that code ...

              Jocke
> --
> dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Schleef]

On Sat, Apr 21, 2001 at 10:22:08PM +0200, Joakim Tjernlund wrote:
> > Joakim.Tjernlund@lumentis.se said:
> > > In the mean time I would appriciate any pointers to fix the endian
> > > problems in mkfs.jffs2 and how to disable compression in JFFS2(can
> > > that  be done with mkfs.jffs2?).
> >
> > David Schleef gave me patches to do byteswapping the other day. I
> requested
> > some cleanups but his code was perfectly usable as it was.
> 
> Sure would like to lay my hands on that code ...


I just checked it in, along with a man page describing the various
options as I understand them.  I also wrote a little shell script
that creates a test filesystem and compares it to a reference
filesystem.  The reference filesystems were created on i386 and
powerpc hosts before I made the endianness changes.  The limit
of my testing is creating a BE JFFS2 filesystem on an i386 and
comparing it to the reference filesystem -- they were identical,
so I called the operation a success.  I'll check in the test
script in the next couple days.




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

Thanks!

I will give it a spin during the week.

 Jocke

-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
Of David Schleef
I just checked it in, along with a man page describing the various
options as I understand them.  I also wrote a little shell script
that creates a test filesystem and compares it to a reference
filesystem.  The reference filesystems were created on i386 and
powerpc hosts before I made the endianness changes.  The limit
of my testing is creating a BE JFFS2 filesystem on an i386 and
comparing it to the reference filesystem -- they were identical,
so I called the operation a success.  I'll check in the test
script in the next couple days.




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

Hi again

I noted that your man page(nice work) states that JFFS2 and mkfs.jffs2 do
not
support hard links, but the MTD homepage states otherwise.
Is it just mkfs.jffs2 that don't support hardlinks?

         Jocke

-----Original Message-----
From: David Schleef [mailto:ds@stm.lbl.gov]On Behalf Of David Schleef
Sent: Monday, April 23, 2001 3:52
To: Joakim Tjernlund
Cc: David Woodhouse; mtd@infradead.org
Subject: Re: JFFS2 as root FS


On Sat, Apr 21, 2001 at 10:22:08PM +0200, Joakim Tjernlund wrote:
> > Joakim.Tjernlund@lumentis.se said:
> > > In the mean time I would appriciate any pointers to fix the endian
> > > problems in mkfs.jffs2 and how to disable compression in JFFS2(can
> > > that  be done with mkfs.jffs2?).
> >
> > David Schleef gave me patches to do byteswapping the other day. I
> requested
> > some cleanups but his code was perfectly usable as it was.
>
> Sure would like to lay my hands on that code ...


I just checked it in, along with a man page describing the various
options as I understand them.  I also wrote a little shell script
that creates a test filesystem and compares it to a reference
filesystem.  The reference filesystems were created on i386 and
powerpc hosts before I made the endianness changes.  The limit
of my testing is creating a BE JFFS2 filesystem on an i386 and
comparing it to the reference filesystem -- they were identical,
so I called the operation a success.  I'll check in the test
script in the next couple days.




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I noted that your man page(nice work) states that JFFS2 and
> mkfs.jffs2 do not support hard links, but the MTD homepage states
> otherwise. Is it just mkfs.jffs2 that don't support hardlinks? 

JFFS doesn't. JFFS2 does.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Schleef]

On Mon, Apr 23, 2001 at 10:31:08AM +0100, David Woodhouse wrote:
> 
> joakim.tjernlund@lumentis.se said:
> >  I noted that your man page(nice work) states that JFFS2 and
> > mkfs.jffs2 do not support hard links, but the MTD homepage states
> > otherwise. Is it just mkfs.jffs2 that don't support hardlinks? 
> 
> JFFS doesn't. JFFS2 does.


I meant to say that mkfs.jffs2 did not handle hard links properly,
because I didn't see evidence of a hard link cache in the code.
Is that true, or no?




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

ds@schleef.org said:
>  I meant to say that mkfs.jffs2 did not handle hard links properly,
> because I didn't see evidence of a hard link cache in the code. Is
> that true, or no? 

That is true. Nobody's yet written the code to notice hard links in the
source directory and put appropriate hard links in the created JFFS2
filesystem.

Note that once you realise you only need to keep a cache of (dev,inode)
tuples for inodes with i_nlink > 1, rather than every inode you touch, and 
that you only need to look into that cache when you're writing out such an 
inode, it becomes a much more feasible task.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Schleef]

On Mon, Apr 23, 2001 at 12:04:16PM +0100, David Woodhouse wrote:
> 
> That is true. Nobody's yet written the code to notice hard links in the
> source directory and put appropriate hard links in the created JFFS2
> filesystem.

Can you (or someone) comment on whether or not JFFS2 satisfies
the necessary criteria for a POSIX-compliant file system?  I
could not (quickly) find a reference to what qualifies as a POSIX
file system, otherwise I would have checked myself.

> Note that once you realise you only need to keep a cache of (dev,inode)
> tuples for inodes with i_nlink > 1, rather than every inode you touch, and 
> that you only need to look into that cache when you're writing out such an 
> inode, it becomes a much more feasible task.

That actually seems to be more complicated than checking every
inode.  That is, if you consider if(n_links>1) more complicated.
Also, you need to check the device to make sure its not the
same inode number on a different device.  But I digress and
become nitpicky.




dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> how to disable compression in JFFS2(can that  be done with
> mkfs.jffs2?). 

Sorry, missed that bit. Just replace jffs2_{de,}compress() with NOPs. 
Return zero from jffs2_compress(). Rebuild jffs2 and mkfs.jffs2 (it pulls 
in the compr files from the kernel dir).

Why, though?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

> Joakim.Tjernlund@lumentis.se said:
> > how to disable compression in JFFS2(can that  be done with
> > mkfs.jffs2?).
>
> Sorry, missed that bit. Just replace jffs2_{de,}compress() with NOPs.
> Return zero from jffs2_compress(). Rebuild jffs2 and mkfs.jffs2 (it pulls
> in the compr files from the kernel dir).
>
> Why, though?

To gain performace, we will have a PPC860 which isn't very powerful but
we will have plenty of flash and RAM. By the way, will mount time be reduced
if I remove compression?

         Jocke
>
> --
> dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
>  To gain performace, we will have a PPC860 which isn't very powerful
> but we will have plenty of flash and RAM. By the way, will mount time
> be reduced if I remove compression?

If Vipin's hypothesis that your speed problem is because of flash access
cycles being slow, you probably won't see an improvement. Worth a try,
though.

It shouldn't fix the mount time though - we don't look at the data on 
mount.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

Hi again

Now that my JFFS2 FS mounts properly&speedy(less than 5 seconds) I try
to use it as a root FS and I got this:

....
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing unused kernel memory: 48k init
INIT: version 2.77 booting
INIT: cannot execute "/etc/rc.sysinit"

The /etc/rc.sysinit file is there and executable, so why won't init execute
it?

        Jocke



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Williams, Kevin M.]

Vipin wrote:
>Well, the kernel may not be able to understand the 
>"mtdblock1" device by name unless you patched the 
>init/main.c file to list a conversion table from 
>mtdblockxx to a *device number*.

Can you please tell me where I can find more information on doing this?  I
have downloaded and grepped the mailing list archives, and looked in the
patches, but only the 2.2.x patches seem to have any changes to main.c
included and those changes do not do what you are describing here.  Reading
mailinglist archives shows I may also need to modify filesystems.c.

Is there a patch file for anything after the official 2.4.0 kernel
available?

I am using a mainline 2.4.3-pre3 kernel and simply copied from the latest
ftp snapshot into my kernel's /fs, /include, and /kernel directories.  It
worked (at least the CFI_probe part did), and if I mknod I can create
entries in my /dev directory and erase them ok (maybe mknod is the wrong
thing to do, I don't know, but erase really does work now!), but mount is
still not working (it returns "bad area!!" and says something like I may
have "wrong device # or fstype not supported").  

I tried enabling CONFIG_MTD_CHAR and CONFIG_MTD_BLOCK but that did not make
anything come up in my /dev directory.

I think I have not completely updated my kernel...

Thank you.

Kevin
 



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: A pair of stupid questions, I hope

[David Woodhouse]

ian.nelson@echostar.com said:
>  I'll ask the guys who need it.  I suspect the proposal would be an
> ISLOCKED ioctl that takes a region as an argument and returns a 0 or
> 1.   I'm a flash novice though, is this something that should go in to
> one of those region structures? 

I was thinking of the internal API - what method do we add to the struct 
mtd_info, and how generic can we make it? Aren't there other similar 
per-block data which we may want to query on some chips?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

JFFS2 as root FS

[Joakim Tjernlund]

Hi there


Has anybody managed to get a root FS with JFFS2 to work?

I followed the mtd howto and I have a root partition(with the necessary
files) and
all I get is: "Kernel panic: I have no root and I want to scream"
message.

first I tried to use "rdev zvmlinux /dev/mtdblock1", but
the kernel ignored that an did a NFS mount as usual. I then
specified on the kernel commad line: root=/dev/mtdblock1
and the I got the kernel panic above.

Any Ideas?

    Jocke



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I followed the mtd howto and I have a root partition(with the
> necessary files) and all I get is: "Kernel panic: I have no root and I
> want to scream" message. 

Does it still happen with CONFIG_DEVFS_FS=n?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

yes, I dont have devFS support compiled into the kernel.

 Jocke

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Wednesday, April 18, 2001 18:51
To: joakim.tjernlund@lumentis.se
Cc: mtd@infradead.org
Subject: Re: JFFS2 as root FS 




joakim.tjernlund@lumentis.se said:
>  I followed the mtd howto and I have a root partition(with the
> necessary files) and all I get is: "Kernel panic: I have no root and I
> want to scream" message. 

Does it still happen with CONFIG_DEVFS_FS=n?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> yes, I dont have devFS support compiled into the kernel. 

Hmmm. And do you have an entry for 'mtdblock' in the big array in 
init/main.c? 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

> 
> joakim.tjernlund@lumentis.se said:
> > yes, I dont have devFS support compiled into the kernel. 
> 
> Hmmm. And do you have an entry for 'mtdblock' in the big array in 
> init/main.c? 

Don't know, I will have to check when I get back to work(I am home now)

           Jocke
> 
> --
> dwmw2
> 
> 



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Vipin Malik]

Joakim Tjernlund wrote:

> Hi there
>
> Has anybody managed to get a root FS with JFFS2 to work?

Sure! But as you say that you followed the HOWTO, and since I wrote the
HOWTO,
I guess that something in my procedures tripped you up that worked ok for
me :)


>
> I followed the mtd howto and I have a root partition(with the necessary
> files) and
> all I get is: "Kernel panic: I have no root and I want to scream"
> message.

Hmm, what kernel version are you using? I've never seen that message (I've
seen Kernel panic: Unable to open root..blah blah..)


>
>
> first I tried to use "rdev zvmlinux /dev/mtdblock1", but
> the kernel ignored that an did a NFS mount as usual.

Wait, wait, wait. What do you mean by this? This is *a problem* right
here.

Why is it doing a NFS mount? Please describe your config and what you are
trying to do.
"usual" kernels don't NFS mount their root fs!



> I then
> specified on the kernel commad line: root=/dev/mtdblock1
> and the I got the kernel panic above.

Well, the kernel may not be able to understand the "mtdblock1" device by
name unless you patched
the init/main.c file to list a conversion table from mtdblockxx to a
*device number*.


>
>
> Any Ideas?

These are some.

Vipin



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

----- Original Message -----
From: "Vipin Malik" <vipin.malik@daniel.com>
To: <joakim.tjernlund@lumentis.se>
Cc: <mtd@infradead.org>
Sent: den 18 april 2001 19:11
Subject: Re: JFFS2 as root FS


> Joakim Tjernlund wrote:
>
> > Hi there
> >
> > Has anybody managed to get a root FS with JFFS2 to work?
>
> Sure! But as you say that you followed the HOWTO, and since I wrote the
> HOWTO,
> I guess that something in my procedures tripped you up that worked ok for
> me :)

Dont think so, I think it's me :-)

>
>
> >
> > I followed the mtd howto and I have a root partition(with the necessary
> > files) and
> > all I get is: "Kernel panic: I have no root and I want to scream"
> > message.
>
> Hmm, what kernel version are you using? I've never seen that message (I've
> seen Kernel panic: Unable to open root..blah blah..)

I using a 2.4 kernel I pulled from Cort Dougan's PPC tree a few weeks ago.
Can't remeber which version rigth now, I will have to check when I get back
to work tomorrow. Should I change to the latest official kernel(2.4.3)?

>
>
> >
> >
> > first I tried to use "rdev zvmlinux /dev/mtdblock1", but
> > the kernel ignored that an did a NFS mount as usual.
>
> Wait, wait, wait. What do you mean by this? This is *a problem* right
> here.
>
> Why is it doing a NFS mount? Please describe your config and what you are
> trying to do.
> "usual" kernels don't NFS mount their root fs!

I am using an RPX CLLF board with a PPC869T. I found a config under
arch/ppc/defconfigs
(If my memory don't fail me)

In that config there were an automount(??) option enabled and a Root fs on
NFS option also
enabled.  I will  disable them and se what happens.


>
>
>
> > I then
> > specified on the kernel commad line: root=/dev/mtdblock1
> > and the I got the kernel panic above.
>
> Well, the kernel may not be able to understand the "mtdblock1" device by
> name unless you patched
> the init/main.c file to list a conversion table from mtdblockxx to a
> *device number*.

Well, this I have not done. Cant remember I saw that in the mtd howto, is
that patch
included in later kernels?



Other questions i have:

  Is mkfs.jffs2 Endian safe? I mean can I run mkfs.jffs2 on an Intel PC and
then copy it to my RPX board?

  Is there a way to disable compression in JFFS2?

I have also noted that sym links in JFFS2 have zero size,  a bug?

>
>
> >
> >
> > Any Ideas?
>
> These are some.
>
> Vipin
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Vipin Malik]

Joakim Tjernlund wrote:

> ----- Original Message -----
> From: "Vipin Malik" <vipin.malik@daniel.com>
> To: <joakim.tjernlund@lumentis.se>
> Cc: <mtd@infradead.org>
> Sent: den 18 april 2001 19:11
> Subject: Re: JFFS2 as root FS
>
> > Joakim Tjernlund wrote:
> >
> > > Hi there
> > >
> > > Has anybody managed to get a root FS with JFFS2 to work?
> >
> > Sure! But as you say that you followed the HOWTO, and since I wrote the
> > HOWTO,
> > I guess that something in my procedures tripped you up that worked ok for
> > me :)
>
> Dont think so, I think it's me :-)
>
> >
> >
> > >
> > > I followed the mtd howto and I have a root partition(with the necessary
> > > files) and
> > > all I get is: "Kernel panic: I have no root and I want to scream"
> > > message.
> >
> > Hmm, what kernel version are you using? I've never seen that message (I've
> > seen Kernel panic: Unable to open root..blah blah..)
>
> I using a 2.4 kernel I pulled from Cort Dougan's PPC tree a few weeks ago.
> Can't remeber which version rigth now, I will have to check when I get back
> to work tomorrow. Should I change to the latest official kernel(2.4.3)?

I don't know. Never played with a non-x86 kernel (well if you don't count the
dragonball kernel variant).
I wouldn't think that you would need to update to the latest one, but i'll let
someone who know's reply.

Make sure that you have the latest sources from CVS patched in though. You
don't want to be playing with the
default mtd/jffs stuff that came with the kernel.


>
>
> >
> >
> > >
> > >
> > > first I tried to use "rdev zvmlinux /dev/mtdblock1", but
> > > the kernel ignored that an did a NFS mount as usual.
> >
> > Wait, wait, wait. What do you mean by this? This is *a problem* right
> > here.
> >
> > Why is it doing a NFS mount? Please describe your config and what you are
> > trying to do.
> > "usual" kernels don't NFS mount their root fs!
>
> I am using an RPX CLLF board with a PPC869T. I found a config under
> arch/ppc/defconfigs
> (If my memory don't fail me)
>
> In that config there were an automount(??) option enabled and a Root fs on
> NFS option also
> enabled.  I will  disable them and se what happens.

I don't think that just enabling these options actually *does* mount root over
nfs. It just allows
it. (Disclaimer: I've never mounted root over nfs myself so take this with a
pinch of salt).

>
>
> >
> >
> >
> > > I then
> > > specified on the kernel commad line: root=/dev/mtdblock1
> > > and the I got the kernel panic above.
> >
> > Well, the kernel may not be able to understand the "mtdblock1" device by
> > name unless you patched
> > the init/main.c file to list a conversion table from mtdblockxx to a
> > *device number*.
>
> Well, this I have not done. Cant remember I saw that in the mtd howto, is
> that patch
> included in later kernels?

You don't need to apply the patch if you stick with the rdev stuff, as that
uses device numbers to
tell the kernel what root is.

You may have to dive into the kernel sources and put prink's to see that your
kernel thinks root device is
that it's  trying to mount. That'll tell you where the problem lies in the
first place.

If it doesn't say something like 31:1 (for /dev/mtdblock1) then your rdev
command did not take. Investigate that then.

If your root device is correct then investigate why it could not mount it. You
did run lilo after you did rdev?



>
>
> Other questions i have:
>
>   Is mkfs.jffs2 Endian safe? I mean can I run mkfs.jffs2 on an Intel PC and
> then copy it to my RPX board?

There *are* people using mtd/jffs on PPC. See the list archives for some issues
that people have had and their possible solutions.

Hmm, you'r not trying to mount jffs as root before you can manually mount it as
a "regular" partition under full manual control?
If you have endian issues, they should pop up at that time. Debugging endian
issues and root mounting problems is not a good plan.


>
>
>   Is there a way to disable compression in JFFS2?

Not that I know of. I think it's in the to-do list. Ask David W.

>
>
> I have also noted that sym links in JFFS2 have zero size,  a bug?

David?


Vipin



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

----- Original Message -----
From: "Vipin Malik" <vipin.malik@daniel.com>
To: "Joakim Tjernlund" <Joakim.Tjernlund@lumentis.se>
Cc: <mtd@infradead.org>
Sent: den 18 april 2001 22:19
Subject: Re: JFFS2 as root FS


> Joakim Tjernlund wrote:
>
> > ----- Original Message -----
> > From: "Vipin Malik" <vipin.malik@daniel.com>
> > To: <joakim.tjernlund@lumentis.se>
> > Cc: <mtd@infradead.org>
> > Sent: den 18 april 2001 19:11
> > Subject: Re: JFFS2 as root FS
> >
> > > Joakim Tjernlund wrote:
> > >
> > > > Hi there
> > > >
> > > > Has anybody managed to get a root FS with JFFS2 to work?
> > >
> > > Sure! But as you say that you followed the HOWTO, and since I wrote
the
> > > HOWTO,
> > > I guess that something in my procedures tripped you up that worked ok
for
> > > me :)
> >
> > Dont think so, I think it's me :-)
> >
> > >
> > >
> > > >
> > > > I followed the mtd howto and I have a root partition(with the
necessary
> > > > files) and
> > > > all I get is: "Kernel panic: I have no root and I want to scream"
> > > > message.
> > >
> > > Hmm, what kernel version are you using? I've never seen that message
(I've
> > > seen Kernel panic: Unable to open root..blah blah..)
> >
> > I using a 2.4 kernel I pulled from Cort Dougan's PPC tree a few weeks
ago.
> > Can't remeber which version rigth now, I will have to check when I get
back
> > to work tomorrow. Should I change to the latest official kernel(2.4.3)?
>
> I don't know. Never played with a non-x86 kernel (well if you don't count
the
> dragonball kernel variant).
> I wouldn't think that you would need to update to the latest one, but i'll
let
> someone who know's reply.
>
> Make sure that you have the latest sources from CVS patched in though. You
> don't want to be playing with the
> default mtd/jffs stuff that came with the kernel.

yeah, I have the latest sources.

>
>
> >
> >
> > >
> > >
> > > >
> > > >
> > > > first I tried to use "rdev zvmlinux /dev/mtdblock1", but
> > > > the kernel ignored that an did a NFS mount as usual.
> > >
> > > Wait, wait, wait. What do you mean by this? This is *a problem* right
> > > here.
> > >
> > > Why is it doing a NFS mount? Please describe your config and what you
are
> > > trying to do.
> > > "usual" kernels don't NFS mount their root fs!
> >
> > I am using an RPX CLLF board with a PPC869T. I found a config under
> > arch/ppc/defconfigs
> > (If my memory don't fail me)
> >
> > In that config there were an automount(??) option enabled and a Root fs
on
> > NFS option also
> > enabled.  I will  disable them and se what happens.
>
> I don't think that just enabling these options actually *does* mount root
over
> nfs. It just allows
> it. (Disclaimer: I've never mounted root over nfs myself so take this with
a
> pinch of salt).

hmm, there has to be something in my config which takes precedence over
rdev, otherwise
the kernel would try to mount mtdblock1 instead of doing a NFS mount. The
kernel
does a BOOTP request to find its IP address, maybe that also implies to
mount a NFS root
instead of mtdblock1?

>
> >
> >
> > >
> > >
> > >
> > > > I then
> > > > specified on the kernel commad line: root=/dev/mtdblock1
> > > > and the I got the kernel panic above.
> > >
> > > Well, the kernel may not be able to understand the "mtdblock1" device
by
> > > name unless you patched
> > > the init/main.c file to list a conversion table from mtdblockxx to a
> > > *device number*.
> >
> > Well, this I have not done. Cant remember I saw that in the mtd howto,
is
> > that patch
> > included in later kernels?
>
> You don't need to apply the patch if you stick with the rdev stuff, as
that
> uses device numbers to
> tell the kernel what root is.

would be nice to try this patch to see if things start to work. Do how this
patch
looks?

>
> You may have to dive into the kernel sources and put prink's to see that
your
> kernel thinks root device is
> that it's  trying to mount. That'll tell you where the problem lies in the
> first place.
>
> If it doesn't say something like 31:1 (for /dev/mtdblock1) then your rdev
> command did not take. Investigate that then.
>
> If your root device is correct then investigate why it could not mount it.
You
> did run lilo after you did rdev?

Currently I let the RPX firmware boot the kernel via tftp. Is that whats
causing my problems?
I have not tried LILO since I think it can only handle x86. Can it do PPC as
well(with a JFFS2 root FS)?

>
>
>
> >
> >
> > Other questions i have:
> >
> >   Is mkfs.jffs2 Endian safe? I mean can I run mkfs.jffs2 on an Intel PC
and
> > then copy it to my RPX board?
>
> There *are* people using mtd/jffs on PPC. See the list archives for some
issues
> that people have had and their possible solutions.
>
> Hmm, you'r not trying to mount jffs as root before you can manually mount
it as
> a "regular" partition under full manual control?

No, I have mounted it manually first and then copied required files more or
less by hand.
I tried mkfs.jffs2, but it didn't work for me. Maybe I am doing something
wrong?
I did this: mkfs.jffs2 -d <path to my root fs dir> -o rootfs.image -e
0x40000
then on RPX: eraseall /dev/mtd1; cp rootfs.image /dev/mtd1(or was it
mtdblock1?)

that gave me lots of errors when mounting JFFS2 on /dev/mtdblock1
(don't have the error messages handy now)

Does mkfs.jffs2 handle dev files & sym links correctly?

> If you have endian issues, they should pop up at that time. Debugging
endian
> issues and root mounting problems is not a good plan.

heh, not a very good plan at all :-)

>
>
> >
> >
> >   Is there a way to disable compression in JFFS2?
>
> Not that I know of. I think it's in the to-do list. Ask David W.

David, is it possible?

>
> >
> >
> > I have also noted that sym links in JFFS2 have zero size,  a bug?
>
> David?
>
>
> Vipin

       Jocke



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Florian Schirmer / TayTron]

Hi!

We had the same problem with root nfs instead of jffs(1). The problem
disappeared as soon as we removed the nfs root feature from the kernel
config. I dont know where the problem exactly is, but this is a (ugly)
solution.

Hope that helps
  Florian



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

Hi again

By adding /dev/mtdblock1 to init/main.c I managed to make Linux recognize
my root FS on mtdblock1 :-)

Now I am having some other problems :-(
First it takes about 1 min 30 sec to mount my root FS. Is that expected? I
was hoping for a much shorter
mount time, 10-20 sec
The root partition is 15 MB and df reports:

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1           15104      6580      8524  44% /mnt/mtdblock1

After the root FS is mounted, linux gets stuck right after message:
"Freeing unused kernel memory: 48k init"

I think that the next step is to run /sbin/init but that never happens.


 Jocke

Below is my console log


PlanetCore Boot Loader v1.02
Copyright 2000 Embedded Planet.  All rights reserved.
DRAM available size = 16 MB
wvCV
DRAM OK
>ru  << thist loads and executes the kernel via tftp >>

loaded at:     00210000 0021C57C
relocated to:  00180000 0018C57C
board data at: 001801B8 001801D4
relocated to:  00200100 0020011C
zimage at:     0024E583 002C725B
avail ram:     002C8000 01000000

Linux/PPC load: root=/dev/mtdblock1 rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.3-pre6 (root@jocke.lumentis.se) (gcc version 2.95.2
19991030 (2.
95.3 prerelease/franzo)) #79 Thu Apr 19 10:35:54 CEST 2001
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 rw
Decrementer Frequency = 180000000/60
Calibrating delay loop... 47.82 BogoMIPS
Memory: 14640k available (1004k kernel code, 376k data, 48k init, 0k
highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
block: queued sectors max/low 9648kB/3216kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:26:1b
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
AB.
loop: loaded (max 8 devices)
RPX Lite or CLLF flash device: 1000000 at ff000000
RPX: Found 4 x16 devices at 0x0 in 32-bit mode
 Amd/Fujitsu Extended Query Table v1.2 at 0x0040
number of CFI chips: 1
0: offset=0x0,size=0x8000,blocks=8
1: offset=0x40000,size=0x40000,blocks=63
mtd: Giving out device 0 to RPX App 0xff000000
mtd: Giving out device 1 to RPX User space1,
mtd: Giving out device 2 to RPX CLLF boot firmware
mtd: Giving out device 3 to RPX  User Space2, Empty
mtd: Giving out device 4 to RPX  Diag & Utils
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 192.168.1.38, my address is 192.168.1.150
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
mtdblock_open
ok
mtdblock: read on "RPX User space1" at 0x400, size 0x400
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 48k init

<< here I power cycle the board >>

A
 PlanetCore Boot Loader v1.02
Copyright 2000 Embedded Planet.  All rights reserved.
DRAM available size = 16 MB




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Florian Schirmer / TayTron]

Hallo!

> By adding /dev/mtdblock1 to init/main.c I managed to make Linux recognize
> my root FS on mtdblock1 :-)
>
> Now I am having some other problems :-(
> First it takes about 1 min 30 sec to mount my root FS. Is that expected? I
> was hoping for a much shorter
> mount time, 10-20 sec

Did you try to mount the flash again under linux? We had a problem with the
endianess some time ago and run into the same trouble as you did. Mounting
took a long time and after that the flash was completely empty. Files cound
be moved onto it, but as soon as you re-mounted the flash it was empty
again. Try if this happens to you too.

I know its a wild guess but maybe it helps!

Happy hacking
   Florian



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: JFFS2 as root FS

[Joakim Tjernlund]

Hi, it's me again :-)

I have tried to mount the FS again and the files are still there.
It still takes 1 min and 30 sec to mount it and sometime when I do a ls the
system hangs
for 10-20 sec before the output from ls is seen. Is this normal?

Maybe I should change my kernel, but to which? Linux 2.4.3? Or maybe a later
kernel from the PPC tree?

Also, when I boot the kernel it stops and ask for a kernel cmdline. Usually
I press
return here and the boot continues with my default values. How can I make
the kernel bypass
this and start without any questions asked?

   Jocke

-----Original Message-----
From: Florian Schirmer / TayTron [mailto:schirmer@taytron.net]
Sent: Thursday, April 19, 2001 15:02
To: joakim.tjernlund@lumentis.se; 'Vipin Malik'
Cc: mtd@infradead.org
Subject: Re: JFFS2 as root FS


Hallo!

> By adding /dev/mtdblock1 to init/main.c I managed to make Linux recognize
> my root FS on mtdblock1 :-)
>
> Now I am having some other problems :-(
> First it takes about 1 min 30 sec to mount my root FS. Is that expected? I
> was hoping for a much shorter
> mount time, 10-20 sec

Did you try to mount the flash again under linux? We had a problem with the
endianess some time ago and run into the same trouble as you did. Mounting
took a long time and after that the flash was completely empty. Files cound
be moved onto it, but as soon as you re-mounted the flash it was empty
again. Try if this happens to you too.

I know its a wild guess but maybe it helps!

Happy hacking
   Florian



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I have tried to mount the FS again and the files are still there. It
> still takes 1 min and 30 sec to mount it and sometime when I do a ls
> the system hangs for 10-20 sec before the output from ls is seen. Is
> this normal? 

That's very very slow. I don't know why it's being so slow for you. 

Your CPU isn't particularly fast, but that shouldn't really make _that_ 
much difference. 

Can you set CONFIG_JFFS2_FS_DEBUG=1 and set default_loglevel to 8 in kernel/
printk.c, then log the messages that it produces? I'd like to see if 
anything untoward is happening.

If it's really just being slow, then maybe you're going to need one or two 
of the features on the wishlist implemented - checkpointing and 
prepopulating inodes on mount.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Nicolas Pitre]

On Thu, 19 Apr 2001, David Woodhouse wrote:

>
> joakim.tjernlund@lumentis.se said:
> >  I have tried to mount the FS again and the files are still there. It
> > still takes 1 min and 30 sec to mount it and sometime when I do a ls
> > the system hangs for 10-20 sec before the output from ls is seen. Is
> > this normal?
>
> That's very very slow. I don't know why it's being so slow for you.

Maybe the flash access timing is awfully slow?  Default values for such
things are often the slowest.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Vipin Malik]

> Now I am having some other problems :-(
> First it takes about 1 min 30 sec to mount my root FS. Is that expected? I
> was hoping for a much shorter
> mount time, 10-20 sec
> The root partition is 15 MB and df reports:
>
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/mtdblock1           15104      6580      8524  44% /mnt/mtdblock1

Just for reference, my AMD SC520 -100MHz (a 100MHz 486+) with a 8MB, 57% full
JFFS2 f/s takes ~19 seconds to mount.
The flash is connected on a 32bit bus. Even if it takes 700us (for max wait
states on my system) per quad word read (32bits), the entire flash can be
read in 1.46 seconds.

Even if your flash is connected x8 wide, your flash read times should not be
more than 10-12seconds.

Obviously, as my flash read time is only ~2 seconds of my 19s fs mount time,
the processor speed plays quite a significant role in the mount process.

To test this theory, I upped the speed to 133MHz and then it took ~15seconds
to mount.
The increase in clock speed was 33%, the mount was (19-15)/15 = 26% faster.
However, if I remove the "constant" portion of the two mounts- the flash read
which is not any faster, then the increase in
mount speed  = ((19-1.46) - (15-1.46))/ (15 - 1.46) = 29.5% faster, almost
linear with the increase with clock speed!
(This also tells me that the code is executing primarily out of cache).

If you say, that your system takes ~90seconds to mount. Let's say that your
flash read time is ~10 seconds (for 16MB), then if all else is
ok, your processor should be ~80/17.5 = 4.5 times slower than mine. This
assumes equal amount of processing. But your processor is doing about
(6580/4636 = 140%) more
processing than mine. Assuming linear overhead, then the new factor is ~57/18
= 3.1X slower. (your flash usage is 6580 blocks, mine is 4636 blocks).

Now you say that you are using a MPC869T. I did not find a 869T on the web. I
presume that you meant 860T. At what MHz?

The 860T is claimed to have a performance of ~66 Dhrystone MIPS at 50MHz. I
downloaded Dhrystone 2.1 and that give me 51 mips at 100Mhz (and 67.7at
133MHz).

However, my 486 has a 16KB combined cache and a 66MHz SDRAM bus. The FLASH is
not cached, so the entire cache can be used for the instruction execution.
The 860T has only 4KB of instruction cache. Under some circumstances (when
the code fits in the cache in my processor and not in yours), the SC520 will
behave like a 100MHz machine while the PPC will be limited to the bus clock
speed. What is you bus clock speed (and your core clock speed).

If your BUS clock is ~25-33 MHz, it's not unbelievable that your processor
runs ~2-3X slower, specially if your processor core is running at <50MHz.
Also remember that execution from cache is significantly faster than
execution from EDO DRAM on the bus.

Something to think about. Of course it could be something completely
different, like a bug in David's code ;)

Vipin



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS2 as root FS

[Joakim Tjernlund]

Wow, that was an impressive analysis!

Regarding my HW, it is a PPC860T and it is running at 50MHz(48 to be exact
since the ext. clock is 8MHz
and the multiplier 6). The bus is supposed to run at the same speed, 48
MHz,(how do I check that?)
The Flash is on a 32 bit bus(4 in x8 mode), erase sector is 256KB.

hmm, mounting my fs should be quicker than 90 seconds.

     Jocke

----- Original Message -----
From: "Vipin Malik" <vipin.malik@daniel.com>
To: <joakim.tjernlund@lumentis.se>
Cc: <mtd@infradead.org>; "Nicolas Pitre" <nico@cam.org>; "David Woodhouse"
<dwmw2@infradead.org>
Sent: den 19 april 2001 18:44
Subject: Re: JFFS2 as root FS


> > Now I am having some other problems :-(
> > First it takes about 1 min 30 sec to mount my root FS. Is that expected?
I
> > was hoping for a much shorter
> > mount time, 10-20 sec
> > The root partition is 15 MB and df reports:
> >
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/mtdblock1           15104      6580      8524  44% /mnt/mtdblock1
>
> Just for reference, my AMD SC520 -100MHz (a 100MHz 486+) with a 8MB, 57%
full
> JFFS2 f/s takes ~19 seconds to mount.
> The flash is connected on a 32bit bus. Even if it takes 700us (for max
wait
> states on my system) per quad word read (32bits), the entire flash can be
> read in 1.46 seconds.
>
> Even if your flash is connected x8 wide, your flash read times should not
be
> more than 10-12seconds.
>
> Obviously, as my flash read time is only ~2 seconds of my 19s fs mount
time,
> the processor speed plays quite a significant role in the mount process.
>
> To test this theory, I upped the speed to 133MHz and then it took
~15seconds
> to mount.
> The increase in clock speed was 33%, the mount was (19-15)/15 = 26%
faster.
> However, if I remove the "constant" portion of the two mounts- the flash
read
> which is not any faster, then the increase in
> mount speed  = ((19-1.46) - (15-1.46))/ (15 - 1.46) = 29.5% faster, almost
> linear with the increase with clock speed!
> (This also tells me that the code is executing primarily out of cache).
>
> If you say, that your system takes ~90seconds to mount. Let's say that
your
> flash read time is ~10 seconds (for 16MB), then if all else is
> ok, your processor should be ~80/17.5 = 4.5 times slower than mine. This
> assumes equal amount of processing. But your processor is doing about
> (6580/4636 = 140%) more
> processing than mine. Assuming linear overhead, then the new factor is
~57/18
> = 3.1X slower. (your flash usage is 6580 blocks, mine is 4636 blocks).
>
> Now you say that you are using a MPC869T. I did not find a 869T on the
web. I
> presume that you meant 860T. At what MHz?
>
> The 860T is claimed to have a performance of ~66 Dhrystone MIPS at 50MHz.
I
> downloaded Dhrystone 2.1 and that give me 51 mips at 100Mhz (and 67.7at
> 133MHz).
>
> However, my 486 has a 16KB combined cache and a 66MHz SDRAM bus. The FLASH
is
> not cached, so the entire cache can be used for the instruction execution.
> The 860T has only 4KB of instruction cache. Under some circumstances (when
> the code fits in the cache in my processor and not in yours), the SC520
will
> behave like a 100MHz machine while the PPC will be limited to the bus
clock
> speed. What is you bus clock speed (and your core clock speed).
>
> If your BUS clock is ~25-33 MHz, it's not unbelievable that your processor
> runs ~2-3X slower, specially if your processor core is running at <50MHz.
> Also remember that execution from cache is significantly faster than
> execution from EDO DRAM on the bus.
>
> Something to think about. Of course it could be something completely
> different, like a bug in David's code ;)
>
> Vipin
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org