Shulou(Shulou.com)05/31 Report--

Editor to share with you how to achieve Cortex-A9 uboot startup code, I hope you will learn something after reading this article, let's discuss it together!

1. Uboot

1. Concept

U-Boot is a boot loader mainly used in embedded systems, which can support a variety of different computer system architectures, including PPC, ARM, AVR32, MIPS, x86, 68k, Nios and MicroBlaze. This is also a set of free software released under the GNU General Public license.

U-Boot not only supports the boot of embedded Linux system, but also supports NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS, android embedded operating system. The target operating systems to be supported are OpenBSD, NetBSD, FreeBSD,4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, ARTOS, android.

2. Basic functions of uboot

List of main features supported by U-Boot:

System boot supports NFS mount, RAMDISK (compressed or uncompressed) root file system, and NFS mount, boot compressed or uncompressed system kernel from FLASH

The basic auxiliary function is powerful operating system interface function; it can flexibly set and transfer several key parameters to the operating system, which is suitable for the debugging requirements and product release of the system at different development stages, especially Linux support; supports multiple storage modes of target board environment parameters, such as FLASH, NVRAM, EEPROM.

CRC32 check verifies whether the kernel and RAMDISK image files in FLASH are intact.

Device driver serial port, SDRAM, FLASH, Ethernet, LCD, NVRAM, EEPROM, keyboard, USB, PCMCIA, PCI, RTC and other driver support

Power-on self-test function SDRAM, FLASH size automatic detection; SDRAM fault detection; CPU model.

3. Common command

There are many uboot commands. Here are only the commands to be used to start the network:

4. Examples of configuration parameters

The following is an example of downloading the kernel and mounting nfs on the network.

1) ubuntu environment

Ubuntu ip:192.168.6.186

Nfs configuration:

The configuration file is as follows:

/ etc/exports

The configuration information is as follows:

Nfs

2) Development board settings

Development board ip:192.168.6.187

Configuration commands:

Setenv ipaddr 192.168.6.187; board ip setenv serverip 192.168.6.186; virtual machine ip setenv gatewayip 192.168.1.1; gateway saveenv; save configuration

Load kernel and device tree

Setenv bootcmd tftp 41000000 uImage\; tftp 42000000 exynos4412-fs4412.dtb\; bootm 41000000-42000000

After bootcmd:uboot2 starts, first execute to find this parameter, and then execute the following command.

Download the kernel image uImage from the tftp server to address 41000000, the device tree file exynos4412-fs4412.dtb to 42000000, and start the kernel with the command bootm.

Mount nfs

Setenv bootargs root=/dev/nfs nfsroot=192.168.6.186:/rootfs rw console=ttySAC2,115200 init=/linuxrc ip=192.168.6.187

Mount the nfs file system

Root=/dev/nfs

Nfsroot=192.168.6.186:/rootfs nfs server address 192.168.6.186, directory / rootfs

The operation permission of rw file system is continuous.

Console=ttySAC2,115200 serial port name and baud rate

The process that runs after the init=/linuxrc kernel starts is linuxrc

Ip=192.168.6.187 development board address

Second, exynos-4412 Soc startup sequence

To understand the boot sequence of an exynos-4412, we first need to understand the memory layout of the soc.

1. Exynos-4412 memory layout

Usually, the memory of a soc is already dead when it is designed by the manufacturer, and for users, we cannot change it.

We only care about one address related to the startup.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

IROM is inside soc, and the manufacturer solidifies the specific program when it leaves the factory. The program in iROM is immutable to the user.

IRAM is inside soc, so it's fast, but it doesn't have much space.

DMC RAM controller, located inside SOC, is used to drive RAM. Large capacity RAM needs to be connected to this controller.

2. Booting Sequence

The startup sequence of different manufacturers is not the same. This article is mainly based on Samsung's exynos-4412 soc to explain the uboot startup sequence based on the board.

According to the figure above, the approximate sequence in which the system starts:

IROM, inside SOC, is a ROM of 64KB, and he trees and pools some of the functions necessary for system startup. For example: clock, stack.

IROM is responsible for loading the image of BL1 from a special boot peripheral into the SRAM of 256KB inside soc. The starting peripherals are determined by the operation button. Depending on the value of the keystroke, iROM will check the image of bl1 differently.

BL1 initializes the system clock and DRAM controller, and then loads OS image into DRAM from the boot peripheral. BL1 does different checks on OS depending on the value of the launch button.

After the boot is complete, BL1 jumps to the operating system (kernel).

IROM will choose different boot devices according to different OM pins, and the corresponding OM registers need to provide the corresponding boot information.

III. Overview of kernel startup process

1. Overview of kernel startup process

Uboot startup process

