下了最新的uboot(2014)年的,我用git clone下来的。发现和网上的教材目录结构不一样了。
虽然启动流程还是分为两个stage,但是代码位置不一样。
例如
cpu目录结构放到arch/arm/下,在这个结构可以找到链接文件uboot-lds和各个芯片架构的start.S。
stage1的改动好像不大
stage2 的函数名 从 start_armboot 改为 _main. 位置在arm/arch/lib/crt0.s (用 grep -rn _main .搜出来的)
在新的_main函数里,把stage2的初始化过程分得更细了
board_init_f
relocate_code
board_init_r
board.c定义了上面的board_init*函数,位置在arch/arm/lib
具体流程其实和之前的一样,只是函数模块化了,可能记起来会更方便。crt0.s里有关_main的描述
* _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.
*
* 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.
*
* (the following applies only to non-SPL builds)
*
* 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.
*
* 4. Call relocate_code(). This function relocates U-Boot from its
* current location into the relocation destination computed by
* board_init_f().
*
* 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. GD has retained values set by board_init_f(). Some CPUs
* have some work left to do at this point regarding memory, so
* call c_runtime_cpu_setup.
*
* 6. Branch to board_init_r().
*/
/*
* entry point of crt0 sequence
*/