On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin <dave.mar...@linaro.org> 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.mar...@linaro.org> wrote: >> On Thu, Sep 2, 2010 at 9:31 AM, Ramana Radhakrishnan >> <ramana.radhakrish...@arm.com> 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 jonsm...@gmail.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
