Implementation of Bootloader in AT91RM9200 System

The AT91RM9200 chip based on the ARM920T core has a lot of room for application in embedded development in the field of industrial control due to its rich internal peripherals, processing speed of up to 200MIPS, and wide temperature range. Bootloader is a boot loader used to boot the operating system. It is used to initialize hardware devices, establish memory space mapping, and provide a suitable hardware and software environment for the final boot of the operating system kernel. It is heavily dependent on the hardware environment and often varies depending on the chips used, external devices, and operating system kernel configuration. Its implementation is an indispensable part of embedded development.

There are two ways to implement a boot program suitable for this system: one is to develop a bootloader by yourself, which is characterized by the fact that the program can occupy as little space as possible while meeting the requirements, but the workload is large and the development cycle is extended. Except for some special requirements, it is generally not written by yourself during engineering development; the other is to use existing code for porting, which is characterized by small workload. There are many open source bootloaders such as vivi, U-boot, Blob, etc. These programs support PowerPC, ARM, MIPS and other platforms. Developers only need to do relatively less porting work. From the perspective of engineering development, this method is often adopted.

The author has developed a radar monitoring extension test board based on AT91RM9200. This article will take this embedded board as an example to introduce the method of developing ARM programs with GNU tools, explore how to use this method to write your own bootloader, and introduce the U-boot transplantation steps and key points in detail.

1 Hardware Features

1.1AT91RM9200 processor startup features

The AT91 series processors have two boot modes: on-chip and off-chip[1], support address remapping, and are representative of ARM chips.

The AT91RM9200 has 16K bytes of SRAM and 128K bytes of ROM integrated inside. If the BMS pin is at a low level, it will boot from the external Flash chip connected to NCS0. If the BMS pin is at a high level, it will boot from the internal ROM. The ROM is embedded with FirmWare. This embedded program automatically detects whether there are legitimate programs in the DataFlash connected to SPI, the EEPROM connected to TWI, and the 8-bit parallel Flash chip connected to EBI. If there are legitimate programs, they will be put into SRAM for execution. If not detected, the debug serial port and USB device port will be initialized to support file downloads of Xmodem and DFU protocols respectively, and the files sent by the user can be put into the internal SRAM [2].

Since this chip supports address remap, after downloading, the SRAM address is remapped from 0x0020_0000 to 0x0000_0000, the internal ROM address is mapped from 0x0000_0000 to 0x0010_0000, and then execution starts from the internal SRAM at address 0x0000_0000.

1.2 Downloading and burning the Bootloader

Many ARM chips, like the AT91 series chips, support Remap, which makes it convenient to use the serial port to download programs and burn Flash. This type of chip generally requires two early boot programs before using the bootloader. This system uses two programs, loader.bin and boot.bin: loader.bin runs in the internal RAM and is used to download programs to SDRAM and run; boot.bin is fixed at the starting address of the flash (as shown in Figure 1) and is used to decompress the U-boot program in the boot Flash.

Set the jumper so that the system starts from the inside after power-on. Download the loader.bin program through the serial port. The size of the program must be less than 16K bytes, that is, the capacity of the internal SRAM. As mentioned above, it will be run after downloading. This program is responsible for downloading the u-boot.bin program to SDRAM through the Xmodem protocol and running it. The developer then uses the U-boot cp command to burn boot.bin and the compressed file u-boot.bin u-boot.gz into Flash. The next time you start from the outside, you can directly start U-boot. Among them, boot.bin realizes the decompression of u-boot.gz into SDRAM and execution.

ATMEL provides the boot and loader codes for their chip development board, which can be downloaded from the Internet. Developers can compare the parameter settings and modify some parameters if necessary.

The following are the key parameters in these two programs. The key parameter in the loader is AT91C_UBOOT_BASE_ADDRESS, and the files received using the Xmodem protocol will be stored at this address. Its macro definition is in main.h:

#define AT91C_UBOOT_BASE_ADDRESS 0x21F00000 。

The key parameters in Boot are:

#define SRC 0x10010000

/*Address of u-boot.gz in flash*/

#define DST 0x21F00000

/*uboot.gz needs to be copied to the address in SDRAM after decompression*/

#define LEN 0x020000

/*Decompressed size (bytes)*/

These parameters may need to be modified according to the specific situation, especially SRC should be consistent with the relevant settings in U-boot. The specific parameters will be introduced in 3. Figure 1 shows the space allocation of Flash memory, and lists the purpose of each address segment. [page]

1.3 Storage space of this embedded board

The distribution of key storage space related to bootloader of the ARM board developed by the author is as follows:

32M Byte SDRAM: 0x2000_0000 – 0x21FF_FFFF

2M Byte Flash: 0x1000_0000 – 0x101F_FFFF

