2.uboot and System porting-part 5th -2.5.uboot Source Analysis 1-Start the first phase

The first part, Chapter catalogue

2.5.1.start. s INTRODUCTION

2.5.2.start. S parsing 1

2.5.3.start. S parsing 2

2.5.4.start. S parsing 3

2.5.5.start. S parsing 4

2.5.6.start. S parsing 5

2.5.7.start. S parsing 6

2.5.8.start. S parsing 7

2.5.9.uboot Relocation Detailed

2.5.10.start. S parsing 8

2.5.11.start. S parsing 9

2.5.12.start. S parsing 10

2.5.13.start. S parsing 11

Part II, Chapter introduction

2.5.1.start. s INTRODUCTION

This section first finds start by analyzing the link script. s file, and then explains how to use Sourceinsight to find the appropriate file skills.

2.5.2.start. S parsing 1

This section begins analysis of start. s file, which mainly analyzes several header files that are included in the beginning of the file, which includes associating the code with the configuration process described in the previous lesson.

2.5.3.start. S parsing 2

This section mainly analyzes the establishment of the 16-byte check head and the exception vector table uboot from Sd/nand, etc., and some other symbols.

2.5.4.start. S parsing 3

This section describes function codes that set the CPU to SVC32 mode, cache and MMU settings, read Ompin to determine boot media selection after reset.

2.5.5.start. S parsing 4

This section analyzes the Lowlevel_init. The starting part in S, including detection reset status, IO recovery, watchdog off, Development Board power lock, etc.

2.5.6.start. S parsing 5

This section focuses on parsing the code snippet that determines the current running address, which is different from the way it is explained in bare metal. Then a brief analysis of the code snippet of the assembly initialization clock is made.

2.5.7.start. S parsing 6

This section focuses on the code for DDR initialization and serial port initialization in low-level initialization, and tells you how "OK" is printed at startup Uboot.

2.5.8.start. S parsing 7

Summarizes all the work in the Lowlevel_init function and returns start. The second phase of the Uboot is analyzed and the relocation part of S is presented.

2.5.9.uboot Relocation Detailed

This section explains Uboot's relocation code COPY_BL2 function, and the relative illumination of the SD card relocation section in bare metal should be easy to understand.

2.5.10.start. S parsing 8

This section begins by explaining the MMU and virtual address mappings, mainly the basic theory of virtual address mapping, the implementation principle, and the role of the cache.

2.5.11.start. S parsing 9

This section analyzes the process code of the start-up code in the middle of the page table, through simple analysis to learn to look at the page table entries, from which you can see the memory mapping relationship.

2.5.12.start. S parsing 10

This section completes the page table explanation and the summary, clearly lets everybody see the X210 in the virtual address mapping icon, simultaneously ends the MMU related part.

2.5.13.start. S parsing 11

This section describes start. The last part of S, including clearing the BSS section, and finally the code to jump to the second stage of Uboot. This chapter concludes.

The third part, with the Tang record

2.5.1.start. s INTRODUCTION

Find the Start.s entrance in 2.5.1.1 and U-boot.lds

(1) The entry of the entire project in C is the main function (this is the C language), so for example a project with 10,000. c files, the first file to be parsed is the one containing the main function.

(2) in Uboot because of the assembly stage participation, so can not directly find MAIN.C. The entry for the entire program depends on where the entry declaration is in the link script. ENTRY (_start) so the _start symbol is the file that is the beginning of the entire program, the _start is where the code is the start code of the entire program.

How to find files in 2.5.1.2, sourceinsight

(1) Current status: We know that there is a symbol called _start in more than 1000 files in Uboot, but we do not know which file the symbol is in. In this case, to find a reference to a symbol in all the files in the project, use the Sourceinsight search function.

(2) Using SI tools to search for a total of 7 _start, and then analyze the search out of 7, found that 2 are api_example,2 are Onenand related, are not what we are looking for. The rest of the 3 are uboot/cpu/s5pc11x/start. S file.

