RK3368 Android 9.0 固件升级后卡Recovery：从日志分析到设备树配置的修复之路

1. 当RK3368遇上Android 9.0固件升级后的Recovery困局最近给RK3368设备升级Android 9.0固件后发现设备卡在Recovery界面无法启动这可能是很多开发者都遇到过的问题。作为一名在嵌入式领域摸爬滚打多年的老手我深知这种问题的棘手程度——它不像普通应用崩溃那样容易定位往往需要深入到系统底层才能找到症结所在。RK3368作为瑞芯微的经典芯片在智能电视盒子、工控设备等领域应用广泛。而Android 9.0引入的分区提前装载机制给固件升级带来了新的挑战。具体表现就是升级完成后设备反复重启都只能进入Recovery模式串口日志中不断刷出Failed to mount /cache、No such file or directory等错误信息就像陷入了死循环。这种情况通常意味着系统在Recovery模式下无法正确识别存储设备的分区结构。我遇到过最极端的情况是客户的生产线上有上百台设备因为这个问题无法出货工程团队连夜排查却毫无头绪。要解决这个问题我们需要像侦探破案一样从串口日志这条线索开始一步步追踪到问题的根源。2. 串口日志故障排查的第一现场2.1 解读错误信息的密码当设备卡在Recovery界面时串口终端输出的日志就是我们最重要的诊断工具。以我最近处理的一个案例为例日志中反复出现的关键错误信息如下E:Failed to mount /cache: No such file or directory E:failed to stat /dev/block/by-name/misc try 1: No such file or directory ... E:Cant mount /cache/recovery/last_locale这些信息看似简单却包含了丰富的问题线索。首先No such file or directory错误表明系统找不到指定的文件或目录但这里的特殊之处在于它发生在块设备层面/dev/block/by-name/而不是普通的文件系统。为了验证这一点我通常在adb shell或串口终端中执行ls -l /dev/block/果然输出结果显示/dev/block目录下空空如也完全没有预期的块设备节点。这说明了一个严重问题Recovery模式下的内核根本没有正确识别到存储设备无论是eMMC还是NAND Flash。2.2 存储设备检测的深层机制在Linux内核中块设备的识别和创建是由存储控制器驱动完成的。对于RK3368平台来说eMMC设备由dwmmc控制器驱动管理NAND Flash则由nandc控制器驱动管理当这些控制器驱动未能正确加载或初始化时对应的存储设备就无法被识别自然也就不会有/dev/block下的设备节点。这就是为什么系统会报No such file or directory错误——它试图访问的/dev/block/by-name/misc等符号链接根本不存在。这种情况在Android 9.0上尤为常见因为Android 9.0引入了提前装载early mount机制要求系统在非常早期的启动阶段就能访问某些关键分区。如果设备树中的配置与实际的硬件不匹配就会导致这一机制失效。3. Android 9.0的分区管理革命3.1 提前装载机制解析Android 9.0引入的提前装载机制是一项重要的架构变更。传统Android系统中文件系统挂载是由init进程在启动后期完成的。而在Android 9.0中某些关键分区如vendor、odm等需要在init之前就被挂载这就是所谓的提前装载。这一变化带来了几个关键影响分区信息不再完全依赖recovery.fstab而是主要通过设备树的fstab节点定义系统需要在内核启动的早期阶段就知道从哪里加载这些分区存储控制器的初始化时机变得更加关键在RK3368平台上如果设备树中boot_devices的设置与实际硬件不匹配提前装载机制就会失败导致我们看到的Recovery模式无法识别分区的问题。3.2 设备树叠加层DTO的作用Android 9.0还广泛使用了设备树叠加层Device Tree Overlay技术。DTO允许在不修改基础设备树的情况下通过叠加的方式修改硬件配置。这对于支持多种存储介质的设备特别有用——比如同一款RK3368板子有的版本用eMMC有的用NAND Flash。在我们的案例中问题恰恰出在这里SDK默认配置是针对eMMC的而实际硬件使用的是NAND Flash。如果没有正确应用DTO或者直接修改基础设备树就会导致NAND控制器未被启用Recovery模式自然无法识别存储设备。4. 设备树配置从诊断到修复4.1 NAND控制器的正确配置要让Recovery模式识别NAND Flash首先需要确保nandc控制器已正确启用。在RK3368的设备树中通常需要做以下修改emmc { status disabled; }; nandc0 { status okay; };这段配置做了两件事禁用eMMC控制器因为我们的硬件不使用eMMC启用NAND控制器但仅仅这样还不够——这只是让内核能够识别NAND Flash芯片还没有解决分区识别的问题。4.2 boot_devices的关键作用Android 9.0的init进程需要知道从哪里加载分区信息这就是boot_devices属性的作用。它指定了存储控制器的路径init会根据这个信息来创建设备节点和符号链接。对于RK3368平台我们需要在firmware_android节点中添加firmware_android { compatible android,firmware; boot_devices ff0f0000.dwmmc,ff400000.nandc; ... };这里的ff400000.nandc就是NAND控制器的设备地址。如果没有这个配置即使NAND控制器已经启用init也不知道该从哪里加载分区表。4.3 fstab节点的配置艺术fstab定义了Android系统的分区挂载信息。在Android 9.0中它已经从传统的recovery.fstab文件转移到了设备树中。一个典型的vendor分区配置如下fstab { compatible android,fstab; vendor { compatible android,vendor; dev /dev/block/by-name/vendor; type ext4; mnt_flags ro,barrier1,inode_readahead_blks8; fsmgr_flags wait,avb; }; };这里有几个关键点需要注意dev路径必须使用/dev/block/by-name/形式的符号链接mnt_flags要根据实际存储介质调整NAND Flash通常需要特定的优化fsmgr_flags中的wait表示这个分区对启动至关重要如果这些配置有误即使存储设备被识别系统也可能无法正确挂载分区。5. 实战完整修复流程5.1 修改设备树的步骤基于以上分析完整的修复流程如下确认硬件使用的存储介质类型eMMC还是NAND在设备树源文件.dts中禁用不使用的存储控制器启用实际使用的控制器设置正确的boot_devices配置fstab节点编译设备树make dtboimage打包新的固件并烧写到设备5.2 验证与调试技巧修改后可以通过以下方式验证配置是否正确在Recovery模式下检查/dev/block目录ls -l /dev/block/by-name/应该能看到misc、cache等分区节点检查内核启动日志确认存储控制器已正确初始化dmesg | grep nandc尝试手动挂载分区测试mount /dev/block/by-name/vendor /vendor如果这些步骤都成功了那么系统应该能够正常启动不再卡在Recovery界面。5.3 常见陷阱与避坑指南在实际操作中有几个容易忽略的细节控制器地址错误boot_devices中的控制器地址必须与芯片手册一致。RK3368的NAND控制器地址通常是0xff400000。fstab格式问题Android 9.0对fstab的语法要求更严格每个字段都必须准确。DTBO未更新如果使用设备树叠加层需要确保新的dtbo镜像被正确打包到固件中。分区大小不匹配修改存储配置后分区表可能需要相应调整否则会导致分区无法识别。记得每次修改后都要完整编译和烧写固件因为部分修改如boot_devices需要完全重新初始化才能生效。