Detailed explanation of u-boot transplantation steps

1 Introduction to U-Boot
U-Boot, the full name of Universal Boot Loader, is an open source project that complies with the terms of the GPL. It has evolved from FADSROM, 8xxROM, and PPCBOOT. Its source code directory and compilation format are very similar to the Linux kernel. In fact, many U-Boot source codes are simplified versions of the corresponding Linux kernel source programs, especially the drivers of some devices, which can be reflected in the comments of the U-Boot source code. However, U-Boot not only supports the booting of embedded Linux systems, but also currently supports NetBSD, VxWorks, QNX, RTEMS, ARTOS, and LynxOS embedded operating systems. The target operating systems it currently supports are OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, LynxOS, pSOS, QNX, RTEMS, and ARTOS. This is one meaning of Universal in U-Boot. Another meaning is that U-Boot supports not only PowerPC series processors, but also MIPS, x86, ARM, NIOS, XScale and many other commonly used series of processors. These two features are exactly the development goals of the U-Boot project, that is, to support as many embedded processors and embedded operating systems as possible. At present, U-Boot has the most extensive support for PowerPC series processors and the most complete support for Linux. Other series of processors and operating systems were gradually expanded after PPCBOOT was renamed U-Boot in November 2002. The smooth transition from PPCBOOT to U-Boot is largely due to the superb professional level and unremitting efforts of Wolfgang Denk [hereinafter referred to as WD], the maintainer of U-Boot, from the German DENX Software Engineering Center. At present, under his leadership, the U-Boot project is under the leadership of many embedded developers who are interested in the transplantation of open source BOOT LOADER and are in full swing to continuously expand and deepen the transplantation work of various series of embedded processors to support the loading and booting of more embedded operating systems.
Reasons to choose U-Boot:
① Open source;
② Supports multiple embedded operating system kernels, such as Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, LynxOS;
③ Supports multiple processor series, such as PowerPC, ARM, x86, MIPS, XScale;
④ High reliability and stability;
④ High reliability and stability;
⑤ Highly flexible function settings, suitable for U-Boot debugging, different operating system boot requirements, product release, etc.;
⑥ Rich device driver source code, such as serial port, Ethernet, SDRAM, FLASH, LCD, NVRAM, EEPROM, RTC, keyboard, etc.;
⑦ Relatively rich development and debugging documents and strong network technology support;

2 U-Boot main directory structure
- board target board related files, mainly including SDRAM, FLASH drivers;
- common common code independent of processor architecture, such as memory size detection and fault detection;
- cpu processor related files. For example, the mpc8xx subdirectory contains serial port, network port, LCD driver and interrupt initialization files;
- driver general device driver, such as CFI FLASH driver (currently has good support for INTEL FLASH)
- doc U-Boot documentation;
- examples example programs that can be run under U-Boot; such as hello_world.c, timer.c;
- include U-Boot header files; especially the configuration header files related to the target board in the configs subdirectory are files that are often modified during the transplantation process;
- lib_xxx processor system related files, such as lib_ppc, lib_arm directories contain files related to PowerPC and ARM architectures respectively;
- net file directory related to network functions, such as bootp, nfs, tftp;
- post power-on self-test file directory. Still need to be further improved;
- rtc RTC driver;
- tools Tools for creating U-Boot S-RECORD and BIN image files;

3 Main functions supported by U-Boot
List of main functions supported by U-Boot
System boot supports NFS mounting and RAMDISK (compressed or uncompressed) root file system
Supports NFS mounting and booting compressed or uncompressed system kernel from FLASH;
Basic auxiliary functions Powerful operating system interface function; Flexible setting and passing of multiple key parameters to the operating system, suitable for system debugging requirements and product release at different development stages, especially the strongest support for Linux;
Supports multiple storage methods of target board environment parameters, such as FLASH, NVRAM, EEPROM;
CRC32 check, can check whether the kernel and RAMDISK image files in FLASH are intact;
Device driver serial port, SDRAM, FLASH, Ethernet, LCD, NVRAM, EEPROM, keyboard, USB, PCMCIA, PCI, RTC and other driver support;
Power-on self-test function SDRAM, FLASH size automatic detection; SDRAM fault detection; CPU model;
Special function XIP kernel boot;

4 Preparation before transplantation

