cramfs for root filesystem?
> > 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 at 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/
cramfs for root filesystem?
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. ___ 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/
cramfs for root filesystem?
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 at 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/
cramfs for root filesystem?
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 at 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 - 1.2 +++ mkcramfs.c 25 Jun 2002 20:09:45 - @@ -573,6 +573,7 @@ stack_entries++; } entry = entry->next; + fix_inode(inode); } /* ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
Dear Steve, in message <3D185263.DBFE0AE1 at 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 at 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/
cramfs for root filesystem?
I have tried to fix up the endian-swapping patch for
the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002
:pserver:anonymous at 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 - 1.1.1.1
+++ mkcramfs.c 25 Jun 2002 15:56:42 -
@@ -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 fileinsert a file image into the filesystem (requires
>= 2.4.0)\n"
" -n nameset 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&0xfc00));
+}
+
+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
cramfs for root filesystem?
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 at 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 at 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/
cramfs for root filesystem?
Steven Hein [mailto:ssh at 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/
cramfs for root filesystem?
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 at sgi.com) Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd. Phone: (715) 726-8410
Chippewa Falls, WI 54729 Fax: (715) 726-6715
-- next part --
diff -uNr linux/drivers/block/rd.c linux-2.4.4/drivers/block/rd.c
--- linux/drivers/block/rd.cFri 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
#include
#include
+#include
#include
#include
#include
@@ -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
*/
cramfs for root filesystem?
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/
cramfs for root filesystem?
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/