As shown in the above figure:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

After the device is powered on, execute the factory code in iROM first, and initialize the necessary hardware to execute uboot

Usually put kernel and device tree files into flash

After the program starts, it usually starts from flash and runs uboot.

Step 1: initialize the hardware (svc mode stack, clock, memory, serial port) step 2: move the uboot from flash to RAM, jump to RAM to execute the rest of the uboot code

Step 3: copy the kernel into RAM, execute the kernel, and give control to the kernel.

two。 Detailed process of kernel startup

The process of the development board from powering up to booting the kernel

4. Detailed explanation of uboot startup process code

1. Lds file

To understand the code flow of the entire uboot project, you must first understand the link script [Link script reference "7. Learn the ARM-GNU directive from 0, and lds uses "].

This file determines the final image file generated by uboot and the layout of each segment.

The uboot link script is as follows:

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

Contents of the file:

26 OUTPUT_FORMAT ("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") 27 OUTPUT_ARCH (arm) 28 ENTRY (_ start) 29 SECTIONS 30 {31. = 0x00000000; 32 33. = ALIGN (4); 34.text: 35 {36 _ image_copy_start =.; 37 CPUDIR/start.o (.text *) 38 * (.text *) 39} 40 41. = ALIGN (4); 42. Rodata: {* (SORT_BY_ALIGNMENT (SORT_BY_NAME (.rodata *)} 43 44. = ALIGN (4); 45. Data: {46 * (.data *) 47} 48 49. = ALIGN (4); 50 51. = 52 53. = ALIGN (4); 54. U _ boot_list: {55 # include 56} 57 58. = ALIGN (4); 59 60 _ image_copy_end =.; 61 62. Rel.dyn: {63 _ rel_dyn_start =.; 64 * (.rel *) 65 _ rel_dyn_end =.; 66} 67 68. Dynsym: {69 _ dynsym_start =. 70 * (.dynsym) 71} 72 73 _ end =.; 74 75 / * 76 * Deprecated: this MMU section is used by pxa at present but 77 * should not be used by new boards/CPUs. 78 * / 79. = ALIGN (4096); 80.mmutable: {81 * (.mmutable) 82} 83 84.BSS _ rel_dyn_start (OVERLAY): {85 _ bss_start =.; 86 * (.bss *) 87. = ALIGN (4); 88 _ bss_end__ =. 89} 90 91 / DISCARD/: {* (.dynstr *)} 92 / DISCARD/: {* (.dynamic *)} 93 / DISCARD/: {* (.plt *)} 94 / DISCARD/: {* (.interp *)} 95 / DISCARD/: {* (.gnu *)} 96} 97

Explanation of the core content:

27 OUTPUT_ARCH (arm): this image runs on the hardware of arm architecture 28 ENTRY (_ start): the entry of the program is _ start 29 SECTIONS 30 {31. = 0x0000000000;: the link address of the program, not the running address [uboot must be a location independent code] 34. Text: 35 {36 _ image_copy_start =. The macro corresponds to the compiled first address of the whole program, and moves the initial location of the code 37 CPUDIR/start.o (.text *): the code snippet 38 * (.text *) in the first object file CPUDIR/start.o: the remaining code snippet 39} 60 _ _ image_copy_end =.;: since the end of the moving code

BSS the segment where the globally uninitialized variable and the globally initialized variable are located:

84. BSS _ rel_dyn_start (OVERLAY): {85 _ bss_start =.; 88 _ bss_end__ =.; 89}

2. Summary of uboot startup code flow

The code only parses to the uboot command line, where the function main_loop () is located.

3. Detailed analysis of startup code

The _ start entry is located in the following file:

U-boot-2013.01/arch/arm/cpu/armv7/start.S

The first stage:

The second stage

The second phase code starts with _ main:

The above code is explained in detail, please learn synchronously with bilibili video.

5. Several key knowledge points of uboot startup

1. How to determine the position of the first machine instruction?

The link script determines the layout of memory.

The uboot link script is as follows:

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

Contents of the file:

28 ENTRY (_ start) 29 SECTIONS 30 {31. = 0x0000000000; 32

The entry to uboot is _ start

The link address is 0x00000000

How does 2.uboot move the code?

The code is located at:

U-boot-2013.01/arch/arm/cpu/armv7/start.S

The relocation code is as follows:

ENTRY (relocate_code) mov R4, R0 / * save addr_sp * / mov R5, R1 / * save addr of gd * / mov R6, R2 / * save addr of destination * / adr R0, _ start cmp R0, R6 moveq R9, # 0 / * no relocation. Relocation offset (R9) = 0 * / beq relocate_done / * skip relocation * / mov R1, R6 / * R1

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.