views:

2046

answers:

7

I am interested in cross-compile a Linux kernel for an ARM target on a x86 host.

There are some good practices you recommend?

Which is the best cross-compile suite in your opinion?

Have you setted up a custom cross-compile environment? If yes, what advices you have? Is it a good idea?

Thanks,

Myrrdyn

A: 

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.

ctacke
That really depends on how small that system is! Most arm system can't do this.
Johan
+4  A: 

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.

barneytron
A: 

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.

womble
+4  A: 

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.

Steve Lazaridis
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
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
Lauterbach is really good, but they do come with a heavy price tag...!
Johan
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
A: 

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.

ephemient
+9  A: 

There are two approaches I've used for ARM/Linux tools. The easiest is to download a pre-built tool chain directly from CodeSourcery.
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 want
Con: You get exactly what you want

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 CodeSourcery tools and replace them later with a custom solution via crosstool-ng if necessary.

ctuffli
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.
rstevens
+3  A: 

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.

Charles Duffy