U-boot analysis-[Detailed description of Embedded Linux System Development Technology-Based on ARM] 2

(Conversion) U-boot analysis-[Detailed description of Embedded Linux System Development Technology-Based on ARM] 2
6.2.1 Introduction to the U-boot Project
At first, Wolfgang Denk of the denx software engineering center created a ppcboot project based on the 8xxrom source code and added support for the processor. Later, sysgo GmbH transplanted ppcboot to the ARM platform and created the armboot project. Then, the U-boot project is created based on the ppcboot project and armboot project.
At present, U-boot has been able to support hundreds of development boards with PowerPC, arm, x86, and MIPS architectures, and has become the most functional, flexible, and most active open source bootloader development. It is still maintained by the Wolfgang Denk of denx.
You can download the U-boot source code package from the SourceForge website, and subscribe to the active U-boot users email forum on the website, this email Forum is very helpful for the development and use of U-boot.
U-boot package download Website: http://sourceforge.net/project/u-boot.
U-boot email list Website: http://lists.sourceforge.net/lists/listinfo/u-boot-users /.
Denx-related websites:
Http://www.denx.de/re/DPLG.html
.
6.2.2 U-boot source code structure
Download the U-boot source package from the website, for example: U-Boot-1.1.2.tar.bz2
Decompress the package to obtain all u-boot source programs. There are 18 subdirectories under the top-level directory, respectively storing and managing different source programs. The files to be stored in these directories have their own rules and can be divided into three categories.
· 1st categories of directories are directly related to the processor architecture or development board hardware;
· The 2nd class directory contains some common functions or drivers;
· The 3rd class directory is the U-boot application, tool, or document.
Table 6.2 lists the directory storage principles under the top-level directory of U-boot.
Table 6.2 top-level directory description of U-boot source code
Contents
Features
Explanation
Board
Platform dependency
Stores directory files related to circuit boards, such as rpxlite (mpc8xx), smdk2410 (ARM920T), and sc520_cdp (x86 ).
CPU
Platform dependency
Stores CPU-related directory files, such as: mpc8xx, ppc4xx, arm720t, ARM920T, XScale, i386, etc.
Lib_ppc
Platform dependency
Stores files common to the PowerPC architecture and is mainly used to implement functions common to the PowerPC platform.
Contents
Features
Explanation
Lib_arm
Platform dependency
Stores files that are common to the ARM architecture and is mainly used to implement common functions of the ARM platform.
Lib_i386
Platform dependency
Stores files that are common to the X86 architecture and is mainly used to implement functions common to the X86 platform.
Include
General
The header file and the development board configuration file. All the development board configuration files are under the configs directory.
Common
General
Universal function implementation
Lib_generic
General
Implementation of Common Library functions
Net
General
Program for storing the network
FS
General
Program for storing the File System
Post
General
Store power-on self-check program
Drivers
General
General device drivers, mainly drivers with Ethernet interfaces
Disk
General
Hard Disk interface program
RTC
General
RTC driver
DTT
General
Driving of a digital temperature measuring device or sensor
Examples
Application routine
Examples of independent applications, such as helloworld
Tools
Tools
Stores images in the S-record or U-boot format, such as mkimage.
Doc
Document
Development and usage documents

The source code of U-boot includes support for dozens of processors and hundreds of development boards. However, for a specific development board, only some of the programs are required to configure the compilation process. Here we take the S3C2410 ARM920T processor as an example to analyze the programs on which the S3C2410 processor and the Development Board depend, as well as general functions and tools of U-boot.
6.2.3 U-boot Compilation
The source code of U-boot is compiled through GCC and makefile. In the makefile under the top-level directory, You can first set the definition of the Development Board, recursively call makefiles under subdirectories at all levels, and finally link the compiled program to a U-boot image.
1. makefile under the top-level directory
It is responsible for compiling the overall U-boot configuration. Read the key lines in the configuration order.
Each type of Development Board requires the definition of board configuration in makefile. For example, the smdk2410 Development Board is defined as follows.

