cramfs for root filesystem?

cramfs for root filesystem?

[Stephen Cameron]

I noticed that here,

http://penguinppc.org/embedded/howto/root-filesystem.html

it says:

> It turns out that cramfs is not supported for a root fs or initrd.
> Basically, the kernel checks a hardcoded list of supported
> filesystems and if the MAGIC number doesn't match it bails.

Then, a couple lines later it says this, which clearly implies
a read-only cramfs root fs is possible::

> ramfs from the 2.4 kernel is a simple filesystem ideal for use in a
> ramdisk. It can be used in combination with a cramfs read-only root
> filesystem, to mount writable filesystems on /tmp and /var, which
> typically need to be writable. This combination is ideal for
> systems which don't require persistent storage.

So, I figured I'd try cramfs as a root fs and see if I'm lucky
and the first statement is just a mistake, and I get:

	RAMDISK: Compressed image found at block 0                                      Freeing initrd memory: 1270k freed                                              cramfs: wrong magic                                                             Kernel panic: VFS: Unable to mount root fs on 01:00                              <0>Rebooting in 180 seconds..

Well, it appears maybe the first statement is correct.

Then again, the message seems to be coming from the cramfs
part of the system...

So when I made my cramfs, I used mkcramfs which I got today (jun 24 2002)
from sourceforge.  I noticed older versions had some notes about endianness.
This version seems to say that little-endian is the proper format for the
filesystem data, and this is what kind of cramfs it makes and the kernel
on a big endian machine like mine needs to do the necessary byte swapping
to handle it.  Also, I created the cramfs on an intel box (little endian)
so in any case the fs is little endian.

Does the linuxppc_2_4_devel kernel from bitkeeper
handle little-endian cramfs filesystems?  Or is there
a patch for this?  Or a patch to mkcramfs to make it
create a big-endian cramfs (despite threads I read saying
this is the wrong way to proceed.)

Or am I on the wrong track completely in trying to use
cramfs for a root filesystem?

Thanks,

-- steve


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[David Blythe]

It looks like you still have an initrd.  Don't try running cramfs as an
initrd. I don't know if anything has changed in later versions of 2.4
but earlier ones used a 1k blocks size for the ramdisk and even if you
tried changing the rd blocksize to 4k to match cramfs it still didn't
work properly ...

There were patches floating around for building a big-endian cramfs,
rather than fixing the cramfs implemention to convert to little endian.
    I don't know if newer versions of cramfs support explicit little
endian rather than native endian.  I can send you a version of mkcramfs
with the swap endian flag if you want.

I'm in the process of getting ramfs to work with cramfs on my system as
we speak.
	david

Stephen Cameron wrote:
> I noticed that here,
>
> http://penguinppc.org/embedded/howto/root-filesystem.html
>
> it says:
>
>
>>It turns out that cramfs is not supported for a root fs or initrd.
>>Basically, the kernel checks a hardcoded list of supported
>>filesystems and if the MAGIC number doesn't match it bails.
>>
>
> Then, a couple lines later it says this, which clearly implies
> a read-only cramfs root fs is possible::
>
>
>>ramfs from the 2.4 kernel is a simple filesystem ideal for use in a
>>ramdisk. It can be used in combination with a cramfs read-only root
>>filesystem, to mount writable filesystems on /tmp and /var, which
>>typically need to be writable. This combination is ideal for
>>systems which don't require persistent storage.
>>
>
> So, I figured I'd try cramfs as a root fs and see if I'm lucky
> and the first statement is just a mistake, and I get:
>
> 	RAMDISK: Compressed image found at block 0                                      Freeing initrd memory: 1270k freed                                              cramfs: wrong magic                                                             Kernel panic: VFS: Unable to mount root fs on 01:00                              <0>Rebooting in 180 seconds..
>
> Well, it appears maybe the first statement is correct.
>
> Then again, the message seems to be coming from the cramfs
> part of the system...
>
> So when I made my cramfs, I used mkcramfs which I got today (jun 24 2002)
> from sourceforge.  I noticed older versions had some notes about endianness.
> This version seems to say that little-endian is the proper format for the
> filesystem data, and this is what kind of cramfs it makes and the kernel
> on a big endian machine like mine needs to do the necessary byte swapping
> to handle it.  Also, I created the cramfs on an intel box (little endian)
> so in any case the fs is little endian.
>
> Does the linuxppc_2_4_devel kernel from bitkeeper
> handle little-endian cramfs filesystems?  Or is there
> a patch for this?  Or a patch to mkcramfs to make it
> create a big-endian cramfs (despite threads I read saying
> this is the wrong way to proceed.)
>
> Or am I on the wrong track completely in trying to use
> cramfs for a root filesystem?
>
> Thanks,
>
> -- steve
>
>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[Steven Hein]

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