(1) First, read the readme file that comes with uboot to get a general idea.
(2) Take a look at common.h. This file defines some basic things and includes some necessary header files. Then take a look at flash.h. This file defines flash_info_t as a struct. It contains some attribute definitions of flash. And it defines all the attributes of flash, among which AMD has: AMD_ID_LV320B, defined as "#define AMD_ID_LV320B 0x22F922F9".
(3) For the modification of "./borad/at91rm9200dk/flash.c", there are the following aspects:
The purpose of the function "void flash_identification(flash_info_t *info)" is to confirm the model of flash. Note that there are some macro definitions in this function to directly read and write flash. And get the ID number.
(4) Modify: "./board/at91rm9200dk/config.mk" to
TEXT_BASE=0x21f80000 to TEXT_BASE=0x21f00000 (Of course, you should modify it according to your own board and make it consistent with the definition of the first-level boot).
(5) Modify "./include/configs/at91rm9200dk.h" to
Change the size of flash and SDRAM.
(6) Another file to be modified is:
./borad/at91rm9200dk/flash.c. This file has many parts to be modified.
a. First, the definition of OrgDef, plus the current flash.
b. Next, modify "#define FLASH_BANK_SIZE 0x200000" to the capacity of your own flash
c. Modify the print information in the function flash_identification(flash_info_t * info), which will be displayed when u-boot starts.
d. Then modify the assignment of some variables in the function flash_init(void).
e. Finally, modify the function information actually printed in the function flash_print_info(flash_info_t * info).
f. There is another function that needs to be modified, which is: "flash_erase". This function needs to detect whether the previously known flash type matches. Otherwise, it returns directly. Comment this out.

(7) Next, let's look at the modification of SDRAM.
The definition of "SIZE" here is based on byte calculation.
Just modify "#define PHYS_SDRAM_SIZE 0X200000" in "./include/configs/at91rm9200dk.h"
. Note that SIZE is in bytes. (
8) There is another point to note.
According to the current settings, the first-level boot loads u_boot into the SDRAM space: 21F00000 -> 21F16B10, which happens to be the high-end part of SDRAM. In addition, BSS is 21F1AE34.

(9) After compiling, you can write to the flash.
a. Compress the u-boot.bin
"gzip –c u-boot.bin > u-boot.gz"
The compressed file size is:
43Kbytes
b. Then burn boot.bin and u-boot.gz into the flash.
Boot.bin is about 11kBytes, located at 0x1000 0000 ~ 0x1000 3fff of the flash

5 U-Boot porting process①
Obtain the latest version of U-Boot source code, which is similar to the Linux kernel source code and is also compressed in bzip2 format. It can be obtained from the official website of U-Boot http://sourceforge.net/projects/U-Boot ;
② Read related documents, mainly the README document in the root directory of the U-Boot source code and the DULG (The DENX U-Boot and Linux Guide) document on the official website of U-Boot http://www.denx.de/twiki/bin/view/DULG/Manual . In particular, the DULG document provides detailed instructions on how to install and establish a cross-development environment and solve common problems in U-Boot porting;
③ Subscribe to the U-Boot user mailing list http://lists.sourceforge.net/lists/listinfo/u-boot-users . If you encounter problems during the U-Boot transplantation process, and you still cannot solve them after referring to relevant documents and searching the U-Boot-User mail archive http://sourceforge.net/mailarchive/forum.php?forum_id=12898 , submit these problems as soon as possible. Many enthusiastic U-Boot developers will be happy to quickly troubleshoot the problems, and it is very likely that WD himself will directly participate in the guidance;
④ Carry out the transplantation work in the established development environment. Most development environments are cross-development environments. In this regard, DENX and MontaVista both provide a complete set of development tools;
⑤ Insert a hardware debugger between the target board and the development host. This is a very critical debugging tool that should be available for U-Boot transplantation. Because in the entire U-Boot transplantation work, especially in the initial stage, the hardware debugger is the only way for us to understand the real running status of the target board. In this regard, WD himself and many embedded developers tend to use BDI2000. On the one hand, its price is not as expensive as the ICE debugger, and at the same time, it has high reliability and powerful functions, and is fully capable of transplanting and debugging U-Boot. In addition, there are many reference documents on BDI2000 debugging on the Internet.
⑥ If you transplant U-Boot on the reference development board, you may need to remove the existing BOOT LOADER on the target board. According to the instruction document of the BOOT LOADER on the board, you can first solve how to restore after removing the current BOOT LOADER. So that you can reload the original BOOT LOADER when needed in the future.