state of 64 bit support

state of 64 bit support

[David Kesselring]

I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
searching the net for info, and following this list for the last couple of
weeks. I have not been able to get some basic questions answered and I
hope that some of you can help me.
First what is the current status of mips 5k 64bit little-endian support
for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
but if you know of one I'd love the link. I have been unsuccessful getting
this built.
On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
64 bit mips? Has anyone gotten it to work?

Also linux. From my understanding, kernel 2.4.20 has the latest patches
for mips32 and mips64. Is that a valid codebase?
It seems that some info in the howto regarding building a compiler with
egcs on linux-mips.org is somewhat dated, is that true?

I really appreciate any guidance. I've been trying to follow the
instructions that are out there but I keep running into problems.
For example, as I try to build gcc 3.2 for mips64el, I can't come up with
a correct include directory. Does anyone have one?

Very, very appreciatively yours,

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587

Re: state of 64 bit support

[Maciej W. Rozycki]

On Fri, 6 Jun 2003, David Kesselring wrote:

> I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
> searching the net for info, and following this list for the last couple of
> weeks. I have not been able to get some basic questions answered and I
> hope that some of you can help me.

 With the above statement I assume you want to have a compiler suitable
for a kernel build only (which is easier to get running) and you do not
need to do 64-bit userland builds (which is tougher).  And that you want a
cross-compiler.

> First what is the current status of mips 5k 64bit little-endian support
> for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
> but if you know of one I'd love the link. I have been unsuccessful getting
> this built.

 There are a few gcc 2.95.x i386/Linux LE binary RPM packages available at
my site, but they have preliminary R4k workarounds applied which have
disadvantageous side effects for later processors.  Your best bet is to
get an RPM source package, disable R4k patches and rebuild. 

> On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
> 64 bit mips? Has anyone gotten it to work?

 If going for version 3.x, you probably want to get 3.3.  I can't say if
it supports MIPS64/Linux without patching -- probably yes.

> Also linux. From my understanding, kernel 2.4.20 has the latest patches
> for mips32 and mips64. Is that a valid codebase?

 Up till now most development was done based on 2.4.x, but Ralf has just
finished updating 2.5.x, so you can select the version that suits you
best.

> It seems that some info in the howto regarding building a compiler with
> egcs on linux-mips.org is somewhat dated, is that true?

 The rules on building a compiler haven't changed much if at all for a
long time.  You should be able to verify it with documentation coming with
gcc.

> I really appreciate any guidance. I've been trying to follow the
> instructions that are out there but I keep running into problems.
> For example, as I try to build gcc 3.2 for mips64el, I can't come up with
> a correct include directory. Does anyone have one?

 You need to get installed headers from a C library.  Glibc is the usual
choice, although there are alternatives.  I have a set of suitable headers
available at my site.  It's a bit dated as it's from glibc 2.2.5, but for
kernel builds it doesn't really matter.

 HTH,

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: state of 64 bit support

[Daniel Jacobowitz]

On Mon, Jun 09, 2003 at 05:28:18PM +0200, Maciej W. Rozycki wrote:
> On Fri, 6 Jun 2003, David Kesselring wrote:
> 
> > I've been trying to get a 64 bit compiler working for a 5kc/5kf core,
> > searching the net for info, and following this list for the last couple of
> > weeks. I have not been able to get some basic questions answered and I
> > hope that some of you can help me.
> 
>  With the above statement I assume you want to have a compiler suitable
> for a kernel build only (which is easier to get running) and you do not
> need to do 64-bit userland builds (which is tougher).  And that you want a
> cross-compiler.
> 
> > First what is the current status of mips 5k 64bit little-endian support
> > for gcc? Do I have to use 2.95/2.96? I don't think there is a linux binary
> > but if you know of one I'd love the link. I have been unsuccessful getting
> > this built.
> 
>  There are a few gcc 2.95.x i386/Linux LE binary RPM packages available at
> my site, but they have preliminary R4k workarounds applied which have
> disadvantageous side effects for later processors.  Your best bet is to
> get an RPM source package, disable R4k patches and rebuild. 
> 
> > On the web, there is a howto to build a mipsel gcc 3.2. Does 3.2 support
> > 64 bit mips? Has anyone gotten it to work?
> 
>  If going for version 3.x, you probably want to get 3.3.  I can't say if
> it supports MIPS64/Linux without patching -- probably yes.

More or less yes (kernel space).  Userspace went in to 3.4.

> 
> > Also linux. From my understanding, kernel 2.4.20 has the latest patches
> > for mips32 and mips64. Is that a valid codebase?
> 
>  Up till now most development was done based on 2.4.x, but Ralf has just
> finished updating 2.5.x, so you can select the version that suits you
> best.

