海思uboot啟動流程詳細分析（二）

1. 第二個start.S 從開始，在中有包含在config.h中：在中：在中，看到了的巨集查看u boot.map在這裡又來到了上一層的start.S中來，所以可以知道這兩個是由兩個文件組成的，一個是u boot.bin和reg_info.bin，就是說兩個不同的start.S的流 ...

1. 第二個start.S

從start_armboot開始，在startup.c中有包含#include <config.h>

在config.h中：

/* Automatically generated - do not edit */
#define CONFIG_BOARDDIR board/hisilicon/hi3559av100
#include <config_defaults.h>
#include <config_uncmd_spl.h>
#include <configs/hi3559av100.h>
#include <asm/config.h>
#include <config_fallbacks.h>

在hi3559av100.h中：

#define CONFIG_SYS_TEXT_BASE            0x48800000

在hi3559av100.h中，看到了CONFIG_SYS_TEXT_BASE的巨集

/* CONFIG_SYS_TEXT_BASE needs to align with where ATF loads bl33.bin */
#define CONFIG_SYS_TEXT_BASE        0x48800000

查看u-boot.map在這裡又來到了上一層的start.S中來，所以可以知道這兩個是由兩個文件組成的，一個是u-boot.bin和reg_info.bin，就是說兩個不同的start.S的流程來合成一個最終的u-boot-hi3559av100.bin

這個便是正常的流程了：

本文將結合u-boot的“board—>machine—>arch—>cpu”框架，介紹u-boot中平臺相關部分的啟動流程。並通過對啟動流程的簡單分析，掌握u-boot移植的基本方法。

2. 多平臺架構

這些問題的本質，是軟體工程中的抽象和封裝，以最簡潔、最高效的方式，實現儘可能多的功能。u-boot作為一個跨平臺、跨設備的bootloader，同樣會面臨這些問題。它的解決方案，就是“board—>machine—>arch—>cpu”框架，如下：

基於圖片1的架構，u-boot和平臺有關的初始化流程，顯得比較直觀、清晰：

1）u-boot啟動後，會先執行CPU（如armv8）的初始化代碼。

2）CPU相關的代碼，會調用ARCH的公共代碼（如arch/arm）。

3）ARCH的公共代碼，在適當的時候，調用board有關的介面。u-boot的功能邏輯，大多是由common代碼實現，部分和平臺有關的部分，則由公共代碼聲明，由board代碼實現。

4）board代碼在需要的時候，會調用machine（arch/arm/mach-xxx）提供的介面，實現特定的功能。因此machine的定位是提供一些基礎的代碼支持，不會直接參与到u-boot的功能邏輯中。

3. 平臺相關部分的啟動流程分析

本文先不涉及u-boot和平臺相關的Kconfig/Makefile部分，以ARM64為例，假定u-boot首先從“arch/arm/cpu/armv8/start.S”的_start介面開始執行。因此我們從_start開始分析。

3.1 _start

_start是u-boot啟動後的第一個執行地址，對armv8來說，它只是簡單的跳轉到reset處執行，如下：

.globl  _start
_start:
    b   reset

3.2 reset

reset:
    /* Allow the board to save important registers */
    b   save_boot_params
.globl  save_boot_params_ret
save_boot_params_ret:

#ifdef CONFIG_SYS_RESET_SCTRL
    bl reset_sctrl
#endif
    /*
     * Could be EL3/EL2/EL1, Initial State:
     * Little Endian, MMU Disabled, i/dCache Disabled
     */
    adr x0, vectors
    switch_el x1, 3f, 2f, 1f
3:  msr vbar_el3, x0
    mrs x0, scr_el3
    orr x0, x0, #0xf            /* SCR_EL3.NS|IRQ|FIQ|EA */
    msr scr_el3, x0
    msr cptr_el3, xzr           /* Enable FP/SIMD */
#ifdef COUNTER_FREQUENCY
    ldr x0, =COUNTER_FREQUENCY
    msr cntfrq_el0, x0          /* Initialize CNTFRQ */
