Analysis of U-Boot transplantation on S3C2410

Introduction

BootLoader is the first link in embedded system software development. It closely connects software and hardware together and is crucial for the subsequent software development of an embedded device. BootLoader also involves a lot of hardware-related knowledge. For ordinary embedded development boards, it is an indispensable step, so it is necessary to do a good job of its transplantation, which is also beneficial for subsequent development work. U-Boot is a popular and powerful BootLoader. It is easy to operate, can support processors of various architectures, and provides a complete command system. S3C2410 is an embedded general-purpose processor based on ARM920T from Samsung. The transplantation platform of this article is the HHARM9-EDU-R2 development board with S3C2410 as the core. The hardware resource configuration of this development board is relatively complete. The main hardware resources are: S3C2410 processor; 1 Intel TE28f128FLASH (16M); 2 Hynix HY57V561620 SDRAM (64M); 10/100M adaptive network chip DM9000; USBHost/Device; RS232×2/RS485×1 serial port; LQ035FLM08L 256K color TFT true color LCD display; full-function JTAG debugging port, etc.

U-Boot Introduction

U-Boot is the abbreviation of Das U-Boot. It is a public software released by denx software center in accordance with GPL. As the boot module for system startup, U-Boot supports multiple processor architectures, such as Power-PC, ARM, MIPS and x86. At present, the U-Boot source code is in the community server of the sourceforge website. There is a group of free developers on the Internet to maintain and develop it. Its project homepage is http://sourceforge.net/projects/u-boot. After downloading and decompressing the U-Boot source code package, the following directory structure will be formed: board, files related to some existing development boards; common, C files that implement various U-Boot commands; cpu, CPU-related files, and the subdirectories are named after the CPUs supported by U-Boot; disk, disk driver partition processing code; doc, documentation; drivers, general device drivers; fs, files that support the file system; include, header files, assembly files that support various hardware platforms, system configuration files, and files that support the file system; net: code related to the network; lib-arm, code related to the ARM architecture; tools, tools for creating S-Record format files and U-Boot Images.

The transplantation of U-Boot in this article is the process of modifying or adding related source files in the above directories according to the hardware resources of the HHARM9-EDU-R2 development board, and recompiling. Before starting the transplantation work, it is very necessary to understand the operation process of U-Boot.

Analysis of U-Boot running process

The code definition after U-Boot compilation is generally no more than 100 kB, and this 100 kB is divided into two stages for execution. The first stage code is defined in start.s, and the size does not exceed 10 kB. It includes the part that starts to execute at address 0x00000000 after the system is powered on. This part of the code runs in Flash, which includes initializing some registers of S3C2410 and copying the second stage code of U-Boot from Flash to SDRAM. Excluding the first stage code, the rest is the second stage code. The starting address of the second stage is specified in the first stage code. After being copied to SDRAM, it jumps from the first stage to this entry address to start executing the remaining part of the code. The second stage mainly performs some BSS segment settings, stack initialization and other tasks, and finally jumps to the main-loop function to accept commands and perform command processing. Figure 1 shows the detailed running process of U-Boot, including the setting, loading and calling process of the kernel.

Figure 1 U-Boot running process

After understanding the operation process of U-Boot, we must also determine the address space distribution of the development board before we can modify and transplant the source code. The address space distribution partly depends on the hardware configuration of the development board and the reset address of the CPU. The address space of the development board in this article is shown in Figure 2.

Figure 2 Development board address space distribution [page]

U-Boot porting and testing

In order to make the porting work faster, you should choose the latest version of U-Boot 1.1.2 (although U-Boot1.1.3 can be obtained through CVS, it is under development and has not yet been released, so it is not suitable for use). Because the latest version can provide support for as many processor cores and development boards as possible. For U-Boot-1.1.2, it not only provides support for the ARM-920T kernel, but also directly provides board-level support for S3C2410, which reduces the porting workload relatively.

Code modification to support ARM-920T kernel

Since U-Boot-1.1.2 provides direct support for the ARM-920T kernel, this step does not require any work. In order to let readers understand the general mode of BootLoder porting, this article only gives a few tips.

Configure your own development board

Create a directory and related files for your own development board.

1) Add the header file S3C2410.h (cp smdk2410.h S3C2410.h) in the include/configs directory with smdk2410.h as the template. This file is the configuration file of the development board, which includes the CPU, system clock, RAM, Flash system and other related configuration information of the development board.

2) Create the S3C2410 directory in the board/directory. Copy all the files in the smdk2410 directory to the S3C2410 directory. There are six files in total: flash.c, memsetup.c, S3C2410.c, Makefile, U-Boot .lds and config.mk. Modify each file according to the actual situation of the development board.

◆ flash.c U-Boot source code file for reading, writing and deleting Flash devices. Since the types of Flash memories in different development boards are different, you need to refer to the corresponding Flash chip manual when modifying flash.c. It includes the following functions:

unsigned long flash-init (void), Flash initialization;
int flash-erase (flash-info-t *info, ints-first, ints-last), Flash erase;
volatile static int write-hword (flash-info-t *info, ulong dest, ulong data), Flash write;
int write-buff (flash-info-t *info, uchar *src, ulong addr, ulong cnt), copy data from memory.

Since the flash chip used in the development board of this article is IntelTE28f128, there is this flash.c in the board/cmi directory, which can be used with a slight modification.

◆memsetup.c. Initialize the clock, SMC controller and SDRAM controller. In order to be able to use U-Boot's GO command to execute the modified U-Boot downloaded by loadb or tftp in the future, add five sentences on the marker "0:":

