U-BOOT小全（五）：BootLoader源码（SPL-UBoot 2）

TrustZone_

已于 2022-10-22 22:23:43 修改

阅读量1.4k

点赞数 1

分类专栏： # Linux内核初始化文章标签： linux Android kernel ARM UBoot

于 2022-10-22 22:22:41 首次发布

本文链接：https://blog.csdn.net/weixin_45264425/article/details/127467587

版权

Linux内核初始化专栏收录该内容

37 篇文章

订阅专栏

前面我们分析到了s_init函数，现在继续。

1、s_init函数

然后调用s_init来进行更多模块的初始化。函数s_init在arch/arm/cpu/armv7/sunxi/board.c中定义，代码如下。

87 void s_init(void)
 88 {
 89 #if !defined CONFIG_SPL_BUILD && defined CONFIG_SUN7I
 90         /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
 91         asm volatile(
 92                 "mrc p15, 0, r0, c1, c0, 1\n"
 93                 "orr r0, r0, #1 << 6\n"
 94                 "mcr p15, 0, r0, c1, c0, 1\n");
 95 #endif  
 96 
 97         watchdog_init();
 98         clock_init();
 99         timer_init();
100         gpio_init();
101         
102 #ifdef CONFIG_SPL_BUILD
103         gd = &gdata; 
104         preloader_console_init();
105         
106 #ifdef CONFIG_SPL_I2C_SUPPORT
107         /* Needed early by sunxi_board_init if PMU is enabled */
108         i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
109 #endif
110         
111         sunxi_board_init();
112 #endif
113 }

在该函数内部，**对watchdog、时钟、定时器timer和gpio进行初始化，并对console终端进行初始化，然后进行i2c的初始化，**最后调用sunxi_board_init函数，该函数在board/sunxi/board.c中定义，代码如下。

2、sunxi_board_init