#endif
    b   0f
2:  msr vbar_el2, x0
    mov x0, #0x33ff
    msr cptr_el2, x0            /* Enable FP/SIMD */
    b   0f
1:  msr vbar_el1, x0
    mov x0, #3 << 20
    msr cpacr_el1, x0           /* Enable FP/SIMD */
0:

    /* Apply ARM core specific erratas */
    bl  apply_core_errata

    /*
     * Cache/BPB/TLB Invalidate
     * i-cache is invalidated before enabled in icache_enable()
     * tlb is invalidated before mmu is enabled in dcache_enable()
     * d-cache is invalidated before enabled in dcache_enable()
     */

    /* Processor specific initialization */
    bl  lowlevel_init

1）reset SCTRL寄存器

具體可參考reset_sctrl函數，由CONFIG_SYS_RESET_SCTRL控制，一般不需要打開。該配置項的解釋如下：

Reset the SCTRL register at the very beginning of execution to avoid interference from stale mappings set up by early firmware/loaders/etc.

http://lists.denx.de/pipermail/u-boot/2015-April/211147.html

2）根據當前的EL級別，配置中斷向量、MMU、Endian、i/d Cache等。

3）配置ARM的勘誤表

具體可參考apply_core_errata函數，由CONFIG_ARM_ERRATA_XXX控制，在項目的初期，可以不打開，後續根據實際情況打開）。

就是ARM有一些bug，但可以通過軟體的方法繞過去，由u-boot的代碼註釋可知，應該只有Cortex-A57才有。具體什麼bug，我也沒有去研究

4）調用lowlevel_init的功能解釋如下（具體可參考u-boot的readme文檔）：

purpose: essential init to permit execution to reach board_init_f()

   - no global_data or BSS

   - there is no stack (ARMv7 may have one but it will soon be removed)

   - must not set up SDRAM or use console

   - must only do the bare minimum to allow execution to continue to

           board_init_f()

   - this is almost never needed

   - return normally from this function

海思的和原生uboot代碼的start.S其實就是增加以下內容

5）如果是多CPU的場景，處理其它的CPU的boot

多CPU功能由CONFIG_ARMV8_MULTIENTRY控制，不需要打開。

6）跳轉到arm公共的_main中執行

ARM64平臺的_main位於crt0_64.S文件中，具體請參考下麵的描述。

3.3 _main

crt0是C-runtime Startup Code的簡稱，意思就是運行C代碼之前的準備工作。關於_main函數，crt0_64.S中有非常詳細的註釋（這一點要給u-boot點100個贊！），大家可以參考。該函數的定義如下：

ENTRY(_main)

/*
 * Set up initial C runtime environment and call board_init_f(0).
 */
#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
    ldr x0, =(CONFIG_SPL_STACK)
#else
    ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
    bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
    mov x0, sp
    bl  board_init_f_alloc_reserve
    mov sp, x0
    /* set up gd here, outside any C code */
    mov x18, x0
    bl  board_init_f_init_reserve

    mov x0, #0
    bl  board_init_f

