All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Post <postster@gmail.com>
To: Nicolas Pitre <nico@cam.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: MTD and XIP
Date: Fri, 5 Nov 2004 22:59:20 -0800	[thread overview]
Message-ID: <9f920bdf04110522596551a0a4@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0411052041230.5250@xanadu.home>

On Fri, 5 Nov 2004 21:08:35 -0500 (EST), Nicolas Pitre <nico@cam.org> wrote:
> Just to let you all know that I committed to CVS my work on making MTD
> deal with flash used for XIP purpose.  At the moment it only supports
> Intel compatible flash on a SA11x0 or PXA2xx based system, but it should
> be easy to extend to other configurations as well.

Nicolas,
This is very cool.  I scanned through the code briefly, and will take
a look at it first chance I get next week (OK, it might be a little
later; I am pretty swamped).  I had hoped to get to doing this sort of
thing in the next few months (i.e. doing XIP support *right* and on a
*relevant* kernel), so I was glad to see your work.  It looks very
clean, but I haven't run a fine-tooth comb through it.
However, the automated post to the CVS list reported:
***** Error reading new file: [Errno 2] No such file or directory: 'xip.h'

Do you have a specific reason to always disable write suspend on XIP
kernels?  That's a pretty big latency hit, and I don't think we need
to disable it for XIP systems.
I saw your comment that "the XIP system config appears to have
problems using write suspend at the moment".  Any specifics?

I suppose one of these days I'll have to get around to doing empirical
measurements on the effect write suspend on busy systems has to write
throughput.  I seem to remember someone else, perhaps David, did that
a while back.

What kind of changes does this require to the map file?  This does
interrupt-pollihg (software-read-while-write, SW/RWW) all the time. 
(Right?)  I think we can add intelligence to the map file, and set a
bit for each hardware partition that has XIP code in it (e.g. kernel,
linear^XIP CRAMFS, ...), so, for instance, we don't constantly suspend
writes / erases to partitions that don't ever have XIP code in them
just because an interrupt happens in the system.  A la my old kludgy
version for 2.4.

More thoughts to come later...

> Also for those interested in making their kernel XIP on ARM, you can
> look at the following patches against Linux-2.6.9:
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2154/1
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2160/1

Once again, cool.  I suppose I should follow the ARM-Linux patch
repository a little closer, too... :)

Cheers,
Dan Post
(Yes, this is my new mail account.  Handy for mailing lists.)

  reply	other threads:[~2004-11-06  6:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-06  2:08 MTD and XIP Nicolas Pitre
2004-11-06  6:59 ` Dan Post [this message]
2004-11-06 16:47   ` Nicolas Pitre
2004-11-06 17:02     ` Nicolas Pitre

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=9f920bdf04110522596551a0a4@mail.gmail.com \
    --to=postster@gmail.com \
    --cc=linux-mtd@lists.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.