Subject: state of 64 bit support

From: David Kesselring <[email-masked]>
Date: Fri, 6 Jun 2003 12:55:13 -0400 (EDT)

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
[email-masked]
919-462-6587

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 9 Jun 2003 17:28:18 +0200 (MET DST)

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

> but if you know of one I'd love the link. I have been unsuccessful getting

 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. 

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

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

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

> 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: [email-masked], PGP key available        +

---

From: Daniel Jacobowitz <[email-masked]>
Date: Mon, 9 Jun 2003 11:44:08 -0400

> it supports MIPS64/Linux without patching -- probably yes.

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

> finished updating 2.5.x, so you can select the version that suits you

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

---

From: Baruch Chaikin <[email-masked]>
Date: Mon, 09 Jun 2003 19:37:19 +0200

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.

---

From: Thiemo Seufer <[email-masked]>
Date: Mon, 9 Jun 2003 18:56:12 +0200

> 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

---

From: Jeff Baitis <[email-masked]>
Date: Mon, 9 Jun 2003 11:49:51 -0700

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

-- 
         Jeffrey Baitis - Associate Software Engineer

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

 tel: 626.535.2776  |  fax: 626.535.2777  |  [email-masked]

---

From: Jeff Baitis <[email-masked]>
Date: Mon, 9 Jun 2003 12:01:58 -0700

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

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

---

From: Johannes Stezenbach <[email-masked]>
Date: Tue, 10 Jun 2003 14:26:09 +0200

> You'll need a smaller libc, dietlibc comes to mind.

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

---

From: Wolfgang Denk <[email-masked]>
Date: Tue, 10 Jun 2003 14:38:38 +0200

> You'll need a smaller libc, dietlibc comes to mind.

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: [email-masked]
Hindsight is an exact science.

---

From: Thiemo Seufer <[email-masked]>
Date: Tue, 10 Jun 2003 14:56:23 +0200

Wolfgang Denk wrote:
[snip]
> > > The platform I'm using is very limited - only one MTD block of 
[snip]
> # ls -l lib | grep -v '^[ld]'

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

---

From: Wolfgang Denk <[email-masked]>
Date: Tue, 10 Jun 2003 15:15:14 +0200

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

> 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

>   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: [email-masked]
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

---

From: Baruch Chaikin <[email-masked]>
Date: Sun, 15 Jun 2003 17:47:31 +0200

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.

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

---

From: Johannes Stezenbach <[email-masked]>
Date: Tue, 17 Jun 2003 14:16:22 +0200

> 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