Deep Dive into ARM Embedded Systems | ARMV8 Linker Script u-boot.lds Source Code Analysis

u-boot.lds is the linker script file for the u-boot project, which plays a crucial role in the compilation and linking of the project. It determines the assembly of u-boot and instructs the linker on how to combine the sections from various source files (such as assembly and C source files) into the final executable file. Additionally, the ENTRY (_start) in the u-boot.lds linker file specifies the entry address of the u-boot program.

In ARMv8, the u-boot linker script path is:

u-boot/arch/arm/cpu/armv8/u-boot.lds

For u-boot-spl and u-boot-tpl in ARMv8, the linker script paths are:

u-boot/arch/arm/cpu/armv8/u-boot-spl.lds

(u-boot customizes u-boot-spl.lds and u-boot-tpl.lds through Kconfig)

In ARMv7, the u-boot linker script path is:

u-boot/arch/arm/cpu/u-boot.lds

For u-boot-spl in ARMv7, the linker script path is:

u-boot/arch/arm/cpu/u-boot-spl.lds

Compiled u-boot linker scripts in ARMv7 and ARMv8:

u-boot/u-boot.lds

Compiled u-boot-spl linker scripts in ARMv7 and ARMv8:

u-boot/spl/u-boot-spl.lds

If the command line has no parameters, the first format is used for encoding output by default.

If the command line options include `-EB`, the second format is used for encoding output.

If the command line options include `-EL`, the third format is used for encoding output.

The ARMv8 architecture is divided into AArch64 (64-bit) and AArch32 (32-bit) execution states.

The CPU architecture also includes the following:

(1) X86: Intel 32-bit instruction set

(2) AMD64: 64-bit, AMD’s first 64-bit processor compatible with the X86 32-bit instruction set

(3) IA-64: Intel 64-bit instruction set, incompatible with the 32-bit instruction set

(4) X86-64: 64-bit, Intel’s extension of the AMD64 instruction set, renamed x86-64, also known as x64

(5) ARM: includes 8-bit, 16-bit, 32-bit, with advantages of low cost, high performance, and low power consumption

(6) AArch32: 32-bit execution state of ARM-V8 architecture

(7) AArch64: 64-bit execution state of ARM-V8 architecture

The entry symbol of the executable program is _start.

Defined in: u-boot/arch/arm/cpu/armv8/start.S

ARMV8_SECURE_BASE is u-boot’s support for PSCI,

when defined, it can redirect the text, data, and stack segments of PSCI to specified memory instead of embedding them in u-boot.

However, manufacturers typically implement this using ATF to separate it from the bootloader, and this feature is not commonly used;

Locator, defines the program link base address, setting the address of _start to 0x00000000, which is the address where U-BOOT starts running after power-up;

This address can be modified through the configuration compilation parameter:

-Ttext=$(CONFIG_TEXT_BASE) for modification,

CONFIG_TEXT_BASE is generally defined in a macro form in configs (XXX_defconfig). If this macro is not defined, the default address is 0x00000000.

Configures the code segment to be aligned to 8 bytes. Since it is a 64-bit instruction set, the corresponding address and data lines are 64 lines, meaning each address corresponds to 64 data lines, which is 64 bits, or 8 bytes.

In a 64-bit instruction set system, each address pointer points to a memory space of 64 bits, 8 bytes.

In a 32-bit instruction set system, each address pointer points to a memory space of 32 bits, 4 bytes.

__image_copy_start and __image_copy_end are used to define the segments that need to be redirected. U-boot is a bootloader divided into pre-redirection initialization and post-redirection initialization, so this section defines the starting and ending addresses of the data that needs to be moved to DDR after completing the pre-redirection initialization;

Most of the time, u-boot runs in limited SRAM or read-only flash. To unify the startup process, u-boot does not access global variables before DDR initialization and relocation.

However, to ensure that u-boot can read and write global variables, memory, and call various driver capabilities, u-boot divides the startup initialization into two parts: pre-redirection initialization (board_f) and post-redirection initialization (board_r).

