Subject: Building cross libraries

From: David Rusling <[email-masked]>
Date: Fri, 07 Jul 2000 16:48:35 +0100

All,

    I've been 'playing' with cross-tools.   Using the various helpful help
files (Phil Blundell and Chris Rutter) I can now build binutils-2.9.5
and gcc-2.95.1 every which way.   However, I cannot build glibc-2.1
or newlib-1.8.2.

    Configuring newlib fail's 'cos it cannot compile/link a test image.
(I'm assuming arm-linux as the build variant).   It fails with unsupported
emulations.  I'm guessing that the kernel builds 'cos it uses steering files
for this stuff.

    Following Chris's instructions, glibc-2.1 fails because gcc 2.95.1
is not the correct version.   I hacked the configure file but it fails
as it builds it later on.

    So, help!        Dave

----------------------------------------------------------------------
David A Rusling   Consulting Engineer
    ARM Limited
    Liberty House,
    Moorbridge Road,
    Maidenhead, SL6 8LT

    Tel: UK-(0)1628-427754
    Fax: UK-(0)1628-780551
    e-mail: [email-masked]
----------------------------------------------------------------------

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for           ++
++                        kernel-related discussions.                      ++

---

From: Mark Hatle <[email-masked]>
Date: Fri, 07 Jul 2000 10:29:14 -0700

For our cross tools, we are currently using gcc-2.95.2 (with some back
patches + my softfloat patch), glibc-2.1.3 and the latest binutils.

If you would like a snap-shot let me know.. (I have them on my personal
server, otherwise I'd post the URL for them.  If there is enough demand,
I may see about getting the current tool chain up on the MontaVista ftp
site.)

--Mark

---

From: David A Rusling <[email-masked]>
Date: Sat, 8 Jul 2000 14:27:52 +0100

> I may see about getting the current tool chain up on the MontaVista ftp

I'll give it a shot but I would like your stuff to compare against.   
As of now I have a set of cross tools that can build Linux and eCOS/GDB.
That means that I can port the kernel and play with the GNU tools, 
next step is be able to cross build (ARM) applications.

Basically, the ARM embedded Linux space is about to explode and 
I see the abilty to cross-develop on Intel Linux the quickest way forwards
for most...

Dave

> --Mark
>
> David Rusling wrote:
> > All,
> >
> >     I've been 'playing' with cross-tools.   Using the various helpful
> > help files (Phil Blundell and Chris Rutter) I can now build
> > binutils-2.9.5 and gcc-2.95.1 every which way.   However, I cannot build
> > glibc-2.1 or newlib-1.8.2.
> >
> > (I'm assuming arm-linux as the build variant).   It fails with
> > unsupported emulations.  I'm guessing that the kernel builds 'cos it uses
> > steering files for this stuff.
> >
> > unsubscribe: body of `unsubscribe linux-arm' to
> > [email-masked] ++        Please use
> > [email-masked] for           ++ ++              
> >          kernel-related discussions.                      ++

---

From: Philip Blundell <[email-masked]>
Date: Sat, 08 Jul 2000 17:05:59 +0100

>and gcc-2.95.1 every which way.   However, I cannot build glibc-2.1

You might like to get binutils 2.10 and gcc "2.95.3" (ie the latest from the 
2.95 branch in CVS).

>as it builds it later on.

What failure are you seeing during the compile?  I used to cross-build glibc 
all the time, though I haven't done it recently.

p.

---

From: Mike Touloumtzis <[email-masked]>
Date: Sun, 9 Jul 2000 20:37:10 -0700

> as it builds it later on.

Here's a notebook I wrote up as I went through the stuff you're doing.
It's obviously directed at me (plus other people at my site who want
to do this), but it has the advantage of being pretty recent.

Haven't built newlib for ARM, so I can't help there.  I built it for
M32R a while ago, but don't remember what was involved.

miket

Building binutils
-----------------

-- Grab safe binutils source.  The current Debian version, 2.9.5.0.31,
   is claimed to be buggy on one of the ARM mailing lists.  2.9.5.0.14
   is reported to be safe on Chris Rutter's ARM cross-compiler page,
   so I'm going to give that a try.  According to Phil Blundell's page
   and FTP site, the 2.9.5.* series binutils don't require ARM patches
   (unlike 2.9.1.*).

   Here's the official site for binutils:
   ftp://ftp.varesearch.com/pub/support/hjl/binutils/

   Actually, scratch the above version number stuff.  The site contains
   2.9.5.0.37, and I'm going to try that, because going back to a much older
   version looks like it will involve a heinous amount of reverse patching.
   If .37 doesn't work, I guess I'll try .14.

-- Also grab current Debian binutils source, so that I can figure out how to
   package the cross-compiler one I'm building.  Looks like the debian stuff
   is really complicated here (this source package produces four different
   .debs).  I guess it's time I read the Debian packaging manual...

These steps will install the ARM binutils under /usr/local/.  The binaries
will be named arm-linux-*.  Binutils is the easy part of cross-gcc
compilation.

1) Unpack tarball.
2) Make build dir 'binutils-build' parallel to source dir.
3) cd to build dir.
3) Run ../configure --help to see options.
4) Run ../configure --target=arm-linux
5) Typical make + make install.

Building GCC
------------

Following instructions on:
http://inkvine.fluff.org/~chris/arm-tools.html

GCC requires the kernel header files.  I'm going to try against a patched
2.4.0-test1-ac19.  Steps to getting this kernel in the right state for
building gcc:

1) Get 2.4.0-test1-ac19 source (from kernel.org).  Have to download
   2.4.0-test1 and apply the ac19 patch to it.  Get the .sign files
   and check the signatures, too!  This kernel can be found at
   ftp.us.kernel.org in:
	/pub/linux/kernel/v2.4/linux-2.4.0-test1.tar.gz
	/pub/linux/kernel/v2.4/linux-2.4.0-test1.tar.gz.sign
   and the -ac19 patch is in:
	/pub/linux/kerner/people/alan/2.4.0test/patch-2.4.0test1-ac19.bz2
	(and corresponding .sign).
   To unpack and apply the patch (somewhere in your home directory):
	$ tar zxvf linux-2.4.0-test1.tar.gz
	$ mv linux linux-2.4.0-test1
	$ cd linux-2.4.0-test1
	$ bzcat ../patch-2.4.0test1-ac19.bz2 | patch -p1 -s -E

2) Get latest RMK (Russell M. King, linux-arm maintainer) patch from 
   ftp://ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/
   (it's against -ac19, that's why I chose that kernel version) and once
   again patch the kernel:
	$ zcat ../patch-2.4.0-test1-ac19-rmk1.gz | patch -p1 -s -E

3) In the top-level kernel Makefile, replace the line:
	ARCH := $(shell uname ... bunch of stuff ...)
   with
	ARCH := arm

4) Configure the kernel with 'make menuconfig'.  Save the default
   configuration.  I'm hoping this works OK, as we don't need to really
   build the kernel, we just need to get its headers into a state
   acceptable for building GCC.  The closest thing in the Makefiles to
   the 7211 is probably the 7500 (although ARM710A, not 710TDMI), but
   that port is not fully merged and the option is commented out.

5) Run 'make dep' to build the dependency tree.

6) Create links in the arm-linux target include directory:
	$ cd /usr/local/arm-linux
	$ mkdir include; cd include
	$ ln -s your-linux-kernel-directory/include/asm-arm asm
	$ ln -s your-linux-kernel-directory/include/linux linux

7) Download gcc 2.95.2, plus Phil Blundell's add-on patch at:
	ftp://ftp.netwinder.org/users/p/philb/gcc-2.95.2-diff-991022.gz
   and the fold-const.c patch from Chris Rutter's page
	http://inkvine.fluff.org/~chris/arm-tools.html
   Read Chris's page top to bottom, as it has a bunch of information on
   what should be done next.

8) Commentary on Chris Rutter's page
   -- Phil Blundell's 2.95.2 gcc patch doesn't apply cleanly, but I looked
      at the patch, and the changes look reasonable (right direction,
      likely bug fixes, etc).  The top-level stuff (ChangeLog, configure,
      configure.in) will get rejected; the other stuff patches cleanly,
      although I had to supply a path to each file.
   -- The fold-const.c patch looks like it's still needed (it hasn't been
      applied in 2.95.2).
   -- The instructions about changing #if 0 to #if 1 in
      gcc/config/arm/linux-elf.h look to be obsolete; there is no #if 0
      in that file.
   -- I used the -Dinhibit_libc hack described in the page.

9) Configure and build, after the necessary patching.
   Command lines (from directory _above_ gcc-2.95.2):
	$ mkdir gcc-build
	$ cd gcc-build
	$ ../gcc-2.95.2/configure --target=arm-linux --disable-threads
	$ make LANGUAGES="c" cross
   My build failed with an error message in libio, but I looked at the
   binaries and found quite a lot of gcc stuff, so I did an impatient
   'make install' without debugging the problem (looks to be lack of a
   target libc) and was able to compile a standalone boot loader with
   no libc dependencies.

Glibc
-----

1) Download glibc-2.1.3 and the crypt and linuxthreads add-ons.

	$ mkdir glibc-build
	$ cd glibc-build
	$ export CC=arm-linux-gcc
	$ ../glibc-2.1.3/configure arm-linux --build=i586-linux \
		--prefix=/usr/local/arm-linux/ --enable-add-ons
	$ make
	$ make install

Gcc Revisited
-------------

You can now go back and compile the full-on gcc.  First, remove the
-Dinhibit_libc hack from the sources.  Delete your previous build
directory, and:

	$ mkdir gcc-build
	$ cd gcc-build
	$ ../gcc-2.95.2/configure --target=arm-linux
	$ make
	$ make install

Don't forget to unset CC if you set it above.

Stripping Binaries
------------------

You now have an unholy amount of stuff in /usr/local.  I went through
and stripped some shared libraries.  Make sure you use 'strip' for Intel
tools and 'arm-linux-strip' for ARM binaries.  Hopefully, I'll automate
this process soon; if you don't know what you're doing, I recommend
against this step.

---

From: David Rusling <[email-masked]>
Date: Mon, 10 Jul 2000 14:35:01 +0100

Mike,

    thank you very much.   I think that what I was doing was not building
the correct version of glibc, I had glibc-2.1, not 2.1.3.  After a bit of
fiddling I can now build static applications for my ARM Linux box.
This is with gcc 2.95.2 but I think that gcc 2.95.1 would also work.

    I build all my stuff for /usr/local/gnu so I ended up having to
create a link from /usr/local/gnu/lib to /usr/local/gnu/arm-linux/lib
(I also have arm-elf for the eCOS work that I've been doing).

    All I have to do now is to figure out how to 'install' the shared
libraries onto my pocket Linux system...

Dave

    Tel: UK-(0)1628-427754
    Fax: UK-(0)1628-780551

---

From: Steve Hill <[email-masked]>
Date: Mon, 10 Jul 2000 08:04:29 -0500

> libraries onto my pocket Linux system...
Well, now that you have a complete working toolchain, you can start building
all the components for your disk image for your pocket Linux system. A good
place to start would be to get ARM packages from the Debian site. If you want
to build 'glibc' from scratch to put on your own disk image, here is one way
of doing it.

1) Create a ramdisk using '/dev/ramX' or use the loopback device and format
   an 'ext2' filesystem on it.

2) Un-pack your 'glibc' sources again.

3) Put your cross-compilation environment in your path and run the configure
   script for 'glibc' only this time using '--prefix=/usr'. This will
   configure 'glibc' in a special way that will install the libraries in
   '/lib' like it is on a "normal" Linux system. (By telling it the prefix
   is /usr AND that the target is a Linux variant, glibc figures out that
   you are creating it to be the main C run time library on the system)

4) Go ahead and do a 'make' and let it finish. STOP THERE!

5) WARNING!!! Now that 'glibc' has been built you are now ready to install
   it. If you were to do a 'make install' it would overwrite your host PC
   libraries and you would be screwed. Instead you want to do the install
   using 'make install_root=[path-to-mounted-disk-image] install'. This
   will then install 'glibc' to your disk image.

6) Continue putting whatever else you want on your image.

7) Unmount disk image. Hurray, you are done.

Hope this helps.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger [email-masked]'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

---

From: Xavier DEBREUIL <[email-masked]>
Date: Mon, 10 Jul 2000 15:25:21 +0000

Hello,
I would like to know the state of the development for Cirrus mcu :
cspl7500
ep7211
ep7212
Is the cspl7500 linux version able to run (with little modifications...) on
ep7211 and ep7212 ?

thank you.

Xavier.

---

From: David Rusling <[email-masked]>
Date: Mon, 10 Jul 2000 15:20:59 +0100

Steve,

    I have a pocket linux system (based around busybox) that I built on
an ARM Linux system (a Corel box).  I use ROM fs myself.  Thanks for
the tips though...

Dave

    Tel: UK-(0)1628-427754
    Fax: UK-(0)1628-780551

---

From: Mike Touloumtzis <[email-masked]>
Date: Mon, 10 Jul 2000 22:09:42 -0700

> Is the cspl7500 linux version able to run (with little modifications...) on

I have the (pretty ancient) 2.2.1 kernel booting and running on
an EDB7211 evaluation board, as of Friday night :-).  Here's a
very terse set of instructions I wrote for myself:

=====================================================================
Get the canonical 2.2.1 kernel from kernel.org and unpack it:

wget ftp://ftp.us.kernel.org/pub/linux/kernel/v2.2/linux-2.2.1.tar.gz
tar zxvf linux-2.2.1.tar.gz
mv linux linux-2.2.1-ep7211

Go to the kernel directory and patch it:

cd linux-2.2.1-ep7211
export PATCHDIR=/place/where/you/keep/your/patches
# Russell King's official Linux/ARM patch:
zcat $PATCHDIR/patch-2.2.1-rmk2.gz | patch -p1
# Phil Blundell's patch:
zcat $PATCHDIR/linux-2.2.1-philb-990208.gz | patch -p1
# www.calcaria.net (linux-7110) "crash+burn" patch:
zcat $PATCHDIR/crash+burn-26.patch.gz | patch -p1
# Ben Williamson's EP7211 port patch (NOTE -p2 instead of -p1!):
zcat $PATCHDIR/cb26-benw3.gz | patch -p2
# my patch (-miket1):
cat $PATCHDIR/patch-2.2.1-miket1 | patch -p1

Fixes in -miket1 patch:
==> include intermediate patches in EXTRAVERSION
==> in arch/arm/Makefile: elf32arm -> armelf_linux in $(LD)
==> in arch/arm/vmlinux-armv.lds: change top line to:
    OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
==> bandaid for Oops in serial bottom half
==> wrong TLB/cache flush coprocessor insns were being assembled
    (found this out the hard way :-).  Gross fix included.

Use Ben Williamson's 'shoehorn' boot loader to download the kernel over
the serial port; first install my patch to set the DRAM refresh to 64kHz
(patch also restores terminal settings when you kill shoehorn).
=====================================================================

Patches (for kernel and shoehorn) attached.

Note that both patches are quick fixes to get things working; I didn't
fix the kernel correctly, and the shoehorn patch still uses the 'anvil'
hardware type because I was in a hurry.  I'm not going to concentrate
much effort on 2.2.1; I'm looking to forward port the EDB7211 stuff to
2.4.0-test*, but I'm not sure how much time I'll have for that in the
next couple of weeks (probably not much).  Although I have the eval
board for work, the Linux kernel stuff is strictly free-time hacking
at this point.  If anyone is already doing/has already done a 7211
port to 2.4, please let me know, I'm lazy!

The version of the kernel I got working just has serial console support,
no keyboard/LCD/touchscreen/ethernet/PCMCIA.  There's a random little
Linux distro called 'Royal Linux' that has a port which includes all this
stuff, but when I tried it a while ago, it crashed a lot ('a lot' as in
'only made it to init one time in three').  Hopefully it works better for
its authors and I was just missing some magic.  I'm planning on getting
my hands on it soon, so that I can use its drivers in the port to 2.4.

miket

---

From: [email-masked]
Date: Sat, 15 Jul 2000 15:03:08 +0100

In message <[email-masked]>, Mike Touloumtzis writes:
>   so I'm going to give that a try.

The latest version of binutils is 2.10.  You can get it from ftp.gnu.org, 
sourceware.cygnus.com and mirrors.  No extra patches are needed for ARM GNU/
Linux.

>   -- The fold-const.c patch looks like it's still needed (it hasn't been

To be honest I don't really remember what the status of the 2.95.2 patch is.  
I think there is a "2.95.3" patch in my directory on netwinder.org that might 
be slightly better.  That should also apply against 2.95.2 without too many 
problems.

p.

---

From: Scott Bambrough <[email-masked]>
Date: Mon, 17 Jul 2000 10:57:00 -0400

> be slightly better.  That should also apply against 2.95.2 without too many

To be quite honest, I think the best source of patches for gcc is my source RPM
on netwinder.org.  I spent a great deal of time organizing and documenting
them.  AFAIK, they are fully up to date.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

---

From: Philip Blundell <[email-masked]>
Date: Mon, 17 Jul 2000 16:28:49 +0100

>To be quite honest, I think the best source of patches for gcc is my source
>RPM on netwinder.org.  I spent a great deal of time organizing and documenting

Good point.  Yes, I agree.

p.