All of lore.kernel.org
 help / color / mirror / Atom feed
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));

  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.