RK33XX/RK35XX系列设备启动流程、写入系统及编译流程

[13584452567]

1. 启动介绍
   更多细节可看瑞芯微的wiki：http://opensource.rock-chips.com/wiki_Boot_option
   以RK3399为例，
   RK3399启动的时候，首先执行BootRom中的代码，然后BootRom将加载第二阶段引导程序（SPL）。不管是执行BootRom还是执行SPL，都需要内存。到这一阶段，仅有芯片内部的SRAM被初始化且能够被程序使用。但是芯片的Cache都很小，几乎不足以完整的载入完整的引导加载程序。所以，RK3399在每次复位后，都会预先加载辅助程序加载器，然后由其初始化容量更大的DDR内存，以便后续的引导程序有足够的内存运行。

第一阶段：硬件起始 开天辟地
芯片软件引导的起始，是硬件。对于ARM处理器，上电后，PC指针寄存器直接复位至零地址，随后从中断向量表表头的reset向量处，获得后续的代码加载地址。后续的代码便会完成硬件自检，基本初始化，输入输出支持等操作。我们一般将这段出厂就写在ROM里，负责启动后续需用户软件的软件成为BootRom，或是Rom Code。现在，我们一般不会使用严格意义上的只读存储器来存放这部分程序，但至少它是一块掉电不易失的存储设备，比如EEPROM,NOR FLASH。虽然一般我们没有权限修改BootRom，但这并不意味BootRom就是一个完全的黑盒，很多芯片都有外部配置引脚，通常是一个拨码开关。

ROM代码是芯片专有，且不能被任何的开源设备取代。RK3399有192K的INTMEM0和32K的BOOTROM。这两部分存储空间组成了最初的引导代码运行环境。芯片自检完成后，如果没有外部引脚的配置，SPL便会默认以：SPI NOR,SPI NAND,Emmc,SD/MMC的顺序查找存储控制器。如果在这些存储控制器的对应地址都没有找到idbloader.img，则进行USB端口的初始化工作。如果找到了idbloader.img，并且校验通过，则使用其来初始化主存DDR，并将boot启动代码拷贝到DDR，加载完整的Bootloader代码至DDR内存中运行。

第二阶段：软件接管 创生万物
在经过BootRom和IDBLoader完成了一系列的初始化工作之后，U-Boot现在应该已经被拷贝到DDR内部并开始运行。
U-Boot启动大多都分为两个阶段：
  第1阶段的主要任务是对依赖于CPU体系结构的相关硬件进行初始化，该阶段通常使用汇编语言实现。同时完成下面的五件任务：
  1) 基本的硬件设备初始化
  2) 为第2阶段准备RAM空间
  3) 如果是从某个固态存储媒质中启动，则复制Bootloader的第2阶段代码到RAM
  4) 设置堆栈
  5) 跳转到第2阶段的C程序入口
第2阶段通常使用C语言实现，以实现更复杂的功能，也使程序有更好的可读性和可移植性。在这一阶段，完成剩下硬件设备的初始化工作，检查系统内存的映射，拷贝内核和rootfs到RAM，为内核设置启动参数。完成之后运行内核。
在这之后的事就交给内核进行处理。

[13584452567]

这张图来自于RK的wiki。
上图中有4个启动流程。流程1是RK为自己的miniloader特别定制的，流程2是大部分SoC所使用的方式（即使用U-Boot TPL进行DDR初始化，SPL加载trust并跳转到下个阶段），流程3适用于有ATF支持的，带spl的RK3399处理器，流程4主要适用于不带trust的armv7指令集的SoC。
这四个流程主要关注前两个，如果你想给自己的板子移植主线U-Boot，那只需要关注流程2即可。

补充：ARM Trust Firmware
ATF里面将整个系统分为4个安全等级，即EL0、EL1、EL2、EL3。将整个安全启动流程不同阶段分为BL1、BL2、BL31、BL32、BL33。其中ATF的源码仓库提供了BL1,BL2,BL31的功能，RK只使用了其中的BL31的功能。
BL1和BL2有其自己的实现方式。故在RK平台上，一般可默认ATF指的就是BL31。BL32则使用的OP-TEE OS

