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

[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

[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 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

[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