Introduction

This page describes how I got a working 2.6 linux kernel and cross compilation toolchain in order to use Maverick Crunch FPU on Cirrus EP93XX processor series.

WARNING : These informations and sripts and patches and whatever are for EP93xx rev. D1 or better. For DO rev. processors they might not work.
The Maverick Crunch is not yet officially supported by Cirrus on 2.6 linux kernels, so here is a summary of usefull informations about it.

Nucleusys have made some scripts and patches to add Maverick FPU support on 2.6 series kernel and build a cross compilation toolchain. It consists of :

1st step : the kernel

Nucleus' kernel patch applies against a 2.6.11.3 kernel. Unfortunaly, I was not able to use Maverick instructions with this patch applied to the kernel. I got some 'illegal instruction' errors, as well as segfaults.
Eric Benard provided on the Linux-ep93xx mailing-list a patch based on Nucleusys' one. It worked fine, thanks Eric !
I made a patch (avail. here) from these two patches so that it applies to a "vanilla" kernel.

That's it, now you can configure and compile your kernel as usual.

2nd step : the toolchain

Nucleusys also provide some scripts to automaticaly build the cross-compilation toolchain. The cross-compilation toolchain is a set of utilities (gcc/binutils/glibc) allowing to compile program for a target system (here ARM) from a host system (x86). There are a lot of cross-compilation toolchains for ARM, but none allows to use Maverick FPU instructions.
Unfortunaly, Nucleus' scripts did not work for me, so I've made a new script, which is avalaible here

If you want to use it, you must edit it and replace some vars :

SRCDIR="SOMEWHERE" to SRCDIR=/the/path/where/are/the/sources/

The SRCDIR directory must contain :

For linux-kernel-headers, I've extracted them from my kernel source tree. (version 2.6.11.7-ep93xx with Eric Benard's patches). Available here

GCCVERS can be 3.4.3 or 3.4.4 (other versions not tested)
BUVERS can be 2.15 or 2.16 (other versions not tested)
GLIBCVERS can be 2.3.3 or 2.3.5 (other versions not tested). GLTVERS should be the same than GLIBCVERS.

The script searches in this SRCDIR directory if there is a "gcc-GCCVERS.patch" file. If yes, it applies it to gcc before compiling. I made a patch from Nucleusys' gcc patches + some other patches from kegel.com. They are available for gcc-3.4.3 and gcc-3.4.4
Idem for glibc and binutils; glibc-2.3.3.patch , glibc-2.3.5.patch and binutils-2.15.patch (no patch needed for binutils 2.16)
Important note if using glibc-2.3.5 :
It seems that glibc-2.3.5 uses _unorddf2() and _unordsf2() functions. glibc-2.3.3 did not use these functions which are provided by gcc. For arm, they are defined in gcc-source-dir/gcc/config/arm/ieee754-df.S file for _unorddf2(), and gcc-source-dir/gcc/config/arm/ieee754-sf.S file for _unordsf2().
Nucleus' gcc patches adds new ieee754 files optimized for MaverickCrunch (ieee754-df-crunch.S and ieee754-sf-crunch.S) used instead of these files. But the new ones do not provide _unorddf2() and _unordsf2() functions.
So to be able to compile glibc-2.3.5 with Maverick crunch support, I've copied the _unorddf2() function from ieee754-df.S to ieee754-df-crunch.S and _unordsf2() from ieee754-sf.S to ieee754-sf-crunch.S
This change is present ONLY in gcc-3.4.4.patch. So, if you want to use glibc-2.3.5 you must use gcc-3.4.4, or report these changes to your prefered compiler version.

Once done, your SRCDIR contains (for example), gcc-3.4.4.tar.bz2, gcc-3.4.4.patch, glibc-2.3.5.tar.bz2, glibc-2.3.5.patch, binutils-2.16.tar.bz2, glibc-linuxthreads-2.3.5.tar.bz2 and linux-kernel-headers-2.6.11.7-ep93xx-eb.tar.bz2

Launch the script, answer the location you want your toolchain to be built (DESTDIR), and wait ... If you're not out of luck, should be fine.
When it's finished, your cross compilation toolchain is located in DESTDIR/ep93xx/.

You can try to compile and run programs with the command :

$DESTDIR/ep93xx/bin/arm-linux-gcc -mcpu=ep9312 -mfix-crunch-d1 -o hello hello.c

Don't forget -mcpu=ep9312 and -mfix-crunch-d1 !!!

In order to build more complicated softwares, such as those who need './configure; make; make install' to be built and installed, you can try to :
According to this page, applications compiled using this toolchain can only be statically linked, I don't know why. I have successfully compiled nbench in both static and dynamic versions, it worked fine. But for flac, only the static linked version worked.

I've rewritten the build script. The new one, called build-test.sh, is available here.
It is not supposed to work better than old one, but it is "cleaner".
I've removed the substitutions in make and config files (perl -pi ...) in order to configure and build tools in a more conventionnal way, with options passed to configure and make.
Binaries are now called arm-gnu-linuc-gcc, arm-gnu-linux-strip ... and so on, instead of arm-linux-gcc, arm-linux-strip ...
I've tested it only with gcc-3.4.4, binutils-2.16 and glibc-2.3.3.
If you have problems with this script, try to use the old one.

Tests

To test the built toolchain, I use the flac program to encode a 23m44s/251MB .wav file into a .flac file.
Flac uses a lot of 32/64 bits floats and integers computing, so this should be a good test.
With glibc-2.3.3, it takes 15m30s on my ep9312@200MHz board to encode, and 3m40s to decode.
With glibc-2.3.5 it takes 14m55s to encode and 3m40s to decode.

Links

Plans / TODO

I've planned to have a look at these points :


If you are interested by one of these subject and/or have some informations, I'd be glad to ear from you !

Disclaimer

Hope you'll understand my english, it's far from being perfect ;-)

Contact

yann at yannouch dot net

History