Linux cross-compilation for ARM architecture

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Charles Duffy]

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.

[Johan]

Lauterbach is really good, but they do come with a heavy price tag...!

[Johan]

That really depends on how small that system is! Most arm system can't do this.

[Steve Lazaridis]

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.

[mmmmmmmm]

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

[artless noise]

That 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]

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.

[71GA]

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.