Memory Size Requirement to Run Linux on Embedded Environment

Memory Size Requirement to Run Linux on Embedded Environment

[David, Albert]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

Hi everyone!
I am new to linux and my current project is to port linux on our custom
hardware based on PPC405EP(AMCC).
Currently we are in a hardware design phase but I am finding it hard to
decide the Flash and SDRAM Memory size.
We are planning to us 2.6 Kernel, with minimum hardware interfaces.

Should we use Kernel 2.4 or 2.6?

Main components of my target device are as follows..

1)AMCC PPC405EP processor operating at 66.66Mhz External Oscillator(Hope we
can go for higher operating frequencies by configuring internal registers of
PPC).
2)Virtex-2 Pro FPGA - memory mapped to PPC405.
3)Ethernet Connectivity.
4)IrDA.
5)Two RS232 Serial Ports.
6) IIC Bus.


I assume the binary size of my application that will run on linux would be
around 2 to 3 MB. By considering these facts of my hardware, what would be
the size of kernel? And how many drivers I may require? What would be the
size of my root file system? 

Is it necessary to have a NAND Flash to handle the power failures? Or any
CFI compliant NOR Flash would do!

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

In this mailing list I have read the typical size of U-BOOT will be around
256KB as suggested by Wolfgang Denk.

A rough approximation of Flash and SDRAM size would help me a lot to proceed
with my hardware design. 

Pardon me If I am asking too basic questions, I know I have to do lot of
reading before I proceed. 
Your inputs are valuable to me!

Thanks in advance for your support,
BR,
Albert David.

- - - - - - - DISCLAIMER - - - - - - - - 
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this message and/or
attachments is strictly prohibited. The company accepts no liability for any
damage caused by any virus transmitted by this email. Furthermore, the
company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays. If you have
received this message in error, please contact the sender and delete the
message. Thank you.

[-- Attachment #2: Type: text/html, Size: 3931 bytes --]

Fwd: Memory Size Requirement to Run Linux on Embedded Environment

[Grant Likely]

Forgot to include list in reply; oops.

g.


---------- Forwarded message ----------
From: Grant Likely <glikely@gmail.com>
Date: Sat, 12 Feb 2005 02:09:13 -0700
Subject: Re: Memory Size Requirement to Run Linux on Embedded Environment
To: "David, Albert" <Albert.David@barco.com>


On Sat, 12 Feb 2005 09:19:19 +0100, David, Albert
<Albert.David@barco.com> wrote:
>
>
> Hi everyone!
> I am new to linux and my current project is to port linux on our custom
> hardware based on PPC405EP(AMCC).
> Currently we are in a hardware design phase but I am finding it hard to
> decide the Flash and SDRAM Memory size.
> We are planning to us 2.6 Kernel, with minimum hardware interfaces.
>
> Should we use Kernel 2.4 or 2.6?
Use 2.6 unless you have a ready to go 2.4 port for your board which
you do not need to modify.  This also assumes that you don't need any
of the new 2.6 features.
>
> I assume the binary size of my application that will run on linux would be
> around 2 to 3 MB. By considering these facts of my hardware, what would be
> the size of kernel? And how many drivers I may require? What would be the
> size of my root file system?
2 to 3 MB if all you put on it is your app, slightly larger otherwise.
 A very minimal system w/ busybox will easily fit into 1 or 2 MB.
>
> 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)
>
> 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
least one sector each.  The rest can be dedicated to the kernel and
initrd images.  Set up a RedBoot partition for each.
>
> A rough approximation of Flash and SDRAM size would help me a lot to proceed
> with my hardware design.
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
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)

Make sure you use uClibc and busybox if you want to keep your system small.

Cheers,
g.

Re: Fwd: Memory Size Requirement to Run Linux on Embedded Environment

[Wolfgang Denk]

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_

Re: Fwd: Memory Size Requirement to Run Linux on Embedded Environment

[Grant Likely]

On Sat, 12 Feb 2005 19:21:00 +0100, Wolfgang Denk <wd@denx.de> wrote:
> 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
True.

> 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.
Yes, your right; I mentioned RedBoot partitioning specifically because
that happens to be what I've used.  Any scheme will work.

> 
> > > 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.
I suggested the beginning of flash under the assumption that u-boot
would be the first code to execute.  Albert, if it is not then you
will need to have some other code at the boot location.

> 
> 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?
Simply suggestions that I've found useful myself; I'm certainly not
saying that that is the best or only way.
> 
> > 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".
I stand corrected.

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

Yes, my suggestions are based on assumptions.  Albert is still
responsible to do his own due diligence to make sure that makes the
right decisions.  Thanks for the clarifications.

Cheers,
g.

Re: Fwd: Memory Size Requirement to Run Linux on Embedded Environment

[Wolfgang Denk]

In message <528646bc05021210572aaeaa3f@mail.gmail.com> you wrote:
> 
> > 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.
> I suggested the beginning of flash under the assumption that u-boot
> would be the first code to execute.  Albert, if it is not then you
> will need to have some other code at the boot location.

That's what I intended topoint out: this is hardware dependent;  some
processiors  support  low-boot  (0x100)  and  high-boot (0xFFF00100),
others  have  a  fixed  reset  vector  (0xFFFFFFFC),  and  yet  other
architectures behave differently (like ARM startin at 0x0000).

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
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg