Linux patches for XIP on MPC8xx?

Linux patches for XIP on MPC8xx?

[Németh Márton]

Hi Wolfgang,

I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back
from 2003. Was there any follow up of your patch for kernel 2.4.4?

Regards,

	Márton Németh

Re: Linux patches for XIP on MPC8xx?

[Wolfgang Grandegger]

Németh Márton wrote:
> Hi Wolfgang,
> 
> I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back
> from 2003. Was there any follow up of your patch for kernel 2.4.4?

Not that I remember.

Wolfgang.

Re: Linux patches for XIP on MPC8xx?

[Wolfgang Denk]

Dear Márton Németh,

in message <4BA865D4.1090403@freemail.hu> you wrote:
> 
> I found your homepage at
> http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back
> from 2003. Was there any follow up of your patch for kernel 2.4.4?

There were very few tests done with later kernel versions, and in all
practical system configurations we tested we found that XIP did not
give real benefits. Usually execution from flash was slower than when
running from RAM, and even booting a (inevitably uncompressed) kernel
from flash is typically slower than loading a compressed image to RUM
and booting from there.

So except for some highly specialized applications (you may also call
these "exotic" configurations) XIP for the Linux kernel does not make
much sense to me.

I am aware that there are reports which come to completely different
conclusions - see for example http://www.elinux.org/Kernel_XIP ; but
then look carefully - the examples come from hardware with really
slow processors, which are probably not typical any more.

Actually this is the first thing you should check: the ratio of
processor speed versus flash memory bandwidth versus RAM bandwidth.
Today you can usually expect CPU clocks way over 400 MHz, and many
systems use DDR, while NOR flash speed has noch changed much.

Also check if it is possible to map the flash memory cached for your
system (which you definitly want when using XIP from flash); this may
prevent some flash access methods from working.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Doubt isn't the opposite of faith; it is an element of faith.
- Paul Tillich, German theologian and historian

Re: Linux patches for XIP on MPC8xx?

[Benjamin Herrenschmidt]

On Tue, 2010-03-23 at 20:44 +0100, Wolfgang Denk wrote:
> There were very few tests done with later kernel versions, and in all
> practical system configurations we tested we found that XIP did not
> give real benefits. Usually execution from flash was slower than when
> running from RAM, and even booting a (inevitably uncompressed) kernel
> from flash is typically slower than loading a compressed image to RUM
> and booting from there.
                                                                     ^

Missing an H here :-)

Cheers,
Ben.

Re: Linux patches for XIP on MPC8xx?

[Vitaly Wool]

Hi,

> There were very few tests done with later kernel versions, and in all
> practical system configurations we tested we found that XIP did not
> give real benefits. Usually execution from flash was slower than when
> running from RAM, and even booting a (inevitably uncompressed) kernel
> from flash is typically slower than loading a compressed image to RUM
> and booting from there.

at some point we were testing some hybrid approaches for XIP and that
gave some nice results.

First of all, the kernel should not necessarily be uncompressed.
Because .data and friend sections are copied to RAM anyway, you can
compress them.

Besides, we had the "weird" XIP kernel version with only run-once code
run as XIP (like .initdata), copying the rest of kernel to RAM in the
background while initializing things, and it was really fast and
didn't produce performance penalty on the further execution.

> So except for some highly specialized applications (you may also call
> these "exotic" configurations) XIP for the Linux kernel does not make
> much sense to me.

Well, I'd put it this way: plain XIP usage is obsolete in the most
cases, but the idea is still viable if you apply it right :)

Thanks,
   Vitaly