... But you have to get it from the linux-mips.org CVS, not from
kernel.org!  Just clarifying.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Building a stand-alone FS on a very limited flash (newbie question)

[Baruch Chaikin]

Hi all,

I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
machine. This works fine, but is unsuitable for system deployment. Do 
you have hints for me where to start, in order to put the file system on 
flash? The platform I'm using is very limited - only one MTD block of 
2.5 MB is available for the file system, out of a 4 MB flash:
    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

For example, I've noticed LibC itself is ~5 MB !

Thanks for any tip,
-    Baruch.

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Thiemo Seufer]

Baruch Chaikin wrote:
> Hi all,
> 
> I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> machine. This works fine, but is unsuitable for system deployment. Do 
> you have hints for me where to start, in order to put the file system on 
> flash? The platform I'm using is very limited - only one MTD block of 
> 2.5 MB is available for the file system, out of a 4 MB flash:
>    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
> 
> For example, I've noticed LibC itself is ~5 MB !

You'll need a smaller libc, dietlibc comes to mind.
http://www.dietlibc.org/


Thiemo

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Johannes Stezenbach]

Thiemo Seufer wrote:
> Baruch Chaikin wrote:
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >    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
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> 
> You'll need a smaller libc, dietlibc comes to mind.
> http://www.dietlibc.org/

The diet libc is the first choice when you want it lean and mean.
Best used in combination with Busybox (patch necessary because the
Busybox uses GNU extensions and BSD cruft which the diet libc maintainer
refuses to implement) or embutils (http://fefe.de/).

OTOH, if you want shared library support, stable/working threads or iconv()
you must look elsewhere...


Johannes

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Wolfgang Denk]

In message <20030609165612.GE32450@rembrandt.csv.ica.uni-stuttgart.de> you wrote:
> Baruch Chaikin wrote:
> > Hi all,
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >    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
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> 
> You'll need a smaller libc, dietlibc comes to mind.
> http://www.dietlibc.org/

I don't really understand what all this discussion is about.

2.5 MB is plenty of space for a compressed ramdisk  image  using  the
standard  C  library. The ramdisk image included with our ELDK is 1.3
MB:

	-> ls -l /opt/eldk/mips_4KC/images/ramdisk_image.gz
	-rw-r--r--    1 root     root      1370532 Mar 18 18:09 /opt/eldk/mips_4KC/images/ram

It is based on Busybox, but also includes  standard  login  with  PAM
support, xinetd plus telnet and FTP.


Yes, libc _is_ big. But 5 MB is wrong. Remember that  you  can  strip
the library for the starget system. In our ramdisk image we get:

# ls -l lib | grep -v '^[ld]'
total 2433
-rwxr-xr-x    1 root     root        97308 Jan  1  1970 ld-2.2.5.so
-rwxr-xr-x    1 root     root      1448336 Jan  1  1970 libc-2.2.5.so
-rwxr-xr-x    1 root     root        28544 Jan  1  1970 libcrypt-2.2.5.so
-rwxr-xr-x    1 root     root        14204 Jan  1  1970 libdl-2.2.5.so
-rwxr-xr-x    1 root     root       515740 Jan  1  1970 libm-2.2.5.so
-rwxr-xr-x    1 root     root        99156 Jan  1  1970 libnsl-2.2.5.so
-rwxr-xr-x    1 root     root        62132 Jan  1  1970 libnss_compat-2.2.5.so
-rwxr-xr-x    1 root     root        56376 Jan  1  1970 libnss_files-2.2.5.so
-rwxr-xr-x    1 root     root        40897 Jan  1  1970 libpam.so.0.75
-rwxr-xr-x    1 root     root        13886 Jan  1  1970 libpam_misc.so.0.75
-rwxr-xr-x    1 root     root        75068 Jan  1  1970 libresolv-2.2.5.so
-rwxr-xr-x    1 root     root        12788 Jan  1  1970 libutil-2.2.5.so



So just use the standard libraries - it will fit easily.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Hindsight is an exact science.

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Thiemo Seufer]

Wolfgang Denk wrote:
[snip]
> > > The platform I'm using is very limited - only one MTD block of 
> > > 2.5 MB is available for the file system, out of a 4 MB flash:
> > >    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
> > > 
> > > For example, I've noticed LibC itself is ~5 MB !
> > 
> > You'll need a smaller libc, dietlibc comes to mind.
> > http://www.dietlibc.org/
> 
> I don't really understand what all this discussion is about.
> 
> 2.5 MB is plenty of space for a compressed ramdisk  image  using  the
> standard  C  library. The ramdisk image included with our ELDK is 1.3
> MB:
[snip]
> # ls -l lib | grep -v '^[ld]'
> total 2433

