RK平台镜像及分区介绍

RK平台有自己的烧录工具，镜像分区配置文件，如何理清他们的关系？

一般的AP处理器，启动流程是这样的，系统上电，从固化在芯片内部的romcode（不同的厂家，叫法可能不一样，也有叫bootrom的）开始运行，这部分代码的主要功能就是根据芯片管脚的配置来选择启动方式，从选择的介质（eMMC、SD卡、SSD）中加载前4KB的代码到SRAM，然后从SRAM开始运行（此时SRAM映射到零地址）。

加载到SRAM运行的这段代码，主要功能是初始化DDR等设备，然后将U-boot从eMMC/SD卡等存储介质加载到DDR内存，然后跳转到DDR中运行U-boot。而U-boot的主要作用，就是从eMMC/SD卡等存储介质上指定的分区，加载内核镜像到DDR内存，从内存启动内核。

在编译U-boot时，可以将前4KB的内容单独编译成一个镜像文件，就是我们大家熟悉的spl.bin，这个镜像文件在系统上电时会被加载到SRAM中运行的（此时DDR还没有初始化，SRAM映射到零地址）。所以，在烧写镜像时，有时候我们会给spl.bin单独一个烧写分区，然后在romcode逻辑中会自动加载这个分区上的镜像到SRAM。对于RK平台来说，这个spl.bin可以自己编译，也可以使用官方提供的镜像：MiniLoaderAll.bin

MiniLoaderAll.bin

MiniLoaderAll.bin没有开源，所以我们只能从功能上进行大致分析：主要作用就是初始化DDR，然后将存储介质上的整个U-boot拷贝加载到DDR中，最后跳转到DDR中去执行U-boot镜像。

MiniLoaderAll.bin和开源的SPL不同之处在于：MiniLoaderAll.bin使用block接口访问NAND/eMMC/SD卡等存储介质，而SPL则是使用MTD接口来访问这些存储介质。

MiniLoaderAll.bin是如何知道从哪里去读取U-boot呢？主要是根据分区表信息来确定U-boot镜像在存储介质上的起始地址。分区表可以通过U-boot中的环境变量来获取，或者读取读取parameter.txt文件，来获取各个分区的信息。

以RK3588的Android12镜像包为例，我们解析其镜像包，解包后，发现有一个parameter.txt文件，这里面存放的就是分区表信息。

parameter.txt文件

打开这个文本文件，我们可以看到其内容：

FIRMWARE_VER: 12.0
MACHINE_MODEL: orangepi5plus
MACHINE_ID: 007
MANUFACTURER: rockchip
MAGIC: 0x5041524B
ATAG: 0x00200800
MACHINE: rk3588_s
CHECK_MASK: 0x80
PWR_HLD: 0,0,A,0,1
TYPE: GPT
CMDLINE:mtdparts=rk29xxnand:
0x00002000@0x00002000(security),
0x00003000@0x00004000(uboot),
0x00002000@0x00007000(trust),
0x00002000@0x00009000(misc),
0x00002000@0x0000b000(dtbo),
0x00000800@0x0000d000(vbmeta),
0x00032000@0x0000d800(boot),
0x00036000@0x0003f800(recovery),
0x000ba000@0x00075800(backup),
0x000c0000@0x0012f800(cache),
0x00008000@0x001ef800(metadata),
0x00000800@0x001f7800(baseparameter),
0x00614000@0x001f8000(super),
-@0x0080c000(userdata:grow)

各行的信息如下：

  • FIRMWARE_VER: 12.0：固件版本，打包updata.img时会使用，升级工具会根据这个识别固件版本
  • MACHINE_MODEL: orangepi5plus：机器型号，打包updata.img使用，不同的项目，可以自己修改，用于升级工具显示。在recovery里面升级固件时可以用于判断固件是否匹配
  • MACHINE_ID: 007 ：产品开发ID，可以位字符和数字组合，打包updata.img使用，不同的项目使用不同的ID，可以用于识别机器机型。在recovery里面升级固件时可以用于判断固件是否匹配
  • MANUFACTURER: rockchip 厂商信息，打包updata.img使用，可以自己修改，用于升级工具显示
  • MAGIC: 0x5041524B 魔数MAGIC，不能修改，一些新的AP使用DTS，这一项没有用，为了兼容，不要删除或修改
  • ATAG: 0x00200800 ATAG，不能修改，一些新的AP使用DTS，这一项没有用，为了兼容，不要删除或修改
  • MACHINE: rk3588_s 内核识别用，不能修改，这个定义和内核匹配
  • CHECK_MASK: 0x80 保留，不能修改
  • PWR_HLD: 0,0,A,0,1
  • TYPE: GPT 指定该文件CMDLINE里面定义的分区用于创建GPT使用，不会烧录到NVM（NAND，EMMC等）存储器里面。

烧录模式loader 和 maskrom 的区别

如果你当前的系统已经烧录过固件，系统将进入LOADER固件烧写模式。如果还未烧录过固件，或者清除了固件数据，上电后，会进入MASKROM模式（板子初始状态）。

在 Loader 模式下，bootloader 会进入升级状态，等待主机命令，用于固件升级等。让 bootloader 在启动时检测到 RECOVERY（恢复）键按下，且 USB 处于连接状态。正常烧录机器过后，按音量+ 和重启可进入。此模式下可烧写包括loader在内的所有固件。

MaskRom 模式用于 bootloader 损坏时的系统修复。 一般情况下是不用进入MaskRom 模式的，只有在 bootloader 校验失败（读取不了 IDR 块，或bootloader 损坏） 的情况下，BootRom 代码 就会进入 MaskRom 模式。在板子上找对应的EMMC_CLKO、GND焊点，短接后通电，系统会认为 Flash 数据出错，从而清除 Flash 数据，进入MASKROM模式。此模式下必须要选择正确的 MiniLoaderAll.bin，并勾选Loader项。