The uboot is divided into two stages: start. S is the first stage of Uboot.
One: Introduction of start. S
U-boot.s found the entrance to Start.s.
① first in the C language, the entry of the entire project is the main function (this is the C language provisions), so if you want to understand the C language of the project, starting from the main function, so as to analyze, if you take a file to start to see, and finally see confused, have no confidence in themselves. How to find it? You can use the search function of Souceinsight to find.
② 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 connection script. ENTRY (_start) so the _start symbol is the entry for the entire program, and the code where the _start is located is the starting code for the entire program.
II: Analysis of start. S
1. Header file contains
①#include <config.h> config.h is in the include file, this file is not the source file, is configured automatically generated files. See the Mkconfig script at the end of the Mkcofig script
Contains an # include <configs/x210_sd.h>
Finally, the analysis found that the final inclusion is/include/configs/x210_sd.h, this file is the entire uboot migration configuration file, there are many macros. This associates the two files together. So analyze start. s, consider configs/x210_sd.h.
②#include <version.h>
/include/version.h contains "Version_autogenerated.h" This header file is generated automatically at compile time, which defines the macro define U_boot_version " U-boot1.3.4joran "The configuration value from the makefile. This macro in our program will be called, in our Uboot startup process, the serial port to print out the Uboot version number, the version number information from here.
③#if defined (CONFIG_ENABLE_MMU)
#include <asm/proc/domain.h>
#endif
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). After analysis, the actual file is: include/asm-arm/proc-armv/ Domain.h From here you can see the role of symbolic links created in the previous configuration, and if these symbolic links are not available, compile at all, because you cannot find the header file. (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 to use Asm/proc/domain.h? This design is mainly for portability. Because if it is directly contained, 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.
④ boot code 16-byte header
Read from code: If CONFIG_EVT1 is defined and no config_fused is defined, then 4 4-byte spaces are defined. From the Sourceinsight section you can see that the red is already defined, black is undefined, so the condition is satisfied, defines 16 bytes of space, and fills up.
The bare metal says, From the SD card and NAND boot is required 16-byte check Head (mkv210image.c is to calculate this check head), before doing bare metal experiment, DNW download method does not need to check the head, do SD card boot, MKV210IMAGE.C will give the original image 210.bin plus 16 byte check head.
Uboot, here's 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 head does have 16 bytes, but this 16-byte content is not correct, and it needs to be computed and then re-populated with a sd_ in the back of the uboot. Fusing folder c110-evt1-mkbl1.c This file is almost our previous mkv210image.c.
In c110-evt1-mkbl1.c:
Here and star. s are interconnected.
Construction of ⑤ anomaly vector table
This exception table order is determined by the CPU design and is determined by the hardware. These exceptions should be handled, and if these exceptions are not handled, the program will run.
Reset exception Handling: The code to reset the exception is b reset, so a valid code that is actually executed after the CPU reset is the code at reset, so the reset symbol is where the actual meaningful code begins.
⑥ interesting deadbeef.
. BALIGNL 16,0xdeadbeef. BALIGNL 16 is in 16 byte alignment, if not aligned, with 0xdeadbeef this number to fill, this fill has no special meaning, just happen to compose an interesting English word----bad beef
Why align? Sometimes it is to improve access efficiency, sometimes hardware requirements.
⑦text_base, etc.
The 100th line of text_base in the entire code is referenced, it is in the makefile configuration stage when the text_base, in fact, we link, the specified program's link address, its value is c3e00000, Many of the variables in the source code and the configured makefile are interrelated, and the values of some symbols can be passed from makefile to the source code, and some symbols
Uboot start the first stage of--start. S