Hi Stephen,

I have actually been using a cramfs initrd reliably for about 2
years.  You do need a kernel patch to add cramfs to the list of
filesystems to check for in the initrd, also my patch forces the
blocksize of the initrd to 4K if it finds that it contains cramfs.
(I unfortunately don't have a publicly accessible web page to
stick this patch, so I'll attach it at the end of this email).

I have also previously posted a patch to mkcramfs to swap
endianness on a cramfs filesystem   (this is also what I do,
create a PPC big endian cramfs using a little endian Intel PC).
I have posted this a couple of times, here's a link to the
most recent:

    http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html

These two patches should get you going with a cramfs initrd.
Good luck!

Steve



David Blythe wrote:
>
> It looks like you still have an initrd.  Don't try running cramfs as an
> initrd. I don't know if anything has changed in later versions of 2.4
> but earlier ones used a 1k blocks size for the ramdisk and even if you
> tried changing the rd blocksize to 4k to match cramfs it still didn't
> work properly ...
>
> There were patches floating around for building a big-endian cramfs,
> rather than fixing the cramfs implemention to convert to little endian.
>     I don't know if newer versions of cramfs support explicit little
> endian rather than native endian.  I can send you a version of mkcramfs
> with the swap endian flag if you want.
>
> I'm in the process of getting ramfs to work with cramfs on my system as
> we speak.
>         david
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

diff -uNr linux/drivers/block/rd.c linux-2.4.4/drivers/block/rd.c
--- linux/drivers/block/rd.c	Fri Feb  9 13:30:22 2001
+++ linux-2.4.4/drivers/block/rd.c	Mon May  7 14:04:15 2001
@@ -47,6 +47,7 @@
 #include <linux/minix_fs.h>
 #include <linux/ext2_fs.h>
 #include <linux/romfs_fs.h>
+#include <linux/cramfs_fs.h>
 #include <linux/fs.h>
 #include <linux/kernel.h>
 #include <linux/hdreg.h>
@@ -469,10 +470,11 @@
 int __init
 identify_ramdisk_image(kdev_t device, struct file *fp, int start_block)
 {
-	const int size = 512;
+	const int size = 1024;
 	struct minix_super_block *minixsb;
 	struct ext2_super_block *ext2sb;
 	struct romfs_super_block *romfsb;
+	struct cramfs_super *cramfsb, *cramfsb2;
 	int nblocks = -1;
 	unsigned char *buf;

@@ -483,6 +485,8 @@
 	minixsb = (struct minix_super_block *) buf;
 	ext2sb = (struct ext2_super_block *) buf;
 	romfsb = (struct romfs_super_block *) buf;
+	cramfsb = (struct cramfs_super *) buf;
+	cramfsb2 = (struct cramfs_super *) (&buf[512]);
 	memset(buf, 0xe5, size);

 	/*
@@ -515,6 +519,41 @@
 		goto done;
 	}

+	/* cramfs also at block zero */
+	/* (superblock can also live at 512-byte offset in block zero) */
+	if ((cramfsb->magic == CRAMFS_MAGIC &&
+		memcmp(cramfsb->signature, CRAMFS_SIGNATURE,
+                                       sizeof(cramfsb->signature)) == 0) ||
+	    ((cramfsb = cramfsb2)  &&  cramfsb2->magic == CRAMFS_MAGIC &&
+		memcmp(cramfsb2->signature, CRAMFS_SIGNATURE,
+                                       sizeof(cramfsb2->signature)) == 0)) {
+
+		printk(KERN_NOTICE
+		       "RAMDISK: cramfs filesystem found at block %d\n",
+		       start_block);
+
+		/* cramfs probably has a different blocksize--adjust the
+		   ramdisk's block size to accomodate */
+		/* FIXME: should have a way to determine the cramfs
+		          blocksize (if it's going to be variable.....) */
+		if (rd_blocksize != PAGE_CACHE_SIZE) {
+			int i;
+
+			rd_blocksize = PAGE_CACHE_SIZE;
+			for (i = 0; i < NUM_RAMDISKS; i++) {
+				rd_hardsec[i] = rd_blocksize;
+				rd_blocksizes[i] = rd_blocksize;
+			}
+			printk(KERN_NOTICE
+				"RAMDISK: overriding ramdisk block size to %d for cramfs filesystem\n",
+				rd_blocksize);
+		}
+		/* Note: even if ramdisk blocksize is changed, nblocks is still
+                   calculated using 1k blocksize for the INITRD device */
+		nblocks = (cramfsb->size+BLOCK_SIZE-1)>>BLOCK_SIZE_BITS;
+		goto done;
+	}
+
 	/*
 	 * Read block 1 to test for minix and ext2 superblock
 	 */

Re: cramfs for root filesystem?

[Wolfgang Denk]

Dear Steve,

in message <3D185263.DBFE0AE1@sgi.com> you wrote:
>
> (I unfortunately don't have a publicly accessible web page to
> stick this patch, so I'll attach it at the end of this email).

If you like, we could stick it in our
ftp://ftp.denx.de/pub/ppc/contrib/
directory.
If you like, please send me the patch, plus a corresponding entry  to
our README file.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"In Christianity neither morality nor religion come into contact with
reality at any point."                          - Friedrich Nietzsche

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[pepe potamo]

good morning, i made a little patch of ide driver to
eject the card without do an cardctl eject. works
fine, and status error and driver not ready for
command message errors dissapear, irq is free
perfectly and all inode and buffers information is
removed.

Also, i made a patch for mtd with and interlaced of 4,
useful for the mbx860, and adaptable to other flash
memory interlaced system.

I modified ppcboot 1.1.4 and boot perfectly on a
mbx860 too.

bye.

\x18\x1a\x1a\x1a\x1a\x1a\x1a

_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos.
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: cramfs for root filesystem?

[Cameron, Steve]

Steven Hein [mailto:ssh@sgi.com] wrote:

> [...] You do need a kernel patch to add cramfs to the list of
> filesystems to check for in the initrd, also my patch forces the
> blocksize of the initrd to 4K if it finds that it contains cramfs. [...]

Hmm, this patch doesn't seem to apply to my fairly recent
linuxppc_2_4_devel tree.  identify_ramdisk_image() for instance
is in init/do_mounts.c, not drivers/block/rd.c, and there is a
#define BUILD_CRAMDISK in there I guess relating to cramfs, though
I'm not sure what it's doing.

> I have also previously posted a patch to mkcramfs to swap
> endianness on a cramfs filesystem   [...]
>     http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html

Hmm, this patch doesn't seem to apply to the mkcramfs I got from
sourceforge yesterday.

Thanks, just the same.

-- steve


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[Steven Hein]

Sorry...  I haven't been living in the development PPC world lately.
These patches should apply against the stock 2.4.18 kernel.
Anyone is welcome to adapt them to the PPC development stuff
and the sourceforge version of mkcramfs   :)

(I'm on a new project involving an ARM processor now, so I'm not
particularly current with the PPC stuff!)

Steve



"Cameron, Steve" wrote:
>
> Steven Hein [mailto:ssh@sgi.com] wrote:
>
> > [...] You do need a kernel patch to add cramfs to the list of
> > filesystems to check for in the initrd, also my patch forces the
> > blocksize of the initrd to 4K if it finds that it contains cramfs. [...]
>
> Hmm, this patch doesn't seem to apply to my fairly recent
> linuxppc_2_4_devel tree.  identify_ramdisk_image() for instance
> is in init/do_mounts.c, not drivers/block/rd.c, and there is a
> #define BUILD_CRAMDISK in there I guess relating to cramfs, though
> I'm not sure what it's doing.
>
> > I have also previously posted a patch to mkcramfs to swap
> > endianness on a cramfs filesystem   [...]
> >     http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html
>
> Hmm, this patch doesn't seem to apply to the mkcramfs I got from
> sourceforge yesterday.
>
> Thanks, just the same.
>
> -- steve
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[Stephen Cameron]

I have tried to fix up the endian-swapping patch for
the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002
:pserver:anonymous@cvs.cramfs.sourceforge.net:/cvsroot/cramfs

No guarantees, of course, use at your own risk.

Currently, I get as far as trying to start init with this
patch, (the same filesystem via NFS works fine.)  This
may be due to the fact that I haven't touched the kernel
code, (that is, I have not allowed for ramdisk to handle
4k block size, as I've been led to believe I must.)

Here's what I'm seeing when I try to use my rootfs
(not that it's necessarily relevant, but I don't
want to imply that I know my patch is perfect):

	RAMDISK: Compressed image found at block 0
	Freeing initrd memory: 1270k freed
	VFS: Mounted root (cramfs filesystem) readonly.
	Freeing unused kernel memory: 196k init
	Warning: unable to open an initial console.
	Kernel panic: No init found.  Try passing init= option to kernel.
	<0>Rebooting in 180 seconds..

-- steve

And here's the patch:

diff -u -r1.1.1.1 mkcramfs.c
--- mkcramfs.c	24 Jun 2002 19:22:19 -0000	1.1.1.1
+++ mkcramfs.c	25 Jun 2002 15:56:42 -0000
@@ -95,6 +95,7 @@
 static char *opt_name = NULL;

 static int warn_dev, warn_gid, warn_namelen, warn_skip, warn_size, warn_uid;
+static int swap_endian = 0;

 /* In-core version of inode / directory entry. */
 struct entry {
@@ -130,6 +131,7 @@
 		" -i file    insert a file image into the filesystem (requires >= 2.4.0)\n"
 		" -n name    set name of cramfs filesystem\n"
 		" -p         pad by %d bytes for boot code\n"
+		" -r         reverse endianness of filesystem\n"
 		" -s         sort directory entries (old option, ignored)\n"
 		" -v         be more verbose\n"
 		" -z         make explicit holes (requires >= 2.3.39)\n"
@@ -372,6 +374,58 @@
 	return totalsize;
 }

+#define wswap(x)	(((x)>>24) | (((x)>>8)&0xff00) | \
+			(((x)&0xff00)<<8) | (((x)&0xff)<<24))
+
+/* routines to swap endianness/bitfields in inode/superblock block data */
+static void fix_inode(struct cramfs_inode *inode)
+{
+	if (!swap_endian) return;
+	inode->mode = (inode->mode >> 8) | ((inode->mode&0xff)<<8);
+	inode->uid = (inode->uid >> 8) | ((inode->uid&0xff)<<8);
+	inode->size = (inode->size >> 16) | (inode->size&0xff00) |
+			((inode->size&0xff)<<16);
+	((u32*)inode)[2] = wswap(inode->offset | (inode->namelen<<26));
+}
+
+static void fix_offset(struct cramfs_inode *inode, u32 offset)
+{
+	u32 tmp;
+	if (!swap_endian) return;
+	tmp = wswap(((u32*)inode)[2]);
+	((u32*)inode)[2] = wswap((offset >> 2) | (tmp&0xfc000000));
+}
+
+static void fix_block_pointer(u32 *p)
+{
+	if (!swap_endian) return;
+	*p = wswap(*p);
+}
+
+static void fix_super(struct cramfs_super *super)
+{
+	u32 *p = (u32*)super;
+
+	if (!swap_endian) return;
+
+	/* fix superblock fields */
+	p[0] = wswap(p[0]); /* magic */
+	p[1] = wswap(p[1]); /* size */
+	p[2] = wswap(p[2]); /* flags */
+	p[3] = wswap(p[3]); /* future */
+
+	/* fix filesystem info fields */
+	p = (u32*)&super->fsid;
+	p[0] = wswap(p[0]); /* crc */
+	p[1] = wswap(p[1]); /* edition */
+	p[2] = wswap(p[2]); /* blocks */
+	p[3] = wswap(p[3]); /* files */
+
+	fix_inode(&super->root);
+}
+
+#undef wswap
+
 /* Returns sizeof(struct cramfs_super), which includes the root inode. */
 static unsigned int write_superblock(struct entry *root, char *base, int size)
 {
@@ -405,7 +459,9 @@
 	super->root.uid = CRAMFS_16(root->uid);
 	super->root.gid = root->gid;
 	super->root.size = CRAMFS_24(root->size);
+	fix_super(super);
 	CRAMFS_SET_OFFSET(&(super->root), offset >> 2);
+	fix_offset(&(super->root), offset);

 	return offset;
 }
@@ -421,6 +477,7 @@
 		die(MKFS_ERROR, 0, "filesystem too big");
 	}
 	CRAMFS_SET_OFFSET(inode, offset >> 2);
+	fix_offset(inode, offset);
 }

 /*
@@ -610,6 +667,7 @@
 		}

 		*(u32 *) (base + offset) = CRAMFS_32(curr);
+		fix_block_pointer((u32*)(base + offset));
 		offset += 4;
 	} while (size);

@@ -700,7 +758,7 @@
 		progname = argv[0];

 	/* command line options */
