Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Baruch Chaikin <bchaikin@il.marvell.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question)
Date: Sun, 15 Jun 2003 17:47:31 +0200	[thread overview]
Message-ID: <3EEC9513.80905@galileo.co.il> (raw)
In-Reply-To: 20030610131519.47A8BC5FD7@atlas.denx.de

All,

To conclude, the recommendation here is to:
o	Compile with uClibC or dietlibc
o	Use busybox
o	Gain extra 0.5 MB space

Another question is the file system itself.  What is the recommendation 
here - JFFS, CRAMFS, anything else?...

Thanks for your answers!
-	Baruch.


Wolfgang Denk wrote:
> In message <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
> 
>>># ls -l lib | grep -v '^[ld]'
>>>total 2433
>>
>>I conclude ELDK consists of little more than the basic networking utilities,
> 
> 
> The ELDK (Embedded Linux Development Kit) consists of MUCH more (more
> than 400 MB if you install everything).
> 
> I was just talking about the  ramdisk  image.  You  are  right,  this
> contains busybox plus basic networking utilities. For this framework,
> the compressed image size is about 1.3 MB.
> 
> 
>>and the libc-related parts eat up most of the space. A more feature-rich
>>system probably can't afford to waste that much.
> 
> 
> The oriiginal poster mentioned that he has 2.5 MB available, so if he
> uses something like the framework I mentioned he  still  has  1.2  MB
> compressed size available. This is a _lot_.
> 
> 
> If memroy really gets tight, there are other  places  where  you  can
> save space, for example the O.P. wrote:
> 
> 
>>  0.5 MB is allocated for the firmware code
>>  1.0 MB for the compressed kernel image
>>  2.5 MB for the (compressed?) file system
> 
> 
> The reservation for both the firmware and for  the  kernel  image  is
> more  than generous; 256 kB + 768 kB should be sufficient, too. Which
> gives another 0.5 MB for application stuff.
> 
> 
> Please understand me right: I do not want  to  deny  that  uClibc  or
> dietlibc  are  fine  methods  to  optimize  the memory footprint of a
> system. But for a starter it is probably much easier to use  standard
> libraries as long as there is memory available.
> 
> For the current thread the keyword was "strip". 
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 


-- 
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the 
individual or entity named above. If the reader of this message is not 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If 
you have received this communication in error, please notify us 
immediately by telephone, or by e-mail and delete the message from your 
computer.

WARNING: multiple messages have this Message-ID (diff)
From: Baruch Chaikin <bchaikin@il.marvell.com>
Cc: linux-mips@linux-mips.org, Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: Re: Building a stand-alone FS on a very limited flash (newbie question)
Date: Sun, 15 Jun 2003 17:47:31 +0200	[thread overview]
Message-ID: <3EEC9513.80905@galileo.co.il> (raw)
Message-ID: <20030615154731.2Cj1rmw5VLLdvoRA9iQFvBJ3SINF4Rnjx1SnotrtOHg@z> (raw)
In-Reply-To: 20030610131519.47A8BC5FD7@atlas.denx.de

All,

To conclude, the recommendation here is to:
o	Compile with uClibC or dietlibc
o	Use busybox
o	Gain extra 0.5 MB space

Another question is the file system itself.  What is the recommendation 
here - JFFS, CRAMFS, anything else?...

Thanks for your answers!
-	Baruch.


Wolfgang Denk wrote:
> In message <20030610125623.GC30175@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
> 
>>># ls -l lib | grep -v '^[ld]'
>>>total 2433
>>
>>I conclude ELDK consists of little more than the basic networking utilities,
> 
> 
> The ELDK (Embedded Linux Development Kit) consists of MUCH more (more
> than 400 MB if you install everything).
> 
> I was just talking about the  ramdisk  image.  You  are  right,  this
> contains busybox plus basic networking utilities. For this framework,
> the compressed image size is about 1.3 MB.
> 
> 
>>and the libc-related parts eat up most of the space. A more feature-rich
>>system probably can't afford to waste that much.
> 
> 
> The oriiginal poster mentioned that he has 2.5 MB available, so if he
> uses something like the framework I mentioned he  still  has  1.2  MB
> compressed size available. This is a _lot_.
> 
> 
> If memroy really gets tight, there are other  places  where  you  can
> save space, for example the O.P. wrote:
> 
> 
>>  0.5 MB is allocated for the firmware code
>>  1.0 MB for the compressed kernel image
>>  2.5 MB for the (compressed?) file system
> 
> 
> The reservation for both the firmware and for  the  kernel  image  is
> more  than generous; 256 kB + 768 kB should be sufficient, too. Which
> gives another 0.5 MB for application stuff.
> 
> 
> Please understand me right: I do not want  to  deny  that  uClibc  or
> dietlibc  are  fine  methods  to  optimize  the memory footprint of a
> system. But for a starter it is probably much easier to use  standard
> libraries as long as there is memory available.
> 
> For the current thread the keyword was "strip". 
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 


-- 
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the 
individual or entity named above. If the reader of this message is not 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If 
you have received this communication in error, please notify us 
immediately by telephone, or by e-mail and delete the message from your 
computer.

  reply	other threads:[~2003-06-15 14:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06 16:55 state of 64 bit support David Kesselring
2003-06-09 15:28 ` Maciej W. Rozycki
2003-06-09 15:44   ` Daniel Jacobowitz
2003-06-09 17:37     ` Building a stand-alone FS on a very limited flash (newbie question) Baruch Chaikin
2003-06-09 16:56       ` Thiemo Seufer
2003-06-10 12:26         ` Johannes Stezenbach
2003-06-10 12:38         ` Wolfgang Denk
2003-06-10 12:56           ` Thiemo Seufer
2003-06-10 13:15             ` Wolfgang Denk
2003-06-15 15:47               ` Baruch Chaikin [this message]
2003-06-15 15:47                 ` Baruch Chaikin
2003-06-17 12:16                 ` Johannes Stezenbach
2003-06-09 17:37       ` Baruch Chaikin
2003-06-09 18:49       ` Jeff Baitis
2003-06-09 19:01         ` Jeff Baitis
  -- strict thread matches above, loose matches on Subject: below --
2003-06-10 10:13 Tor Arntsen

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=3EEC9513.80905@galileo.co.il \
    --to=bchaikin@il.marvell.com \
    --cc=linux-mips@linux-mips.org \
    --cc=rabeeh@galileo.co.il \
    /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