ROCKCHIP平台uboot启动篇（bootrom）

总目录

---

前言

本文讲述uboot的启动流程，将从soc的启动开始，到arch级和板初始化展开，揭示uboot如何启动linux内核的过程。

硬件平台：rk356x、rk3588等适用

---

总体流程

rk平台根据前级loader（preloader）是否开源，目前是2套启动方案：
第一种：bootrom-》ddr bin-》miniloader-》trust-》uboot-》kernel
第二种：bootrom-》tpl（这里相当于ddr bin）-》spl（这里相当于miniloader）-》trust-》uboot-》kernel
tpl+spl实现的是和ddr bin和miniloader一致的功能，相互替换。

bootflow1是bin ddr和miniloader的启动过程，bootflow2是tpl、spl启动过程。

一、Romboot

由于最开始存储器还未初始化，不能直接运行存储器上的代码，cpu只能访问可以直接寻址的存储器，如rom。

板子上电后，首先执行的是soc内部rom中的一段固定、无法修改的代码。这里一般称romboot，也有的地方称为bl1。

对于soc说来，上电复位了才是一切的始端。pmic为soc提供稳定电流，复位电路会将所有的寄存器和内存重置到起始状态，同时确认pll输出稳定时钟，以确保一个干净的稳定的启动状态。这里有点类似计算机bios复位。

然后，启动代码根据寄存器、外部soc管脚的配置，决定进入下载模式，还是从某种存储介质（sd卡，emmc、flash等，各平台可能有所差异）启动uboot。

以下是rk356x的数据手册部分截图

以下是rk3588数据手册部分截图。

从数据手册上来看rk3588、rk356x不仅支持从这些介质上启动，还可以通过usb otg下载系统代码，但启动接口有略微差别。

二、preloader

一般来说这里的就是ddr bin和miniloader或者tpl、spl阶段，也有的地方称bl2。

ddr bin 运行在sram中，负责初始化内存控制器，为后续程序提供必要哦的存储空间。

miniloader启承上启下的作用，完成硬件的基础初始化，加载后续固体（如trust）。

tpl（tiny program loader）和 spl（secondary program loader）与上述2者功能一致。

随便提一嘴，一般存储介质找有效的可执行文件，一般需要head头标识，在rk平台称为idb，只要符合idb格式的并放在存储介质指定位置，都可以被maskrom加载（MASK ROM是有原始数据的样本ROM）。

在rk的sdk里的mkimage脚本呢里有一段以下代码

tools/mkimage -n rkxxxx -T rksd -d rkxx_ddr_vx.xx.bin idbloader.img
cat rkxx_miniloader_vx.xx.bin >> idbloader.img

idbloader.img打包完成后会由其中rkxx_miniloader_xxx.bin加载uboot.img文件。

顺便聊聊rom、sram、ddr吧。

嵌入式系统的内存一般包含ROM、SRAM和DDR，其中ROM和SRAM位于SOC片内，DDR位于芯片外部。它们的特点如下：
（1）ROM中的内容断电后不会消失，不仅可用于代码执行，还可以用于镜像存储，但其只有只读权限
（2）SRAM和DDR中的内容在断电后都会消失，因此只能被用于代码的动态执行，而不能用于镜像存储
（3）ROM和SRAM都是直接连接总线上，系统上电后即可直接执行。而DDR需要通过DDR phy和DDR controller连接到总线上，因此使用之前必须要先对其执行初始化操作
　　根据上述各种内存的特点和前面镜像加载启动流程的需求，在内存规划中我们需要考虑以下几个问题：
（1）由于bootrom代码需要固化到ROM中，且是系统最先执行的，因此ROM地址需要被映射到cpu的重启地址处
（2）由于ROM是只读的，bootrom镜像除了代码段和只读数据段之外还包含可读写数据段，这部分数据在bootrom启动时需要从ROM重定位到SRAM中
（3）由于bootrom被固化在ROM中，芯片出产后就不能更改，因此DDR初始化代码不能集成到bootrom中。故ddr bin需要被加载到SRAM中执行，且在ddr bin中执行DDR初始化流程
（4）ddr bin之后的其它镜像既可以运行于SRAM中，也可以运行于DDR中
（5）从前面的镜像启动流程可知，若ddr bin运行于secure EL1下，当其执行完成后，需要通过smc再次陷入bootrom去执行BL31流程，因此BL2和BL1的地址不能有重叠
（6）BL31除了执行启动流程外，在系统运行过程中还会以secure monitor的方式驻留，为normal空间的smc异常提供服务历程，以及为normal os和trust os之间提供消息转发、中断路由转发等功能。因此，BL31镜像需要永久驻留内存，在系统启动完成后不能被回收
（7）与BL31类似，BL32在启动后需要驻留内存为系统提供安全相关服务，因此为其所分配的内存也不能被回收
（8）除此之外，BL1、BL2和BL33（一般为uboot）的内存在系统启动完成后都可以被释放给操作系统使用。

ps：smc是armv8支持的异常跳转指令，它用于程序从EL1或EL2跳转到EL3异常等级。
至于什么是EL1、EL2、EL3以后会讲到。

三、trust

安全相关，与产品平台有关，有的产品可能用不到。也有地方称bl31 bl32。
在arm产品中若系统不支持TRUST OS，则可去掉BL32，若不支持EL3异常等级及secure monitor，则可去掉BL31。

以下为sdk uboot目录下bl31的相关bin文件，从命名可看出对应地址。

rockchip的trust可以理解为ARM Trusted Firmware + OP-TEE OS的功能合集。它实现了安全世界里需求的共呢以及Secure Monitor （两个世界核心代码）的功能。

待续。。。

---