Tag Archive: grasshopper

From my previous post, you’re been able to read I am trying to cross compile and set up an AVR32 system. I have been trying some things and learning about cross compiling. I realise, last post was written from my notes, and may appear a little messy. I have make some progress, and learned how to do things, and realise I should have dome some things differently then my first attempt.

I have decided to create two kinds of posts for this topic. First will be a how-to guide. Just step-by-step guide to re-create the cross-compiler, the grasshopper root-fs, and possibly what I might create in my next steps. I am trying to set up a distcc based cross compile system, using ArchLinux’ pacman package manager and its package build utility makepkg, which has native distcc support. But it is still a long road before that works.

Apart from that, I will create a separate post with pitfalls. During this project I have come across certain error messages, which, of course, I have asked Google. Therefore I think it’s important to post those errors so it can be found.

Quite a while ago, I bought a Grasshopper. (a.k.a. ICnova AP7000 Base) I bought the thing and never even touched it… until recently. This little board has an AP7000 CPU. It’s architecture is AVR32. Not the most common thing. That’s why I bought it ;)

Well…. I have been playing around with it for the past week, or rather, some preparation to play with it, such as, a cross compiler. Since it’s a less common architecture, there are some oddities to overcome, but let’s begin. I will be using crosstool-ng to build the cross compiler. When building a cross compiler for ARM, it’s just setting the target and build, but for AVR32, the build process is not that straight forwards.

The first thing to encounter is the fact that “config.sub” doesn’t recognise the architecture, and so the build doesn’t even start. A simple “hack”, by replacing the content of “lib/ct-ng.1.19.0/scripts/config.sub” with

echo avr32-unknown-linux-uclibc

The second thing to encounter, upstream binutils has never heard of the AVR32 architecture. Have I mentioned it’s a less common architecture?
Specifically, the Binary File Descriptor library, libbfd, misses the definitions for AVR32. ATMEL provides a
patch against binutils 2.22. It’s not the most recent version… but ok.

GCC also doesn’t know anything about the AVR32 architecture. I have found GCC 4.4.7 at the ATMEL site. There seems to be a binutils 2.23, but that gave compilation errors, so I stuck with 2.22 (at least, for now. I just want a working cross compiler)

The GNU C Library also doesn’t know anything about the AVR32 architecture. I have to use the uClibc C library instead. The crosstool-NG integration isn’t complete, as I need to provide an external configuration file for uClibc. But here I ran into a number of problems as well. First of all. I am using version 0.9.31. I haven’t got a later version to work.

During stage 2 of the C compiler compilation

[ALL  ]    In file included from /home/andre/x-tools-avr32/avr32-unknown-linux-gnu/avr32-unknown-linux-gnu/sysroot/usr/include/bits/uClibc_mutex.h:15,
[ALL  ]                     from /home/andre/x-tools-avr32/avr32-unknown-linux-gnu/avr32-unknown-linux-gnu/sysroot/usr/include/bits/uClibc_stdio.h:107,
[ALL  ]                     from /home/andre/x-tools-avr32/avr32-unknown-linux-gnu/avr32-unknown-linux-gnu/sysroot/usr/include/stdio.h:72,
[ALL  ]                     from /home/andre/cross/bin/.build/src/gcc-custom/libgcc/../gcc/tsystem.h:87,
[ALL  ]                     from /home/andre/cross/bin/.build/src/gcc-custom/libgcc/../gcc/libgcc2.c:29:
[ERROR]    /home/andre/x-tools-avr32/avr32-unknown-linux-gnu/avr32-unknown-linux-gnu/sysroot/usr/include/pthread.h:227: error: expected ')' before '*' token

The default threading implementation is “nptl”, when I set it to “linuxthreads”, the problem is fixed. The next problem:

[ALL  ]    avr32-unknown-linux-uclibc-ranlib libgcov.a
[ALL  ]    # If the gcc directory specifies which extra parts to
[ALL  ]    # build for this target, and the libgcc configuration also
[ALL  ]    # specifies, make sure they match.  This can be removed
[ALL  ]    # when the gcc directory no longer holds libgcc configuration;
[ALL  ]    # it is useful when migrating a target.
[ALL  ]    Configuration mismatch!
[ALL  ]    Extra parts from gcc directory: crtbegin.o crtbeginS.o crtend.o crten
dS.o crti.o crtn.o
[ALL  ]    Extra parts from libgcc: crtbegin.o crtbeginS.o crtbeginT.o crtend.o 

requires yet another fix in a build script. Actually, I just commented out the part that checked for this configuration mismatch. The file that needs to be patched is “libgcc/Makefile.in” in the GCC files from the ATMEL site. (comment away lines 839-851)

I also ran in some problems with messages like

Error: .size expression with symbol `_init' does not evaluate to a constant
Error: .size expression with symbol `_fini' does not evaluate to a constant

For wich I found a solution here. Even though the solution at the said site is for PowerPC, the solution should apply to all architectures. The solution consists of removing two lines from a file. “.build/src/uClibc-0.9.31/libc/sysdeps/linux/$ARCH/crtn.S”, “.size _init, .-_init” and “.size _fini, .-_fini”.

With those patches, I managed to get a working cross compiler. From there, I was able to cross compile a linux kernel version 3.15. Compiling some other programs like busybox gave a few problems with the uClibc. As I mentioned, I need to feed an uClibc config file to the crosstool-NG. I had to enable certain options to make certain functionally available.

One of the problems I ran into was

loginutils/lib.a(getty.o): In function `getty_main':
getty.c:(.text.getty_main+0x42a): undefined reference to `usleep'

This site mentioned, I need to enable “SuSv3 legacy functions” to enable the build of usleep. As I was at it, I’ve enabled SuSv3 legacy macro’s and SuSv4 legacy functions as well. Just in case anything needs them. Anyhow…. I will stop writing here, as I am running into another subject. I will write more soon, as I have more to tell about the grasshopper, including issues regarding NFS booting. I needed this cross-compiled busybox, which gave me the SuSv3 problem, to use in the NFS root…. so strictly spoken, this last remark belongs in the next post :P