(3) then enter start. s file, found in 57 lines is the definition of _start label, so we found the entire uboot of the entry code, is the 57th line.

2.5.1.3, si in search of file skills

(1) above, found the start. s file, and we'll start from start. s file begins analysis Uboot first stage.

(2) In Si, if we know the name of the file we are looking for, but we do not know which directory he is in, how do we find and open this file? The method is to open the Project Management section of the right in the SI, then click on the leftmost one (this is to browse by file), then enter the name of the file you are looking for in the input field above. When we input, si is constantly helping us to match, even if you don't remember the full name of the file, but probably remember the name, it will help you find the file you are looking for.

2.5.2.start. S parsing 1

2.5.2.1, non-trivial header file contains

(1) #include <config.h>. Config.h is in the Include directory, this file is not the source of the file itself, but the configuration process automatically generated files. (see Mkconfig script). The content of this file actually contains a header file: #include <configs/x210_sd.h> ".

(2) After analysis, found start. The first header file contained in S is: Include/configs/x210_sd.h, which is the configuration file for the entire uboot migration. There are a lot of macros in it. So this header file contains the associated include/configs/x210_sd.h file and the Start.s file. Therefore after the analysis of the start. s file, the main thing to consider is the X210_sd.h file.

(3) #include <version.h>. The include/version.h contains the include/version_autogenerated.h, which is automatically generated during the configuration process. Inside is a line of content: #define U_boot_version "U-boot 1.3.4". The value of the macro u_boot_version defined here is a string, and the version number information in the string is derived from the configuration value in makefile. This macro in the program will be called, in the Uboot startup process will be the serial port to print out the Uboot version number, that version number information is from this.

(4) #include <asm/proc/domain.h>. The ASM directory is not a native directory in the Uboot, and there is no such directory in Uboot. The ASM directory is a symbolic link created at the time of configuration, and the actual point is asm-arm (when you analyze the Mkconfig script in the previous section).

(5) After analysis, the actual file is: Include/asm-arm/proc-armv/domain.h

(6) From here you can see the role of the symbolic link created in the previous configuration, if there is no such symbolic link is compiled at all, because the header file is not found. (So Uboot cannot configure compilation under Windows shared folders because there are no symbolic links in windows)

Thinking: why start. s does not directly contain asm-arm/proc-armv/domain.h, but uses asm/proc/domain.h. This design is mainly for portability. Because if it is included directly, the start

. s file and CPU architecture (and hardware), portability is poor. For example, I want to transplant the uboot into the MIPS architecture, then start. All header files in the S source code contain all to be modified. After we have used the symbolic link, start. s in the source code does not need to change, only need to be configured in the specific hardware migration, the creation of symbolic links pointing to different, it can be portable.

2.5.3.start. S parsing 2

2.5.3.1, boot code 16-byte header

(1) in bare metal, a 16-byte check head is required at the beginning of the entire image, such as the SD card boot/nand boot. (Mkv210image.c is to calculate this check head). We did not consider this 16-byte check header when we used to do the bare-metal program, because: 1, if we are the USB boot direct download way boot does not need 16 byte check head (Irom application Note); 2 If the SD card is in the boot mkv210image.c the original image is added with a 16-byte check head.

(2) uboot here start. A 16-byte fill placeholder is placed at the beginning of the S, and the 16 byte of the placeholder only guarantees that the official image's header does have 16 bytes, but that the 16-byte content is not correct, or that the checksum needs to be computed and then refilled.

Construction of 2.5.3.2 and anomaly vector table

(1) The Anomaly vector table is the hardware decision, the software is only the reference hardware design to achieve it.

(2) Each anomaly in the exception vector table should be handled, otherwise it would have run away. But we did not deal with all kinds of anomalies very carefully in the uboot.

