platform:RK3399
OS:Android 7.1

现象描述

使用RK的高可靠OTA方案.一直编译和测试没有问题.今天转User版本的OTA固件发现编译失败.并报错:

boot or recovery image sha mismatch

网上搜索的解决方案是关闭校验,但是这样并不安全.所以自己分析.

分析步骤

步骤1:验证是否是环境问题.

之前都是编译的Userdebug版本,第一次编译User版本,怀疑是环境问题.

执行

make clean
make distclean

清理环境之后编译发现仍然有问题

更换帐号编译,使用自己的帐号编译,仍然发现不行.

于是怀疑是上次编译到本次编译之间的提交导致这个问题.

步骤2:分析提交

一共有三次提交:

1.更换预装APP
2.更换kernel开机logo
3.支持power按键广播

初看这只是三个普通的提交,不会引起校验失败,但是结果确实是报错.所以问题肯定出现在这三个提交.

结合报错,boot和recovery校验失败.由于三次提交都没有涉及到recovery,所以应该是boot校验失败,因此是第二个提交,更换开机logo图片导致校验失败.可是更换一张图片怎么会导致校验失败呢?

步骤3:仔细分析boot.img和logo图片

对比提交前logo图片和提交前boot.img

发现:

logo图片大小从300K->6.9M

boot.img从19M->34M

但是我们的分区如下:

[    2.460275]      uboot: 0x000400000 -- 0x000800000 (4 MB)                          
[    2.460293]      trust: 0x000800000 -- 0x000c00000 (4 MB)                          
[    2.460303]   uboot_ro: 0x000c00000 -- 0x001000000 (4 MB)                          
[    2.460312]   trust_ro: 0x001000000 -- 0x001400000 (4 MB)                          
[    2.460320]       misc: 0x001400000 -- 0x001800000 (4 MB)                          
[    2.460329]   resource: 0x001800000 -- 0x002800000 (16 MB)                         
[    2.460338]     kernel: 0x002800000 -- 0x004000000 (24 MB)                         
[    2.460347]       boot: 0x004000000 -- 0x006000000 (32 MB)                         
[    2.460356]   recovery: 0x006000000 -- 0x00a000000 (64 MB)                         
[    2.460365]     backup: 0x00a000000 -- 0x011000000 (112 MB)                        
[    2.460374]      cache: 0x011000000 -- 0x019000000 (128 MB)                        
[    2.460384]     system: 0x019000000 -- 0x0d9000000 (3072 MB)                       
[    2.460393]   metadata: 0x0d9000000 -- 0x0da000000 (16 MB)                         
[    2.460402] verity_mode: 0x0da000000 -- 0x0da008000 (0 MB)                         
[    2.460422]   reserved: 0x0da008000 -- 0x0da408000 (4 MB)                          
[    2.460432]        frp: 0x0da408000 -- 0x0da488000 (0 MB)                          
[    2.460441]   userdata: 0x0da488000 -- 0x747800000 (26323 MB)

竟然是更换的logo图片太大导致boot.img包过大,超过了boot分区的大小.导致一直运行校验失败!

步骤4:继续分析

但是在测试的时候,编译的固件却是可以正常运行的.这又该怎么解释呢?

问题就出现在boot.img上.采用userdebug调试的时候,kernel.img和boot.img是分区烧录的,所以没有超过分区大小;但是编译OTA User版本的时候使用的是高可靠方案,kernel.img是合到boot.img中的,kernel分区不用烧录固件,以支持差分升级.所以此时boot.img固件的大小就超过了分区大小,导致一直报校验失败.

解决方案

解决方法,有两个思路:

1.增加boot分区大小.

修改parameter_hrr.txt文件,增大boot分区.注意boot分区后的分区地址都需要对应改变.

- CMDLINE: console=ttyFIQ0 androidboot.baseband=N/A androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(uboot_ro),0x00002000@0x00008000(trust_ro),0x00002000@0x0000A000(misc),0x00008000@0x0000C000(resource),0x0000C000@0x00014000(kernel),0x00010000@0x00020000(boot),0x00020000@0x00030000(recovery),0x00038000@0x00050000(backup),0x00040000@0x00088000(cache),0x00600000@0x000C8000(system),0x00008000@0x006C8000(metadata),0x00000040@0x006D0000(verity_mode),0x00002000@0x006D0040(reserved),0x00000400@0x006D2040(frp),-@0x006D2440(userdata)

+ CMDLINE: console=ttyFIQ0 androidboot.baseband=N/A androidboot.selinux=permissive
androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(uboot_ro),0x00002000@0x00008000(trust_ro),0x00002000@0x0000A000(misc),0x00008000@0x0000C000(resource),0x0000C000@0x00014000(kernel),0x00020000@0x00030000(boot),0x00020000@0x00040000(recovery),0x00038000@0x00060000(backup),0x00040000@0x00098000(cache),0x00600000@0x000D8000(system),0x00008000@0x006D8000(metadata),0x00000040@0x006E0000(verity_mode),0x00002000@0x006E0040(reserved),0x00000400@0x006E2040(frp),-@0x006E2440(userdata)

2.压缩图片.

由于bmp是无损格式的图片,所以是没有办法压缩的.

原图片是1920*1200*24=6.9M

可以把位深改为8位,于是大小改为:1920*1200*8=2.2M