#if !defined(CONFIG_SPL_BUILD)
/*
 * Set up intermediate environment (new sp and gd) and call
 * relocate_code(addr_moni). Trick here is that we'll return
 * 'here' but relocated.
 */
    ldr x0, [x18, #GD_START_ADDR_SP]/* x0 <- gd-="">start_addr_sp */
    bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
    ldr x18, [x18, #GD_BD]      /* x18 <- gd-="">bd */
    sub x18, x18, #GD_SIZE      /* new GD is below bd */

    adr lr, relocation_return
    ldr x9, [x18, #GD_RELOC_OFF]    /* x9 <- gd-="">reloc_off */
    add lr, lr, x9/* new return address after relocation */
    ldr x0, [x18, #GD_RELOCADDR]    /* x0 <- gd-="">relocaddr */
    b   relocate_code

relocation_return:

/*
 * Set up final (full) environment
 */
    bl  c_runtime_cpu_setup /* still call old routine */

/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */

/*
 * Clear BSS section
 */
    ldr x0, =__bss_start    /* this is auto-relocated! */
    ldr x1, =__bss_end  /* this is auto-relocated! */
    mov x2, #0
clear_loop:
    str x2, [x0]
    add x0, x0, #8
    cmp x0, x1
    b.lo    clear_loop

    /* call board_init_r(gd_t *id, ulong dest_addr) */
    mov x0, x18         /* gd_t */
    ldr x1, [x18, #GD_RELOCADDR]    /* dest_addr */
    b   board_init_r        /* PC relative jump */

    /* NOTREACHED - board_init_r() does not return */

#endif /* !CONFIG_SPL_BUILD */

ENDPROC(_main)

功能可總結為（大部分翻譯自crt0_64.S中的註釋）：

1）設置C代碼的運行環境，為調用board_init_f介面做準備。包括：

a）設置堆棧（C代碼的函數調用，堆棧是必須的）。如果當前的編譯是SPL（由CONFIG_SPL_BUILD定義），可單獨定義堆棧基址（CONFIG_SPL_STACK），否則，通過CONFIG_SYS_INIT_SP_ADDR定義堆棧基址。

b）調用board_init_f_alloc_reserve介面，從堆棧開始的地方，為u-boot中大名鼎鼎的GD ('global data') 數據結構，分配空間。

c）調用board_init_f_init_reserve介面，對GD進行初始化。

2）調用board_init_f函數，完成一些前期的初始化工作，例如：

a）點亮一個Debug用的LED燈，表示u-boot已經活了。

b）初始化DRAM、DDR等system範圍的RAM等。

c）計算後續代碼需要使用的一些參數，包括relocation destination、the future stack、the future GD location等。

註5：關於u-boot的relocation操作，後續會有專門的文章介紹。

3）如果當前是SPL（由CONFIG_SPL_BUILD控制），則_main函數結束，直接返回。如果是正常的u-boot，則繼續執行後續的動作。

4）根據board_init_f指定的參數，執行u-boot的relocation操作。

5）清除BBS段。

6）調用board_init_r函數，執行後續的初始化操作（已經不再本文的討論範圍了，具體請參考後續的分析文章）。

4. 總結

4.1 SPL功能

SPL是Secondary Program Loader的簡稱，之所以稱作secondary，是相對於ROM code來說的。SPL是u-boot中獨立的一個代碼分支，由CONFIG_SPL_BUILD配置項控制，是為了在正常的u-boot image之外，提供一個獨立的、小size的SPL image，通常用於那些SRAM比較小（或者其它限制）、無法直接裝載並運行整個u-boot的平臺。

如果使用了SPL功能，u-boot的啟動流程通常是：

ROM code載入SPL並運行；

SPL進行必要的初始化之後，載入u-boot並運行；

u-boot進行後續的操作。

因此，如果使用SPL功能，需要儘可能的減少SPL的代碼量，以減小它的size。

4.2 配置項總結

經過第3章的流程分析，我們可以總結出和“平臺相關部分的啟動流程”有關的配置項，記錄如下：

CONFIG_SYS_RESET_SCTRL，控制是否在啟動的時候reset SCTRL寄存器，一般不需要打開；

CONFIG_ARM_ERRATA_XXX，控制ARM core的勘誤信息，一般不需要打開；

CONFIG_GICV2、CONFIG_GICV3，控制GIC的版本，用到的時候再說明；

CONFIG_ARMV8_MULTIENTRY，控制是否在u-boot中使用多CPU，一般不需要；

CONFIG_SPL_BUILD，是否是能SPL的編譯，需要的話可以打開；

CONFIG_SPL_STACK，如果配置了CONFIG_SPL_BUILD，是否為SPL image配置單獨的stack（SP基址），如果需要，通過該配置項配置，如果不需要，則使用CONFIG_SYS_INIT_SP_ADDR；