(3) The code for the reset exception is: b Reset, so the actual code to be executed after the CPU reset is the code at reset, so the reset symbol is where the real meaningful code begins.

2.5.3.3, a deadbeef of meaning

(1). BALIGNL 16,0xdeadbeef. This instruction is to arrange the current address alignment, if the current address is not aligned automatically go back to the address until the alignment, and the back of the memory to be used to fill with 0xdeadbeef.

(2) 0xdeadbeef This is a hexadecimal number, this number is very interesting, the hexadecimal number that makes up this number is all the letters in the ABCDEF, and these 8 letters just make up the English dead beef These two words, literally mean bad beef.

(3) Why to align access? Sometimes it is the requirement of efficiency, sometimes the special requirement of hardware.

2.5.3.4, Text_base, etc.

(1) The 100th line of this text_base is the last course in the analysis of makefile when the configuration phase of the text_base, in fact, we are linked to the specified Uboot link address. (Value is c3e00000)

(2) Many variables in the source code and configuration makefile can be transported to each other. In simple terms, the values of some symbols can be passed from makefile to the source code.

2.5.4.start. S parsing 3

(1) Cfg_phy_uboot_base 33e00000UBOOT Physical Address in DDR

2.5.4.1, setting the CPU to SVC mode

(1) MSRcpsr_c, #0xd3 The CPU is set to prohibit Fiq irq,arm State, Svc mode.

(2) In fact, the ARM CPU is reset to enter the SVC mode by default, but it is also used in the software to set it to SVC mode. The CPU is always in SVC mode when the entire uboot is working.

2.5.4.2, setting up L2, L1cache, and MMU

(1) BLdisable_l2cache//Forbidden L2 Cache

(2) BLset_l2cache_auxctrl_cycle//L2 cache correlation Initialization

(3) BLenable_l2cache//enable L2 cache

(4) Refresh the Icache and Dcache of the L1 cache.

(5) Close the MMU

Summary: The above 5 steps are related to the CPU cache and the MMU, do not have to look closely, probably know.

2.5.4.3, identify and stage boot media selection

(1) Where to start up is determined by the high and low levels of the SOC's om5:om0, which are 6 pins.

(2) In fact, there is a register inside the 210 (address is 0xe0000004), the value in this register is the hardware according to the OM pin settings and automatically set the value. This value reflects the connection of the OM pin (level), which is the true boot media who.

(3) Our code can determine whether the currently selected boot media is NAND or SD or otherwise by reading the value of the register and then judging its value.

(4) Start. After the 225-227 lines of s are executed, a number is stored in the R2 register, which is equal to a specific value when the SD boot is equal to another specific value, which indicates the start from NAND

(5) #boot_mmcsd (0x03) is assigned to R3 in line 260, which is actually executed when the SD is started, so 0x03 is stored in R3 after this piece of code is executed, and later is reserved.

2.5.4.4, set stack (stack in SRAM) and call Lowlevel_init

(1) 284-286 rows for the first time set up the stack. This time the stack is set in SRAM because the current entire code is still running in SRAM, and the DDR is not initialized yet. Stack address 0xd0036000 is its own designation, the principle is to specify that this space is only for the stack, not be occupied by others.

(2) to initialize the stack before calling the function, the main reason is that the function is called again within the called function, and BL only stores the return address in the LR, but we only have one LR, so the second layer before calling the function to put the LR into the stack, otherwise the return address of the first layer when the function is returned is lost.

2.5.5.start. S parsing 4

(1) Using Sourceinsight's reference function, find the Lowlevel_init function real place, is in the uboot/board/samsumg/x210/lowlevel_init. S in.

2.5.5.1, check the reset status

(1) Complex CPU allows multiple reset conditions. such as direct cold power, hot start, sleep (low power) in the wake of the state, and so on, all of which belong to the reset. So we are going to check the reset state in the reset code to determine what the situation is.

