| Abstract:Embedded systems generally do not have general bootloader. U-boot is a powerful bootloader development software, but it is relatively complicated. This article introduces the boot process of U-boot, and provides the porting methods and steps of U-boot on the B0 Development Board. Keywords:Bootloader; U-boot; embedded system; transplantation; 1 Introduction to Bootloader and U-boot The bootloader code is a piece of code executed before the chip is reset and enters the operating system. It is mainly used to complete the transition from hardware startup to operating system startup, so as to provide a basic operating environment for the operating system, such as initializing the CPU, stack, and storage system. The bootloader code is related to the kernel structure, specific model, application system configuration, and operating system of the CPU chip. Its function is similar to the BIOS program of the PC. Because bootloader is related to the CPU and circuit board configurations, it is impossible to have a general bootloader. during development, you need to port it according to the specific situation. In Embedded Linux systems, commonly used bootloaders include armboot, Redboot, blob, and U-boot. Among them, U-boot is a popular and powerful bootloader that supports multiple architectures, but it is relatively complicated. The implementation of bootloader depends on the CPU architecture. Most bootloaders are divided into two parts: stage 1 and stage 2. For the basic principles of bootloader, see references. U-boot is an open source project on the SourceForge website. It supports powerpcmpc5xx, mpc8xx, mpc82xx, mpc7xx, mpc74xx, arm (ARM7, arm9-, Strongarm, XScale), MIPS (4kc, 5kc), x86, and other processors, supported embedded operating systems include Linux, VX-works, NetBSD, QNX, RTEMS, Artos, and lynxos. They are mainly used to develop embedded system initialization code bootloader. The main site of the software is http // sourceforge.net/projects/ U-boot. U-boot was initially developed by the PPC-boot of denxwww.denx.de. It has the most comprehensive support for PowerPC series Processors and the best support for Linux operating systems. Source code open U-boot software projects are often updated, which is a good example of learning the underlying hardware code development.
2 U-boot system startup process Most bootloaders are divided into two parts: stage1 and stage2, and U-boot is no exception. Code dependent on the CPU architecture (such as device initialization Code) is usually stored in stage1 and can be implemented in assembly language, while stage2 is implemented in common C language, in this way, you can implement complex functions and have better readability and portability. 2.1 stage1 (start. s code structure) The stage1 code of U-boot is usually stored in the start. s file, which is written in assembly language. The main code is as follows: (1) define the entry. An executable image must have one entry point and only one global entry. Generally, this entry is placed at 0x0 address of the RoM (flash). Therefore, the compiler must be notified to know the entry, which can be done by modifying the connector script. (2) set the exception vector ). (3) set the CPU speed, clock frequency, and interrupt control register. (4) initialize the memory controller. (5) copy the program in the Rom to ram. (6) initialize the stack. (7) Go to ram for execution. This task can be completed using the ldr pc command. 2.2 stage2c code Lib ARM/board. in C, start armboot is a function starting with C language. It is also the main function of C language in the whole startup code, and is also the main function of the whole U-boot (armboot). This function mainly completes the following operations: (1) call a series of initialization functions. (2) initialize the flash device. (3) initialize the system memory allocation function. (4) If the target system has a NAND device, initialize the NAND device. (5) If the target system has a display device, initialize the device. (6) initialize related network devices, and fill in IP addresses and MAC addresses. (7) enter the command loop (that is, the operating cycle of the entire boot), accept the commands entered by the user from the serial port, and then perform the corresponding work. 3. Transplant instances This system development board is mainly composed of b0x embedded microprocessor, 2 MB flash (sst39vf160), 8 Mb SDRAM (hy57v641620), 4 LEDs and arm JTAG interfaces. The Functional Diagram 1 of the relevant part of the Development Board with b0x is shown in. 3.1 U-boot file download There are two methods to download the U-boot file. The first method is to download the latest file through CVS in Linux. The method is as follows: $ Cvs-dpserveranonymous@cvs.sourceforge. Net/cvsroot/U-boot Login When you need to enter the anonymous logon password, you can press the Enter key. $ Cvs-z6-dpserveranonymous@cvs.source forge.net/cvsroot/u-boot?co.p modulename The second is to download the officially released compressed file through FTP // ftp.denx.de/pub/u-boot. 3.2 structure of the U-boot file There are many files downloaded for the first time. decompress the files and store them in the U-boot directory. The specific content has been detailed in the README file. The main folders related to transplantation include: (1) Each sub-folder of the CPU has the following files: Makefile Config. mk CPU. C and processor-related code Interrupts. c interrupt handling code Serial Port initialization code of serial. c Start. s global start code (2) Every sub-folder of the Board contains the following files: Makefile Config. mk Smdk2410.c and board-related code (take smdk2410 as an example) Flash. c flash operation code Memsetup. s initialize the SDRAM code Connection file for u-boot.lds (3) related implementation code under the Lib ARM architecture, such as the optimization Implementation of memcpy and other assembly languages. 3.3 create a cross-compilation environment To get the U-boot binary boot code that is downloaded to the target board, you also need to compile the downloaded u-boot1.1.1. U-boot compilation is generally carried out in the Linux system, can be compiled by ARM-LIN-UX-GCC. It is usually complicated to build a cross-compilation environment step by step. The simplest method is to use the cross-compilation tool compiled by others. The method is as follows: (1) download arm-Linux-gcc-3.3.2.tar.bz2 at http // handhelds.org/download/toolchain (2)use the username roottoken to decompress arm-linux-gcc-3.3.2.tar.bz2 to the/root directory. # Tar jxvf arm-linux-gcc-3.3.2.tar.bz2 (3) In http // handhelds.org/download/toolchaindownload arm-linux-toolchain-post-2.2.13.tar.gz just uses its header file, mainly from the kernel/linux-x.x/include (4) unzip the arm-linux-toolchain-post-2.2. 13.tar.gz to/skiff/local/ # Tar zxvf arm-linux-toolchain-post-2.2.13.tar.gz (5) copy the header file to/root/usr/3.3.2/ARM-Linux/and delete/skiff. # Cp-Dr/skiff/local/ARM-Linux/include/root/usr/3.3.2/ARM-Linux # Rm-fr/skiff In this way, an ARM Linux cross-compiling environment is established. (6) Add/root/usr/local/ARM/3.3.2/bin to the path environment variable. Path = $ path:/root/usr/local/ARM/3.3.2/bin can check whether the PATH variable is set correctly. # Echo $ path 3.4 pre-Compilation of porting To port U-boot to a new development board, you only need to modify the hardware-related part. There are two main layers of transplantation. The first layer is for CPU transplantation, and the second layer is for board transplantation. Because U-boot 1.1.1 already contains the transplantation of B0, the transplantation of the Board myboard is mainly for the transplantation of the Board. Before transplantation, read the README file in the U-boot directory carefully, and briefly introduce how to transplant it. To reduce the workload of transplantation, you can select a Development Board similar to the hardware to be transplanted under the include/config directory. I chose the B2 Development Board. The procedure is as follows: (1) The CPU folder under U-boot 1.1.1 already contains the directory of B0 with start. sinterrupts. C and CPU. cserial. c files. Therefore, you do not need to create CPU-related directories. (2) Create the myboard directory under the board directory and files such as my-board.c, Flash. C, memsetup. s and u-boot.lds. You do not need to create a file from scratch. Simply select a similar directory and copy it directly. Then, modify the file name and content. During the transplantation of U-boot, I chose the U-boot 1.1.1/board/Dave/B2 directory. (3) add myboard under the include/configs directory. h. You do not need to create a global macro definition from scratch. You can find similar CPU header files in the include/configs directory for copying, here I use the b2.h file for relevant modifications. (4) modify the MAKEFILE file in the root directory of U-boot, and add Myboard_config: unconfig @./Mkconfig $ (@: _ Config =) arm cloud44b0 myboard (5) modify the MAKEFILE file under the U-boot root directory and add the declaration to the board. Then add "myboard" and "list ARM7 =" B2 EP7312 impa7 myboard "to the makefile ″. (6) run make clobber to delete the wrong depend file. (7) run make myboard config. (8) The Execution here indicates that the makefile of the entire software has been created. You can modify the cross-compilation option in the generated makefile, open the MAKEFILE file, and find the statement: Ifeq ($ (ARCH), arm) Cross_compile = arm-Linux- End if Change it Ifeq ($ (ARCH), arm) Cross compile =/root/usr/local/3.3.2/bin/ARM-Linux- End if This step is the same as setting the environment variable above. Run make and report an error. Modify myboard/flash. # include "in C ″.. /common/flash. C "is" U-boot/board/Dave/common/flash. C ", re-compile to pass. 4. Specific modification points during transplantation If there are no pre-compiled errors, you can start porting hardware-related code. First, you must have a clear understanding of the migrated hardware, such as the control registers of the CPU and CPU, and the layout of programs in each phase of startup in flashsdram. In the porting process, I first modify most of the parameters in the/include/config/my-board.h header file (most macro definitions are set here), and then gradually modify them according to the U-boot startup process. You should be familiar with the arm assembly language and C language and have a deep understanding of the U-boot Startup Process Code. The CPU frequency of the B2 board is 75 MHz, the flash is 4 Mbit, the SDRAM is 16 Mbit, the serial port baud rate is 115200bit/s, and the environment variables are placed in the EEPROM. Depending on the two development boards, you need to modify the CPU frequency, flash and sdramcapacity, and environment variable location. Because the reference board already has most of the code, you only need to modify the corresponding myboard. Related Files include/config/myboard. H (most macro definitions are set here),/board/myboard/flash. the drive sequence of cflash,/board/myboard. C (SDRAM driver),/CPU/serial. C (driver enabling part of the serial port. /Include/config/myboard. H is the place where the global macro is defined. The main modifications include: Change # define config initi44b0 clock speed 75 # Define config 89c44b0 clock speed 64; Change # define phys SDRAM 1 Size 0x01000000/* 16 MB */ # Define phys SDRAM 1 Size 0x00800000/* 8 Mb */; Change # define phys flash size 0x00400000/* 4 MB * # Define phys flash size 0x00200000/* 2 MB */; Change # define CFG Max flash sect 256/* max number of sectors on one chip */ # Define CFG Max flash sect 35; Change # define CFG env is in EEPROM 1/* use EEPROM for Environment vars */ # Define CFG env is in Flash 1 Others (such as the size of the stack) can be modified as needed. Because the capacity of flash and SDRAM changes, we should re-arrange the position of the Startup Program in flash and SDRAM. The author places the U-boot code in flash at the beginning of 0x0, and copies the U-boot code in SDRAM at the beginning of 0xc700000. Flash modification is not only related to the capacity, but also to the specific model. Flash Memory burning, writing, and erasure are generally not universal. Check the manufacturer's instruction manual, modify the memory of different types. During the modification process, you need to know the write address, Data command, and sector size and position of the specific register in flash for correct setting. The memory controller part to be modified is initialized by the start. the CPU init crit in the s file sets the CPU cache and is set by the Board/myboard/memsetup. s. B0 provides the SDRAM Controller. Compared with some CPUs that require UPM table programming, it only needs to modify the settings of relevant registers, thus reducing the development difficulty. The serial port baud rate does not need to be modified (all are 115200bit/s). simply use the serial port drive of the B2 board. The serial port configuration mainly includes the initialization of the serial port. It is worth noting that the baud rate of the serial port is closely related to the clock mclk. For details, see the CPU user manual. After configuration, you can re-compile the U-boot code. After the obtained u-boot.bin is downloaded to the target board through the JTAG port, if the correct startup information can be output from the serial port, it indicates that the transplantation is basically successful. In the actual process, you need to modify it multiple times because of weeks. After transplantation, you can also add some other functions (such as LCD drivers), which is relatively easy to add. 5 conclusion U-boot is a powerful bootloader development software. It is suitable for CPU platforms and supports many embedded operating systems. This article is based on the relevant information in the actual development process, and summarized on the basis of the successful transplantation of U-boot. The basic methods and steps for different CPUs and Development Boards are the same, and we hope to help related embedded system designers. |
