Chapter 14. Linker Script Language (LSL)
To make full use of the linker, you can write a script with information about the architecture of the target processor and locating information. The language for the script is called the Linker Script Language (LSL).
This chapter first describes the structure of an LSL file. The next section contains a summary of the LSL syntax. In the remaining sections, the semantics of the Linker Script Language is explained.
The TASKING linker is a target independent linker/locator that can simultaneously link and locate all programs for all cores available on a target board. The target board may be of arbitrary complexity. A simple target board may contain one standard processor with some external memory that executes one task. A complex target board may contain multiple standard processors and DSPs combined with configurable IP-cores loaded in an FPGA. Each core may execute a different program, and external memory may be shared by multiple cores.
LSL serves two purposes. First it enables you to specify the characteristics (that are of interest to the linker) of your specific target board and of the cores installed on the board. Second it enables you to specify how sections should be located in memory.
14.1. Structure of a Linker Script File
A script file consists of several definitions. The definitions can appear in any order.
The architecture definition (required)
In essence an architecture definition describes how the linker should convert logical addresses into physical addresses for a given type of core. If the core supports multiple address spaces, then for each space the linker must know how to perform this conversion. In this context a physical address is an offset on a given internal or external bus. Additionally the architecture definition contains information about items such as the (hardware) stack and the interrupt vector table.
This specification is normally written by Altium. Altium supplies LSL files in the include.lsl
directory.
The architecture definition of the LSL file should not be changed by you unless you also modify the core's hardware architecture. If the LSL file describes a multi-core system an architecture definition must be available for each different type of core.
See
Section 14.4, Semantics of the Architecture Definition for detailed descriptions of LSL in the architecture
definition.
The derivative definition
The derivative definition describes the configuration of the internal (on-chip) bus and memory system.
Basically it tells the linker how to convert offsets on the buses specified in the architecture definition into offsets in internal memory. Microcontrollers and DSPs often have internal memory and I/O sub-systems apart from one or more cores. The design of such a chip is called a derivative.
Altium provides LSL descriptions of supported derivatives, along with "SFR files", which provide easy access to registers in I/O sub-systems from C and assembly programs. When you build an ASIC or use a derivative that is not (yet) supported by the TASKING tools, you may have to write a derivative definition.
745
TASKING VX-toolset for TriCore User Guide
When you want to use multiple cores of the same type, you must instantiate the cores in a derivative definition, since the linker automatically instantiates only a single core for an unused architecture.
See
Section 14.5, Semantics of the Derivative Definition
for a detailed description of LSL in the derivative definition.
The processor definition
The processor definition describes an instance of a derivative. Typically the processor definition instantiates one derivative only (single-core processor). A processor that contains multiple cores having the same
(homogeneous) or different (heterogeneous) architecture can also be described by instantiating multiple derivatives of the same or different types in separate processor definitions.
See Section 14.6, Semantics of the Board Specification
for a detailed description of LSL in the processor definition.
The memory and bus definitions (optional)
Memory and bus definitions are used within the context of a derivative definition to specify internal memory and on-chip buses. In the context of a board specification the memory and bus definitions are used to define external (off-chip) memory and buses. Given the above definitions the linker can convert a logical address into an offset into an on-chip or off-chip memory device.
See
Section 14.6.3, Defining External Memory and Buses , for more information on how to specify the
external physical memory layout. Internal memory for a processor should be defined in the derivative definition for that processor.
The board specification
The processor definition and memory and bus definitions together form a board specification. LSL provides language constructs to easily describe single-core and heterogeneous or homogeneous multi-core systems. The board specification describes all characteristics of your target board's system buses, memory devices, I/O sub-systems, and cores that are of interest to the linker. Based on the information provided in the board specification the linker can for each core:
• convert a logical address to an offset within a memory device
• locate sections in physical memory
• maintain an overall view of the used and free physical memory within the whole system while locating
The section layout definition (optional)
The optional section layout definition enables you to exactly control where input sections are located.
Features are provided such as: the ability to place sections at a given load-address or run-time address, to place sections in a given order, and to overlay code and/or data sections.
Which object files (sections) constitute the task that will run on a given core is specified on the command line when you invoke the linker. The linker will link and locate all sections of all tasks simultaneously.
From the section layout definition the linker can deduce where a given section may be located in memory,
746