(2) The significance of determining which kind of reset is: When the cold power-up DDR is required to initialize the use of, while the hot-start or low-power state of the reset does not need to re-initialize the DDR.

2.5.5.2, IO State recovery

(1) This has nothing to do with the previous and mainline startup code, so you don't have to worry about him.

2.5.5.3, off-guard dog

(1) Refer to the watchdog section in bare metal

2.5.5.4, some SRAM Srom related GPIO settings

(1) Regardless of the mainline startup code, no tube

2.5.5.5, power supply latch

(1) Lowlevel_init. The 第100-104 line of S, the Development Board power latch.

Summary: In the first 100 lines, Lowlevel_init. s does not do much meaningful things (except for the watchdog, Power Lock), and then the following starts with a meaningful operation from 110 lines.

2.5.6.start. S parsing 5

2.5.6.1, judging the current code execution location

(1) Lowlevel_init. 110-115 lines of S.

(2) The purpose of these lines of code is to determine where the current code is executing in SRAM or DDR. Why do you make this decision? The reason 1:BL1 (the former part of Uboot) has a copy in the SRAM, and also in the DDR, so if it is cold start then the current code should be running in SRAM BL1, if the low-power state of the reset should be in the DDR. Cause 2: We determine that the address of the current running code is useful and can guide the operation of the code behind it. For example, in Lowlevel_init. The run address of the current code is determined in S to determine whether to perform clock initialization and initialize the DDR code. If the current code is in SRAM, indicating a cold start, then both the clock and the DDR need to be initialized, and if the current code is in DDR, then the hot start will not have the clock and the DDR initialized again.

(2) Bicr1, PC, R0 The meaning of this code is: some bit in the value of the PC to clear 0, leaving some special bit bits assigned to R1 (R0 1 of those bits 0) equals: R1 = PC & ~ (ff000fff )

LDRR2, _text_base loads the link address to R2, and then the corresponding bits of R2 are 0 left to the special location.

(3) Finally compare R1 and R2.

Summary: This section of code is to determine whether the current run is in SRAM (unequal) or DDR (equal) by reading the current run address and the link address, and then processing the two address after the comparison is equal. This determines whether to skip the following clock and DDR initialization.

2.5.6.2, System_clock_init

(1) Using the SI search function, determine that this function is in the current file of 205 lines, until the No. 385 line. The process of initializing the clock is the same as initializing it in bare metal, but it is more complete and is written in assembly code.

(2) In X210_sd.h 300 rows to 428 lines, are clock-related configuration values. These macro definitions determine how much a 210 of the clock is configured. That means the code is lowlevel_init. S is all written, but the code's settings are defined by the macro in X210_sd.h. Therefore, if you need to change the CPU's clock settings when porting, you do not need to move the code at all, just change the configuration values in X210_sd.h.

2.5.7.start. S parsing 6

2.5.7.1, Mem_ctrl_asm_init

(1) This function is used to initialize the DDR

(2) function position in Uboot/cpu/s5pc11x/s5pc110/cpu_init. S file.

(3) This function is the same as initializing the DDR code in bare metal. Actually the code that initializes the DDR in bare metal is copied from here. Configuration values can also be copied from here, but at that time I myself according to understand + copy the whole out of a copy.

(4) Other configuration values in configuration values refer to the explanation in bare metal to understand that there is a difference between the one and the bare metal. DMC0_MEMCONFIG_0, configured with a value of 0x20e01323 in bare metal, and configured as 0x30f01313 in Uboot. This configuration will result in a different result.

The DMC0 256MB memory address range in bare metal is 0x20000000-0x2fffffff;

The 256MB memory address range for DMC0 in Uboot is 0x30000000-0x3fffffff.

(5) An address that was previously configured to start with 2 in bare metal and did not say that it could be configured to start with 3. From the analysis of the jiuding transplant Uboot can be seen: DMC0 on the allowed address range is 20000000-3fffffff (altogether 512MB), and we actually only connect 256MB physical memory, SOC allows us to give this 256MB pick address range.