Smdk2410_config: unconfig
@./Mkconfig $ (@: _ Config =) arm ARM920T smdk2410 null s3c24x0

Run the "make smdk2410_config" command to configure U-boot and generate include/config through the./mkconfig script.
MK configuration file. The file content is generated based on the makefile configuration of the Development Board.

Arch = arm
CPU = ARM920T
Board = smdk2410
SOC = s3c24x0

The above include/config. mk file defines arch, CPU, board, SOC variables. In this way, the directory files that the hardware platform depends on can be determined according to these definitions. The following table lists the directories related to the smdk2410 platform.
Board/smdk2410/
CPU/ARM920T/
CPU/ARM920T/s3c24x0/
Lib_arm/
Include/ASM-arm/
Include/configs/smdk2410.h
Return to the starting part of the MAKEFILE file in the top-level directory. The following lines contain the definition of these variables.

# Load arch, board, and CPU Configuration
Include include/config. mk
Export arch CPU board vendor SOC

The compilation options and rules of makefile are defined in the config. mk file in the top-level directory. General rules for various architectures are defined directly in this document. Use arch, CPU, board, Soc, and other variables to define different options for different hardware platforms. Rules of different architectures are contained in files such as ppc_config.mk, arm_config.mk, and mis_config.mk.
The makefile in the top-level directory also defines the cross compiler and the target file on which u-boot depends.

Ifeq ($ (ARCH), arm)
Cross_compile = arm-Linux-// prefix of the Cross Compiler
# Endif
Export cross_compile
...
# U-boot objects... order is important (I. e. Start must be first)
Objs = CPU/$ (CPU)/start. O // target file related to the processor
...
Libs = lib_generic/libgeneric. A // define the dependent directory. The target file is first connected to the *. A file under each directory.
Libs = Board/$ (boarddir)/Lib $ (board).
Libs = CPU/$ (CPU)/Lib $ (CPU).
Ifdef SOC
Libs = CPU/$ (CPU)/$ (SOC)/Lib $ (SOC).
Endif
Libs = lib _ $ (ARCH)/Lib $ (ARCH).
...

Then there is the dependency of the U-boot image compilation.

U-boot.srec u-boot.bin system. Map
ALL: $ (all)
U-boot.srec: U-boot
$ (Objcopy) $ {objcflags}-o srec $
U-boot.bin: U-boot
$ (Objcopy) $ {objcflags}-O binary $
......
U-boot: depend $ (subdirs) $ (objs) $ (libs) $ (ldscript)
Undef_sym = '$ (objdump)-x $ (libs )\
| Sed-n-e's/. * \ (_ u_boot_cmd _. * \)/-U \ 1/P' | sort | uniq ';\
$ (LD) $ (ldflags) $ undef_sym $ (objs )\
-- Start-group $ (libs) $ (platform_libs) -- end-group \
-Map u-boot.map-o u-boot

Makefile defaults to all, including u-boot.srec, u-boot.bin, system. Map. U-boot.srec and u-boot.bin depend on U-boot again. U-boot is to assemble the target file into U-boot according to the u-boot.map address table through the LD command.
Other makefile content will not be analyzed in detail. The above code analysis should provide a clue for reading the code.
2. Development Board configuration header file
In addition to the makefile compilation process, you also need to define configuration options or parameters for the Development Board in the program. This header file is include/configs/. h. Use the corresponding board definition instead.
This header file mainly defines two types of variables.
The first type is the option with the prefix of config _, which is used to select the processor, device interface, command, and attribute. For example:

# Define config_arm920t 1
# Define config_driver_cs8900 1

The other is the parameter prefix CFG _, which defines parameters such as bus frequency, serial port baud rate, and Flash address. For example:

