Toolchain tests, problems and a few workarounds...

[Wolfram Sang]

A small update, good news first:

On 02/01/11 12:19, Wolfram Sang wrote:

> *** GNUARM 3.4.3 TOOLCHAIN
> 
> master branch
> =============
> 
> ../../src/rate_ctr.c:24:22: inttypes.h: No such file or directory

Fixed, thanks.

> remotes/origin/steve-m/loader_sciphone
> ======================================
...
> 4) This then, leads to:
> 
> arm-elf-ld: address 0x400054d4 of board/mt62xx/loader.mtkram.elf section .text is not within region LRAM

Still happens with gnuarm-3.4.3, but not too much of a problem, because...

> *** CUSTOM 4.3.2 TOOLCHAIN
> 
> every branch
> ============
> 
> configure:3231: checking whether the C compiler works
> configure:3253: arm-elf-gcc -Os -ffunction-sections -I/home/wsa/Dev/osmocom-bb/src/target/firmware/include   conftest.c  >&5
> /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit':
> /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit'
> /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
> /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'

... with Michael's patch from today the above is now fixed with the
custom 4.3.2 and it later compiles the loader_sciphone-branch flawlessly
\o/ Compal binaries work, too.

For those interested, our toolchain can be found here:

ftp://ftp.pengutronix.de/pub/oselas/oselas.toolchain-1.99.3.6-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18_i386.tar.bz2

(Test reports welcome; 4.5.2 is in the making...)

My next step would be to try to get the g2_loader into the master-branch.

Cya,

   Wolfram