Bootloader 测试解决方案
发布于 2022-05-19 15:37
一、什么是 bootloader？
1、bootloader 简介
BootLoader 又叫做 bootloader，是在操作系统内核（linux 内核,又叫kernel
2、作用流程
（1）手机启动大致流程与 bootloader 的作用：
当我们按power 键2s 以上时候，bootloader会判断操作为开机，然后引导程序将bootloader从ROM(手机固态存储)加载到RAM（手机 运行内存）开始执行初始化硬件信息，驱动支持，上电自检功能等，确保系统启动的必要硬件环境需求。
初始化硬件信息后，开始加载 boot.img，vbmeta，system 等分区信息到 RAM,但是这里并未调用,之后bootloader 程序开始验证各个分区的签名信息（通常用avb信息），比如：keystore 中的内部签名、各分区的hash 值，IMEI、HWconfig 等。
验证成功进入下一个阶段，屏幕就开始有图标或者动画出现（bootloader unlock提示不算，一般Android，系统图标就代表验证成功进入kernel了）验证失败的话，屏幕都不会亮；至此bootloader 的工作结束。
bootloader验证成功后进入linux内核，即kernel，在kernel阶段， kernel开始初始化进程管理、内存管理，加载 Display,Camera Driver， Binder Driver等相关工作；（第一步是初始化硬件信息，这里是初始化进程、内存、驱动这些）加载完成之后进入Native阶段，启动init进程，init进程会不从RAM里面不断调用各种进程，启动Media Server(多媒体服务)、service，manager(binder 服务管家)、bootanim(开机动画)等重要服务等；init进程还会孵化出installd(用于 App 安装)、ueventd、adbd、lmkd(用于内存管理)等用户守护进程；
在这个阶段会不断调用进程，启动各种服务，直观表现有开机动画这些产生，手机系统界面（如MIUI），此时release case 里面的tzsunstory、指纹、medom 这些信息都在这个阶段产生。之后进入到Framework 层，对进程数据这些进行解析；
最后进入app 层，启动第一个app 进程，就是Launcher，也就是桌面，然后是chrome 这些，这样一个手机系统就启动完成。
2、bootloader 的开发进程
Bootloader和我们手机操作系统的研发是并行的，分为两条线: bootloader 版本1.0(研发)->做release测试->测试完成后投入到正常的刷机模式 中，比如 2.0.0.212->然后继续升级、调整bootloader,生成bootloader版本2.0->做release测试->测试完成后投入到正式刷机模式版本中2.0.0.212
其中如果bootloader1.0 是第一个bootloader 版本，并且投入到212 中，那么212之前的版本比如：2.0.0.211就是不包含bootloader的,没有厂商定制的开机动画之类，但是也是可以启动的,有一个android原生的boot;
其次：bootloader 2.0版本是投入到212版本的，那么在212之前的版本使用的bootloader1.0，212之后就使用新的bootloader 2.0。
bootloader 的研发阶段：
bootloader研发调整（研发完善功能，解重大bug，对应测试的IT阶段）IT阶段测试结束后，开始执行full的case，这时候研发也在对bootloader 继续升级（VI 之类的）、解bug当full的case完成并且pass 之后，进入下一个阶段，Pre-C 阶段，我们会开始申请Pre-C 签名，做Pre-C 版本，这个版本是交给客户那边验收的，但是并不是最终版本，期间会不断的给客户提供版本，客户验收，有bug之后解除，再重新签名提供给客户这样循环。
Pre-C 阶段完成后，意味着我们和客户那边都没有什么重大问题，可以准备做commercial签名和版本.这个就是最终商业版本，这个版本也不是一次就成功的，会经常几个版本调整，之后交付，项目完成。
二、bootloader测试
1、开机
（1）关机下，短按power 一秒，串口显示对应日志。
（2）设备启动情况与设备是否有重启情况检查。手机开机，启动，充电，ramdump 都会产生不同值记录信息。normal boot 指正常开机，此时设备启动值为0x00000001，启动状态值为0x00000000.这两个值一起时，说明设备正常开机没有进行其他任何操作。Crash重启，启动值0x00000002 或0x00000006，状态值0xc0dedead。此时状态值会大概记录设备重启原因。
（3）S2,S3。即手机的强开强关以及触发crash的一种功能。这个功能的触发方式对于不同厂商的不同版本都不相同。
2、硬件自检
删除2003 分区信息，设备启动不了。验证写入另一台的硬件信息，设备无法启动。刷入有效硬件信息后设备正常开机且显示设备号等。
3、签名验证
（1）验证通过使用刷机软件擦除各分区的签名和哈希值和备份值两个分区后，设备无法启动，插入usb自动进入刷机模式（强制操作）。
（2）签名分类：普通签名，一般为hash 加密值；内部签名，用于手机内部验证，bin 文件；外部签名，用于刷机文件验证，sin文件。修改签名：通过修改文件对应部位的内容修改；或者通过客户提供的软件修改，工具修改的是签名的类型。如果我们想要操作外部签名，就需要用工具给签名分区签一个外部签名，再进行修改。外部签名以cmc 开头。
4、分区验证
（1）66671 分区为某特定值时才可以进行解锁，其他值都不能解锁。
（2）目的：验证 a 分区和 b 分区在执行XFL 的功能没有差异。步骤：进入刷机模式，查看a 为活跃分区，dump a 分区所有文件，进入刷机模式，flash boot 包到b 分区，设备b 分区为活跃分区，进入刷机模式模式，擦除a 的所有分区，再次拔开进入刷机模式模式，查看活跃分区是b。
（3）目的：验证设备在unlock 下可以把文件刷到确定的分区中。步骤：当a 分区为活跃的，进入fastboot，cmd 输入命令fastboot flash boot+ 文件，可以成功刷到当前的活跃分区中，擦除刚刚刷入的文件，设置b 为活跃分区，fastboot set_active b，输入上面的adb 命令，可以成功刷入当前的活跃分区即b，再擦除，指定刷到a 和b 两个分区fastboot flash boot_a/boot_b+文件，都可以成功。
（4）验证手机unlock 设备在fastboot 模式下，可以刷入所有的分区信 息。前提：设备为unlock。步骤：把所有的文件dump 出来，然后用fastboot flash 分区名分区文件路径命令刷入。可以用window 的批处理文件操作。
5、刷机模式
（1）Sevice mode，验证特定分区。设置为特定值时，插上usb 就可以进入某种厂商自定义刷机模式，设置其他值时，则需要进行某些操作才可以进入。此模块的case 主要是在验证底层的相关功能设计，看分区信息，对功能的影响。
（2）Fastboot 功能验证。作为一种线刷方式，不同厂商的进入方式不太相同，但是总的来说都是分为按键法和命令法。查看是否可以进入此刷机模式，并验证进入后的功能是否正常。
6、bootloader 状态
（1）查看 boot 状态。通过adb 命令查看 boot 状态。手机在bootloader locked 下为设置的特定值，unlocked 为又是一种特定值，同时也可以根据手机开始时的ui 进行检查。若手机处于解锁状态，手机开始会有图标显示（一个三角形，此为安卓原生，不同的厂商可能会做定制将起改变）
（2）使用正确的解锁码可以执行正确的解锁操作。一般厂商都是根据设备号可以查询获取到 fastboot 解锁码。设备要刷入全套key。确保分区信息允许解锁操作，key 对应分区必须有值，如果没有需要重新刷key。步骤：进入刷机模式，确认key 的存在，如果没有自己添加。进入fastboot，连接好串口，输入对应adb 命令就可以解锁。查看串口日志，搜索userdata，可以看到已被清除erasing ：userdata。退出fastboot 再进入原始的刷机模式，查看misc 分区信息，可以看到数据清楚。这一步是再检查 misc 中是否有引导恢复信息，预期结果是有的。确认key 分区变成空。手机开机。部分手机，需要手动进入recovery 模式，擦除userdata。然后才可以开机。可以理解为上面的日志中只是一种计划，真正是在开机的时候才会进行擦除数据。开机的时候应该自动进入recovery 分区擦除userdata，但是有的设备需要 自己手动进入。
7、开机后相关操作
（1）Radio 相关日志测试。通信相关服务（电话短信蓝牙wifi）。Radio_power 理解为通信服务是否启动。Long pressadb 设备crash，这些操作的目的都是为了验证在开关机时是否加载了通信服务。
（2）使用厂商定制刷机软件，刷key。进入刷机模式，刷入bootloader，刷入剩下的版本，开机，测试蓝牙WiFi 功能。
8、总结
（1) bootloader的primarybootloader部分，主要执行硬件检测，确保硬件能正常工作，然后将 secondary stage bootloader 拷贝到内存(RAM)开始执行。
（2) Secondarystagebootloader 会进行一些硬件初始化工作，获取内存大小信息等，然后根据用户的按键进入到某种启动模式。比如说大家所熟知的通过电源键和其它一些按键的组合，可以进入到recovery，fastboot或者选择启动模式的启动界面等。
fastboot模式：fastboot是 android定义的一种简单的刷机协议，用户可以通过fastboot命令行工具来进行刷机。比如说fastboot flash boot boot.img这个命令就是把boot.img的内容刷写到boot分区中。一般的手机厂商不直接提供 fastboot模式刷机，总是会提供自己专有的刷机工具和刷机方法。但是其本质实际上是相同的，都是将软件直接flash到各个分区中。这种通常称为线刷，是比较原始的方法。当手机处于开不了机的情况下，可以使用此厂家提供的工具进行刷入；
3、boot 分区
当我们只是按下电源键开机时，会进入正常启动模式。Secondary stage bootloader会从boot分区开始启动。Boot分区的格式是固定的，首先是一个头部，然后是Linux 内核，最后是用作根文件系统的ramdisk。当Linux内核启动完毕后，就开始执行根文件系统中的init程序，init程序会读取启动脚本文件(init.rc和 init.xxxx.rc)。
android内核挂载/nfsroot/androidfs 之后，根据init.rc,init.goldfish.rc 来初始化并装载系统库、程序等直到开机完成。init.rc 脚本包括了文件系统初始化、装载的许多过程。
4、recovery 分区
recovery模式：recovery是android定义的一个标准刷机协议。当进入recovery模式时，secondarystagebootloader从recovery分区开始 启动，recovery分区实际上是一个简单的Linux 系统，当内核启动完毕后，开始执行第一个程序 init(init程序是 Linux 系统所有程序的老祖宗)。init会启动一个叫做recovery的程序（recovery模式的名称也由此而来）。通过recovery程序，用户可以执行清除数据，安装刷机包操作。一般的手机厂商都提供一个简单的recovery刷机，多只能进行upate的操作。不能进行卡刷；如果想要自己卡刷，则需要事先刷入第三方的Recovery，然后选择刷机包。
5、system 分区
除linux Kernel部分位于boot分区外，在其上的Library、runtime、 framework、core application都是处于system 分区
a、/system/app
核心应用程序档(*.apk)，都是放在这。像是Phone、Alarm Clock, Browser, Contacts等等。
b、system/lib
Library部分，存放的是所有动态链接库(.so 文件)，这些SO是JNI层， Dalvik虚拟机，本地库，HAL层所需要的，因为系统应用/system/app下的apk是不会解压的 SO到程序的目录下，所以其相应用的SO，都应放在/system/lib下面。当一个系统 apk的SO加载时，会从此目录下寻找对应用的SO文件；
c、/system/media/audio/(notification, alarms, ringtones, ui)
这里放系统的声音档，像是闹铃声，来电铃声等等。这些声音档，多是ogg格式。
d、/system/bin
存放的是一些可执行文件，基本上是由 C/C++编写的。其中有一个重要的命令叫app_process。一般大家称之为Zygote。（Zygote是卵的意思，所有的Android 进程都是由它生出来的)。Zygote首先会加载dalvik 虚拟机，然后产生一个叫做 system_server的进程。system_server 顾名思义被称作 Android 的系统服务程序，它主要管理整个android系统。system_server启动完成后开始寻找一个叫做启动器的程序，找到之后由zygote开始启动执行启动器，这就是我们常见到的桌面程 序。
6、Data 分区
当我们开机进入桌面程序后，一般来说我们都会下载安装一些APP，这些APP都安装在data/app目录下。所有的Android程序生成的数据基本上都保存在 data/data目录下。wipedata实质上就是格式化data分区，这样我们安装的所有 APP和程序数据就都丢失了。
a、/data/app
放的是使用者自己安装的应用程式执行档(*.apk)。
b、/data/anr/traces.txt
当你的应用程式发生ANR(Application is Not Responding) 错误时，Android 会自动将问题点的code stack list写在这个档案内，你直接用cat命令就可以看他的内容。
c、/data/system/dropbox/***.txt
主要是系统内apk发生crash时写的日志文件，主要有system_app_crash、data_app_crash等日志。
附录 2.vbmeta 与 boot.img
验证启动（Verified Boot）是Android 一个重要的安全功能，主要是为了访问启动镜像被篡改，提高系统的抗攻击能力，简单描述做法就是在启动过程中增加一条校验链，即ROM code 校验BootLoader，确保BootLoader的合法性和完整性，BootLoader 则需要校验boot image，确保Kernel启动所需image的合法性和完整性，而Kernel则负责校验System分区和vendor分区。
由于ROM code 和BootLoader通常都是由设备厂商OEM提供，而各家实际做法和研发能力不尽相同，为了让设备厂商更方便的引入Verified boot功能，Google在 Android O上推出了一个统一的验证启动框架Android verified boot 2.0，好处是既保证了基于该框架开发的verified boot功能能够满足CDD要求，也保留了各家 OEM定制启动校验流程的弹性。
由于ROM code 校验BootLoader 的功能通常与IC的设计相关，所以AVB 2.0的重点在BootLoader之后的校验流程。BootLoader之后系统启动所涉及的关键镜像通常包括boot.img，system.img，Android O 的treble Project还引入了 dtbo和vendor.img。这些image挨个校验可以说费时费力，而AVB 2.0的做法事实上十分简单，引入一个新的分区：vbmeta.img（verified boot metadata），然后 把所有需要校验的内容在编译时就计算好打包到这个分区，那么启动过程中 BootLoader只需要校验vbmeta.img，就能确认vbmeta内的数据是否可信。再用 vbmeta中的数据去比对bootimg，dtbo，system,img，vendor.img 即可。至于OEM 是还需要放什么其他东西到vbmeta中，则可以由OEM自由定制，可以说保留了很好的客制化空间。
Boot.img就指的Android 系统启动所必须加载的文件。简单地说，boot.img 包含两部分，分别为kernel和ramdisk。当你的Android手机启动时首先会启动 RADIO，然后是SPL。此时SPL会根据你的按键，确定进入哪个模式（例如 Recovery， Fastboot 等等），如果没有按其他键，那么spl会将kernel载入到记 忆体中，ramdisk也会载入到你的设备的根目录。
附录 3.UART
通用异步收发传输器（Universal Asynchronous Receiver/Transmitter，通常称作 UART）是一种串行异步收发协议，应用十分广泛。UART工作原理是将数据的二进制一位一位地进行传输。在UART通讯协议中信号线上的状态位于高电平代表’1’低电平代表’0’。当然两个设备使用UART串口通讯时，必须先约定好传输速率和一些数据位。硬件连接比较简单，仅需要3条线，注意连接时两个设备 UART 电平，如电平范围不一致请做电平转换后再连接，如下图所示：
TX：发送数据端，要接对面设备的 RX
RX：接收数据端，要接对面设备的 TX
GND：保证两设备共地，有统一的参考平面
以上便是关于Bootloader测试解决方案的总结，欢迎大家及时浏览。
本文来自网络或网友投稿，如有侵犯您的权益，请发邮件至：aisoutu@outlook.com 我们将第一时间删除。
相关素材