80 void sunxi_board_init(void)
 81 {
 82         int power_failed = 0;
 83         unsigned long ramsize;
 84 
 85         printf("DRAM:");
 86         ramsize = sunxi_dram_init();
 87         printf(" %lu MiB\n", ramsize >> 20);
 88         if (!ramsize)
 89                 hang();
 90 
 91 #ifdef CONFIG_AXP152_POWER
 92         power_failed = axp152_init();
 93         power_failed |= axp152_set_dcdc2(1400);
 94         power_failed |= axp152_set_dcdc3(1500);
 95         power_failed |= axp152_set_dcdc4(1250);
 96         power_failed |= axp152_set_ldo2(3000);
 97 #endif
 98 #ifdef CONFIG_AXP209_POWER
 99         power_failed |= axp209_init();
100         power_failed |= axp209_set_dcdc2(1400);
101 #ifdef CONFIG_FAST_MBUS
102         power_failed |= axp209_set_dcdc3(1300);
103 #else
104         power_failed |= axp209_set_dcdc3(1250);
105 #endif
106         power_failed |= axp209_set_ldo2(3000);
107         power_failed |= axp209_set_ldo3(2800);
108         power_failed |= axp209_set_ldo4(2800);
109 #endif
110
111         /*
112          * Only clock up the CPU to full speed if we are reasonably
113          * assured it's being powered with suitable core voltage
114          */
115         if (!power_failed)
116 #ifdef CONFIG_SUN7I
117                 clock_set_pll1(912000000);
118 #else
119                 clock_set_pll1(1008000000);
120 #endif
121         else
122                 printf("Failed to set core voltage! Can't set CPU frequency\n");

该函数首先对DRAM进行初始化，然后利用前面初始化的i2c来对axp209电源管理芯片进行配置。

现在回到start.S当中，reset复位异常向量处理的最后一步是调用_main函数。_main函数存在于arch/arm/lib/crt0.S中，在分析代码之前，可以先看看这个函数的注释，注释写的非常详细。

3、_main函数

 13 /*
 14  * This file handles the target-independent stages of the U-Boot
 15  * start-up where a C runtime environment is needed. Its entry point
 16  * is _main and is branched into from the target's start.S file.
 17  *
 18  * _main execution sequence is:
 19  *
 20  * 1. Set up initial environment for calling board_init_f().
 21  *    This environment only provides a stack and a place to store
 22  *    the GD ('global data') structure, both located in some readily
 23  *    available RAM (SRAM, locked cache...). In this context, VARIABLE
 24  *    global data, initialized or not (BSS), are UNAVAILABLE; only
 25  *    CONSTANT initialized data are available.
 26  *
 27  * 2. Call board_init_f(). This function prepares the hardware for
 28  *    execution from system RAM (DRAM, DDR...) As system RAM may not
 29  *    be available yet, , board_init_f() must use the current GD to
 30  *    store any data which must be passed on to later stages. These
 31  *    data include the relocation destination, the future stack, and
 32  *    the future GD location.
 33  *
 34  * (the following applies only to non-SPL builds)
 35  *
 36  * 3. Set up intermediate environment where the stack and GD are the
 37  *    ones allocated by board_init_f() in system RAM, but BSS and
 38  *    initialized non-const data are still not available.
 39  *
 40  * 4. Call relocate_code(). This function relocates U-Boot from its
 41  *    current location into the relocation destination computed by
 42  *    board_init_f().
 43  *
 44  * 5. Set up final environment for calling board_init_r(). This
 45  *    environment has BSS (initialized to 0), initialized non-const
 46  *    data (initialized to their intended value), and stack in system
 47  *    RAM. GD has retained values set by board_init_f(). Some CPUs
 48  *    have some work left to do at this point regarding memory, so
 49  *    call c_runtime_cpu_setup.
 50  *
 51  * 6. Branch to board_init_r().
 52  */

我们对照注释先整理一下_main函数的执行顺序：

1）为调用board_init_f()函数准备最初的环境。

该环境仅仅提供一个栈和存储GD结构体（全局数据）的空间，它们都位于一些可用的RAM中（比如SRAM和锁定的缓存中）。在这样的环境下，可变的全局变量，包括已初始化的和未初始化的（BSS），都是不可用的；只有已初始化的常量才是可用的。

2）调用board_init_f()函数。

**该函数为后续在系统RAM（DRAM、DDR）中执行的代码准备好硬件环境。**由于此时系统RAM可能还不可用，board_init_f()函数必须使用当前的GD来存储任何必须传递到后续步骤的数据。这些数据包括重定位目的地址、重新定义的栈和重新定义的GD位置。

下面的步骤只有在non-SPL下才可用。
（这里我觉得其实对于我们实验室使用了安全启动的系统是不具备SPL的。因为加载uboot的东西是其他的image）

3）创建一个中间的环境：

栈和GD都在系统RAM中由board_init_f()函数分配，但是BSS和已初始化的非常量数据仍然不可用。

4）调用relocate_code()。

该函数将U-Boot从当前的位置重定位到由board_init_f()函数计算得出的重定位目的地址处。

5）为调用board_init_r()函数创建最终的环境。

该环境包括BSS（已经初始化为0）、已初始化的非常量数据（已初始化为预期的值）和系统RAM中的栈。GD保存着被board_init_f()函数设定的值。 某些CPU还有一些关于存储的工作要做，所以会调用c_runtime_cpu_setup函数。

6）跳转到board_init_r()函数。

阅览完代码注释后，再来分析一下代码。

 54 /*
 55  * entry point of crt0 sequence
 56  */
 57 
 58 ENTRY(_main)
 59 
 60 /*
 61  * Set up initial C runtime environment and call board_init_f(0).
 62  */
 63 
 64 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
 65         ldr     sp, =(CONFIG_SPL_STACK)
 66 #else
 67         ldr     sp, =(CONFIG_SYS_INIT_SP_ADDR)
 68 #endif
 69         bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
 70         sub     sp, sp, #GD_SIZE        /* allocate one GD above SP */
 71         bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
 72         mov     r9, sp          /* GD is above SP */
 73         mov     r0, #0
 74         bl      board_init_f
 75 
 76 #if ! defined(CONFIG_SPL_BUILD)
 77 
 78 /*
 79  * Set up intermediate environment (new sp and gd) and call
 80  * relocate_code(addr_moni). Trick here is that we'll return
 81  * 'here' but relocated.
 82  */
 83 
 84         ldr     sp, [r9, #GD_START_ADDR_SP]/* sp = gd->start_addr_sp */
 85         bic     sp, sp, #7      /* 8-byte alignment for ABI compliance */
 86         ldr     r9, [r9, #GD_BD]                /* r9 = gd->bd */
 87         sub     r9, r9, #GD_SIZE                /* new GD is below bd */
 88 
 89         adr     lr, here
 90         ldr     r0, [r9, #GD_RELOC_OFF]         /* r0 = gd->reloc_off */
 91         add     lr, lr, r0
 92         ldr     r0, [r9, #GD_RELOCADDR]         /* r0 = gd->relocaddr */
 93         b       relocate_code
 94 here:
 95 
 96 /* Set up final (full) environment */
 97 
 98         bl      c_runtime_cpu_setup     /* we still call old routine here */
 99 
100         ldr     r0, =__bss_start        /* this is auto-relocated! */
101         ldr     r1, =__bss_end          /* this is auto-relocated! */
102 
103         mov     r2, #0x00000000         /* prepare zero to clear BSS */
104 
105 clbss_l:cmp     r0, r1        /* while not at end of BSS */
106         strlo   r2, [r0]      /* clear 32-bit BSS word */
107         addlo   r0, r0, #4    /* move to next */
108         blo     clbss_l
109 
110         bl coloured_LED_init
111         bl red_led_on
112 
113         /* call board_init_r(gd_t *id, ulong dest_addr) */
114         mov     r0, r9                  /* gd_t */
115         ldr     r1, [r9, #GD_RELOCADDR] /* dest_addr */
116         /* call board_init_r */
117         ldr     pc, =board_init_r       /* this is auto-relocated! */
118 
119         /* we should not return here. */
120 
121 #endif
122 
123 ENDPROC(_main)

因为我们采用了SPL框架，所以后面的步骤3_{6都不会执行，也就是代码行76}121不会执行。第64~68行代码设定栈指针，然后保证栈指针的8字节对齐，接着在栈的顶部为GD结构体分配存储空间，由于栈指针在分配空间时往底部移动了，所以要重新保证栈指针的8字节对齐。在设定栈指针的字节对齐后，有一句mov r9，sp，因为前面的操作中r9保存的是GD的地址，所以这里表明GD位置位于栈指针之上。

最后调用board_init_f(0)函数，注意这个函数是带有参数的。参数为赋值为0的r0。具体的调用规则可以查看ATPCS(ARM-THUMB procedure call standard)。

关于ATPCS，ARM官网上有一篇名为《The ARM-THUMB Procedure Call Standard》的文档对其做了全面的介绍，网址是http://infocenter.arm.com/help/topic/com.arm.doc.espc0002/ATPCS.pdf。这里，我们简单了解一下ATPCS，ATPCS统一了APCS(ARM Procedure Call Standard)和TPCS(Thumb Procedure Call Standard)两种标准。

ATPCS标准提出的目的是：

1）同时支持ARM态和Thumb态。
2）支持ARM态和Thumb态的联合工作。
3）支持更小的代码体积、嵌入式应用的合适功能、高性能。
4）支持可选的浮点运算架构和指令集。
5）二进制兼容APCS和TPCS。


ATPCS规定了一些子程序之间的基本调用规则。这些基本规则包括子程序调用过程中寄存器的使用规则、数据栈的使用规则和参数的传递规则。

为适应一些特定的需要，对这些基本的调用规则进行一些修改，可得到几种不同的子程序调用规则，这些特定的调用规则包括：支持数据栈限制检查的ATPCS、支持只读段位置无关的ATPCS、支持可读写段位置无关的ATPCS、支持ARM程序和Thumb程序混合使用的ATPCS、处理浮点运算的ATPCS。

在这里，board_init_f函数在arch/arm/lib里的board.c和spl.c中都有定义，因为这里还是SPL的启动阶段，所以应该用的是spl.c中的board_init_f函数。这可以从当前目录中的Makefile来确认一下：

ifndef CONFIG_SPL_BUILD
ifdef CONFIG_ARM64
obj-y += relocate_64.o
else
obj-y += relocate.o
endif
ifndef CONFIG_SYS_GENERIC_BOARD
obj-y += board.o
endif
obj-$(CONFIG_CPU_V7M) += cmd_boot.o
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
else
obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
endif

在定义了CONFIG_SPL_BUILD的条件下，我们链接的是spl.o中的board_init_f函数。

在arch/arm/lib/spl.c中定义的board_init_f函数有如下的注释：

/*
 * In the context of SPL, board_init_f must ensure that any clocks/etc for
 * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
 * and call board_init_f.  We provide this version by default but mark it
 * as __weak to allow for platforms to do this in their own way if needed.
 */

注释中说，在SPL启动阶段，board_init_f函数必须保证用于DDR的时钟等配置完成，并且保证栈指针是有效的，而且清除了BSS。这里也将它标记为__weak属性，如果需要的话，就可以重写该函数。

4、board_init_f

在arch/arm/lib/spl.c中定义的board_init_f函数如下。

 26 void __weak board_init_f(ulong dummy)
 27 {     
 28         /* Clear the BSS. */
 29         memset(__bss_start, 0, __bss_end - __bss_start);
 30 
 31         /* Set global data pointer. */
 32         gd = &gdata;
 33 
 34         board_init_r(NULL, 0);
 35 }

该函数对BSS进行清零操作，然后调用common/spl/spl.c中的board_init_r函数，该函数首先判断从哪种存储设备启动，这里给出RAM、MMC和NAND的代码。

5、board_init_r

155         boot_device = spl_boot_device();
156         debug("boot device - %d\n", boot_device);
157         switch (boot_device) {
158 #ifdef CONFIG_SPL_RAM_DEVICE
159         case BOOT_DEVICE_RAM:
160                 spl_ram_load_image();
161                 break;
162 #endif
163 #ifdef CONFIG_SPL_MMC_SUPPORT
164         case BOOT_DEVICE_MMC1:
165         case BOOT_DEVICE_MMC2:
166         case BOOT_DEVICE_MMC2_2:
167                 spl_mmc_load_image();
168                 break;
169 #endif
170 #ifdef CONFIG_SPL_NAND_SUPPORT
171         case BOOT_DEVICE_NAND:
172                 spl_nand_load_image();
173                 break;
174 #endif

第158~162行：如果定义了CONFIG_SPL_RAM_DEVICE，并且设备是RAM，则执行spl_ram_load_image()，也就是将image下载到RAM中。

第163~169行：如果定义了CONFIG_SPL_MMC_SUPPORT，并且设备是MMC/SD，则执行spl_mmc_load_image()，也就是将image从mmc/sd里面读取到RAM中。

第170~174行：如果定义了CONFIG_SPL_NAND_SUPPORT，并且设备是Nand Flash，则执行spl_nand_load_image(),也就是将image从Nand Flash中读取到RAM中。

这里我们用的是common/spl/spl_mmc.c中的spl_mmc_load_image()函数，该函数首先初始化MMC接口。

spl_mmc_load_image()

 80         mmc_initialize(gd->bd);
 81         /* We register only one device. So, the dev id is always 0 */
 82         mmc = find_mmc_device(0);
 83         printf("@@ debug by baikal      use the only one device\n");
 84         if (!mmc) {
 85 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 86                 puts("spl: mmc device not found!!\n");
 87 #endif
 88                 hang();
 89         }
 90         printf("@@  debug by baikal    here we mmc_init\n");
 91         err = mmc_init(mmc);
 92         if (err) {
 93 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 94                 printf("spl: mmc init failed: err - %d\n", err);
 95 #endif
 96                 hang();
 97         }

然后根据boot_mode将U-Boot加载到内存RAM中。

99         boot_mode = spl_boot_mode();
100         if (boot_mode == MMCSD_MODE_RAW) {
101                 debug("boot mode - RAW\n");
102 #ifdef CONFIG_SPL_OS_BOOT
103                 if (spl_start_uboot() || mmc_load_image_raw_os(mmc))
104 #endif
105                 err = mmc_load_image_raw(mmc,
106                 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
107 #ifdef CONFIG_SPL_FAT_SUPPORT
108         } else if (boot_mode == MMCSD_MODE_FAT) {

其中，CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR的定义如下：

#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 80      /* 40KiB */

这个表明U-Boot放置在MMC的40KB偏移处，因为是在8KB偏移处放置32KB大小的SPL，所以40KB=8KB+32KB。其实SPL用不了32KB大小，但是因为SPL是放置在内部的32KB的SRAM中运行，所以给SPL预留32KB的空间。

在mmc_load_image_raw函数中解析镜像头，根据镜像头的结构体数据将U-Boot加载到合适的DDR地址。

我们可以看一下u-boot.img的头：

    bash-4.2# tools/mkimage -l u-boot.img 
Image Name:   U-Boot 2014.04-rc2-10390-g96510e
Created:      Sun Jun 29 16:51:19 2014
Image Type:   ARM U-Boot Firmware (uncompressed)
Data Size:    240744 Bytes = 235.10 kB = 0.23 MB
Load Address: 4a000000
Entry Point:  00000000

根据该头部信息，我们得知SPL会将U-Boot加载到0x4a000000地址处运行。当要启动的image位于RAM中后，我们就可以启动它。

然后接着

224         switch (spl_image.os) {
225         case IH_OS_U_BOOT:
226                debug("Jumping to U-Boot\n");
227                break;
228 #ifdef CONFIG_SPL_OS_BOOT
229         case IH_OS_LINUX:
230                debug("Jumping to Linux\n");
231                spl_board_prepare_for_linux();
232                jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
233 #endif
234         default:
235                debug("Unsupported OS image.. Jumping nevertheless..\n");
236         }
237         jump_to_image_no_args(&spl_image);

其中，第224行：判断image的类型。

第225~227行：如果是U-Boot，则直接到237行去运行U-Boot。

第228~233行：如果是Linux，则到232行去启动Linux。

至此，SPL结束它的生命，控制权交于U-Boot或Linux。

（这玩意说明这个board_init_r也是有多个存在，或者是复用，不然这个玩意怎么能跳过UBoot自己去加载Linux。或者是说其实SPL本身也可以去加载Linux?因为他的功能不就是加载Uboot，然后Uboot去加载Kernel，现在我不要你了，我自己去加载kernel，省事。说起这个，对哦？为什么不直接加载Kernel，而要通过UBoot，通过我的认识，应该是SPL就那么大点，干不了那么对事情。通过分级加载来省了内存。其实要解决这个疑惑，可以后面来看看这个下一个阶段做了什么工作，是SPL不能完成的，）

在这里，整个过程是SPL→U-Boot→Linux。我们分析了**SPL调用U-Boot的过程，**接下来再分析一下U-Boot调用Linux的过程。

参考资料：
《深入理解BootLoader》