Linux-uboot-学习笔记（6）：uboot启动第一阶段源码分析

uboot启动的第一阶段主要是start.S文件，也就是在BL1阶段将SD卡的前16K内容加载到SRAM中执行的那部分，从而指导第二阶段BL2的启动任务。

start.S源码分析

头文件包含（28-33）

在这里插入图片描述
#include <config.h>。config.h是在include目录下的，这个文件不是源码中本身存在的文件，而是配置过程中自动生成的文件。（详见mkconfig脚本）。这个文件的内容其实是包含了一个头文件：#include <configs/x210_sd.h>。经过分析后，发现start.S中包含的第一个头文件就是：include/configs/x210_sd.h，这个文件是整个uboot移植时的配置文件。这里面是好多宏。因此这个头文件包含将include/configs/x210_sd.h文件和start.S文件关联了起来。因此之后在分析start.S文件时，主要要考虑的就是x210_sd.h文件。
#include <version.h>。include/version.h中包含了include/version_autogenerated.h，这个头文件就是配置过程中自动生成的。里面就一行内容：#define U_BOOT_VERSION “U-Boot 1.3.4”。这里面定义的宏U_BOOT_VERSION的值是一个字符串，字符串中的版本号信息来自于Makefile中的配置值。这个宏在程序中会被调用，在uboot启动过程中会串口打印出uboot的版本号，那个版本号信息就是从这来的。
#include <asm/proc/domain.h>。asm目录不是uboot中的原生目录，uboot中本来是没有这个目录的。asm目录是配置时创建的一个符号链接，实际指向的是就是asm-arm，实际文件是：include/asm-arm/proc-armv/domain.h。

通过符号链接的目的：这样的设计主要是为了可移植性。因为如果直接包含，则start.S文件和CPU架构（和硬件）有关了，可移植性就差了。如果要移植其他型号，只需要在配置文件中改变符号链接即可，start.S文件则不需要进行改变。

启动代码的16字节头（49-54）

在这里插入图片描述
后面通过计算校验和重新填充到这里，作为SD卡启动时的16字节校验头。

寻找程序入口（57）

在C语言中整个项目的入口就是main函数，但在uboot中因为有汇编阶段参与，因此不能直接找main.c。整个程序的入口取决于链接脚本中ENTRY声明的地方。在u-boot.lds文件中有ENTRY(_start) 因此 _start 符号所在的文件就是整个程序的起始文件，_start所在处的代码就是整个程序的起始代码。
因此我们可以索引到start.S文件的第57行为ENTRY入口的_start符号所在地。
在这里插入图片描述

构建异常向量表（58-85）

在这里插入图片描述

.balignl 16,0xdeadbeef。这一句指令是让当前地址对齐排布，如果当前地址不对齐则自动向后走地址直到对齐，并且向后走的那些内存要用0xdeadbeef来填充。填充的那一块一般是没有用的。

TEXT_BASE（99-100）

在这里插入图片描述
这里的0xc3e00000就是我们链接时指定的uboot的链接地址。

设置CPU为SVC模式（141-149）

在这里插入图片描述
msr cpsr_c, #0xd3 将CPU设置为禁止FIQ IRQ，ARM状态，SVC模式。
其实ARM CPU在复位时默认就会进入SVC模式，但是这里还是使用软件将其置为SVC模式。整个uboot工作时CPU一直处于SVC模式。

设置L2、L1cache和MMU（200-221）

在这里插入图片描述
使能L2 cache。

刷新L1 cache的icache和dcache和关闭MMU。

启动介质选择（224-227）

在这里插入图片描述
从哪里启动是由SoC的OM5:OM0这6个引脚的高低电平决定的。
实际上在210内部有一个寄存器（地址是0xE0000004），这个寄存器中的值是硬件根据OM引脚的设置而自动设置值的。这个值反映的就是OM引脚的接法（电平高低），也就是真正的启动介质是谁。我们代码中可以通过读取这个寄存器的值然后判断其值来确定当前选中的启动介质是Nand还是SD还是其他的。
start.S的225-227行执行完后，在r2寄存器中存储了一个数字，这个数字等于某个特定值时就表示SD启动，等于另一个特定值时表示从Nand启动····
通过计算可得r2的值为0xc对应到SD卡启动：
在这里插入图片描述
260行中给r3中赋值 #BOOT_MMCSD(0x03)，这个在SD启动时实际会被执行，因此执行完这一段代码后r3中存储了0x03，以后备用。

设置SRAM中的栈（284-286）

在这里插入图片描述
284-286行第一次设置栈。这次设置栈是在SRAM中设置的，因为当前整个代码还在SRAM中运行，此时DDR还未被初始化还不能用。栈地址0xd0036000是自己指定的，指定的原则就是这块空间只给栈用，不会被别人占用。
在调用函数前初始化栈，主要原因是在被调用的函数内还有再次调用函数，而BL只会将返回地址存储到LR中，但是我们只有一个LR，所以在第二层调用函数前要先将LR入栈，否则函数返回时第一层的返回地址就丢了。

