From: Shane Nay <shane@agendacomputing.com>
To: Tim Riker <Tim@Rikers.org>, shane@agendacomputing.com
Cc: Daniel Quinlan <quinlan@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: cramfs filesystem patch
Date: Thu, 14 Dec 2000 20:14:01 +0000 [thread overview]
Message-ID: <0012142014013V.01011@www.easysolutions.net> (raw)
In-Reply-To: <200012080511.VAA02305@sodium.transmeta.com> <0012090153240K.23219@www.easysolutions.net> <3A31D3BC.46FBFBEB@Rikers.org>
In-Reply-To: <3A31D3BC.46FBFBEB@Rikers.org>
On Saturday 09 December 2000 06:39, Tim Riker wrote:
> I'd like to see these patches as well. They may be useful on the iPAQ
> (and similar hardware like my Yopy here... ;-)
>
> I wish some hardware vendor out there would build an x86 box that used
> memory addressable flash from 0 up and RAM up higher. A simple Linux
> kernel boot loader could then replace the BIOS. Flash would be less
> expensive than 8086 lower memory windowed flash hacks.
>
> Has any work been done on e2compr in 2.4 yet?
>
Patch inserted. It's not ready for kernel inclusion or anything..., there are some
remaining issues to fix that I haven't figured out good ways to handle yet.
For instance, we still use a /dev/rom to bootstrap the kernel as to which
file system module to pull up. Then all the read/writes completely by pass
/dev/rom. Silly, I know, but I haven't figured out a smart way to deal with
this particular problem.
Sorry for the late reply..., your message got lost in a sea of mail. You might
find some other interesting stuff on the ftp.agendacomputing.com ftp site.
XIP MTD flash read/write, which I haven't forward ported to MTDs CVS yet.
(Working on it) But that would allow if you guys can get XIP kernel working
in ARM like we have in MIPS to read and write to flash. Other randomn stuff,
and things get added with a slightly normal frequency. One benefit with this
patch is copying, the other is dumping that 32k buffer, and giving it back to
pageable memory.
Thanks,
Shane.
diff -urN linux.orig/fs/Config.in linux/fs/Config.in
--- linux.orig/fs/Config.in Fri Oct 27 04:23:18 2000
+++ linux/fs/Config.in Fri Oct 27 03:57:52 2000
@@ -29,6 +29,10 @@
int 'JFFS debugging verbosity (0 = quiet, 3 = noisy)' CONFIG_JFFS_FS_VERBOSE 0
fi
tristate 'Compressed ROM file system support' CONFIG_CRAMFS
+dep_mbool 'Linear addressing for CRAMFS' CONFIG_CRAMFS_LINEAR_ADDRESSING $CONFIG_CRAMFS
+if [ "$CONFIG_CRAMFS_LINEAR_ADDRESSING" != "n" ] ; then
+ hex 'Starting address for CRAMFS filesystem' CONFIG_CRAMFS_LA_ADDRESS bf200008
+fi
tristate 'Simple RAM-based file system support' CONFIG_RAMFS
tristate 'ISO 9660 CDROM file system support' CONFIG_ISO9660_FS
diff -urN linux.orig/fs/cramfs/inode.c linux/fs/cramfs/inode.c
--- linux.orig/fs/cramfs/inode.c Fri Oct 27 04:22:36 2000
+++ linux/fs/cramfs/inode.c Fri Oct 27 04:30:18 2000
@@ -11,6 +11,20 @@
* The actual compression is based on zlib, see the other files.
*/
+/* Linear Addressing code
+ *
+ * Copyright (C) 2000 Shane Nay.
+ *
+ * Allows you to have a linearly addressed cramfs filesystem.
+ * Saves the need for buffer, and the munging of the buffer.
+ * Savings a bit over 32k with default PAGE_SIZE, BUFFER_SIZE
+ * etc. Usefull on embedded platform with ROM :-).
+ *
+ * Downsides- Currently linear addressed cramfs partitions
+ * don't co-exist with block cramfs partitions.
+ *
+ */
+
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/pagemap.h>
@@ -68,6 +82,23 @@
return inode;
}
+#if defined(CONFIG_CRAMFS_CRAMFS_LINEAR_ADDRESSING) && defined (CONFIG_CRAMFS_LA_ADDRESS)
+
+/*
+ * Returns a pointer to the linearly addressed filesystem.
+ * Simple byte size pointer addition.
+ */
+static unsigned char* romdisk_top=(unsigned char*) CONFIG_CRAMFS_LA_ADDRESS;
+
+static void *cramfs_read(struct super_block *sb, unsigned int offset, unsigned int len)
+{
+ if (!len)
+ return NULL;
+ return romdisk_top + offset;
+}
+
+#else /* !CONFIG_CRAMFS_LINEAR_ADDRESSING aka Regular block mode */
+
/*
* We have our own block cache: don't fill up the buffer cache
* with the rom-image, because the way the filesystem is set
@@ -149,6 +180,8 @@
}
return read_buffers[buffer] + offset;
}
+
+#endif
static struct super_block * cramfs_read_super(struct super_block *sb, void *data, int silent)
@@ -161,10 +194,11 @@
set_blocksize(sb->s_dev, PAGE_CACHE_SIZE);
sb->s_blocksize = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+#if !( defined(CONFIG_CRAMFS_CRAMFS_LINEAR_ADDRESSING) && defined (CONFIG_CRAMFS_LA_ADDRESS) )
/* Invalidate the read buffers on mount: think disk change.. */
for (i = 0; i < READ_BUFFERS; i++)
buffer_blocknr[i] = -1;
+#endif
/* Read the first block and get the superblock from it */
memcpy(&super, cramfs_read(sb, 0, sizeof(super)), sizeof(super));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-15 7:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-08 5:11 cramfs filesystem patch Daniel Quinlan
2000-12-09 1:53 ` Shane Nay
2000-12-09 6:39 ` Tim Riker
2000-12-14 20:14 ` Shane Nay [this message]
[not found] <200012132204.OAA20616@magnesium.transmeta.com>
2000-12-13 12:22 ` Shane Nay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0012142014013V.01011@www.easysolutions.net \
--to=shane@agendacomputing.com \
--cc=Tim@Rikers.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quinlan@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox