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.
next prev parent 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