紧接着调用lowlevel_init函数，该函数用来初始化一些基本的功能。

lowlevel_init（288）

该函数位于uboot/board/samsumg/x210/lowlevel_init.S：
（1）压栈（42）
在这里插入图片描述
因为在进入函数中，lr中存在的是函数的返回地址，但是在后面还要调用其他函数，所以需要把lr压栈，防止把函数返回地址丢掉。
（2）检查复位状态（46-52）

复杂CPU允许多种复位情况。譬如直接冷上电、热启动、睡眠(低功耗)状态下的唤醒等，这些情况都属于复位。所以我们在复位代码中要去检测复位状态，来判断到底是哪种情况。
判断哪种复位的意义在于：冷上电时DDR是需要初始化才能用的；而热启动或者低功耗状态下的复位则不需要再次初始化DDR。

（3）IO状态恢复（55-59）
（4）关看门狗（61-64）
（5）SRAM SROM相关GPIO设置（66-97）
（6）供电锁存（100-104）
（7）判断当前代码执行位置（110-115）
在这里插入图片描述
这几行代码的作用就是判定当前代码执行的位置在SRAM中还是在DDR中。为什么要做这个判定？原因1：BL1（uboot的前一部分）在SRAM中有一份，在DDR中也有一份，因此如果是冷启动那么当前代码应该是在SRAM中运行的BL1，如果是低功耗状态的复位这时候应该就是在DDR中运行的。原因2：我们判定当前运行代码的地址是有用的，可以指导后面代码的运行。譬如在lowlevel_init.S中判定当前代码的运行地址，就是为了确定要不要执行时钟初始化和初始化DDR的代码。如果当前代码是在SRAM中，说明冷启动，那么时钟和DDR都需要初始化；如果当前代码是在DDR中，那么说明是热启动则时钟和DDR都不用再次初始化。

（8）初始化时钟和DDR（117-121）
在这里插入图片描述
system_clock_init：在x210_sd.h中300行到428行，都是和时钟相关的配置值。这些宏定义就决定了210的时钟配置是多少。也就是说代码在lowlevel_init.S中都写好了，但是代码的设置值都被宏定义在x210_sd.h中了。因此，如果移植时需要更改CPU的时钟设置，根本不需要动代码，只需要在x210_sd.h中更改配置值即可。

mem_ctrl_asm_init：该函数用来初始化DDR，在uboot中DMC0的256MB内存地址范围为0x30000000-0x3FFFFFFF。我们需要的内存配置值在x210_sd.h的438行到468行之间。分析的时候要注意条件编译的条件，配置头文件中考虑了不同时钟配置下的内存配置值，这个的主要目的是让不同时钟需求的客户都能找到合适自己的内存配置值。
（9）初始化串口（124-127）
在这里插入图片描述
执行到pop {pc} 表示出栈，则lowlevel_init函数执行完成。这时从栈中获取返回地址，继续执行start.S中lowlevel_init函数之后的代码。

在lowlevel_init.S中进行的任务： 检查复位状态、IO恢复、关看门狗、开发板供电锁存、时钟初始化、DDR初始化、串口初始化并打印’O’、tzpc初始化、打印’K’。

再次设置栈（297-299）

在这里插入图片描述
之前在调用lowlevel_init程序前设置过1次栈（start.S 284-287行），那时候因为DDR尚未初始化，因此程序执行都是在SRAM中，所以在SRAM中分配了一部分内存作为栈。本次因为DDR已经被初始化了，因此要把栈挪移到DDR中，所以要重新设置栈，这是第2次（start.S 297-299行）；这里实际设置的栈的地址是33E00000（代码段的物理基地址），刚好在uboot的代码段的下面紧挨着。
为什么要再次设置栈？DDR已经初始化了，已经有大片内存可以用了，没必要再把栈放在SRAM中可怜兮兮的了。

再次判断当前地址决定是否进行重定位（305-310）

在这里插入图片描述
再次用相同的代码判断运行地址是在SRAM中还是DDR中，不过本次判断的目的不同（上次判断是为了决定是否要执行初始化时钟和DDR的代码）这次判断是为了决定是否进行uboot的relocate。
冷启动时当前情况是uboot的前一部分（16kb或者8kb）开机自动从SD卡加载到SRAM中正在运行，uboot的第二部分（其实第二部分是整个uboot）还躺在SD卡的某个扇区开头的N个扇区中。此时uboot的第一阶段已经即将结束了（第一阶段该做的事基本做完了），结束之前要把第二部分加载到DDR中链接地址处（33e00000），这个加载过程就叫重定位。