(6) Summarize: In Uboot, the available physical address range is: 0X30000000-0X4FFFFFFF. Altogether 512MB, of which 30000000-3FFFFFFF is dmc0,40000000-4fffffff for DMC1.

(7) The memory configuration value we need is between 438 lines and 468 rows in X210_sd.h. When analyzing the conditions of conditional compilation, the configuration header file takes into account the memory configuration values under different clock configurations, the main purpose of which is to allow customers with different clock requirements to find the appropriate memory configuration values.

(8) in Uboot DMC0 and DMC1 all work, so in bare metal as long as the configuration values and configuration code in the Uboot all migrated past, should be able to let DMC0 and DMC1 work.

2.5.7.2, Uart_asm_init

(1) This function is used to initialize the serial port

(2) An ' O ' is sent through the serial port after the initialization is finished.

2.5.7.3, Tzpc_init

(1) Trust zone initialization, no, no matter

2.5.7.4, pop {pc} to return

(1) print ' K ' via serial port before returning

a lowlevel_init of analysis; s executed if that's true then the serial port will print out the word "OK". This should be the earliest output information we saw in the Uboot.

2.5.8.start. S parsing 7

Summary review: Lowlevel_init. What has been done in total in S:

Check reset status, IO Recovery, off watchdog, board power Latch, clock initialization, DDR initialization, serial port initialization and print ' O ', tzpc initialization, print ' K '.

Notable among them: off watchdog, board power Latch, clock initialization, DDR initialization, print "OK"

2.5.8.1, set the stack again (the stack in the DDR)

(1) Develop the board power lock again. First, it is not wrong to do 2 times, and second, to do 2 times is meaningless for the 2nd time; there is a curious and conservative strategy when porting code to try to add code rather than delete it.

(2) before calling the Lowlevel_init program, set 1 times before the stack (start. S 284-287 lines), because the DDR has not been initialized, so the program execution is in SRAM, so the SRAM is allocated a portion of memory as a stack. This time because the DDR has been initialized, so to move the stack into the DDR, so to reset the stack, this is the second time (start. S 297-299 Line); The address of the stack actually set here is 33E00000, just next to the Uboot code snippet.

(3) Why should I set up the stack again? DDR has been initialized, there is already a large amount of memory can be used, there is no need to put the stack in the SRAM of the poor, the original SRAM memory space is limited, the stack is placed there to be careful not to use too many stacks or the stack will overflow, We are also migrating stacks to DDR in a timely manner to avoid the cautious use of stacks whenever possible.

Feeling: The main skill of uboot in the start-up stage lies in the maneuvers under limited conditions in a small range.

2.5.8.2, judge the current address again to determine whether to relocate

(1) again using the same code to determine whether the running address is in SRAM or DDR, but the purpose of this decision is different (last judgment is to decide whether to execute the initialization clock and DDR code) This decision is to determine if the uboot relocate.

(2) The current situation at cold start is uboot (16kb or 8kb) boot automatically from the SD card loaded into the SRAM is running, the second part of Uboot (in fact, the second section is the entire uboot) is also lying in the SD card in the beginning of a sector of n sectors. At this point the first phase of uboot is about to end (the first phase is done), and the second part is loaded into the DDR at the link address (33e00000), and this loading process is called relocation.

2.5.9.uboot Relocation Detailed

(1) D0037488 This memory address is in SRAM, and the value in this address is automatically set by the hardware. Depending on which channel the SD card is in in our actual circuit, the value in this address will be set to the corresponding number. For example, when we start from the SD0 channel, this value is EB000000; When starting from the SD2 channel, this value is EB200000

(2) We are at start. The 260 row of S determines the boot from MMCSD, and then #boot_mmcsd is stored in the INF_REG3 register written to the 278 row. Then again in 322 lines read out, and #boot_mmcsd to compare, OK is starting from MMCSD. Finally jumps to the Mmcsd_boot function to perform the relocation action.

