Maverick armel cross toolchain

Jon Smirl jonsmirl at
Thu Sep 2 17:42:48 BST 2010

On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin <dave.martin at> wrote:
> [ un-breaking Loic email address in CC so people reply to the right
> place--- not sure what happened there ]
> On Thu, Sep 2, 2010 at 9:53 AM, Dave Martin <dave.martin at> wrote:
>> On Thu, Sep 2, 2010 at 9:31 AM, Ramana Radhakrishnan
>> <ramana.radhakrishnan at> wrote:
>>>> > arm-linux-gnueabi-gcc -g -DDEBUG -Os  -fno-strict-aliasing
>>>> > -fno-common -ffixed-r8 -ffunction-sections -msoft-float -Wcast-align
>>>> > -Wall -D__KERNEL__ -DTEXT_BASE= -fno-builtin -ffreestanding -isystem
>>>> > /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include -pipe -march=armv4t
>>>> > -mlong-calls -mtune=arm7tdmi-s -DCONFIG_ARM -D__ARM__
>>>> > -mthumb-interwork  -Wall -Wstrict-prototypes -Wcast-align -Wextra
>>>> > -Werror -Iobj_redbee-econotag_board -I../board -DBOARD=redbee-econotag
>>>> > -I../lib/include -I../src -I. -mthumb -mcallee-super-interworking -MMD
>>>> > -c -o obj_redbee-econotag_board/sleep.o sleep.c
>>>> > sleep.c:1:0: error: AAPCS does not support -mcallee-super-interworking
>>>>  This sounds like a missing implementation rather than just a toolchain
>>>>  flag; or perhaps it's not needed at all with AAPCS?
>>> -mcallee-super-interworking is ancient and need not be used with AAPCS
>>> toolchains. The linker will deal with interworking issues on AAPCS
>>> toolchains by inserting stubs at appropriate locations and arranging for
>>> correct control and state transfer at the required interfaces.
>> Note that this may only work if the calls to/from the ROM are via
>> linker-visible interfaces.
>> This means that no magic interworking would happen for things like
>> calling magic addresses, or for callback pointers passed into the ROM.
>>  This is because the the tools have no way to know whether the target
>> symbols for call/return are interworking or not in these cases.
>> There are some ways around this--- but it's probably best not to get
>> into that unless it's really needed.

The Freescale mc13224 contains an armv4t and a ROM that implements a
bunch of radio support in thumb code. Freescale has licensed this code
from somebody and can't release it GPL. The link libraries supporting
it are also not GPL.

Freescale's solution to this is to provide us with a human readable
link map for the ROM. With the link map we have the entry points and
can read the documentation on how they work.

So what's the best way to access this ROM?
Mar, are there other issues?

We'd really like to see a standardized cross ARM toolchain. Right now
we are all building our own with various compatibility issues.  What
about prebuilt newlib too?

I'm in the process of writing Linux kernel support for talking to
these 802.15.4 radios.

Jon Smirl
jonsmirl at

More information about the Linaro-dev mailing list