MTD, generic physmap memory, MTD_BLOCK

[Shane Nay]

> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cramfs-linear-addressing.patch
Type: text/english
Size: 2826 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20001216/baf6b5ef/attachment.bin