From: "Jörn Engel" <joern@lazybastard.org>
To: Christoph Hellwig <hch@infradead.org>,
Jared Hulbert <jaredeh@gmail.com>,
carsteno@de.ibm.com, Nick Piggin <nickpiggin@yahoo.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
richard.griffiths@windriver.com,
Richard Griffiths <res07ml0@verizon.net>,
Linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
Date: Fri, 8 Jun 2007 15:10:09 +0200 [thread overview]
Message-ID: <20070608131009.GA20718@lazybastard.org> (raw)
In-Reply-To: <20070607211519.GA22348@infradead.org>
On Thu, 7 June 2007 22:15:19 +0100, Christoph Hellwig wrote:
>
> With the filemap_xip.c helpers adding xip support to any filesystem
> is pretty trivial for the highlevel filesystem operations. The only
> interesting bit is the lowlevel code (the get_xip_page method and
> the others Carsten mentioned), but we need to do these lowlevel
> code in a generic and proper way anyway.
>
> I'll try to hack up an xip prototype for jffs2 next week.
I'd absolutely love to see this code! However, it may be a little
harder than you think.
XIP is basically limited to NOR flash. And the NOR interface is to
simply map all flash to some physical memory area and interpret
reads/writes to/from this area in a special way. Internally the flash
chip is implementing a state machine that is controlled by writes and
defines the data read.
Easiest case: read_array state. In this state, every address will
return the flash content associated to that address on read. Pretty
much any write will cause a transition to a different state, though.
Any state other than read_array will return flash registers on any read.
In other words, writing to flash prohibits XIP, at least temporarily. A
read-write xip flash filesystem needs to tear down any xip mapping
before writing and have the flash chip return to read_array mode before
setting up a new mapping.
If the underlying device consists of several chips or of chips that
implement seperate state machines for different areas of the chip (some
Intel chips), only mappings belonging to the chip/area currently being
written are affected. That should make quite a nice optimizations,
although it can be ignored for a first shot.
Jörn
--
Joern's library part 12:
http://physics.nist.gov/cuu/Units/binary.html
next prev parent reply other threads:[~2007-06-08 14:14 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 22:09 Richard Griffiths
2007-05-22 22:49 ` Andrew Morton
2007-05-22 22:58 ` Richard Griffiths (wrs)
2007-05-23 7:51 ` Carsten Otte
2007-05-23 15:25 ` Richard Griffiths (wrs)
2007-05-24 6:46 ` Carsten Otte
2007-05-23 17:21 ` Jared Hulbert
2007-05-24 6:57 ` Carsten Otte
2007-05-29 5:10 ` Nick Piggin
2007-06-02 0:48 ` Jared Hulbert
2007-06-02 8:42 ` Nick Piggin
2007-06-04 13:32 ` Carsten Otte
2007-06-06 11:13 ` Jared Hulbert
2007-06-06 11:33 ` Christoph Hellwig
2007-06-06 15:17 ` Richard Griffiths
2007-06-06 15:50 ` Christoph Hellwig
2007-06-06 16:09 ` Jared Hulbert
2007-06-06 16:07 ` Jared Hulbert
2007-06-06 16:16 ` Christoph Hellwig
2007-06-06 18:26 ` Jared Hulbert
2007-06-07 19:37 ` Christoph Hellwig
2007-06-07 19:40 ` Christoph Hellwig
2007-06-07 20:27 ` Jared Hulbert
2007-06-08 7:39 ` Carsten Otte
2007-06-07 21:11 ` Jared Hulbert
2007-06-07 21:15 ` Christoph Hellwig
2007-06-07 22:59 ` Jared Hulbert
2007-06-08 13:19 ` Jörn Engel
2007-06-08 13:10 ` Jörn Engel [this message]
2007-06-06 16:15 ` Carsten Otte
2007-06-06 16:23 ` Christoph Hellwig
2007-06-06 18:40 ` Jared Hulbert
2007-06-06 22:59 ` Matt Mackall
2007-06-07 17:07 ` Carsten Otte
2007-06-07 19:38 ` Christoph Hellwig
2007-06-07 20:34 ` Jared Hulbert
2007-06-08 7:28 ` Christoph Hellwig
2007-06-08 16:02 ` Jared Hulbert
2007-06-08 7:17 ` Carsten Otte
2007-06-08 7:26 ` Christoph Hellwig
2007-06-08 7:50 ` Carsten Otte
2007-06-08 7:57 ` Christoph Hellwig
2007-06-08 7:59 ` Carsten Otte
2007-06-08 8:04 ` Christoph Hellwig
2007-06-08 16:05 ` Jared Hulbert
2007-06-08 16:09 ` Christoph Hellwig
2007-06-08 16:11 ` Jared Hulbert
2007-06-08 16:15 ` Christoph Hellwig
2007-06-08 17:51 ` Jörn Engel
2007-06-08 19:04 ` Carsten Otte
2007-06-08 19:06 ` Carsten Otte
2007-06-08 19:36 ` Jörn Engel
2007-06-09 7:55 ` Carsten Otte
2007-06-09 10:37 ` Jörn Engel
2007-06-08 23:02 ` Jared Hulbert
2007-06-07 21:19 ` Jared Hulbert
2007-06-06 12:05 ` Carsten Otte
2007-06-06 19:01 ` Jared Hulbert
2007-06-07 1:00 ` Justin Treon
2007-06-13 0:11 ` Jared Hulbert
2007-06-14 13:57 ` Carsten Otte
2007-06-14 16:53 ` Jared Hulbert
2007-06-15 9:22 ` Carsten Otte
2007-06-15 11:49 ` Heiko Carstens
2007-06-15 17:30 ` Jared Hulbert
2007-06-18 7:38 ` Carsten Otte
2007-06-15 13:53 ` Carsten Otte
2007-06-15 21:46 ` Jared Hulbert
2007-05-23 8:21 ` Alistair John Strachan
2007-05-24 20:22 ` Jared Hulbert
2007-05-24 20:52 ` Richard Griffiths
2007-05-24 21:21 ` Jared Hulbert
[not found] <337240.79058.qm@web59309.mail.re1.yahoo.com>
2007-06-09 8:09 ` Carsten Otte
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=20070608131009.GA20718@lazybastard.org \
--to=joern@lazybastard.org \
--cc=Linux-kernel@vger.kernel.org \
--cc=akpm@linux-foundation.org \
--cc=carsteno@de.ibm.com \
--cc=hch@infradead.org \
--cc=jaredeh@gmail.com \
--cc=nickpiggin@yahoo.com.au \
--cc=res07ml0@verizon.net \
--cc=richard.griffiths@windriver.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
all inboxes | Powered by JetHome®