U-BOOT transplant experience

After running bare metal recently, I started to run the system, but I thought that there is a Bootloader between bare metal and system. Anyway, I didn't study it in depth before, so I decided to spend one to two weeks to play with U-BOOT.
I referred to the two great experts fzb and Zhao Chunjiang, and also studied the two classic versions of 2010.06 and 2011.06. I also compared the U-BOOT written by TQ (the board I bought was Tianqian). I learned a lot and discovered a lot of things. The following is my own experience so that I can refer to it later.

The two-stage startup process of U-BOOT: (For the 2010.06 classic version)
The first stage: the path of start.S is located at arch\\arm\\cpu\\arm920t\\This assembly code is generally called the first stage initialization code. The main function is to initialize the operating environment; initialize the memory; re-place the UBOOT code into the memory; jump into the memory to execute the second initialization code
1 Turn off the door dog and shield all interrupts
2 Set the frequency division ratio
3 bl cpu_init_crit() Turn off MMU and initialize the memory
bl lowlevel_init() Configure the memory, modify the memory refresh rate parameters, etc.
4 relocate Determine whether the current code is in NORFLASH or RAM
copy_loop Copy the FLASH code to RAM
5 stack_setup Stack settings
clear_bss _bss_start to _bss_end The data is cleared to 0
6 ldr pc, start_armboot Jump to the second stage
//=
... The main function is to initialize two important data structures, set the memory allocation of SDRAM, initialize various peripherals needed, and finally jump into the main_loop() function in a loop. The
second stage start_armboot is divided into two parts: board_init_f and board_init_r. The

first executed board_init_f part:
1. Allocate an address for the gd data structure and clear it to zero
2. Execute each initialization function in the init_fnc_ptr function pointer array, as follows
board_early_init_f, timer_init, env_init init_baudrate serial_init
console_init_f display_banner dram_init
3. A. Allocate the upper 64KB of SDRAM as TLB for U-BOOT
B. Allocate the next unit of SDRAM as U-BOOT code segment, data segment, BSS segment
(here is a sentence, the original BSS segment is used to store uninitialized global variables and static variables)
C. Then open up malloc space to store bd, gd, 3 words of exception heap space
4. Assign the address value of relorate to the corresponding variable of the gd structure (2011.06 version, used to return to start.S)

and then execute the board_init_r part:
1. Assign values ​​to the gd and bd data structures
2. Initialize various peripherals:
initialize NORFLASH, NANDFLASH, initialize ONENAND FLASH
Initialize environment variables Initialize PCI Set IP address Initialize various peripherals: IIC, LCD, keyboard, USB Initialize console Establish IRQ interrupt stack Initialize Ethernet
Initialize jump table (defines the basic common function library in U-Boot). . This does not include peripherals
3. An infinite loop executes the main_loop() function

/**********************************
Comparison of the two versions of U-BOOT startup:
************************************/
In fact, they are similar in general, but compared with the classic version (2010.06 version), the new version has become disgusting.
The main differences are as follows:
1. The 5th step of the stack setup in the first stage of the original version is placed before the 4th step of relorate (this is nothing)
2. The board_init_f in the second stage of the original version is placed before the 4th step of relorate in the first stage, which means that
after executing the stack_setup stack setup, it enters the partial initialization of the second stage, and then returns to the first stage through 4. Assigning the address value of relorate to the corresponding variable of the gd structure (2011.06 version, used to return to start.S). . . I feel that the new version is very messy and disorganized after the revision (open source is revised every year, which is annoying , haha )


//= ...







