The first part
2.3.1uboot Configuration Compilation Practice
1) Source source code when Uboot official website to download. The source code for this download may not be ported to the Development Board you are currently using, and you cannot even find a ported version of the SOC that is used by the current Development Board.
2) after the SOC manufacturer exits a SOC, the manufacturer's engineers will go to Uboot's website to download a uboot, the first step on their own SOC transplant, the target of the porting is the Development Board of the manufacturer. (for example, the Development Board of Samsung's s5pv210 chip makers is called SMDKV210), so Samsung's engineers transplanted the uboot based on their own SMDKV210 Development Board.
3) Specific Development Board providers (such as X210 's manufacturer Shenzhen jiuding technology) First buy the Samsung SMDKV210 Development Board, then crop it (cut out some useless interface functions, configure it down, and some configurations will be replaced). The new development boards generated after hardware replacement and cropping are different from those of Samsung's official SMDKV210, so the uboot is not the same, but because the SOC is the same, all similarities are at least 60%, All specific Development Board vendors will be ported to a uboot transplant of their own Development board, modelled on the Uboot transplanted in Samsung SMDK210. We bought X210 Development Board when the manufacturer CD-ROM with the BSP in the Uboot source code is he transplanted.
1. tq210 the BSP of the Uboot Development Board disc that was ported. BSP is the Board support Packages (Board-level supporting package, generally provided by the Development Board vendor), the content of which is the Development Board of all relevant source code, documentation, tutorials and so on.
2. Take the entire BSP package file to the Linux native directory for decompression analysis, do not unzip the open in the shared folder in Windows.
3. We maintain a uboot under Linux, under Windows also maintain a copy of Uboot, before we start any work, these two copies of Uboot content, are embedded in the official Uboot content, we do the purpose; compile in Linux, Code analysis and viewing under Windows. (Windows has sourceinsight and other good tools to help us look at the code, edit the code, compile and look at the code under Linux is very cumbersome.) ）
4. Configuration uboot and Linux kernel and other complex projects can not be compiled directly, you must first configure, and then compile. Uboot also first configuration, method: first CD into the root directory of the source, configuration, uboot support a lot of development boards, but the compiled image can only be used on a certain development Board, all need to be configured. The general configuration file searches the makefile for the name of the Development Board. Execute the Make tq210_config configuration command under the root directory. The configuring for TQ210 board is generally present .... Next is to compile, be sure to check ARM-LINUX-GCC right, check in two steps, 1. Check that there are no appropriate ARM-LINUX-GCC installed in the current compilation environment. 2. Check that the compiler is set correctly in the makefile of the current directory (uboot root directory). The path and name of the cross-compilation tool chain will be set in the total makefile of the project, and it must be ensured that the path and name are identical to our own, otherwise it will compile in error. Make sure the above 2 points can be compiled, compiled very simple, directly made, or MAKE-J4
1. Uboot's Source directory analysis 1
Sky Inlay official Uboot and Samsung original Uboot contrast, with the sky inlay official as the blueprint to learn, with Samsung official this copy as the control. Different versions of Uboot or the same version of the uboot that are migrated by different people may have different directory structure and file content. In the future, you can add, change, delete uboot after you know it. Embedded in Samsung's uboot for the raw material for the transplant, the Samsung version of the Uboot in a lot of unnecessary folders, files were deleted. The deletion of a lot of the unused.
2. Introduction of various documents:
1.. gitignore git tool files, git is a version management tool. (There is a similar SVN), this file is related to Git, and uboot itself regardless of, do not have to tube.
2. The arm_config.mk suffix is. MK, which is a makefile file that will be called in a makefile in the future.
3. Three changelog files, modify the record file, which records the version change of this uboot project and the revision of each version over the previous version. These records are available for all formal projects. Mainly for the maintenance of Uboot engineers.
4. Config.mk and arm_config.mk of similar nature
5. COPYING. Copyright notice, Uboot itself is a GPL license.
6. CREDITS. Acknowledgement. It records people who have contributed to Uboot.
7. Image_split. A script, see the description is used to split uboot.bin to BL1, temporarily use not, first regardless.
8. Maintainers maintainer, is currently involved in the maintenance of Uboot source code community workers.
9. Makeall. A script that should be helpful for compiling uboot.
Makefile. This is very important, is the Uboot source code of the main Makefile, in the future the entire uboot is compiled with this Makefile management compiled, so we will study in the next lesson uboot configuration compilation process to analyze this Makefile.
Mkconfig This is important and is the primary configuration script for the Uboot configuration phase. The portability of uboot is largely maintained by this configuration script. We will examine this configuration script in the next lesson in the Uboot configuration compilation process.
Mkmovi. A script, related to Inand, SD card boot.
Readme. All the software has Reandme, generally get a thing read the Readme first, this thing is a simple instruction.
Rules.mk This file is our Uboot makefile use of the rules, itself very important, but we do not analyze, not to see
Above these files. For us more important, need to look carefully at the 2, Mkconfig and makefile. A configuration responsible for uboot, one responsible for compiling. Need to be explained in detail.
Uboot Source Directory Analysis:
1. API: The api.uboot of the hardware-independent function function is basically free of the tube, these functions are used by uboot itself.
2. Api_examples:api the relevant test instance code.
3. Board:board is the board meaning, Board is the Development Board, Board folder each file represents a development board. The file below this folder is used to describe the information of this Development Board. The number of folders in the Board directory indicates how many boards the current uboot has been ported to (how many boards the current uboot supports). Question one; Think about how Uboot supports multiple boards, and how portability is possible. Question two: board under so many folders, exactly how to determine the specific use of which one? Uboot in the configuration phase there are some ways to help us determine which folder is used in the Board directory. Problem three: More and more Development boards, board directory More and more folders, inconvenient to control. Thus Uboot added a mechanism, you can not directly put the Development Board directory in the Board directory, but in the board decentralized manufacturers directory (vendor directory, the specific chip manufacturer name), and then the IC manufacturers of all the chip development boards are dropped to this vendor directory. So you will find our TQ210 corresponding to the Development Board directory in/board/samsung/embedsky/ TQ210. This level of the directory will affect the configuration phase, in the configuration phase of the Uboot to be aware of the path depth and the actual storage to correspond, or the configuration after the compilation can not find the file compilation will fail. Note that one detail is the problem of compatibility caused by historical reasons. The first Board directory is the Development Board name, and later changed to the name of the manufacturer. But because of the forward compatibility, the same manufacturer originally outside the Development Board has not been diverted to the name of the manufacturer.
Note: It is important to emphasize that the Uboot configuration phase (which is actually the Mkconfig script under the root directory and the configuration section in makefile) is the main problem in the area of portability that can help us determine the specific folder path, and then compile the files that should be found. To compile successfully. Therefore, the differences in the board directory can cause different configurations. If the transplant doesn't pay attention here, it will certainly fail.
4. Common:common is common in general. This folder is decentralized with some code that is not specific to the normal use of hardware. For example, the console implementation, CRC check. But more are mainly two kinds: one is the beginning of the CMD, is used to implement the Uboot command system, and the other is the Env start, is used to implement the environment variables.
5. Cpu: This directory is SOC-related, the code is stored in the SOC related initialization and control code (such as CPU, interrupt, serial and other SOC internal peripherals, including start code start. S is also in the inside. There are many subfolders, each of which is a SOC family. This folder is strictly hardware-related, so always be aware of it. But because this folder is SOC-related. Our own development Board and Samsung's Development Board although the board design is different but the SOC is the same, generally do not need to change.
6. Disk. Disk-related, no research, no use.
7. Doc. The document directory, which contains a lot of uboot related documents that can help us understand the Uboot code. But pure English
8. Drivers. As the name implies, the driver, which is put in the Linux source code is deducted from the intact Linux device driver, the main development Board must use some of the drivers, such as network card driver, INAND/SD card NAND flash driver. You know: The driver in Uboot is actually the driver in Linux, uboot to a certain extent, porting the Linux driver to its own use. But Linux is an operating system and Uboot is a bare-metal program, so this porting will be different, let me say, the driver in Uboot is actually part of the Linux driver.
9. Example: Instance code. No use.
Fs: File system 0 filesystem. This is also ported from the Linux source code. Used to manage resources such as Flash
Include: Header file directory, uboot and Linux kernel in the management of the header file is the same idea, is to put all the header files in the Include directory, rather than the header file corresponding to the C file. All of the header files in Uboot are included when the path structure is to be found here.
Lib_ Some of the library files (typical lib_arm and lib_generic) that are associated with the schema. Lib_arm, for example, is a library file used by the ARM architecture. Lib_generic The library files that are common to all schemas. The content in such folders is basically free from the tube when porting.
Libfdt. Related to the device tree. The Linux kernel changed the mechanism of initiating the parameters in the 3.4 or so versions, and then used the device tree to start the parameters, and described the hardware information.
NAND_SPL Nand related.
. Net. Network-related. For example, the TFTP NFS ping command in Uboot is implemented here.
Beginning with Onenand. is the Onenand related code, is Samsung Plus. Not in the standard uboot.
. Post. Never paid attention.
Sd_fusing. This code implements the code to burn the uboot image to the SD card. The following should be studied carefully.
Tools: There are some tool class codes. such as Mkimage.
Summary: will be used to the board common CPU drivers include Lib_arm sd_fusing lib_generic
Part IV: uboot Main MAKEFILE Analysis 1
1.1 Uboot VERSION OK (Makefile 24-29 lines) u_boot_version "1.3.4xyz"
1) The Uboot version number is divided into 4 levels:
VERSION: Motherboard number
Patchlevel: Minor version number
Sublevel: Version number again
Extraversion: Additional version information
These 4 uses. Separating together constitutes the final version number.
2) The Makefile version number eventually generates a variable u_boot_version, which records the version number configured in Makefile. The Include/version_autogenerated.h file is a file that is automatically generated during compilation and is not available in all source directories, but it is in the compiled uboot. The content inside it is a macro definition, and the value defined by the macro is the Uboot version number we configured in makefile.
3) Verification Method: Modify the main makefile several version related variables, and then compile Uboot, and then burn to the SD card, boot from the SD card, and then go to the start Uboot print out the version information to see if the change is consistent with their analysis.
2.1 Hostarch and Hostos
1. Executing uname-m directly in the shell gets i686, and the resulting value is actually the version number of the CPU of the computer you are currently executing this command.
2. In the shell | Called pipeline, the function of the pipeline is to put the output of an expression in front of the pipeline as a subsequent input to do the processing, the final output is our entire output of the formula.
3. Hostarch This name: Host, is currently in the development of this computer is called the host; Arch is Architecture (architecture), which represents the architecture of the CPU, all hostarch on the host CPU. These two environment variables are the host's operating system and the CPU architecture of the host, which is then saved and used later.
2.3 Silent Compilation Issues: (50-54)
1. Usually the default compile-time command line print out a lot of compilation information, but sometimes we do not want to see these compilation information, the background compiled can. This is the silent compilation. The use of the method is compile-time make-s,-s will be passed as makeflags to makefile, in the 50-54 line of code under the action of the Xecho variable will be turned empty. This enables silent compilation.
2.4 2 compilation methods (in-place compilation and individual output folder compilation)
Ifdef O
Ifeq ("$ (Origin O)", "Command line")
Build_dir: = $ (O)
endif
endif
Ifneq ($ (build_dir),)
Saved-output: = $ (Build_dir)
# Attempt to create a output directory.
$ (shell [-D ${build_dir}] | | mkdir-p ${build_dir})
# Verify if it was successful.
Build_dir: = $ (Shell CD $ (build_dir) &&/bin/pwd)
$ (if $ (build_dir), $ (Error output Directory "$ (saved-output)" does not exist))
endif # IFNEQ ($ (build_dir),)
Objtree: = $ (if $ (build_dir), $ (Build_dir), $ (CURDIR))
Srctree: = $ (CURDIR)
Topdir: = $ (Srctree)
Lndir: = $ (Objtree)
Export Topdir Srctree Objtree
1. Compiling complex projects, Makefile provides a 2 compilation management method. By default, the. c file is in the current folder, and the compiled. o file is placed in the same folder, which is called in-place compilation. The advantage of in-place compilation is that it is easy to handle. There are some drawbacks to compiling in-place: first, contaminating the source file directory. The second flaw is that a set of source code can only be processed in accordance with one configuration and compilation method, and cannot maintain 2 or more 2 configuration compilation methods at the same time.
2. In order to solve the above 2 defects, Uboot supports the compilation of separate output folders (Linux kernel also support), and uboot This technology is learned from the Linux kernel. The basic idea is to specify a different output directory at compile time, and all future compilations will be generated. o files or other generated files are all dropped to that output directory. The source code directory does not make any pollution, so the output directory will host all the results of this configuration compilation. Specific usage: The default is to compile in situ, if you need to specify a specific output directory compilation There are 2 ways to specify the output directory: (56-76 comments)
1) Make o= output directory
2) The second type: Export build_dir= output directory and then make
If two are specified, (both Build_dir environment variables exist and O=XX), the O=XX priority is high.
Two compiled implementation codes in makefile 78-123
2.4 Objtree Srctree Topdir
Objtree: The root directory where the compiled. o files are stored. Under the default compilation, Objtree equals the current directory, and under O=xx compilation, Objtree is equal to the output directory we set.
Srctree: Source directory, in fact, is the root directory, that is, the current directory. Summary: Under Default compilation, Objtree and Srctree are equal. Objtree and Srctree are not equal under O=XX compilation. These two variables are defined in makefile in order to record where to put the file after compilation. is to implement this kind of compiling method of o=xx. Mkconfig a variable defined in makefile, defined here, and used later, its value is the mkconfig in the root of our source code, which is a configuration script. This script is the configuration script for the Uboot configuration phase. You will need to use at least 3 lessons to explain this configuration script in detail at a later period.
Mkconfig: = $ (Srctree)/mkconfig (Makefile 101)
Export Mkconfig
2.4.3.3 include $ (obj) include/config.mk (133 lines)
(1) Include/config.mk is not the source code, (you do not have compiled source directory is not found in this file), in the configuration process (make Tq210_config) to generate this file. Therefore, the value of this file is related to our configuration process and is automatically generated by the configuration process according to our configuration.
(2) We TQ210 configure the generated config.mk content in Inand case:
ARCH = Arm
CPU = s5pv210
BOARD = TQ210
VENDOR = Embedsky
SOC = s5pv210
(3) Our next line is (134) export exports these 5 variables as environment variables. So the two lines add up to actually define 5 environment variables for the current makefile. These 5 environment variables are not given directly because we want these 5 values to be easily and centrally configured.
(4) Here the configuration value comes from 2596 lines where the configuration item. If we want to change one of the configuration values here to 2596 rows call the parameters of the Mkconfig script when the parameter is passed.
(5) ARCH Cross_compile
Next, there are 2 important environment variables. One is arch, the above export, the value from our configuration process, its value will affect the value of the following Cross_compile environment variable, the meaning of Arch defines the current compiled target CPU architecture. Cross_compile is the prefix that defines the cross-compilation tool. These prefixes are defined to be used later (using prefixes with suffixes to define tools in the various tool chains used in the compilation process). The reason we separate the prefix from the suffix is that the cross-compilation tool chain on different CPU architectures is just the same as the prefixes, and the suffixes are the same. As a result, the prefix and suffix are separated by definition, and porting can be achieved only when the prefixes are defined in different schemas. Cross_compile is defined in 136-142. Cross_compile is determined by arch, as long as the configuration of arch=arm, then we can only in the arm of the branch to set the value of Cross_compile. This setting value can only be guaranteed if the cross-compiler tool chain is found, not necessarily the full path, but also the relative path. (If you've already exported the toolchain to an environment variable and you've set up a symbolic link, that's cross_compile=arm-linux-). When actually running, we can change the value of setting cross_compile in Makefile, or make cross_compile=xxx at compile time, and the method of compiling Shishun can override the settings in makefile.
2.4.4 include $ (topdir)/CONFIG.MK 189 lines
1. Definition of the Compilation tool: Config.mk 97–107
2. Include the Development Board configuration item (config.mk,112 line)
The autoconfig.mk file is not provided by the source and is automatically generated by the configuration process. The purpose of this file is to guide the entire Uboot compilation process, which is actually a lot of config_ at the beginning of the macro. (Can be understood as a variable). These macros or variables can affect the direction of our Uboot compilation process (the principle is conditional compilation). There are many places in the Uboot code that are written using conditional compilation, which is used for portability. (It can be said that the source code of Uboot to a large extent is pieced together, the same code contains a variety of different development boards of the applicable code, using conditional compilation to distinguish).
This file is not produced in thin air, the configuration process is also required raw materials to produce this file, raw materials in the source directory is: include/configs/xxxx.h header file. (x210 in the Development Board for Include/configs/tq210.h). This h header is full of macro definitions, which are the porting of our current development Board. The porting of each Development board corresponds to a header file in this directory, which is important for each macro definition in the header file, and the macro definition of these configurations is the key to our porting of uboot.
2.4.5.1 linker script (CONFIG.MK) 144-147
1. If the Config_nand_u_boot macro is defined, the linker script is called U-boot-nand.lds, and if this macro is not defined, the linker script is called U-boot.lds.
2. From the literal meaning analysis, you can know: Config_nand_u_boot is in NAND
Version is used, we use TQ210 is the Inand version, so this macro does not.
2. Actually in Board\embedsky\tq210\u-boot.lds, this is the linker script. We will consider this link script when we analyze the Uboot compilation connection process.
2.4.5.2 Text_base (CONFIG.MK)
When configuring the TQ210 Development Board in 1.Makefile, a file is generated in the Board\embedsky\tq210\ directory config.mk the contents of which are: Text_base = 0xc3e00000.
2.text_base is the link address that we specify when we complete the uboot link in the future. Because virtual address mapping is enabled in Uboot, this c3e00000 address is equal to 0x23e00000 (and possibly 33e00000 specific addresses depending on the virtual address mappings made in uboot).
3. Review the issue of the link address in bare metal, and then think about the DNW way to download Tq210_usb.bin first, and then download Uboot.bin when the second address is 23E0000.
2.4.5.3. Automatic derivation rules (Config.mk 239-256)
We are talking about Makefile is mentioned automatic derivation rules, specific understanding can refer to (with me to learn makefile).
Uboot Main Makefile Analysis:
1.291 rows appear the first target all in the entire main makefile (that is, the default target, we are in the Uboot root directory make is actually equal to make all, is equal to make this goal)
2. There are some of the more important objectives. For example: U-boot is an elf-formatted executable file that is eventually compiled with link generation.
3.unconfig literal meaning to understand is not configured. This symbol is used to make a dependency on each of our Development Board configuration targets. The goal is to configure when we have configured a development board and then go back to configuring it.
4. When we configure the Development Board, make tq210_config, so the analysis of Tq210_config is definitely a goal in the main makefile.
2.4.7 uboot Configuration Process detailed 1
1. The 6 parameters of the Mkconfig script. Tq210_config:unconfig
$ (mkconfig) $ (@:_config=) arm s5pv210 TQ210 Embedsky s5pv210
Tq210_config inside the _config part with empty replacement, get: TQ210, this is the first parameter, so:
$1:tq210
$2:arm
$3:s5pv210
$4:tq210
$5:embedsky
$6:s5pv210
So $# = 6
3. The 23rd line, in fact, is to see if the Board_name variable has a value, no assignment. Result board_name=tq210
4. Line 25th, if $ #小于4, exit 1 (The Mkconfig script returns 1).
5. Line 26th, if $ #大于6, exit 1
So: Mkconfig script can only be 4,5,6. Other values are not available.
Linux Symbolic Link: ends with 33-118 lines. These symbolic links are the core of the configuration, and the main purpose of these symbolic link files (folders) is to provide a directional connection to the process of including the header files. The fundamental goal is to make uboot portable.
Uboot Portability Implementation principle: In the Uboot many parallel code, each belongs to their own different architecture/cpu/Development Board, we are specific to a development Board at compile time with a symbolic link to provide a specific name of the folder for compilation use. This allows you to correctly include the correct files by using different files with different configurations during the configuration process.
(6) Create a symbolic Link:
First: Create an ASM file in the Include directory, point to Asm-arm (46-48 lines)
The second: Create an arch file under Include/asm-arm, point to include/asm-arm/arch-s5pv210
Third: Create a regs.h file under the Include directory, point to Include/s5pv210.h
Delete the second one.
Fourth one: Create an arch file under Include/asm-arm, point to include/asm-arm/arch-s5pv210
Fifth one: Create a proc file under Include/asm-arm, point to Include/asm-arm/proc-arm
Summary: Altogether 4 symbolic links have been created. These 4 symbolic links are very useful in the future of writing code during the header file. For example, a header file may contain: #include <asm/xx.h>
2.4.8 uboot Configuration details the second part:
(1) Create a include/config.mk file (mkconfig file 12-129)
(2) The Include/config.mk file was created so that the main makefile on line 133th
Thinking: The Uboot configuration and the compilation process. Compiling requires these variables such as Arch=arm cpu=xx to guide the compilation, and the configuration is to provide these variables for the compile phase. So why not define these variables directly in makefile, and create config.mk files in the Mkconfig script, and then include them in makefile?
To understand these scripts, you need to be aware of your path.
(5) Create (default)/append (append at make-a) include/config.h file (134-141 of mkconfig file)
(6) The contents of this file is a line of # include <configs/TQ210.h> this header file when we ported the TQ210 Development Board, the macro definition of the Development Board configuration file, this file is the main file we transplanted TQ210.
(7) TQ210.h file will be used to generate a autoconfig.mk file, this file will be introduced by the main makefile, guide the entire compilation process, which will affect our uboot in most of the. c files in the selection of some conditional compilation. To achieve ultimate portability.
Note that the entire configuration process of uboot, many files are associated (sometimes the file is created in which file, sometimes the file is contained in which file, sometimes this file is determined by the content of which file is generated)
Uboot in the configuration and compilation process, all files or global variables are in the form of a string (not the concept of a C-language string, which refers to a sequence of characters). This means that our entire Uboot configuration process is string matching, so be sure to detail, pay attention to the case, be careful not to lose a typo, because once the wrong one finally will appear some silent wonderful mistakes, difficult to troubleshoot, this is the uboot transplant process in the most difficult place for beginners.
2.4.9 Connection scripts for Uboot
1.uboot connection scripts and our previous bare-metal link scripts are not essential differences, high difficulty, more files, use more skills.
2. ENTRY (_start) is used to specify the entry address of the entire program, the so-called entry address is the beginning of the entire program. Can be considered to be the first sentence of the entire program. A bit like the C language of Main.
3. Previously told in bare metal, specify the program's link address has 2 methods: one is in the makefile of the LD flags with-ttext
0x20000000 to specify: The second type is specified at the beginning of the sections of the link script with the. =0x20000000. Both of these can achieve the same effect. In fact, these two skills can be used in conjunction with each other. Two are specified later with the-ttext specified as prevail.
5. Uboot the final link start address is specified in makefile with-ttext, note the text_base variable. The final source is in the makefile configuration corresponding command, which is obtained when make xxx_config.
6. Note the order in which the files are arranged in the code snippet. The files that you specify that must be placed in the previous section are those that must be arranged in the first 16kb, and the functions in those files are called in the first 16kb. In the second part of the procedure called, the order of the sequence is irrelevant.
7. The compilation tool also allows us to customize the segments in the link script, in addition to the rodata of the. Text. Data. BSS section. For example, the. U_boot_cmd segment in Uboot is a custom segment. Custom segments are important.
1.5.1 start. s INTRODUCTION
Find Start.s Entrance in U-boot.lds
1. The entrance to the entire project in C is the main function (which is specified in C), 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, it is not possible to find main.c directly because of the assembly phase involved. The entire program entry depends on where the entry declaration is in the linker 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.
3. Use the SI tool to search for co-_start, then analyze that is the file we need. then enter start. s file and then into 76, 77 lines, which is the definition of the _start label, we find the entire Uboot entry code.
4. We started from start. S file parses the first phase of the Uboot code.
5. In Si, if we know the name of the file we are looking for, but we do not know which directory it 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 the file not units), and then enter the above input field to find the name of the file. When we input, si is constantly helping us to match, even if you do not remember the filename can only remember the approximate name, but also can help you find the file you want.
Uboot Transplant Preparation Work II
