android boot

1: soc 的 usb 功能应该在给cpu 上电之后就应该work，但是在与pc通讯过程中（以下所有的pc与device的通讯都可以看成是一个client 一个 server）的协议都 cpu厂商自己定义的，而不是通用的android 的adb协议或fastboot协议，所以在我所经历的不同的cpu vendor中，在最开始download code 时候（在没有 fastboot的前期），都有自己的烧录工具。比如： qualcomm 的（啥工具，忘了叫什么名字了）， intel的xfstk， nvdia的nvflash. 不同的cpu, 这些工具使用的 usb 通讯上层协议，都是 cpu厂商自己的，而非fastboot，adb 这种通用的。

intel的xfstk， nvdia的nvflash，qualcomm的emergency download 模式，cpu的固化程序会判断，按键，或者第一次打板子emmc是空的时候，系统会自动判断并且进入这种 cpu厂商的recovery mode。注意，这个和后来的recover mode 不是一个recovery，后来的那个是android的recovery mode。

2：boot /code 的角色，权限，所能掌控的信息

一个设备有很多boot，很多阶段，每个阶段都对应着能够访问的限定的空间。一般而言，越底层（cpu厂商），权限越高；却上层（user）,权限越低。

=================================

所以首先划分一下都有哪些角色。

cpu 厂商：

cpu厂商的客户，开发者：

user：

资源可分为： cpu , sram,dram, emmc

emmc可分为：reserver 区，user 能访问的区域，开发者能访问的区域(recovery),

=================================

同时权限越高，进入操作期就越早，这个期间能够被操作的介质空间也越小。然后逐步把权力下方给权限小的，并且同时把大的资源enable起来。

例如：

开机流程：

cpu 上电后固化代码在 sram中执行，

download 流程：

开机和download的流程其实本质上是一样的，见下面的

================================

其中一个概念：执行的代码，必须是了解代码要执行对象的参数信息，那就是说这段代码有着他所属的生活群体。比如固化code（let's say it boot0）了解cpu信息，但是他不了解外围器件由cpu厂商的客户（即开发者）挑选的器件的信息，比如emmc的型号，参数等，这些信息只有开发者知道，所以要有一段code配置这些设备，let's say it boot1.

boot0执行完之后，如果想更进一步执行有关开发者选定器件相关的code，就需要： load boot1到dram中，并把控制权交给boot1来执行，例如初始化emmc，得到了更大的存储空间。然后load bootloader上的程序(在emmc上)，这是开机过程；或者准备download pc上的code到emmc上，这是download 过程。

这种关系，承担任务的转换，主要与进入操作期的时间早晚（比如上电后是有boot0最开始有机会执行），和对他所能掌控的设备（比如boot0无法得知外围器件信息，如果想更进一步，只能由boot1来完成），来决定的。但是boot0-->boot1角色的转换，是有boot0来发起的

=================================

======================================================================================================

recovery mode：这段区域是user不可见的一段区域，所以他们不会破坏掉他，这也就是为什么有时候操作系统不工作了，人们会选择到recovery mode来做一些工作。

recovery 其实就是一个小型的最基本的操作系统

recovery 区域只是存储recovery 系统的一个分区而已，而partition表（在windows系统中叫mbr），所以这个分区表更是user不能访问的。

但是fastboot是可以重写partition表格和根据表格烧录code的，类似于windows中的bois。

fastboot是 android在boot阶段的一个usb协议。

adb 是androi的os起来之后的一个usb协议。

=====

更多相关文章

随机推荐