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协议。

=====