Re: [arm-gnu] not a gnu question per se, but related (linker script help)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [arm-gnu] not a gnu question per se, but related (linker script help)
- To: arm-gnu@xxxxxxxxxxxxxxxx
- Subject: Re: [arm-gnu] not a gnu question per se, but related (linker script help)
- From: 42Bastian <list-bastian.schick@xxxxxxxxxxx>
- Date: Fri, 30 Apr 2010 07:34:31 +0200
Am 30.04.2010 05:16, schrieb Andrew Kohlsmith (mailing lists account):
> Good evening,
:-) Depends, morning here in Germany.
> In order to isolate bootloader changes from affecting the application's ability
> to use bootloader functions, I'm thinking of creating a jump table much the
> same as the ARM's exception table. The idea is certainly not new; I know from
> my ancient history that the Commodore 64 used the same idea to provide a fixed
> set of addresses for functions.
>
> Is there a slick way of creating this jump table using the linker? Do I just
> create a section in my boot.s file, populate it with branch instructions to the
> functions, and then use PROVIDE() statements in the linker? Is there a better
> way? This is all thumb code, and I know that branches in thumb are limited to
> 2kB, so maybe I should be using an ARM jump table instead since the bootloader
> functions can occupy anything in the first 4k of Flash? Should I be looking at
> this differently?
I would do the following:
1) Place all shared functions at the end of the bootloader section
2) Create a table of addresses at a well know place. (Either linker, or a
small assembly file).
3) In you application, let a function-pointer array point to this place.
4) Call the functions via function pointers.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+