Uboot start process analysis (two)

1 Introduction

Uboot start process analysis (a) In the previous article https://www.cnblogs.com/Cqlismy/p/12000889.html has been briefly analyzed low_level_init function, which calls the process is as follows:

save_boot_params_ret
    |
    cpu_init_crit
    |        　　|
    |        　　lowlevel_init
    |        　　|
    |        　　s_init
    |
    _main

Next, proceed to the analysis function _main down.

2, _main function

In the last save_boot_params_ret, bl _main run this code, Uboot it will jump to _main function to run, the definition of the function in arch / arm / lib / crt0.S file, the function _main function has been file comments very clearly, take a look at what _main function is the function, comments as follows:

/*
 * This file handles the target-independent stages of the U-Boot
 * start-up where a C runtime environment is needed. Its entry point
 * is _main and is branched into from the target's start.S file.
 *
 * _main execution sequence is:
 *
 * 1. Set up initial environment for calling board_init_f().
 *    This environment only provides a stack and a place to store
 *    the GD ('global data') structure, both located in some readily
 *    available RAM (SRAM, locked cache...). In this context, VARIABLE
 *    global data, initialized or not (BSS), are UNAVAILABLE; only
 *    CONSTANT initialized data are available. GD should be zeroed
 *    before board_init_f() is called.
 *
 * 2. Call board_init_f(). This function prepares the hardware for
 *    execution from system RAM (DRAM, DDR...) As system RAM may not
 *    be available yet, , board_init_f() must use the current GD to
 *    store any data which must be passed on to later stages. These
 *    data include the relocation destination, the future stack, and
 *    the future GD location.
 *
 * 3. Set up intermediate environment where the stack and GD are the
 *    ones allocated by board_init_f() in system RAM, but BSS and
 *    initialized non-const data are still not available.
 *
 * 4a.For U-Boot proper (not SPL), call relocate_code(). This function
 *    relocates U-Boot from its current location into the relocation
 *    destination computed by board_init_f().
 *
 * 4b.For SPL, board_init_f() just returns (to crt0). There is no
 *    code relocation in SPL.
 *
 * 5. Set up final environment for calling board_init_r(). This
 *    environment has BSS (initialized to 0), initialized non-const
 *    data (initialized to their intended value), and stack in system
 *    RAM (for SPL moving the stack and GD into RAM is optional - see
 *    CONFIG_SPL_STACK_R). GD has retained values set by board_init_f().
 *
 * 6. For U-Boot proper (not SPL), some CPUs have some work left to do
 *    at this point regarding memory, so call c_runtime_cpu_setup.
 *
 * 7. Branch to board_init_r().
 *
 * For more information see 'Board Initialisation Flow in README.
 */

From the comments, we can probably know the order of execution _main function is:

Provided for the first call board_init_f () function initial environment, this environment provides only stack and a storage position GD ( 'global data') structure, both of which are located in RAM may be used (SRAM, locked cache ...) in before calling board_init_f () function, GD should be cleared;

Uboot start process analysis (two)

Guess you like