MTD and XIP

MTD and XIP

[Nicolas Pitre]

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.

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

Enjoy!


Nicolas

Re: MTD and XIP

[Dan Post]

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.)

Re: MTD and XIP

[Nicolas Pitre]

On Fri, 5 Nov 2004, Dan Post wrote:

> 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.  

Heh, I meant to do that work for a year or two, or more precisely since 
dwmw2 posted his first implementation.

> 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'

Dunno what that means -- the file does exist in the repository.

> 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?

It was causing me jffs2 corruption problems and I couldn't figure out 
why.  So after two days of bug chasing I gave up and disabled write 
suspend, blaming the hardware.  I measured the IRQ latency hit to be in 
the 400 usec range in that case.

If you want to have a look please be my guest. To reproduce the problem, 
simply comment out the clearing of the write suspend bit and do:

	eraseall /dev/mtd2
	mount -t jffs2 /dev/mtdblock2 /mnt
	cd /mnt
	tar -cvf test.tar /sbin
	tar -xvf test.tar

This was enough for jffs2 to complain about node totlen mismatch errors 
and occasional CRC errors.  When disabling write suspend all those 
problems went away.  And you don't need to have a previous erase suspend 
for the problem to occur -- in fact the generic code doesn't suspend a 
write on interleaved chips if there is a suspended erase already for 
code simplicity (it would require selective write resume depending on 
the suspended state bit but I didn't implement it yet).

> 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.

It should be inversely proportional to the number of running tasks in 
the system since writes only happen in the writing task's time slice.  
The amount of Peripheral interrupts will also bring the write throughput 
down as well of course.

> What kind of changes does this require to the map file? 

None (for now).

> This does interrupt-pollihg (software-read-while-write, SW/RWW) all 
> the time. (Right?)

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.

Indeed.  That's in the TODO comment in xip_disable() already.


Nicolas

Re: MTD and XIP

[Nicolas Pitre]

On Sat, 6 Nov 2004, Nicolas Pitre wrote:

> On Fri, 5 Nov 2004, Dan Post wrote:
> 
> > 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?
> 
> It was causing me jffs2 corruption problems and I couldn't figure out 
> why.  So after two days of bug chasing I gave up and disabled write 
> suspend, blaming the hardware.  I measured the IRQ latency hit to be in 
> the 400 usec range in that case.
> 
> If you want to have a look please be my guest. To reproduce the problem, 
> simply comment out the clearing of the write suspend bit and do:
> 
> 	eraseall /dev/mtd2
> 	mount -t jffs2 /dev/mtdblock2 /mnt
> 	cd /mnt
> 	tar -cvf test.tar /sbin
> 	tar -xvf test.tar
> 
> This was enough for jffs2 to complain about node totlen mismatch errors 
> and occasional CRC errors.

Oh and BTW you don't need to have your kernel actually XIP to test this.
A standard kernel but with CONFIG_MTD_XIP enabled will show the problem 
as well, and it makes the loading of new test kernels quicker (unless 
you do everything modular).


Nicolas