I conclude ELDK consists of little more than the basic networking utilities,
and the libc-related parts eat up most of the space. A more feature-rich
system probably can't afford to waste that much.


Thiemo

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Baruch Chaikin]

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.

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Baruch Chaikin]

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.

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Johannes Stezenbach]

Baruch Chaikin wrote:
> 
> Another question is the file system itself.  What is the recommendation 
> here - JFFS, CRAMFS, anything else?...

jffs if you need read/write, cramfs or squashfs for read-only.

stock cramfs has endianness problems (mkcramfs must run on same
endianness as kernel), but patches exist.

http://sourceforge.net/projects/squashfs/
http://sourceforge.net/projects/cramfs/

Johannes

Building a stand-alone FS on a very limited flash (newbie question)

[Baruch Chaikin]

Hi all,

I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
machine. This works fine, but is unsuitable for system deployment. Do 
you have hints for me where to start, in order to put the file system on 
flash? The platform I'm using is very limited - only one MTD block of 
2.5 MB is available for the file system, out of a 4 MB flash:
    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

For example, I've noticed LibC itself is ~5 MB !

Thanks for any tip,
-    Baruch.

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Jeff Baitis]

I highly recommend looking at the UClibC project. Erik's code is a pleasure to
work with.  http://www.uclibc.org/

It is even possible to build libstdc++ with UClibC, if you are so inclined...
And, a number of commercial projects use UClibC , such as Linksys:
http://lkml.org/archive/2003/6/7/164/index.html

and Belkin:

http://lkml.org/archive/2003/6/8/31/index.html

<shameless YRO plug>

-Jeff



On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
> Hi all,
> 
> I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> machine. This works fine, but is unsuitable for system deployment. Do 
> you have hints for me where to start, in order to put the file system on 
> flash? The platform I'm using is very limited - only one MTD block of 
> 2.5 MB is available for the file system, out of a 4 MB flash:
>     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
> 
> For example, I've noticed LibC itself is ~5 MB !
> 
> Thanks for any tip,
> -    Baruch.
> 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Jeff Baitis]

I made a mistake. I'm sorry, these projects use *busybox*. Don't know
if they use UClibC or not. Some wires in my brain got crossed.

Sorry about that.


But, I do recommend UClibC.

-Jeff

On Mon, Jun 09, 2003 at 11:49:51AM -0700, Jeff Baitis wrote:
> I highly recommend looking at the UClibC project. Erik's code is a pleasure to
> work with.  http://www.uclibc.org/
> 
> It is even possible to build libstdc++ with UClibC, if you are so inclined...
> And, a number of commercial projects use UClibC , such as Linksys:
> http://lkml.org/archive/2003/6/7/164/index.html
> 
> and Belkin:
> 
> http://lkml.org/archive/2003/6/8/31/index.html
> 
> <shameless YRO plug>
> 
> -Jeff
> 
> 
> 
> On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
> > Hi all,
> > 
> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
> > machine. This works fine, but is unsuitable for system deployment. Do 
> > you have hints for me where to start, in order to put the file system on 
> > flash? The platform I'm using is very limited - only one MTD block of 
> > 2.5 MB is available for the file system, out of a 4 MB flash:
> >     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
> > 
> > For example, I've noticed LibC itself is ~5 MB !
> > 
> > Thanks for any tip,
> > -    Baruch.
> > 
> > 
> > 
> 
> -- 
>          Jeffrey Baitis - Associate Software Engineer
> 
>                     Evolution Robotics, Inc.
>                      130 West Union Street
>                        Pasadena CA 91103
> 
>  tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 
> 
> 

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: Building a stand-alone FS on a very limited flash (newbie question)

[Tor Arntsen]

On Jun 9, 20:08, Jeff Baitis wrote:
>I made a mistake. I'm sorry, these projects use *busybox*. Don't know
>if they use UClibC or not. Some wires in my brain got crossed.
[...]

You can combine busybox and UClibC to create a very small Unix file system holding 
most of the tools you would want.  I made myself a single-floppy feature-full rescue
root disk for my x86 system using busybox and UClibC.  Looks like one good way
to solve the space problem described below.

-Tor

>> On Mon, Jun 09, 2003 at 07:37:19PM +0200, Baruch Chaikin wrote:
>> > Hi all,
>> > 
>> > I'm using MIPS kernel 2.4.18 with NFS file system mounted on a RedHat 
>> > machine. This works fine, but is unsuitable for system deployment. Do 
>> > you have hints for me where to start, in order to put the file system on 
>> > flash? The platform I'm using is very limited - only one MTD block of 
>> > 2.5 MB is available for the file system, out of a 4 MB flash:
>> >     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
[...]