I am interested in cross-compiling a Linux kernel for an ARM target on a x86 host. Are there some good practices you recommend? Which is the best cross-compile suite in your opinion? Have you settled up a custom cross-compile environment? If yes, what advices do you have? Is it a good idea?
7 Answers
There are two approaches I've used for ARM/Linux tools. The easiest is to download a pre-built tool chain directly.
Pro: It just works and you can get on with the interesting part of your project
Con: You are stuck with whichever version of gcc/binutils/libc they picked
If the later matters to you, check out crosstool-ng. This project is a configuration tool similar to the Linux kernel configuration application. Set which versions of gcc, binutils, libc (GNU or uCLibc), threading, and Linux kernel to build and crosstool-ng does the rest (i.e. downloads the tar balls, configures the tools, and builds them).
Pro: You get exactly what you selected during the configuration
Con: You get exactly what you selected during the configuration
meaning you take on full responsibility for the choice of compiler/binutil/libc and their associated features/shortcomings/bugs. Also, as mentioned in the comments, there is some "pain" involved in selecting the versions of binutils, C library etc. as not all combinations necessarily work together or even build.
One hybrid approach might be to start with the pre-built tools and replace them later with a custom solution via crosstool-ng if necessary.
Update: The answer originally used the CodeSourcery tools as an example of a pre-built tool chain. The CodeSourcery tools for ARM were free to download from Mentor Graphics, but they are now called the Sourcery CodeBench and must be purchased from Mentor Graphics. Other options now include Linaro as well as distribution specific tools from Android, Ubuntu, and others.

- 3,559
- 4
- 31
- 43
-
2Another con for crosstool-ng is that you have to find out for yourself which combinations of gcc/glibc/target architecture versions work and which do not. (Okay, you can look them up in the "known-to-work" list on the crosstool-ng homepage but if your preferred combination is not on the list it is up to yourself to find out if it works. – mmmmmmmm Sep 13 '09 at 17:17
-
1That is true, but starting with one of the working configurations makes things easier. If you must make Canadian cross tools for Windows and/or another OS, then the pre-built ones may never fit. It definitely takes a few weeks, not a few minutes to use ct-ng. However, code generation is usually better than pre-builts and you can get the latest features if desired (LTO, C++0x, C++11, etc). – artless noise Jun 13 '14 at 15:16
-
1**Sourcery CodeBench (Lite)** is **no longer available** for ARM! It is available for other targets though... Looks like Mentor Graphics wants us to buy the propietary version **Sourcery CodeBench**. – 71GA Mar 13 '15 at 01:56
I use the emdebian toolchain for compiling stuff for my ARM machines that isn't happy being compiled natively in the small resources available (/me glares at the kernel). The main package is gcc-4.X-arm-linux-gnueabi
(X = 1,2,3), and provides appropriately suffixed gcc/cpp/ld/etc commands. I add this to my sources.list
:
deb http://www.emdebian.org/debian/ unstable main
Of course, if you're not using Debian, this probably isn't so useful, but by gum it works well for me.

- 12,033
- 5
- 52
- 66
I've used scratchbox while experimenting with building apps for maemo (Nokia N810), which uses an ARM processor. Supposedly, scratchbox is not restricted to maemo development.

- 7,943
- 3
- 23
- 25
I've used crosstool on several targets. It's great as long as you want to build your toolchain from scratch. Of course there are several pre built toolchains for arm as well, just google it -- too many to mention here.
1) In my opinion building your own toolchain works the best. You end up having tight control over everything, plus if you're new to embedded linux, it's a GREAT learning experience.
2) Don't go with a commercial toolchain. Even if you don't want to take the time to build your own, there are free alternatives out there.
If your company will spend the money, have them buy you a jtag debugger.
It will save you tons of time. and it allows you to easily learn and step through the kernel startup, etc..
I highly recommend using the Lauterbach jtag products... They work with a ton of targets and the software is cross platform. Their support is great as well.
If you can't get a jtag debugger and you're working in the kernel, use an VM to do that, usermode linux, vmware..etc.. your code will be debugged on x86.. porting it to your arm target will be a different story, but it's a cheaper way to iron out some bugs.
If you're porting a bootloader, use uboot. Of course, if you're using a reference platform, then you're probably better off using what they provide with the BSP.
I hope that helps.

- 2,210
- 1
- 15
- 15
-
Modern versions of qemu have gdbclient support, so as long as your ARM target is one that qemu covers, using that for a virtual test environment works decently, and doesn't require you to debug on a different architecture. But yes, there's no replacement for real hardware with a JTAG port. – Charles Duffy Jan 30 '09 at 16:26
-
That said, commercial toolchains aren't all so bad -- I used to work for MontaVista, and I'm confident that there was a lot of value-add in all the porting and debugging work we did. Sure, you can roll your own minimal toolchain easily enough, but getting a full embedded distro is much more work. – Charles Duffy Jan 30 '09 at 16:28
-
1
-
Very true, but over all if you think about an engineer's hourly rate and the amount of printk debugging VS the cost of the tool. It's well worth it. – Steve Lazaridis Feb 11 '09 at 17:03
Buildroot is a tool I've had reasonably good luck with for building a custom uClibc-based toolchain from scratch. It's very customizable, and not excessively particular about what distribution you happen to be running on.
Also, many of its existing users (ie. embedded router distros) are also targeting ARM.

- 280,126
- 43
- 390
- 441
-
*builtroot* currently uses *crosstool-ng* (2014); as does Ubuntu and Linaro. It depends if you want them to use *crosstool-ng* or you want to take the time yourself. Many projects are shifting away from *uClibc* to *eglibc* since this answer was written. Many packages need small tweaks if you use *uClibc* as the API is not 100% compatible with *glibc*. – artless noise Jun 13 '14 at 15:20
If you're using Gentoo, getting a cross-compiling toolchain is as easy as
$ emerge crossdev $ crossdev -t $ARCH-$VENDOR-$OS-$LIBC
where ARCH
is arm
or armeb
, VENDOR is unknown
or softfloat
, OS
is linux
, and LIBC
is gnu
or uclibc
.
If all you want is a compiler (and linker) for the kernel, the LIBC
part is irrelevant, and you can use -s1
/--stage1
to inform crossdev
that you only need binutils
and gcc
.

- 198,619
- 38
- 280
- 391
This is what Eurotech uses for their Debian ARM distibution. You'll note that they don't recommend using a cross compiler if you can avoid it. Compiling on the target itself tends to be a more reliable way of getting outputs that you know will run.

- 66,480
- 18
- 94
- 155
-
4That really depends on how small that system is! Most arm system can't do this. – Johan Feb 11 '09 at 06:13