对应关系大致为：
Maskrom（BootRom） -> BL1
Loader -> BL2
Trust -> BL31（ATF）+BL32（OP-TEE）
U-Boot -> BL33

[chouex]

OS里的blockdevice是不是只是emmc中的一部份? 由那開始? 因為我的盒子好像在OS中看不到u-boot的ROM, 只找到有armbian的BOOT/ROOTFS.

要換U-boot或者U-boot壞了是不是只可由usb firmware update更新?

*blockdecice指 lsblk能看到的设备

[13584452567]

OS里的blockdevice是不是只是emmc中的一部份? 由那開始? 因為我的盒子好像在OS中看不到u-boot的ROM, 只找到有armbian的BOOT/ROOTFS.

要換U-boot或者U-boot壞了是不是只可由usb firmware update更新?

block device是有文件系统的部分。gpt分区表并没有强制要求分区总长度必须等于闪存容量，所以oem都会在文件系统之外放一些固件，rockchip的miniloader和idbloader就是这样的。gpt分区表并未规划闪存最前的那一小部分，uboot就在那里。

嵌入式设备一般不需要更新引导，甚至大部分设备的内核也不会更新，参考安卓手机那些。不过rockchip如果uboot坏了的话，你可以用USB Download，也可以让系统启动其他介质上的系统。然后在另一个系统内通过dd来修复uboot。当然，uboot也有自己的紧急模式，那个里面也可以更新uboot。

[chouex]

Device          Start      End  Sectors  Size Type
/dev/mmcblk1p1  32768   555007   522240  255M Linux filesystem
/dev/mmcblk1p2 557056 61071326 60514271 28.9G Linux filesystem

確實mmcblk1p1是由32768(0x8000)開始, 不過前面基本是0, 不像是BOOT_START前面的內容。像是gpt分区表。
lsblk只有mmcblk1,mmcblk1boot0,mmcblk1boot1 3個block, (mmcblk1boot* 全0) 我覺得0~0x8000操作系統存取不了
0x8000是sector不是byte, 0~16MB就有數據了

