1
===========================
4
===========================
6
Much of the organization of the APEX binary image is controlled by the
7
linker script and sections therein. This has become sufficiently
8
complex such that documentation specific to the linker sections is
9
necessary to make sense of it.
11
Section names always begin with a period in order to isolate the
12
section symbols from other globals in the link. No section may begin
13
with the string '.rel' because the linker will complain that it is a
16
The primary hurdles that the loader encounters, before it can execute
17
as a bonafide C program are:
22
o In some instances, very little of the loader is available for execution
24
When the processor leaves RESET and begins executing code, the loader
25
must initialize SDRAM, put the kernel into SDRAM, and then jump to the
26
kernel with appropriate supporting data structures. Sometimes, it is
27
that easy, but there are many times when it is not.
29
o Without RAM for a stack, some architectures can make no procedure
30
calls. Some CPUs have SRAM and some architectures can be coerced
31
into using cache as RAM. It is safest to eliminate procedure
32
calls until system RAM
33
o Booting from NAND flash or I2C, for example, may only give us 512
34
bytes or a 1k of code to execute before we have to copy the reset
35
of the loader to RAM. Constrained boot modes provide a direct
36
challenge to writing a single, loader program.
38
There are several popular solutions to these problems, C macros to
39
eliminate procedure calls, using cache as RAM for a stack, and writing
40
a separate program to handle the bootstrap from NAND and other
41
constrained boot modes. APEX takes a different approach.
43
The linker script defines a sequence of sections. Each section is
44
owned by a particular type of code, platform, architecture,
45
relocation. The linker script collates these sections, allowing the
46
startup code to be interleaved without requiring function calls. This
47
interleaving also guarantees that important code is placed at the top
48
of the APEX binary image.
50
The result is that a single APEX image can be used to perform a
51
complete startup for a platform. If the hardware *can* be booted,
54
Some sections include subsections with suffixes .func and .exit.
55
These force an order on the code within the section should it be
58
The sections are as follows. If this list doesn't match the linker
59
script, please contact the author.
63
is the first code to execute. On ARM, it is either empty, or it is a
64
jump over the section that follows it (.envlink) which is used to
65
identify APEX in flash.
69
is a data structure used to identify APEX from user-mode programs by
70
scanning flash for the signature.
74
performs the first, architecture specific startups. As little as is
75
possible should be in .reset.
79
is the first opportunity for the target to perform some
80
initialzations. This code should be as small as possible, just enough
81
to support early relocation, perhaps a UART, and the RAM
86
is an opportunity to perform an early relocation, before RAM has been
87
initialized, in order to get access to enough of the loader to perform
88
the RAM setup. Early relocation is often necessary when booting from
89
NAND flash or I2C EEPROM.
93
checks whether or not APEX is already running in RAM. It depends on
94
data from the platform to determine the range of RAM addresses. This
95
code is factored out of the RAM initialization code in order to
96
simplify platform adaptations and to make sure that all targets
97
function the same way.
101
is the code to initialize RAM, SDRAM or otherwise. It should 'return'
102
a zero in the register that the architecture expects to find return
103
values. This zero tells the .reset.post code that the RAM was
106
On ARM platforms, the SDRAM initialization usually implements a
107
udelay() function that is used elsewhere in the application. This
108
function should be placed in section .bootstrap.sdram.func and the RAM
109
initialization must jump over this code to a symbol in section
110
.bootstrap.sdram.exit.
114
checks the 'return' value from the RAM initialization to determine
115
whether or not initialization occurred. If it was initialized, it may
120
performs the final relocation of APEX to RAM and to the final linked
121
executation address. The specifics of where APEX is sourced depends
122
on the boot mode. For NOR flash and running from RAM, the relocator
123
is a simple copy. For NAND flash, all of APEX is pulled from the NAND
128
This section is for architecture pickups, in case something special
129
needs to be done after the loader is moved or relocated. It also
130
performs the C setups before jumping to init() and beginning the
131
standard C portion of APEX.
135
is a pickup segment to hold bootstrap code that wasn't included in the
136
previous segments. Legacy platforms will have their initialization
137
code here as a function call from .reset.post. New platforms should
138
put nothing in the .bootstrap section.
added
removed
docs/Sections
