Description
Embedded systems can be designed to contain a non-volatile memory (ROM or Flash) which contains some built-in system code, and a RAM region where applications or customisation code can be downloaded later. Often the downloaded code needs to make use of routines which exist in the ROM image.

Solution
There are a number of possible solutions to this:

1. The application can use the SWI mechanism to call ROM functions.
2. Dynamic linking can be used, where the application is linked against the ROM when it is loaded into the system. This is not recommended using the current version of the ARM software tools.
3. Simple static linking of the application using the addresses of the ROM routines from the ROM build.

The static linking scheme (3) is often all that is required for many embedded systems. What is required is a way to feed the symbols from the ROM link into the following application link step.

ARM has written a utility ('SYMB') which allows an application to be statically linked with a ROM image. It reads the low level symbol table from the ROM image file (AIF or ELF format), and will create a new 'stub' object file that can be used when the application is linked, to allow ROM routines to be called. If you have a valid SDT support contract with ARM, then please contact us for more information about this utility, quoting your SDT serial number and contact details.

One issue with linking application code against ROM code in a different region of the memory map is the range of the branch and link (BL) instruction used for function calls. In ARM instruction set, BL has a range of +/-32Mbytes. In the Thumb instruction set, BL has a range of +/-4Mbytes. So, if a direct BL is to be used to call from application to ROM, the application must located within branch range of the ROM (system design issue). The SYMB utility can generate 'long branch veneers' to avoid the BL range restriction and allow the application and ROM to be located anywhere in memory.

One disadvantage of the static linking scheme is that in some cases there will be multiple ROM revisions which can cause problems because the ROM routines will move. This means a new version of the stub object file must be generated for each ROM revision, and the application must be re-built.

If multiple applications need to be downloaded to a target system in any order, there may be a requirement for code to be position independent. See Can ARM code be relocatable/reentrant?.