linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Conserving memory for an embedded application
Date: Wed, 25 Sep 2002 16:25:42 +1000	[thread overview]
Message-ID: <3D9156E6.1030703@snapgear.com> (raw)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 25 Sep 2002 14:53, Michael D. Crawford wrote:
>> One question I have is whether it is possible to burn an uncompressed image
>> of the kernel into flash, and then boot the kernel in-place, so that it is
>> not copied to RAM when it runs.  Of course the kernel would need RAM for
>> its data structures and user programs, but it would seem to me I should be
>> able to run the kernel without making a RAM copy.
> The uclinux guys have eXecute In Place  - google search for uclinux and XIP 
> will produce a stack of hits - here's one:
> http://www.snapgear.com/tb20010618.html

Yep, we have this for uClinux. Currently we are only doing
this on MMU-less processors though, I haven't heard of anyone
doing kernel (or apps) XIP from flash on VM processors.

Kernel running direct from flash is reasonably easy to do
in uClinux, and pretty much all supported architectures can do it.
(The supported archiectures includes embedded Motorola m68k
(68306, 68328, 68332, 68360), Motorola ColdFire (5206, 5206e,
5249, 5272, 5307, 5407), MMUless ARM cores (Atmel/AT91,
NetSilicon/NET+ARM, Samsung/4510, Conexant/P52, etc),
SPARC LEON, NEC v850, OPENcores OR1000, NIOS core, i960,
and in the works SH2, and MIPS 4k.

We can do apps too, although on most architecture with no
VM this requires some compiler support for PIC code (either
using a GOT or only relative addressing). Currently this
is only done for the m68k, ColdFire and ARM platforms. This
would not be a problem for VM processors.

Most uClinux platforms only have flash, so this setup is
used extensively. And most people use read-only root filesystems
on flash to make them as small as possible. Someting like
the ROMfs type or CRAMfs are good options here.

I know others have mentioned performance here. But for most
people in this space it is the unit $ that is most important.
For simple uClinux systems using a 2.0.39 kernel you can run
in 2MiB of RAM if you don't want many apps (and you have
configured your kernel appropriaetely). That would be with 1MiB
of flash for kernel and small filesystem. Although you can trade
off RAM and flash here to get your best mix. I build demo
uClinux systems for the older Motorola ColdFire eval boards that
have 1MiB of RAM. And in that I run a 2.0.39 kernel and a shell,
with about 100k left over :-)  [And that is all in RAM, kernel +
filesystem + apps]

Many of the modern embedded 32bit CPU's have cache, and the slower
flash access speeds are well hidden anyway. Usually only a small
performance penalty. I have a demo board that I can configure
for either 32 or 16 bit memory, and the difference on most
benchmarks with that is about 10%.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com


             reply	other threads:[~2002-09-25  6:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-25  6:25 Greg Ungerer [this message]
2002-09-30  0:38 ` Conserving memory for an embedded application Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2002-09-25  4:53 Michael D. Crawford
2002-09-24 21:59 ` Brad Hards
2002-09-25  0:52 ` Ralf Baechle
2002-09-25  5:18 ` Robert Schwebel

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=3D9156E6.1030703@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).