背景
公司的rk3568开发板的DDR用的是两个512MB,最近要用这个开发板要跑鸿蒙的系统,但是由于内存有些小要换成两个1GB的,发现烧录进去之后系统加载不了。
问题描述
通过串口打印信息,发现设备去找了好几次DDR,但是没找到导致系统完全起不来。
追溯问题
由于是系统刚开始,初步判断打印信息是在uboot里面的,因此就去查看uboot源码。
通过之前正常的打印信息,大致找到了打印信息为:
目录为:u-boot/drivers/ram/rockchip
文件为:u-boot/drivers/ram/rockchip/sdram_common.c
函数接口:int sdram_init (void)
我是通过其他平台的打印信息,找到这个接口的,当你打开sdram_rk3568.c文件会发现,这个文件是空的,只有定义没有实现,但是在u-boot/drivers/ram/rockchip这个目录下只有sdram_rk3568.c参与了编译过程。
通过uboot源码没有找到rk3568的打印信息的具体实现,开始在网上寻找相关问题。
最终了解到初始化DDR是在MiniLoaderAll.bin这个固件里面实现的,但是这个固件是通过几个闭源的二进制镜像文件生成的,因此从打印信息来追问题,并不能很好的追下去。
虽然,看到是闭源二进制文件,我还是继续看了这方面相关知识。
常用镜像介绍
MiniLoaderAll.bin
该镜像是运行在 RK3568 平台 U-Boot 之前的一段 Loader 代码(也就是比 U-Boot 更早阶段的 Loader),MiniLoaderAll.bin 由 TPL 和 SPL两部分组成, TPL 用于初始化 DDR,运行在 SRAM;而 SPL 运行在DDR,主要负责加载、引导 uboot.img。也即设备启动的第一阶段
uboot.img
uboot.img 是一种 FIT 格式镜像,它由多个镜像合并而成,其中包括
trust 镜像(ARM Trusted Firmware + OP-TEE OS)、u-boot 镜像、u-boot dtb;编译 U-Boot 时会将这些镜像打包成一个 uboot.img。uboot.img 会烧录到开发板 uboot 分区。这个是设备启动的第二阶段
boot.img
boot.img 也是一种 FIT 格式镜像,它也是由多个镜像合并而成,其中包括内核镜像、内核 DTB、资源镜像 resource.img。boot.img 会烧录到开发板 boot 分区。
recovery.img
ecovery 模式镜像,recovery.img 用于进入 recovery 模式,recovery.img 会烧录到开发recovery 分区。recovery 模式是一种用于对设备进行修复、升级更新的模式。recovery.img 也是 FIT 格式镜像,也是由多个镜像合并而成,其中包括ramdisk(进入 recovery 模式时挂载该根文件系统)、内核镜像(进入recovery 模式时启动该内核镜像)、内核 DTB 以及 resource.img。rootfs.img
正常启动模式下对应的根文件系统镜像,包含有大量的库文件、可执行文件等。rootfs.img 会烧录到开发板 rootfs 分区。
userdata.img
给用户使用,可用于存放用户的 App 或数据;该镜像会烧写至开发板 userdata 分区,系统启动之后,会将其挂载到/userdata 目录
从上面的镜像介绍中可以看出我MiniLoaderAll.bin这个镜像是进行DDR初始化的,因此我判断我的打印信息在这个固件里面,继续追这个固件是如何生成的。
如何生成 MiniloaderAll.bin 镜像
ddr bin就是TPL,spl bin就是SPL,这个镜像文件是由三个bin文件生成的,是瑞芯微他们提前做好的,因此无法通过调试查出问题在哪。
参考: