1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | .. Copyright (C) 2018 Chris Johns <chrisj@rtems.org> |
---|
4 | |
---|
5 | Target Execution |
---|
6 | ================ |
---|
7 | .. index:: Target Execution |
---|
8 | |
---|
9 | Fixed position statically linked executables have a fixed address in a target's |
---|
10 | address space. The location in the address space for code, data and read-only |
---|
11 | data is fixed. The BSP defines the memory map and it is set by the BSP |
---|
12 | developer based on the target's hardware requirements and it's bootloader. |
---|
13 | |
---|
14 | Targets typically contains a bootloader that is executed after the target's |
---|
15 | processor exits reset. A bootloader is specific to a target's processor and |
---|
16 | hardware configuration and is responsible for the low level initialization of |
---|
17 | the hardware resources needed to load and execute an operating system's |
---|
18 | kernel. In the case of RTEMS this is the RTEMS executable. |
---|
19 | |
---|
20 | Bootloaders vary in size, complexity and functionality. Some architectures have |
---|
21 | a number of bootloader stages and others have only minimal support. An example |
---|
22 | of a high end system is Xilinx's Zynq processor with three stages. First a mask |
---|
23 | ROM in the System On Chip (SOC) executes after reset loading a first stage |
---|
24 | bootloader (FSBL) from an SD card, QSPI flash or NAND flash depending on |
---|
25 | signals connected to the device. The FSBL loads a second stage bootloader |
---|
26 | (SSBL) such as U-Boot and this loads the kernel. U-Boot can be configured to |
---|
27 | load a kernel from a range of media and file system formats as well as over a |
---|
28 | network using a number of protocols. This structure provides flexibility at the |
---|
29 | system level to support development environments such as a workshop or |
---|
30 | laboratory through to tightly control production configurations. |
---|
31 | |
---|
32 | Bootloaders often have custom formats for the executable image they load. The |
---|
33 | formats can be simple to keep the bootloader simple or complex to support |
---|
34 | check-sums, encryption or redundancy in case an image becomes corrupted. A |
---|
35 | bootloader often provides a host tool that creates the required file from the |
---|
36 | RTEMS executable's ELF file. |
---|
37 | |
---|
38 | If RTEMS is to run from RAM the bootloader reads the image and loads the code, |
---|
39 | initialized data and read-only data into the RAM and then jumps to a known |
---|
40 | entry point. If the code is executed from non-volatile storage the process to |
---|
41 | write the image into that storage will have extracted the various binary parts |
---|
42 | and written those to the correct location. |
---|
43 | |
---|
44 | The important point to note is the binary parts of the executable are somehow |
---|
45 | loaded into the target's address space ready to execute. The way this done may |
---|
46 | vary but the out come is always the same, the binary code, data and read-only |
---|
47 | data is resident in the processor's address space at the BSP defined |
---|
48 | addresses. |
---|