# Define pai_flash_base 0x00000000
# Define pai_prompt "=>"
3. Compilation result
Based on the analysis of makefile, compilation is divided into two steps. Configure step 1, for example, make smdk2410_config; compile step 2 and execute make.
After compilation, you can obtain the image files and symbol tables in various U-boot formats, as shown in table 6.3.
Table 6.3 image files generated by U-boot Compilation
File Name
Description
File Name
Description
System. Map
Symbol table of the U-Boot Image
U-boot.bin
Original binary format of the U-Boot Image
U-boot
ELF format of the U-Boot Image
U-boot.srec
U-boot image S-record format

The three image formats of U-boot can be burned to flash, but you need to check whether the loader can recognize these formats. General u-boot.bin is the most commonly used, download directly according to the binary format, and burn to flash according to the absolute address can be. Both U-boot and u-boot.srec-format images come with positioning information.
4. U-Boot Tool
There are also some U-boot tools in the tools directory. Some of these tools are also frequently used. Table 6.4 describes the use of several tools.
Table 6.4 U-boot tools
Device Name
Description
Device Name
Description
BMP logo
Mark the bitmap Structure
Img2srec
Converting SREC format images
Envcrc
Verify the environment variables embedded in U-boot
Mkimage
Convert the U-boot Format Image
Gen_eth_addr
Generate the MAC address of the Ethernet Interface
Updater
U-boot automatic update tool

These tools have source code. You can refer to rewrite other tools. Mkimage is a commonly used tool. Both Linux kernel images and ramdisk file system images can be converted to the U-boot format.
6.2.4 transplantation of U-boot
U-boot supports a variety of architecture processors, and more development boards are supported. Because bootloader is completely dependent on the hardware platform, you need to port the U-boot program on the new circuit board.
Before you start porting U-boot, familiarize yourself with the hardware circuit board and processor. Check whether U-boot supports the processors and I/O devices of the New Development Board. If u-boot already supports a very similar circuit board, the porting process will be very simple.
The job of porting U-boot is to add files and configuration options related to the hardware of the Development Board, and then configure the compilation.
Before starting the migration, analyze the Development Board supported by U-boot and compare the Development Board with the closest hardware configuration. The principle is that the processor architecture is the same first, and then the peripheral interfaces such as Ethernet interfaces. Also verify that the U-boot of this reference Development Board can be configured and compiled at least.
Taking the S3C2410 processor development board as an example, the U-Boot-1.1.2 version has supported the smdk2410 Development Board. We can port based on smdk2410, so we first compile smdk2410.
Let's take the S3C2410 Development Board fs2410 as an example. For the porting process, refer to the smdk2410 Development Board, smdk2410 has been supported in the U-Boot-1.1.2.
The basic steps for porting U-boot are as follows.
(1) Add new configuration options for the Development Board in the top-level makefile. Use an existing configuration item as an example.

Smdk2410_config: unconfig
@./Mkconfig $ (@: _ Config =) arm ARM920T smdk2410 null s3c24x0

Refer to the above two rows and add the following two rows.

Fs2410_config: unconfig
@./Mkconfig $ (@: _ Config =) arm ARM920T fs2410 null s3c24x0

(2) create a new directory to store the Code related to the Development Board and add files.
Board/fs2410/config. mk
Board/fs2410/flash. c
Board/fs2410/fs2410.c
Board/fs2410/makefile
Board/fs2410/memsetup. s
U-boot.lds/board/fs2410/
(3) Add a new configuration file for the Development Board
You can copy and modify the configuration file of the Development Board. For example:
$ CP include/configs/smdk2410.h include/configs/fs2410.h
To port a new CPU, create a new directory to store CPU-related code.
(4) configure the Development Board
$ Make fs2410_config
(5) Compile U-boot
Run the make command to obtain the U-boot image after compilation. Some errors are related to the configuration options. Generally, opening some function options will lead to some errors. You can try to make the same configuration as the reference board at the beginning.
(6) add driver or function options
On the basis of being able to compile, you must also implement the Ethernet interface of U-boot, flash erase, and other functions.
The Ethernet driver of the fs2410 Development Board is exactly the same as that of the smdk2410, so you can use it directly. The CS8900 driver file is as follows.
Drivers/cs8900.c
Drivers/cs8900.h
There is a lot of trouble to choose flash, and the flash chip price or procurement factors have an impact. The size and model of most development boards are different. Therefore, the Flash Driver needs to be transplanted. The Flash. c file is usually available under each Development Board directory and needs to be modified according to the specific flash type. For example:
Board/fs2410/flash. c
(7) debug the U-boot source code until u-boot can be started properly on the Development Board.
The debugging process may be difficult and requires tools, and some problems may be difficult for a long time.
6.2.5 Add the U-boot command
The U-boot command provides users with interactive functions and has implemented dozens of commonly used commands. If the Development Board requires special operations, you can add a new U-boot command.
Every u_boot_cmd command is defined by the u_boot_cmd macro. This macro is defined in the include/command. h header file. Each Command defines a javas_tbl_t struct.