-	while ((c = getopt(argc, argv, "hEe:i:n:psvz")) != EOF) {
+	while ((c = getopt(argc, argv, "hEe:i:n:prsvz")) != EOF) {
 		switch (c) {
 		case 'h':
 			usage(MKFS_OK);
@@ -727,6 +785,10 @@
 		case 'p':
 			opt_pad = PAD_SIZE;
 			fslen_ub += PAD_SIZE;
+			break;
+		case 'r':
+			swap_endian = 1;
+			fprintf(stderr, "Swapping filesystem endianness.\n");
 			break;
 		case 's':
 			/* old option, ignored */

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: cramfs for root filesystem?

[David Blythe]

Stephen Cameron wrote:
> I have tried to fix up the endian-swapping patch for
> the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002
> :pserver:anonymous@cvs.cramfs.sourceforge.net:/cvsroot/cramfs
>
>


If you are going to take that version of mkcramfs, you could just as
well take the corresponding version of the cramfs fs implemention since
it hardwires conversion to *little endian* into the kernel
implementation, or if you really still want a big endian cramfs, just
usurp all of the endianness macros (e.g., CRAMFS_32(), CRAMFS_16(), etc)
that were added to the header.

	david


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: cramfs for root filesystem?

[Cameron, Steve]

I wrote:

> I have tried to fix up the endian-swapping patch for
> the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002
> :pserver:anonymous@cvs.cramfs.sourceforge.net:/cvsroot/cramfs

Well, I missed one thing, at least, so here is
an additional patch, below. There must be more to it
still as I haven't yet got it working.  (not sure
if problem is in mkcramfs or my kernel).

-- steve

diff -u -r1.2 mkcramfs.c
--- mkcramfs.c	25 Jun 2002 16:12:58 -0000	1.2
+++ mkcramfs.c	25 Jun 2002 20:09:45 -0000
@@ -573,6 +573,7 @@
 				stack_entries++;
 			}
 			entry = entry->next;
+			fix_inode(inode);
 		}

 		/*

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: cramfs for root filesystem?

[Cameron, Steve]

>
> Stephen Cameron wrote:
> > I have tried to fix up the endian-swapping patch for
> > the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002
> > :pserver:anonymous@cvs.cramfs.sourceforge.net:/cvsroot/cramfs

> If you are going to take that version of mkcramfs, you could just as
> well take the corresponding version of the cramfs fs
> implemention since
> it hardwires conversion to *little endian* into the kernel

Yes, this would be the preferable solution, and is what I looked
for first, but I didn't know it was done already. Where can I
get that?

Oh! Duh!  Now I see it!  (knocking self on head :-)

I hadn't noticed that I got it up when I did the
"cvs co ." to check out mkcramfs from sourceforge.
I wasn't expecting kernel parts in there.

I just tried it out, and it works great!  Thanks
for saving me some effort.

-- steve


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/