linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: Grant Likely <glikely@gmail.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Fwd: Memory Size Requirement to Run Linux on Embedded Environment
Date: Sat, 12 Feb 2005 19:21:00 +0100	[thread overview]
Message-ID: <20050212182105.A5967C1430@atlas.denx.de> (raw)
In-Reply-To: Your message of "Sat, 12 Feb 2005 03:17:49 MST." <528646bc05021202175e967842@mail.gmail.com>

In message <528646bc05021202175e967842@mail.gmail.com> you wrote:
> 
> > There will be parameters of about 65KB are to be used and these parameters
> > can be changed in the field. This parameter block will have 2 copies to
> > avoid data corruption due to power fail. Hence to avoid the use of NAND
> > Flash I will be using 2 Parameter files to read and write(into flash) in a
> > linux environment during normal operation. Am I right??
> You could map the FLASH as a MTD device and write to two different
> sectors directly; then you can use a RAM disk instead of going with
> JFFS on your flash.  Use a separate RedBoot partition for each
> parameter sector.  (Note; using RedBoot partitions does not preclude
> using u-boot)

I can't parse that. Using a ramdisk (as root filesystem?) has nothing
to do with using a JFFS2 (not JFFS) filesystem for data storage.  And
actually  it's  usually  better to use a cramfs based root filesystem
plus tmpfs for transient data  storage.  Finally,  I  don't  see  any
reason  for  a "RedBoot" partition - any MTD partition will work just
fine.

> > In this mailing list I have read the typical size of U-BOOT will be around
> > 256KB as suggested by Wolfgang Denk.
> U-boot will live at the beginning of flash.  The u-boot environment
> will take up another sector.  Your parameter files will take up at

This is not correct. U-Boot is located where your memory map dictates
it, this can be the begining or the end or right  in  the  middle  of
your flash - depending on your hardware design.

And 256 kB is an upper size limit  including  the  environment  (with
enough spare even for redundand environment in most configuration). A
typical U-Boot image (including environment) is 150...190 kB.

> least one sector each.  The rest can be dedicated to the kernel and
> initrd images.  Set up a RedBoot partition for each.

What for?

> How much RAM does your app need?  32M is gobs for a simple system.  If
> it's ultra simple you may even be able to go down to 16 (don't quote

In 16 MB you can run a native GCC  which  definitely  is  far  beyond
being "ultra simple".

> me though).  Add more if your app is RAM hungry.  16M of flash should
> also be gobs.  (Assuming 1-2M for the kernel and the rest for the
> initrd image)

It is very difficult to make recommendations without more information
about system requirements. Yes, it is usually possible  to  implement
simple devices like a firewall / router / WLAN AP etc. in 4 or better
8 MB flash and 16 MB RAM. But you will also have to take into account
if  there  are  requirements  like  reliable  software  updates  with
guaranteed fall-back (which may  require  storage  capacity  for  the
fall-back version) or similar features.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"If you own a machine, you are in turn owned by it,  and  spend  your
time serving it..."    - Marion Zimmer Bradley, _The Forbidden Tower_

  reply	other threads:[~2005-02-12 18:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-12  8:19 Memory Size Requirement to Run Linux on Embedded Environment David, Albert
     [not found] ` <528646bc05021201091a106a96@mail.gmail.com>
2005-02-12 10:17   ` Fwd: " Grant Likely
2005-02-12 18:21     ` Wolfgang Denk [this message]
2005-02-12 18:57       ` Grant Likely
2005-02-12 22:15         ` Wolfgang Denk

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=20050212182105.A5967C1430@atlas.denx.de \
    --to=wd@denx.de \
    --cc=glikely@gmail.com \
    --cc=linuxppc-embedded@ozlabs.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).