判断SD卡启动通道（305-332）

在这里插入图片描述

不管通过什么方法，最终结果都会跳转到mmcsd_boot函数中。

mmcsd_boot函数（343-351）

在这里插入图片描述
真正的重定位是通过调用movi_bl2_copy函数完成的，在uboot/cpu/s5pc11x/movi.c中。是一个C语言的函数。
copy_bl2(2, MOVI_BL2_POS, MOVI_BL2_BLKCNT, CFG_PHY_UBOOT_BASE, 0);
分析参数：2表示通道2；MOVI_BL2_POS是uboot的第二部分在SD卡中的开始扇区，这个扇区数字必须和烧录uboot时烧录的位置相同；MOVI_BL2_BLKCNT是uboot的长度占用的扇区数；CFG_PHY_UBOOT_BASE是重定位时将uboot的第二部分复制到DDR中的起始地址（33E00000）。

补充：虚拟地址和物理地址

物理地址就是物理设备设计生产时赋予的地址。 像裸机中使用的寄存器的地址就是CPU设计时指定的，这个就是物理地址。物理地址是硬件编码的，是设计生产时确定好的，一旦确定了就不能改了。
虚拟地址意思就是在我们软件操作和硬件被操作之间增加一个层次，叫做虚拟地址映射层。有了虚拟地址映射后，软件操作只需要给虚拟地址，硬件操作还是用原来的物理地址，映射层建立一个虚拟地址到物理地址的映射表。当我们软件运行的时候，软件中使用的虚拟地址在映射表中查询得到对应的物理地址再发给硬件去执行（虚拟地址到物理地址的映射是不可能通过软件来实现的）。

MMU单元
MMU就是memory management unit，内存管理单元。MMU实际上是SOC中一个硬件单元，它的主要功能就是实现虚拟地址到物理地址的映射。
MMU单片在CP15协处理器中进行控制，也就是说要操控MMU进行虚拟地址映射，方法就是对cp15协处理器的寄存器进行编程。

TTB
translation table base，转换表基地址。转换表是建立一套虚拟地址映射的关键。转换表分2部分，表索引和表项。表索引对应虚拟地址，表项对应物理地址。 一对表索引（虚拟地址）和表项（物理地址）构成一个转换表单元，能够对一个内存块进行虚拟地址转换。（映射中基本规定中规定了内存映射和管理是以块为单位的，至于块有多大，要看你的MMU的支持和你自己的选择。在ARM中支持3种块大小，细表1KB、粗表4KB、段1MB）。整个建立虚拟地址映射的主要工作就是建立这张转换表。

建立地址映射

（1）使能域访问（359-363）
在这里插入图片描述
cp15协处理器内部有c0到c15共16个寄存器，这些寄存器每一个都有自己的作用。我们通过mrc和mcr指令来访问这些寄存器。所谓的操作cp协处理器其实就是操作cp15的这些寄存器。
c3寄存器在mmu中的作用是控制域访问。域访问是和MMU的访问控制有关的。
（2）设置TTB（365-371）
在这里插入图片描述
转换表放置在内存中的，放置时要求起始地址在内存中要xx位对齐。转换表不需要软件去干涉使用，而是将基地址TTB设置到cp15的c2寄存器中，然后MMU工作时会自动去查转换表。
（3）使能MMU单元（374-382）

cp15的c1寄存器的bit0控制MMU的开关。只要将这一个bit置1即可开启MMU。开启MMU之后上层软件层的地址就必须经过TT的转换才能发给下层物理层去执行。
（4）找到映射表位于lowlevel_init.S中：
在这里插入图片描述
这里从593-653，是建立虚拟映射表的过程。

通过这个宏来传参，从而建立虚拟映射表。
在这里插入图片描述
整个转换表可以看作是一个int类型的数组，数组中的一个元素就是一个表索引和表项的单元。数组中的元素值就是表项，这个元素的数组下标就是表索引。

ARM的段式映射中长度为1MB，因此一个映射单元只能管1MB内存，那我们整个4G范围内需要4G/1MB=4096个映射单元，也就是说这个数组的元素个数是4096.实际上我们做的时候并没有依次单个处理这4096个单元，而是把4096个分成几部分，然后每部分用for循环做相同的处理。

第3次设置栈（386-398）

在这里插入图片描述
第三次设置栈。这次设置栈还是在DDR中，之前虽然已经在DDR中设置过一次栈了，但是本次设置栈的目的是将栈放在比较合适（安全，紧凑而不浪费内存）的地方。
我们实际将栈设置在uboot起始地址上方2MB处，这样安全的栈空间是：2MB-uboot(200K)大小-0x1000=1.8MB左右。这个空间既没有太浪费内存，又足够安全。