hexdump /dev/mmcblk1 -n 0x8000 -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  02 00 ee ff ff ff 01 00  00 00 ff df a3 03 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  a3 f6 6b 46 00 00 00 00  01 00 00 00 00 00 00 00  |..kF............|
00000220  ff df a3 03 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  de df a3 03 00 00 00 00  5b 98 38 26 75 db 4b 46  |........[.8&u.KF|
00000240  b7 c6 fb 27 26 47 69 dd  02 00 00 00 00 00 00 00  |...'&Gi.........|
00000250  80 00 00 00 80 00 00 00  6f c3 83 9f 00 00 00 00  |........o.......|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000410  96 21 4b f8 07 65 f0 47  a4 9b c5 1e 0a 00 0d 5b  |.!K..e.G.......[|
00000420  00 80 00 00 00 00 00 00  ff 77 08 00 00 00 00 00  |.........w......|
00000430  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
00000440  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
00000450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000480  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000490  5d 08 c1 30 7c a5 25 45  90 90 a1 ea bb 2e 05 2b  |]..0|.%E.......+|
000004a0  00 80 08 00 00 00 00 00  de df a3 03 00 00 00 00  |................|
000004b0  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
000004c0  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00008000

binwalk(16MB)

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
246456        0x3C2B8         CRC32 polynomial table, little endian
316608        0x4D4C0         Flattened device tree, size: 20421 bytes, version: 17
8388608       0x800000        Flattened device tree, size: 2547 bytes, version: 17
9226288       0x8CC830        CRC32 polynomial table, little endian
9282196       0x8DA294        Android bootimg, kernel size: 1919249152 bytes, kernel addr: 0x5F6C656E, ramdisk size: 1919181921 bytes, ramdisk addr: 0x5700635F, product name: ""
9799680       0x958800        Flattened device tree, size: 20421 bytes, version: 17

refs:
https://opensource.rock-chips.com/wiki_Boot_option
https://opensource.rock-chips.com/wiki_Partitions

[13584452567]

Device          Start      End  Sectors  Size Type
/dev/mmcblk1p1  32768   555007   522240  255M Linux filesystem
/dev/mmcblk1p2 557056 61071326 60514271 28.9G Linux filesystem

確實mmcblk1p1是由32768(0x8000)開始, 不過前面基本是0, 不像是BOOT_START前面的內容。像是gpt分区表。
lsblk只有mmcblk1,mmcblk1boot0,mmcblk1boot1 3個block, (mmcblk1boot* 全0) 我覺得0~0x8000操作系統存取不了

hexdump /dev/mmcblk1 -n 0x8000 -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  02 00 ee ff ff ff 01 00  00 00 ff df a3 03 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000210  a3 f6 6b 46 00 00 00 00  01 00 00 00 00 00 00 00  |..kF............|
00000220  ff df a3 03 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000230  de df a3 03 00 00 00 00  5b 98 38 26 75 db 4b 46  |........[.8&u.KF|
00000240  b7 c6 fb 27 26 47 69 dd  02 00 00 00 00 00 00 00  |...'&Gi.........|
00000250  80 00 00 00 80 00 00 00  6f c3 83 9f 00 00 00 00  |........o.......|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000410  96 21 4b f8 07 65 f0 47  a4 9b c5 1e 0a 00 0d 5b  |.!K..e.G.......[|
00000420  00 80 00 00 00 00 00 00  ff 77 08 00 00 00 00 00  |.........w......|
00000430  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
00000440  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
00000450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000480  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000490  5d 08 c1 30 7c a5 25 45  90 90 a1 ea bb 2e 05 2b  |]..0|.%E.......+|
000004a0  00 80 08 00 00 00 00 00  de df a3 03 00 00 00 00  |................|
000004b0  00 00 00 00 00 00 00 00  70 00 72 00 69 00 6d 00  |........p.r.i.m.|
000004c0  61 00 72 00 79 00 00 00  00 00 00 00 00 00 00 00  |a.r.y...........|
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00008000

refs:
https://opensource.rock-chips.com/wiki_Partitions

rk规定了不同阶段的起始位置，但是没规定不同阶段引导文件的大小啊。有0是正常的。

一般来说，嵌入式设备的系统最好不要能够接触引导部分。类比手机，高通的abl或者是xbl也不是大众能够接触到的。哪怕是电脑，BIOS也并不是简简单单就可以随意刷写的。

[chouex]

你說得沒錯, mmcblk1的結構應該就如上圖所示, 我把單位由sector(512bytes)當成byte所以才看不到東西, 在0x4000找到了疑似uboot, 操作系統修改uboot也是有可能的, 也解釋了我上次刷壞了misc分區(amlogic)可能是因為armbain-install (不過我是在u盤比emmc大的情況安裝)

[13584452567]

线刷流程

1. 准备工作

• 从本仓库的releases页面下载系统镜像并解压，解压后的文件后缀名应为img
• 电脑安装瑞芯微的驱动
• 下载瑞芯微开发工具并解压出RK3399FlashTool文件夹

2. 刷机过程

• 打开刷机工具，界面应为
  

• 点击红色框选位置的按钮，在弹出的窗口内选择你下载解压的img文件
  

• 重启设备，使其进入maskrom模式。这一步你可以adb跳转，也可以loader模式切换，也可以使用主板自带的短接按钮或者短接点。总之，只要设备能够进入maskrom模式即可。如果你的驱动安装无误，设备进入了maskrom模式且正确链接至电脑后，软件下方的“没有发现设备”字样会变为“发现一个MASKROM设备”

• 此时，点击下方的执行按钮，就会开始强刷流程。如果遇到读取boot失败错误，请强制重启设备并重新执行上述流程。

至此，入门线刷流程结束。

[13584452567]

如果想使用本仓库支持一台新RK设备的话，是不是只需要有该设备的 dtb 就可以自行自作固件？还需要其他东西吗？

理论上需要uboot和dtb，但是如果你测试现有uboot或者dtb能够正常启动的话，也可以直接套用

[hwei]

system 的地址是 0x00000000 意思是从开头覆盖 eMMC 中的数据对么？
Loader 的地址 0xCCCCCCCC 又是是什么意思？

[13584452567]

system 的地址是 0x00000000 意思是从开头覆盖 eMMC 中的数据对么？

Loader 的地址 0xCCCCCCCC 又是是什么意思？

0xCCCCCCCC是一个保留地址，用于指示工具发送loader文件。

maskrom模式是bootrom实现，并不具有硬盘这些外设的处理能力，需要通过USB发送一个可用引导文件执行初始化这些硬件。类似的，高通系列的芯片进入EDL模式后需要先使用sahara发送一个firehose（即program）过去初始化端口后才能烧录固件。我觉得这个的主要原因是芯片内部的bootrom存储空间有限和其不可写的特性

[hwei]

我看了这个文档 https://opensource.rock-chips.com/wiki_Rkdeveloptool ，用 rkdeveloptool db rkxx_loader_vx.xx.bin 可以初始化 DRAM 和运行 usbplug。是不是 loader 会写入 SoC 内部的 SRAM？这样普通模式启动就可以用内部的 loader 初始化 DRAM。而 Maskrom 模式是不执行 SRAM 中的 loader ，所以需要每次额外传入 loader bin ？

[13584452567]

我看了这个文档 opensource.rock-chips.com/wiki_Rkdeveloptool ，用 rkdeveloptool db rkxx_loader_vx.xx.bin 可以初始化 DRAM 和运行 usbplug。是不是 loader 会写入 SoC 内部的 SRAM？这样普通模式启动就可以用内部的 loader 初始化 DRAM。而 Maskrom 模式是不执行 SRAM 中的 loader ，所以需要每次额外传入 loader bin ？

iDBLoader实际上就是在SRAM里面运行然后完成其他外设初始化的

是的，外置loader可以根据不同的需求进行修改。由于rk并没有开源这个东西，故虽然理论上可以修改它用作别的用途，实际中并没有这样的实例。

[13584452567]

卡刷流程

根据rk默认的启动流程，一般不会优先使用SD/MMC上的系统。不过有些设备可能调整过默认的启动流程来默认启动SD卡上的系统。

卡刷相当的简单。从本仓库的releases内下载对应设备的镜像文件，使用烧录软件（例如rufus，balena etcher，dd）将其烧录到对应的存储介质上。然后将其插入设备重启。

附：u-boot环境下破坏当前环境下的引导

PS:此操作高危，请反复阅读，并清楚你在做什么。

链接ttl到设备，启动过程中用任意按键打断u-boot的启动流，使其进入命令行模式。输入命令：mmc erase 0x40 2
此命令会擦除第64扇区的前面一小段来破坏idbloader格式，从而让此设备引导不可用。

[13584452567]

预留
主线u-boot编译流程

[13584452567]

预留
主线kernel编译流程

[13584452567]

预留
一些其他操作
部分邪术

[13584452567]

预留
GPU用户空间部分编译

[benja956]

佬，我搜寻了好久，终于找到你这一篇介绍。我当前的问题是：正常刷入固件，但无法启动。我怀疑是我把分区或者启动文件破坏了。不知道大佬有没有时间协助我排障

[benja956]

已经解决。线刷不成功可能是由于3个原因造成。
1.线刷包损坏。（云编译的固件可能存在此问题）
2.刷入损坏的线刷包导致的分区信息丢失。（解决方案：可以通过bin文件重建）
3.刷机工具因为某种奇怪的原因，无法刷入固件。（解决方案：重新解压一组刷机工具）