# Define u_boot_cmd (name, maxargs, rep, CMD, usage, help )\
Pai_tbl_t _ u_boot_cmd _ # name struct_section = {# name, maxargs, rep, CMD, usage, help}

In this way, each U-boot command has a struct to describe. Struct contains member variables: command name, maximum number of parameters, number of duplicates, command execution function, usage, and help.
The commands entered on the console are interpreted and executed by the program in common/command. C. Find_cmd () is used to match the input command and find the corresponding command structure from the list.
Based on the basic framework of the U-boot command, you can analyze the simple icache operation commands to learn how to add new commands.
(1) define the cache command. The flags of all u-boot commands are defined in include/cmd_confdefs.h.

# Define pai_pai_cache 0x00000010ull/* icache, dcache */

If you have more commands, add the definition here.
(2) The operation function that implements the cache command. The following is the code of the icache command in the common/cmd_cache.c file.

# If (config_commands & cmd_cmd_cache)
Static int on_off (const char * s)
{// This function parses the parameter to determine whether to enable or disable the cache.
If (strcmp (S, "on") = 0) {// The parameter is "on"
Return (1 );
} Else if (strcmp (S, "off") = 0) {// The parameter is "off"
Return (0 );
}
Return (-1 );
}

Int do_icache (pai_tbl_t * cmdtp, int flag, int argc, char * argv [])
{// Operation function for Instruction Cache
Switch (argc ){
Case 2:/* if the number of parameters is 1, enable or disable the command cache operation */
Switch (on_off (argv [1]) {
Case 0: icache_disable (); // open the Instruction Cache
Break;
Case 1: icache_enable (); // disable the command Cache
Break;
}
/* Fall trough */
Case 1:/* if the number of parameters is 0, the command cache status is obtained */
Printf ("Instruction Cache is % s \ n ",
Icache_status ()? "On": "off ");
Return 0;
Default: // in other default cases, print command instructions
Printf ("Usage: \ n % s \ n", required TP-> usage );
Return 1;
}
Return 0;
}
......
U_boot_cmd (// use macro-defined command
Icache, 2, 1, do_icache, // The command is icache, and the command execution function is do_icache ()
"Icache-enable or disable Instruction Cache \ n", // help information
"[On, off] \ n"
"-Enable or disable Instruction Cache \ n"
);
......
# Endif

The u- boot commands are described by struct _ u_boot_cmd _ # name. You can understand the two definitions of u_boot_cmd in include/command. h.

# Define u_boot_cmd (name, maxargs, rep, CMD, usage, help )\
Pai_tbl_t _ u_boot_cmd _ # name struct_section = {# name, maxargs, rep, CMD, usage, help}

Also, do not forget to add the compiled target file to the common/makefile.
(3) Open the command flag of the config_commands option. This program file starts with # If statement needs to pre-process whether to include this command function. The config_commands option is defined in the configuration file of the Development Board. For example, the smdk2410 platform has the following definitions in include/configs/smdk2410.h.

/*************************************** ********************
* Command Definition
**************************************** *******************/
# Define config_commands \
(Config_cmd_dfl | \
Pai_pai_cache | \
Pai_pai_reginfo | \
1__1__date | \
Pai_pai_elf)

Follow these three steps to add the new U-boot command.