kernel executing from flash

kernel executing from flash

[christof]

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-MD5: e709e4c63f7346156ea8e3dfbf17f7a9
X-Mailer: freenet-Web2Mail-Interface. See http://www.freenet.de/ for more.

Hello,

all Linux I know will be copied during startup from Harddisk, NFS or Flash to RAM and will be executed there.
Is there a possibility for smaller systems to run the
kernel directly from flash memory as other embedded os's do? Did somebody try this or is it totaly impossible?

Thanks in advance
Christof
--
free eMail at http://www.freenet.de/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: kernel executing from flash

[Markus Sundberg]

christof <xfr@freenet.de> writes:

> Hello,
>
> all Linux I know will be copied during startup from Harddisk, NFS or
> Flash to RAM and will be executed there.  Is there a possibility for
> smaller systems to run the kernel directly from flash memory as other
> embedded os's do? Did somebody try this or is it totaly impossible?

Well, I see no reason why it shouldn't be possible, but not without
modifying things.

You'd need to link the .data, .data.cacheline_aligned, .data.init
and .bss sections so they are located in RAM, and the former
three plus the exception vectors would have to be copied from flash
to their linked location.

The question is why?
RAM is usually cheaper than flash, and if you run the kernel in
RAM as usual you can have it compressed in flash, whereas if
you intend to run it directly from flash it must be uncompressed.

//Marcus
--
Signature under construction, please come back later.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: kernel executing from flash

[Wolfgang Denk]

In message <1314024740.953824470340.JavaMail.wwwrun@moe.freenet.de> you wrote:
>
> all Linux I know will be copied during startup from Harddisk, NFS or Flash to RAM and will be executed there.
> Is there a possibility for smaller systems to run the
> kernel directly from flash memory as other embedded os's do? Did somebody try this or is it totaly impossible?

It may be possible, but usually it does not make much sense - to  run
the  kernel directly from FLASH you must store an uncompressed kernel
image there, so you need  more  FLASH.  Given  the  price  difference
between  FLASH  and  DRAM  memory is often cheaper to uncompress into
RAM, and run from RAM.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: kernel executing from flash

[Rob Taylor]

> In message
> <1314024740.953824470340.JavaMail.wwwrun@moe.freenet.de> you wrote:
> >
> > all Linux I know will be copied during startup from Harddisk,
> NFS or Flash to RAM and will be executed there.
> > Is there a possibility for smaller systems to run the
> > kernel directly from flash memory as other embedded os's do?
> Did somebody try this or is it totaly impossible?
>
> It may be possible, but usually it does not make much sense - to  run
> the  kernel directly from FLASH you must store an uncompressed kernel
> image there, so you need  more  FLASH.  Given  the  price  difference
> between  FLASH  and  DRAM  memory is often cheaper to uncompress into
> RAM, and run from RAM.
>
not to mention that DRAM is usually faster than FLASH...

Rob

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: kernel executing from flash

[christof]

My primary aim is not to gain speed or to save money, although this is
important for my application too.
By fetching opcodes from flash I expect more stability in temperature- and
emc-critical environement, for data in "ROM" is saver than in RAM. Of corse,
there is always run-time critical data in RAM (processor stack), but the
probability of "irrepairable" errors should decrease by runnig from flash.

Thanks for Your quick answers
Christof


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: kernel executing from flash

[Wolfgang Denk]

In message <38E089AD.F415DCB7@freenet.de> you wrote:
>
> My primary aim is not to gain speed or to save money, although this is
> important for my application too.
> By fetching opcodes from flash I expect more stability in temperature- and
> emc-critical environement, for data in "ROM" is saver than in RAM. Of corse,
> there is always run-time critical data in RAM (processor stack), but the
> probability of "irrepairable" errors should decrease by runnig from flash.

A crash is a crash is a crash...

If you have memory errors, your system is bound to  crash  sooner  or
later, no matter if it hits the program code, or the stack, or data.

What's the difference between a crash because of a bad opcode or  one
because of a division by zero because of faulty data?

Black magic...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Work 8 hours, sleep 8 hours; but not the same 8 hours.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: kernel executing from flash

[Rob Taylor]

> For our (non-linux) embedded systems, if we're going to run from
> flash, we store the executable in flash uncompressed.  Price is an
> issue which favors RAM, but speed issues no longer favor RAM - the new
> intel burst flash is faster than RAM in one of our systems.

isn't it only faster for burst reads tho? that sort of speed increase
doesn't really help when running code..

Rob


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: kernel executing from flash

[Graham Stoney]

> > For our (non-linux) embedded systems, if we're going to run from
> > flash, we store the executable in flash uncompressed.  Price is an
> > issue which favors RAM, but speed issues no longer favor RAM - the new
> > intel burst flash is faster than RAM in one of our systems.

Rob Taylor writes:
>
> isn't it only faster for burst reads tho? that sort of speed increase
> doesn't really help when running code..

I think you might be mistaken here. Code accesses tend to be very linear, and
since the Instruction cache loads entire lines at a time, burst accesses are a
big win for code.

Regards,
Graham

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/