(3) The real relocation is done by calling the Movi_bl2_copy function, in UBOOT/CPU/S5PC11X/MOVI.C. is a C-language function

(4) Copy_bl2 (2, Movi_bl2_pos, movi_bl2_blkcnt,

Cfg_phy_uboot_base, 0);

Analysis parameters: 2 means that the channel 2;movi_bl2_pos is the second part of the Uboot in the SD card in the beginning sector, the sector number must be burned with the same location as the burning Uboot, movi_bl2_blkcnt is the length of the uboot the number of sectors occupied; Cfg_phy_ Uboot_base is the start address (33E00000) that copies the second part of UBOOT to the DDR when relocating.

2.5.10.start. S parsing 8

2.5.10.1, what is virtual address, physical address

(1) The physical address is the address given when the physical device is designed and produced. The address of a register as used in bare metal is the one specified in the CPU design, and this is the physical address. The physical address is hardware-encoded, is the design of the production is OK, once determined can not be changed.

(2) The fact is that the physical address of the register can not be programmed to modify, how much is how much, can only be obtained and manipulated by querying the data sheet. The downside is not being flexible enough. One solution is to use virtual addresses.

(3) The virtual address means adding a layer between our software operations and the hardware being manipulated, called virtual address mapping. With the virtual address mapping, the software operation only needs to give the virtual address, the hardware operation or the original physical address, the mapping layer to establish a virtual address to the physical address of the mapping table. When we run the software, the virtual address used in the software is queried in the mapping table to get the corresponding physical address and then sent to the hardware to execute (the virtual address to the physical address of the mapping is not possible through the software implementation).

The function of 2.5.10.2 and MMU unit

(1) The MMU is the memory management unit, the RAM management cell. The MMU is actually a hardware unit in the SOC, and its main function is to implement the mapping of virtual address to physical address.

(2) The MMU monolithic chip is controlled in the CP15 coprocessor, that is, to manipulate the MMU for virtual address mapping by programming the registers of the CP15 coprocessor.

Additional revenue from 2.5.10.3, address mapping 1: Access control

(1) Access control is: in the management of the memory block, and then each block of independent virtual address mapping, and then in each block of the mapping relationship also implemented access control (The block is readable, writable, read-only, write-only, inaccessible, etc. control)

(2) Recall that there is a common error in programming in the C language: segmentation fault. In fact, this segment error is related to the access control implemented by the MMU. The current program can only manipulate the range of addresses (blocks of memory) that it has permission to manipulate, and if the current program pointer errors access a block of memory that should not be accessed, a segment error is triggered.

Additional benefits of 2.5.10.4, address mapping 2:cache

(1) The work of the cache is related to the virtual address mapping.

(2) Cache is fast caching, meaning slower than CPU but more than a DDR block. The CPU is too slow to DDR, so the content used in some DDR is cached in advance, and the CPU is found in the cache each time it needs to find something. If it is in the cache, it will be used directly in the cache, or if it is not in the cache, look for it in the DDR.

Reference reading: http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=22891521&id=2109284

2.5.11.start. S parsing 9

2.5.11.1, enable domain access (CP15 C3 Register)

(1) CP15 coprocessor internal C0 to C15 a total of 16 registers, each of these registers has its own role. We access these registers through the MRC and MCR directives. The so-called operation of the CP Coprocessor is actually the operation of these registers of CP15.

(2) The role of the C3 Register in the MMU is to control domain access. Domain access is related to the access control of the MMU.

2.5.11.2, setting TTB (CP15 C2 Register)

(1) TTB is the translation table base, which translates the base address. The first thing to understand is TT (translation table), TTB is actually the base address of the conversion table.