The board_early_init_f function is in the smdk2410.c file in the board/samsung/smdk2410 directory. The timer_init function is in the timer.c file in the arch/arm/cpu/arm920t/s3c24x0 directory.
The env_init function is in the env_flash.c file in the common directory.
The init_baudrate function is in the board.c file in the arch/arm/lib directory.
The serial_init function is in the serial_s3c24x0.c file in the drivers/serial directory. CONFIG_S3C24X0_SERIAL is defined in include/configs/smdk2410.h.
console_init_f function is in the console.c file in the common directory
display_banner function is in the board.c file in the arch/arm/lib directory
dram_init function is in the smdk2410.c file in the board/samsung/smdk2410 directory
Initialization of various peripherals:
flash_init function is in the cfi_flash.c file in the drivers/mtd directory (because CONFIG_FLASH_CFI_DRIVER is defined in include/configs/smdk2410.h)
nand_init function is defined in the nand.c file in the divers/mtd/nand directory
env_relocate function is defined in the env_common.c file in the common directory
stdio_init () is defined in the stdio.c file in the common directory
jumptable_init () is defined in the exports.c file in the common directory
console_init_r () is defined in the console.c file in the common directory
interrupt_init () enable_interrupts () are defined in the interrupts.c file in the arch/arm/lib directory. eth_initialize (
) is defined in lines 209 to 298 of eth.c file in the net directory. main_loop () is defined in main.c
file in the common directory [page] //

= ... ) ; Ln303: When detecting whether a key is pressed, add the LOGO display program: embedsky_tq_logo(); main_loop() function Ln 381: LCD initialization program Ln481: Branch selection download OR loading mode: if ( BootFrmNORFLASH() ) run_command ("menu",0); else { Printf (" Booting Linux \\n "); run_command ("boot_zImage",0); } Analysis: The previous points are about LCD and LOGO display. I won't say much (because I didn't get the LCD transplantation when I transplanted it myself). Let's talk about Ln481 in the main_loop() function: Branch selection download OR loading mode First, run_command is the execution command function. As you can see from the name, it is also defined in /common/main.c Let's talk about the most important "menu" and "boot_zImage" 1 If booting from NORFLASH, it is in download mode, and the menu() function is executed, which is defined in /common/cmd_menu.c. Open the cmd_menu.c file and you will find that it contains some serial port option lists. The download list we found when we turned on the 2440 power supply was printed out from the main_menu_usage() function, and the selected items are executed through the console through menu_shell(). The execution process of each option is clearly listed, which feels like running a bare metal machine and making it yourself according to the fzb serial console. 2 Else booting from NANDFLASH, it is in loading mode, and the LINUX system is configured and started. In the lib_arm /boot_zImage.c file: the boot_zImage() function The contents of the function execution are as follows: 1. copy kernel image 2. setup linux parameters 3. get machine type 4. GO -> call-linux Some insights after comparison: Although I have also ported U-BOOT, and can also build my own board support package, and can implement basic serial console, NAND OR NOR FLASH, DM9000 network, JFFS2 file system and other basic functions, but compared with Tianqian, which can download and load mode, there are still many shortcomings So, porting by myself is just to feel the method. After understanding it, I will still port further on the basis of Tianqian. I don’t think it’s necessary to do it from beginning to end by myself. It’s enough to understand the method and be familiar with the framework.





































// =
... ​ ​ ​ ​ ​Wait How do you know what macro definitions to add? Generally speaking, you can define the ones that are needed for the peripheral initialization function and the U-BOOT second-stage startup function. . . 2 Change the corresponding initialization function: such as board_nand_init function and s3c2440_hwcontrol function Because the initialization function in U-BOOT is basically based on 2410, and the NAND configuration parameters of 2440 are different from it, some parts need to be changed 3 Add the initialization function to the second stage board_init_r. Generally speaking, the basic peripherals have been added. See if you define macros to let it compile this function Summary of some transplantation rules: In fact, after transplanting several times, you will find that the transplantation modification of UBOOT still follows certain rules. That is, first open the relevant macro definition support in the configuration header file, and add the initialization function that needs to support the function in the board-level initialization (generally the second-stage initialization process) code. If the board version corresponding to the initialization function is incompatible or does not exist, you have to write it yourself. // = ... ​ ​ ​ ​ ​ OK, we can move on to the next step of system porting and driver writing. Recently, the fat guy from 503 said that he wanted to do a project related to projectors and cameras. I am interested in image processing and think his idea is very good. I might do it. GO, I feel dizzy, I will take a few days off~~