Before redirection, some necessary initializations are completed, including possible DDR initialization, and then u-boot is moved to DDR through __image_copy_start and __image_copy_end, and post-redirection initialization is performed in DDR, at which point u-boot can normally access global variables and other information.

If you want to read and write some global variable information during the board_f process, how can you do it? U-boot accomplishes this by defining global_data (gd).

CPUDIR/start.o (.text*)

Defines the header text segment of the linking program,

armv8 is arch/arm/cpu/armv8/start.S,

all text segments in start.S will be linked to this segment, and the segment entry symbol is _start;

The main purpose of introducing EFI compatibility is to boot x86 platform architectures. The code and data segments of EFI are directly linked to the code segments following start.o.

If you need to support UEFI, you can configure

CONFIG_EFI_LOADER = y

CONFIG_CMD_BOOTEFI = y

CONFIG_EFI = y

CONFIG_CMD_EFIDEBUG = y

CONFIG_CMD_EFICONFIG = y

CONFIG_EFI_SECURE_BOOT=y

Read-only data segment:

SORT_BY_NAME keyword: The linker will sort the names of files or segments in ascending order and then organize their contents.

SORT_BY_ALIGNMENT: All file segments are sorted in descending order, with larger alignments placed before smaller ones to reduce the extra space needed for alignment.

.bss: Stores uninitialized global and static variables. Uninitialized variables are zeroed out at program startup and do not actually occupy memory, thus not increasing file size.

.data: Stores global and static variables that are initialized to non-zero values, occupying memory and increasing file size.

.rodata: Read-only data, such as global variables modified with const (generally storing constants and string literals), shared among multiple processes to improve space utilization.

Stores the __u_boot_list structure or __u_boot_list variable for all drivers in u-boot.

Sorts and aligns them, storing the sorted results in the __u_boot_list memory segment.

The u_boot_list segment defines all commands and device drivers currently supported in the system. This segment collects commands defined by a series of extended macros U_BOOT_CMD and device drivers defined by U_BOOT_DRIVER scattered across various files, sorting them by name for quick retrieval and execution in the command line and detecting registered devices and device tree matching probe device driver initialization; (device driver probing is only effective when the dm modular driver is defined).

C language function command rules: __u_boot_list_ + 2_ + @_list + _2_ + @_entry

For example:

__u_boot_list_2_array_1

__u_boot_list_2_array_2_first

__u_boot_list_2_array_2_second

__u_boot_list_2_array_2_third

__u_boot_list_2_array_3

Defines the end position of the U-Boot code;

Both __image_copy_start and __image_copy_end segments contain a char[0] data, with a size of zero;

The symbols __image_copy_start and __image_copy_end are used only for code relocation.

Generally, u-boot runs based on the defined base address. If the load address, link address, and run address are inconsistent, it may lead to the inability to execute u-boot.

By configuring CONFIG_POSITION_INDEPENDENT, the address-independent feature can be enabled. This option adds the -PIE parameter when linking u-boot. This parameter generates rela* segments in the u-boot ELF file, and u-boot traverses the relative address values in this segment against the actual runtime address values to sequentially fix all addresses that need redirection, allowing for address-independent execution;

Regardless of how the link base address is defined, u-boot can run at any RAM address (generally requiring a minimum of 4K or 64K address alignment);

Note that this feature can only be implemented on SRAM, as it modifies the address in the text and data segments at runtime. If it runs on on-chip flash, it cannot write to flash, causing the feature to fail and not achieve address independence;

“bss” is an abbreviation for block started by symbol, used to store uninitialized global and static variables; they are dynamically allocated at runtime and do not occupy memory in the ELF file.

Ignored section segments.

At runtime, these segments used for parsing and linking information are usually not needed, so they are discarded during linking to reduce program size and save memory;

/DISCARD/ is a special output segment name indicating that the linker should discard matching input segments instead of placing them in any output segment.

This is useful during EFI loading, mainly adding some header information to the binary header of u-boot, including size-endian, data segment, text segment size, etc., for EFI-related loaders to read information. This header information comes from the header information of the Linux arm64 Image; this header is not part of u-boot but is just appended;