mov r3, pc
ldr r4, = 0x3FFF0000
and r3, r3, r4 //The above three sentences get the actual starting memory address
aad r0, r0, r3 //When debugging uboot with the GO command, the starting address is in RAM
add r2, r2, r3 //Add the address of the initialized memory information to the actual starting address

◆S3C2410.C. Set various bus clocks, turn on data Cache and instruction Cache, and set related memory parameters.

◆Makefile.Modify: OBJS := S3C2410.o flash.omemsetup.o

◆U-Boot.lds.Make the following changes:

.text
{
cpu/ arm920t/ start.o ( .text)
* (.text)
}

◆config.mk.Used to set the starting address of the program connection. Because functions will be added to U-Boot, 6M space is left. Change 33F80000 to 33A00000.

Implement the driver program of the network card

In the drivers/ directory, add the network port device control programs dm9000.c and dm9000.h using dm9000x.c and dm9000x.h as templates. dm9000.c mainly includes the following functions:

int eth-init (bd-t *bd), initialize the network device;
int eth-send(volatile void *, int), send data packets;
int eth-rx(void), receive data packets.
void eth-halt (void), shut down the network device;

in order to facilitate the data reading and writing operations of the network device, the following functions are also defined:

static int dm9000-probe (void), search for DM9000 chip, allocate space and register it;
static u16 phy-read(int), read a word from the Phyxcer register;
static void phy-write (int, u16), write a word to the Phyxcer register;
static u16 read-srom-word (int), read a word data from SROM;
static u8 DM9000-ior (int), read a byte from the I/O port;
static void DM9000-iow(int reg, u8 value), write a byte to the I/O port;
finally, add dm9000.o to drivers/Makefile.

Modify the Makefile file
Add the following two lines below the ARM92xT Systems comment in U-Boot-1.1.2/Makefile:
S3C2410-config: unconfig
@./mkconfig ＄(@:-config =) arm arm920tS3C2410 [page]

"arm" is the type of CPU, arm920t is the code directory corresponding to the ARM CPU, and S3C2410 is the directory corresponding to your own development board.

The cross compiler is installed in the directory: / path/ armv4l-unknown -linux-, so set CROSS-COMPILE to the corresponding path: CROSS-COMPILE = / path/ arm4l-unknown-linux

-Generate target files and test
Run the following commands in sequence:

# make clean
# make S3C2410-config
# Make

will generate three files:

U-Boot - ELF format file, which can be recognized by most Debug programs;
U-Boot.bin - Binary file, pure U-Boot

binary execution code, does not save ELF format and debugging information. This file is generally used to burn into the user development board; U-Boot .srec - Motorola S-Record format, can be downloaded to the development board through the serial port.

Test and application

1) Testing

Use the prepared Flash burning program to burn the generated binary file U-Boot.bin into the zero address of Flash through the JTAG port. After the burning is successful, unplug the JTAG debugging line and reset the development board. The following information is output from the Minicom terminal:

U-Boot 1.1.2 (Jul 20 2005-09 ：34 ：21)
U-Boot code ： 33F00000-> 33F1952C BSS：-> 33F1D870
RAM Configuration ：
Bank # 0 ： 30000000 64 MB
Flash Memory Start 0x0000000
Device ID of the Flash is 18 Flash
： 16 MB
Write 18 to Watchdog and it is 18 now
In ： serial
Out ： serial
Err ： serial
SMDK2410 #The

above information output by the serial port shows that the CPU and serial port are working properly. The commands flinfo and mtest provided by U-Boot can be used to test Flash and RAM. After testing, Flash information can be read correctly and RAM can be read and written correctly, indicating that Flash and DRAM have been initialized correctly. Using the tftp command to transfer any small file in the host machine's tftpboot directory to RAM successfully indicates that the network card chip is also successfully driven.

2) Simple application

The main function of U-Boot is to boot the kernel. Therefore, by booting a specific kernel through U-Boot, the stability of its transplantation can be further tested. There are two different ways to use U-Boot to boot the kernel. The first method is to directly burn the kernel image file and the root file system into Flash. With this method, U-Boot reads the kernel image and the root file system in Flash into the specified location in RAM at startup and starts the kernel from the same location. The second method is to download the kernel image file and the root file system to RAM and start directly (instead of reading from Flash into RAM). This method does not require burning Flash. In order to reduce the number of times Flash is burned, the author adopts the second method in this article. The steps are as follows:

SMDK2410 # tftp 30008000 zImage
SMDK2410 # tftp 30800000 ramdisk.Image.gz
SMDK2410 # go 30008000During

the execution of the above instructions, no exceptions occurred, the kernel started successfully, and finally entered the Shell prompt "#". Under the Shell prompt, enter the various commands customized when the kernel is compiled, and they can all run normally. In addition, write a simple C program and compile it with a cross compiler. The executable file generated can run normally on the development board. The above facts show that the kernel has been stably running on the development board after being guided by U-Boot. This application further verifies the stability of U-Boot transplantation. So far, the transplantation work has come to an end. Conclusion At present

,

the U-Boot transplanted by the author can run stably on the development board, which makes the debugging of the Linux kernel separated from the BDM debugger, saves a lot of development time, greatly improves efficiency, and is a strong support for subsequent embedded development. Of course, U-Boot is just an easy-to-use BootLoader. There are many technical details in the development of embedded Linux. Only by constantly modifying, debugging and summarizing according to actual conditions can we achieve greater success.