From: Shane Nay <shane@agendacomputing.com>
To: Nicolas Pitre <nico@cam.org>, <mstumpf@pobox.com>
Cc: <mtd@infradead.org>
Subject: Re: MTD, generic physmap memory, MTD_BLOCK
Date: Sat, 16 Dec 2000 01:04:04 +0000 [thread overview]
Message-ID: <0012160104041B.11759@www.easysolutions.net> (raw)
In-Reply-To: <Pine.LNX.4.30.0012131359200.3311-100000@xanadu.gn.com>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
> > It's a trivial driver, and I'll write it / modify existing MTD code if
> > desired/needed, but it really seems important to have so that I can
> > execute-in-place from a cramfs partition in ROM (and also have this as my
> > root partition).
>
> It's impossible to execute_in_place from a cramfs partition since the
> in-place code is compressed.
Unless you expand the inode and mark things as uncompressed and aligned and
others as compressed. Attached is a patch to cramfs that allows it to access
the memory locations that are mapped in directly rather than buffering
compressed data..., which is a big fat waste and is a "first step" towards
XIPable cramfs. We're working on a cramfs that is XIPable, but only for
MIPs. The increased performance of a linearly addressed cramfs partition is
pretty decent..., although I haven't figured out a smart way to bootstrap
right into the cramfs stuff... (I'm thinking init.c or around there is where
I should be looking)
Thanks,
Shane.
Oh, BTW, I finished "a version" of mtd for XIP kernel writable for
cfi_cmdset_0001.c, and cfi_probe. I haven't figured out a smart way to deal
with having two versions of stuff yet..., because most of the code is the
same. You can find it on
ftp.agendacomputing.com/pub/kernel/*someversion*/patches . Once I figure out
a smart way to do this, and forward port to CVS I'll put it in the mainline
MTD code unless there are any nay-sayers.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cramfs-linear-addressing.patch --]
[-- Type: text/english; name="cramfs-linear-addressing.patch", Size: 2826 bytes --]
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));
next prev parent reply other threads:[~2000-12-16 12:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-13 16:48 MTD, generic physmap memory, MTD_BLOCK Michael Stumpf
2000-12-13 19:02 ` Nicolas Pitre
2000-12-16 1:04 ` Shane Nay [this message]
2000-12-17 22:24 ` David Woodhouse
2000-12-18 21:31 ` Shane Nay
2000-12-19 9:24 ` David Woodhouse
2000-12-18 22:35 ` Shane Nay
-- strict thread matches above, loose matches on Subject: below --
2000-12-19 13:32 Michael Stumpf
2000-12-19 2:51 ` 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=0012160104041B.11759@www.easysolutions.net \
--to=shane@agendacomputing.com \
--cc=mstumpf@pobox.com \
--cc=mtd@infradead.org \
--cc=nico@cam.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.