On Thu, Sep 2, 2010 at 5:42 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin dave.martin@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.martin@linaro.org wrote:
On Thu, Sep 2, 2010 at 9:31 AM, Ramana Radhakrishnan ramana.radhakrishnan@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.
If I remember correctly, with the newer AAPCS ABI, non-interworking code is not supported directly: to conform to the ABI, code _must_ interwork.
You may find that using a legacy ABI such as -mabi=atpcs will allow you to use the super-interworking options, but since support for this may eventually disappear this might not be the best long-term approach.
Otherwise, I guess the solution depends on what types of transition occur between the ROM and your code.
Since you are building your code in Thumb, and the code you are calling in the ROM is also Thumb, you might not need interworking at all.
If you are passing callbacks to the ROM which the ROM expects to call as ARM code, you have the option of writing some assembler stubs in ARM for getting from the ROM to your callbacks, and passing the stubs' addresses to the ROM instead of the real function entry points. This is effectively what -mcallee-super-interworking does if I understand the documentation correctly. Alternatively, simply build your callback functions as ARM: since you are building your code with interworking, there should be no problems unless the callback functions call back into the ROM. Returning from a callback to the ROM is probably not a problem, since _your_ functions are built with interworking enabled and will return in the correct way.
For calling the functions in the ROM, doing things like ((void (*)())<address>)() should work fine, though you must remember to set the bottom bit of the address if the target function is Thumb. Defining the symbols in a linker script should also work, and avoids adding any extra code to the image -- the same restriction applies concerning the bottom bit of the address.
Returning correctly from ROM functions back to callers in your code is unlikely to be a problem--- either the ROM code will unconditionally return to Thumb state (OK for you since you are building your code in Thumb anyway) or the ROM code will do correct interworking returns. Depending on how the code in the ROM was generated, there might be a mixture of these two cases.
Do you have any thoughts on this, Ramana? Is there an easier way?
Cheers ---Dave