CM3588 升级 kernel 和 u-boot 踩坑
一直在用 CM3588 跑“散装” NAS，但一直有一个小问题困扰着我。就是这个系统在 reboot 或者 poweroff 的时候有一定几率会卡住死机。虽然作为 NAS 重启或者关机的时间不多。但是这个问题却如梗在喉让我不太舒服。也一直没有时间去深入看一下怎么回事。隐约感觉应该是 kernel 或者是 u-boot 有问题。
这两天刚好发现友善官方的 kernel 和 u-boot 有一些代码提交记录。于是就打算升级一下看看能不能解决这个问题。简单记录一下升级过程。
编译
参考官方的 wiki
https://wiki.friendlyelec.com/wiki/index.php/CM3588
编译 u-boot
https://wiki.friendlyelec.com/wiki/index.php/CM3588#Build_u-boot_v2017.09
编译 kernel
https://wiki.friendlyelec.com/wiki/index.php/CM3588#Build_kernel_linux-v6.1.y
安装
因为我们是在现有的系统上进行升级，所以将手动安装 u-boot 和 kernel。
u-boot
参考 rk 官方的分区表 https://opensource.rock-chips.com/wiki_Partitions
u-boot 的位置位于 loader2，起始扇区数是 16384。我们可以将上面编译好的 uboot.img 直接写入磁盘上。
这是 CM3588 内置存储设备的分区表情况。预留了前面 16M 给 u-boot 使用。第一个分区给了 /boot 目录存放内核文件。剩下的容量其实也并没有使用，系统和文件都放在 nvme 和 sata 设备上面。
nas:/boot$ sudo fdisk -l /dev/mmcblk2
Found valid GPT with protective MBR; using GPT
Disk /dev/mmcblk2: 120832000 sectors, 1656M
Logical sector size: 512
Disk identifier (GUID): 8158f5c7-a3da-4615-b9b9-4886c5101a61
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 120831966
Number Start (sector) End (sector) Size Name
1 32768 1953791 938M
2 1953792 120829951 56.6G
直接通过 dd 命令写入 u-boot。
dd if=uboot.img of=/dev/mmcblk2 seek=16384 bs=512 conv=notrunc
kernel
- 将编译好的内核
./arch/arm64/boot/Image，直接覆盖/boot/Image - 将
./out-modules/lib/modules内的文件复制到/lib/modules mkinitfs 6.1.57生成 initramfs。后面的参数是 kernel 版本名称，根据实际情况调整。mkinitfs 是 alpine 的命令，其它 linux 都有对应命令，替换即可。- 转换 initramfs 到 u-boot 能识别的格式。
mkimage -A arm64 -O linux -T ramdisk -C gzip -n uInitrd -d initramfs-vanilla uInitrd - 复制
./arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev09.dtb到/boot/dtb/rockchip/rk3588-nanopi6-rev09.dtb
踩坑
至此 kenrel 和 u-boot 升级都结束了。理论上来说重启一下就可以生效了。此前其实也修改了内核的一些配置，这个流程已经走了几遍了，都是没有问题的。但实际情况就是重启之后等了10分钟系统都没有再上线。我还以为是又触发了那个卡死的bug，于是强行断电重启问题依旧。
那只能把我的散装 NAS 拿出来，插上调试线，看看到底是 u-boot 的问题还是 kernel 的问题。这里忘记拍照截图了。但是看了一下启动日志，发现 u-boot 已经是新版的了。并且引导成功，开始加载内核了。然后内核卡住了。打开内核的日志信息。发现它尝试从 /dev/mmcblk2p8 分区引导。但是我的系统中并没有这个分区，然后引导就失败了。我的启动磁盘信息都是写在 /boot/boot.cmd 里面的，这个文件没有改动过。于是看了一下官方内核的提交记录，里面发现一条信息 https://github.com/friendlyarm/kernel-rockchip/commit/e7c28e5cc40aebf9eb955dd49ca706a6a4424a7a，不懂为什么要写死这个设备信息。解决的方法也很简单，删掉这行代码重新编译，从新替换一下 dtb 文件即可。