2 Developing bootloader with GNU tools

GNU provides free compilation tools that can be downloaded from the Internet. The cross-compilation tools for the ARM platform include the assembler arm-linux-as, the C compiler arm-linux-gcc, the linker arm-linux-ld, and the binary conversion tool arm-linux-objcopy. The GNU compiler is very powerful, with hundreds of operation options to meet the various needs of developers. Its characteristics are low development cost and no need for expensive emulators. It can not only develop programs that run under the operating system, but also develop bare-metal applications [3]. GNU tools all run under Linux. Developers need a PC running Linux as a host machine and download the development to the board. U-boot, vivi, etc. all use these tools. They provide a good example for developers. In general, the program development process based on GNU tools is as follows: (1) Write C, C++ or assembly source program; (2) Generate target files using the relevant compiler; (3) Write a connection script; (4) Use the linker to generate the final file (elf format); (5) Use the binary conversion tool to generate downloadable binary code.

The purpose of writing a bootloader for this system is to complete the most basic function of booting the operating system. The basic functions of the bootloader should include: (1) initialization of hardware, such as setting exception vectors, setting CPU speed, clock frequency and interrupt control registers, initializing memory controllers, initializing stacks, etc.; (2) supporting file downloads, serial port Kermit protocol downloads or network port downloads supporting tftp protocol. The latter is relatively complex to implement, but fast, and can be selected according to the situation; (3) Flash operations; (4) It is best to support two working modes: download and boot; (5) decompress the kernel, configure parameters, etc. Function (1) directly involves hardware, and GNU assembly should be used for implementation. Different from the ARM assembler written in the ADS environment, this assembly language has its own characteristics, supports preprocessing, can use #include<> and C language style comments, and the file extension is capital S (the compiler uses this to distinguish whether the assembly program is preprocessed). Developers can refer to the information provided by GNU and the source code of U-boot.

3 U-boot transplantation

3.1 Source code analysis

U-BOOT (Universe Bootloader) is an open source project on the Sourceforge website. It supports multiple architectures such as PowerPC, ARM, MIPS, and x86, and its code is easy to port[4]. In my development, I used the source code of U-Boot1.1.2 and the GCC compiler version was 2.95.3. Developers must first understand the structure and function of the code. On this basis, they can analyze the running order and mutual calling relationship of the code.

Figure 2 U-boot execution sequence

The running process of U-Boot is shown in Figure 2. The program starts from cpu/at91rm9200/start.S. The entry is defined by .globl _start in start.S. Then the processor status is set, the interrupt and memory timing are initialized, and it is determined whether the entire U-Boot code needs to be relocated. Then it jumps to star_armboot() to run. This function is defined in /lib_asm/board.c. After completing some initialization work, it loops and calls the main_loop() function in commmon/main.c. You can read the code in this order when developing. In the board directory of the code, you can find the corresponding directory of the development board with the same chip as your own. Here, the directory at91rm9200dk is selected, and most of the modification work is also here when transplanting.

3.2 Transplantation Tips

The code files that are mainly concerned with and modified during the transplantation and the corresponding modification points are as follows:

(1) include/commom.h. The code includes some header files using many conditional compilations and declares a series of basic functions. This header file is included by many files. Understanding the content of this file is very helpful for understanding and modifying the code.

(2) include/configs/at91rm9200dk.h. This file contains detailed settings for this board. The key settings include clock settings, terminal selection (GDBU, USART0, USART1), SDRAM start address PHYS_SDRAM and size PHYS_SDRAM_SIZE, Flash memory start address PHYS_FLASH_1 and size PHYS_FLASH_SIZE, and the storage address CFG_ENV_ADDR and size CFG_ENV_SIZE of U-Boot environment variables in Flash, and U-Boot start address CFG_U_BOOT_BASE and size CFG_U_BOOT_SIZE. Other parameters can be modified according to the needs of the developer. The above parameters should be modified according to the actual situation.

According to development experience, it is easy to overlook the storage address CFG_ENV_ADDR and size CFG_ENV_SIZE of the environment variable in FLASH. When the saveenv command in U-boot is executed, the environment variable set by the setenv command will be stored in the Flash, requiring the starting address to be the boundary of a section of the Flash. In the project, according to the manual of the AM29LV160DB chip and the connection of the address line of the Flash on the circuit schematic, make the following modifications to this file:

#define CFG_ENV_ADDR (PHYS_FLASH_1 + 0xe000)

#define CFG_ENV_SIZE  0x2000  /* 0x8000 */

Modified to:

#define CFG_ENV_ADDR (PHYS_FLASH_1 + 0x8000)

#define CFG_ENV_SIZE  0x8000  /*0x8000 */

The address allocation of the Flash memory can be seen in Figure 1.

(3) board/at91rm9200dk/config.mk. Here, TEXT_BASE is set to 0x21f00000, which is consistent with the DST parameter setting of the Boot program mentioned in Part 1 of this article.

(4) board/at91rm9200dk/flash.c. Since the Flash chip used is different from the Flash chip targeted by the source code, first add the following macro to include/flash.h: #define AMD_ID_LV160DB 0x22492249, which is the device ID number of the AM29LV160DB chip, in order to correctly identify it in the flash_identification() function. In addition, the definition

OrgDef OrgAMDLV160DB[] ={

{  1, 16*1024 },

/*   1 * 16 kBytes sectors */

{  2,  8*1024 },

/*   2 * 8  kBytes sectors */

{  1, 32*1024 },

/*   1 * 32 kBytes sectors */

{ 31, 64*1024 },

/*  31 * 64 kBytes sectors */

};[page]

This OrgDef array gives the information of the segments in Flash. Modify the printed information in the function flash_identification(flash_info_t * info), modify the variables in flash_init(void) and flash_print_info(flash_info_t * info) accordingly, and finally modify the identity judgment part in flash_erase() accordingly (if only one Flash chip is supported, it can be removed).

According to the hardware situation of this system, the key is to modify the driver part of Flash. Since the Bootloader is used to boot the operating system, as analyzed in the second part of this article, it only needs to complete the most basic hardware initialization, so what is often needed in actual transplantation is generally as described above.

Next, compile under Linux and set the environment variable PATH to the directory where the cross compiler is located, such as:

PATH=$PATH:/usr/local/arm/2.95/bin

Execute the following command in the top-level directory of the code:

make distclean

make at91rm9200dk_config

make

After successful compilation, three files can be obtained: u-boot, u-boot.bin, and u-boot.srec. The boot file contains a lot of debugging information and can be read by many debugging programs. Developers can also use commands such as readelf and objdump to view the segment address and other information contained in it. The u-boot.bin file is a binary file that can be directly executed by ARM. u-boot.srec is a file in Motorola MT srec format.

Burn U-boot to the Flash chip according to the method described in 1.2, set the jumper to make the BMS pin low, start the CPU from the outside, and display the U-boot startup information from the hyperterminal.

3.3 Debugging

Problems encountered during debugging may be porting problems or hardware problems, which require developers to make judgments. Carefully reading the source code of U-boot is very helpful for understanding the hardware environment and debugging. At the same time, the code has some conditional compilation for debugging, using functions such as dbg() and debug() to output debugging information. Developers can compile through these debugging information output functions to obtain debugging information for related parts.

After the compilation is successful, load u-boot.bin into SDRAM and run it. Test erase, cp, printenv, saveenv and other commands to detect the operation of Flash. Use tftp command to detect the network port download function, and then load the operating system kernel. After completing the above tasks, the transplantation is successful. The U-Boot transplanted through the above steps has successfully booted the Linux operating system on the ARM board developed by me.

4 Conclusion

This article is based on the author's development experience of AT91RM9200. First, it introduces the characteristics of the processor, discusses the general methods and steps of developing bootloader using GNU, and finally analyzes the transplantation of U-boot on embedded systems in detail. The transplantation of bootloader on embedded platforms based on other CPUs is similar to this. I hope this article can be of reference significance to embedded developers. AT91RM9200 is a high-performance chip based on ARM920T core suitable for industrial control, automotive electronics, medical equipment and other fields. It is a relatively high-end RISC processor. The article first analyzes the characteristics of AT91RM9200 chip booting, and then implements the method of Bootloader (boot loader of the operating system) on the embedded system based on AT91RM9200, especially through a detailed introduction to the method of transplanting U-boot and common problems.

The author's innovation in this article is to explain the method of implementing bootloader in system development based on RISC chips (ARM, MIPS, PPC, etc.), providing a reference for a large number of embedded developers.

References:

[1] Zhu Yijun, Yang Yuhong, Zhao Kai, Duan Zhiying, AT91 Series ARM Microcontroller Architecture and Development Examples [M], Beijing University of Aeronautics and Astronautics Press, 2005

[2]  Atmel Corporation, ARM920TTM Based Microcontroller AT91RM9200，2004

[3] Wookey, Chris Rutter, Jeff Sutherl, Paul Webb, The GNU Toolchain for ARM Targets HOWTO.

[4] The DENX U-BOOT and Linux Guide (DULG), http://www.denx.de/twiki/bim/view/DULG/Mannual

[5] Wan Yongbo, Zhang Genbao, Tian Ze, Yang Feng, Analysis of Bootloader Startup Process of Embedded System Based on ARM, Microcomputer Information, Vol. 21, No. 11-2, 2005, p. 90