(2) The conversion table is the key to establish a set of virtual address mappings. The conversion table is divided into 2 parts, table indexes, and table entries. The table index corresponds to the virtual address, and the table entry corresponds to the physical address. A pair of table indexes and table entries form a conversion table unit that enables virtual address translation of a block of memory. (the basic rules in the map stipulate that memory mapping and management are in blocks, as for how big the block is, depends on your MMU support and your own choice.) Support for 3 block sizes in arm, table 1KB, thick table 4KB, segment 1MB). The real conversion table consists of several conversion table units, each of which is responsible for 1 blocks of memory, and the overall conversion table is responsible for mapping the entire memory space (0-4G).

(3) The main task of establishing virtual address mapping is to build this conversion table

(4) The conversion table is placed in memory, and when placed requires that the starting address be aligned in memory with XX bits. The conversion table does not require the software to interfere with the use, but the base address TTB is set to the CP15 C2 Register, and the MMU will automatically check the conversion table when working.

2.5.11.3, enable MMU unit (CP15 C1 Register)

(1) The bit0 of the CP15 C1 register controls the MMU switch. Just set this bit 1 to open the MMU. After opening the MMU, the address of the upper software layer must be transformed by TT to be sent to the underlying physical layer for execution.

2.5.11.4, find the mapping table to be analyzed

(1) By symbol lookup, determine the conversion table in Lowlevel_init. s file of 593 lines.

2 types of virtual address management for 2.5.11.5 and s5pv210

2.5.12.start. S parsing 10

2.5.12.1, Macro Fl_section_entry

2.5.12.2, page table entries each bit bit meaning

2.5.12.3, paragraph-style page table detailed

2.5.12.4, experimental operation verification

2.5.12.5, Summary: Learning about MMU and virtual address mapping

Macro understanding of conversion tables: the entire conversion table can be thought of as an array of type int, and an element in the array is a table index and a cell of a table item. The element value in the array is the table item, and the array subscript for the element is the table index.

ARM's segment-map length is 1MB, so a mapping unit can only tube 1MB of memory, then we need to 4g/1mb=4096 the entire 4G range of mapping units, That is, the number of elements in this array is 4096. In fact, we did not process the 4,096 units individually, but instead divide the 4,096 into parts, and each part uses the for loop for the same processing.

2.5.13.start. S parsing 11

2.5.13.1, set the stack again

(1) Third set stack. This time the stack is still in the DDR, although it has already been set up once in the DDR, but the purpose of this stack is to place the stack in a more appropriate (secure, compact without wasting memory).

(2) We actually set the stack at 2MB above the Uboot start address, so that the safe stack space is: 2mb-uboot size -0x1000=1.8mb around. This space is neither too wasteful of memory nor secure enough.

2.5.13.2, clearing BSS

(1) Clearing the BSS code is the same as in bare metal. Note that the symbol representing the beginning and end addresses of the BSS segment is derived from the link script u-boot.lds.

2.5.13.3, Ldrpc, _start_armboot

(1) Start_armboot is a uboot/lib_arm/board.c, this is a C language implementation of the function. This function is the second phase of Uboot. The function of this code is to pass the address of the function of the second stage of Uboot to the PC, which is actually using a far jump to jump directly to the second stage start address in the DDR.

(2) The meaning of the far jump is that the address loaded is irrelevant to the current run address, and to the link address. So this far jump can be achieved by jumping from the first phase of SRAM to the second stage in the DDR.

(3) This far jump is the dividing line between the first and second stages of uboot.

2.5.13.4, Summary: What is the first stage of Uboot's work?

(1) Constructing the anomaly vector table

(2) Setting the CPU to SVC mode

(3) Off-guard dog

(4) Development Board supply lock

(5) Clock initialization

(6) DDR initialization

(7) Serial port initialization and printing "OK"

(8) Reposition

(9) Create a mapping table and open the MMU

(10) Jump to the second stage

2.uboot and System porting-part 5th -2.5.uboot Source Analysis 1-Start the first phase