U-Boot transplantation (7) summarizes the overall structure of the U-Boot project

3. How does u-boot’s general directory become platform-independent?

include/configs/100ask24x0.h  

There are two main types of variables defined in this header file.

　One category is options, prefixed by CONFIG_, used to select processors, device interfaces, commands, attributes, etc., mainly used to decide whether to compile certain files or functions.

The other type is parameters, with the prefix CFG_, used to define parameters such as bus frequency, serial port baud rate, and Flash address. These constant parameters are mainly used to support code in the general directory and define board resource parameters.

These two types of macro definitions are very critical to the portability of u-boot, such as drivers/cs8900.c. For cs8900, many operations are common, but not all boards have this chip, even if it is in the memory The base address mapped in is also platform dependent. So for the smdk2410 board, it is defined in smdk2410.h

#define CONFIG_DRIVER_CS8900 1              /* we have a CS8900 on-board */

#define CS8900_BASE　0x19000300              /*IO mode base address*/

The definition of CONFIG_DRIVER_CS8900 allows cs8900.c to be compiled (of course CFG_CMD_NET must be defined), because there is a compilation condition judgment before the function definition in cs8900.c: #ifdef CONFIG_DRIVER_CS8900 If this option is not defined, the entire cs8900.c will not be compiled.

The constant parameter CS8900_BASE is used in the cs8900.h header file to define the address of each functional register. u-boot's CS8900 works in IO mode. As long as the base address of the IO register mapped in memory is given, the rest of the code is platform-independent.

  The u-boot command is also configured through the configuration header file of the target board. For example, if you want to add the ping command, you must add CFG_CMD_NET and CFG_CMD_PING. Otherwise common/cmd_net.c will not be compiled.

From here I can think that u-boot project configurability and portability can be divided into two layers:

One is implemented by the makefile, which configures the files and folders to be included in the project and what compiler to use.

The second is to achieve source code level configurability and versatility through the configuration header file of the target board. It is mainly implemented using #ifdef #else #endif and the like.

Personally I think this is very important and very useful.

4. Other important files of smkd2410:

include/s3c24x0.h defines the addresses of each special function register (SFR) of the s3x24x0 chip.

cpu/arm920t/start.s The boot code executed in flash, which is stage1 in bootloader, is responsible for initializing the hardware environment, loading u-boot from flash into RAM, and then jumping to start_armboot in lib_arm/board.c to execute.

lib_arm/board.c u-boot initialization process, especially the initialization of the global data structures gd and bd used by u-boot, as well as the initialization of devices and consoles.

board/smdk2410/flash.c The code in the board directory relies heavily on the target board. There are relatively common codes for different CPUs, SOC, ARCH, and u-boot, but the board composition is diverse, mainly memory. Address, flash model, peripheral chips such as network. For fs2410, the main consideration is to transplant it from the smdk2410 board. The difference is mainly in the nor flash.