在u-boot里面加入Android lk bootloader的一键烧写功能（1）

主要任务:在u-boot里面加入Android lk bootloader的一键烧写功能。

硬件平台：SEP6200测试板  unicore架构 /256M RAM/4G NandFlash

       我们知道要在特定的平台上安装Android系统需要烧写的几个镜像文件，首先是bootloader，然后linux内核的kernel文件，ramdisk文件，文件系统system.img 。以上的镜像是必须的。根据我们的需求可能还需要userdata.img（存放一些预装的用户程序、文件等）、recovery.img用来进入Android的恢复模式、misc（存放recovery的引导信息，logo信息等）。那么如果每次编译完新系统都需要烧写一大堆的文件，岂不是很麻烦。所以我们可以利用镜像整合的工具将这些文件集合到一个文件中，然后一次性烧写到我们的系统中，这样就可以省下不少的时间，这也是手机厂商为啥在发布刷机包的时候只发布一个文件就好了的原因。

       lk（little kernel）是一个开源的针对Android系统的bootloader，可以在https://www.codeaurora.org/2010/03/02/little-kernel-based-android-bootloader/找到它的详细信息。而我之前拿到的lk版本已经实现了一键烧写Android镜像的功能，但是由于lk所提供的shell功能太少，没有u-boot的功能强大，所以我现在要将这个功能加入到现在使用的u-boot版本中。

       我们先来看看Android编译完成之后有哪些镜像吧。

       1.kernel   Android的kernel现在和Android源码是分离的，所以我们需要单独编译kernel然后拷贝到便以输出的目录中。Android的kernel是基于linux的，在linux的基础上加入了一些Android特性，如binder之类的。

       2.ramdisk.img 内存文件系统的文件，包含了Android启动之后的根分区的目录和一些文件，启动后挂载至 /  根分区。

       3.boot.img  这个文件是对kernel和ramdisk.img的整合。我们来看一下这个文件的组织结构：android源码有个bootimg.h中描述如下：

/*
** +-----------------+ 
** | boot header     | 1 page
** +-----------------+
** | kernel          | n pages  
** +-----------------+
** | ramdisk         | m pages  
** +-----------------+
** | second stage    | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
**    the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr.  kernel_args[] is
**    appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
**    else: jump to kernel_addr
*/

       首先在boot.img的头部有一个页（我们的是2kB）存放着kernel、ramdisk的信息，包括大小、传递参数等。值得一提的是， ramdisk为 1F8B0800000000开头。 我们可以借用这个特征去寻找ramdisk的地址。second stage是启动时如果需要其他的阶段可以先执行这边的指令，不是必须的，我们的工程里面没有加入second stage

        4.recovery.img Android系统提供了一种recovery模式，可以让我们去刷机安装一些更新包，可以清除用户数据和cache等功能。相信用过Android手机的人都应该进入过recovery，平时我们去刷机的时候进入的就是这个模式。Android 可以通过Recovery 模式，实现恢复出厂设置 、OTA 升级、patch 升级及firmware 升级。在开机后按下某个键（根据源码配置）可以进入recovery 模式。

大部分升级（包括刷机）都可以通过一个SD卡 中的"updata.zip"文件升级包进行傻瓜式升级（步骤简单的升级）。而这一过程就是在系统进入Recovery 模式后，通过升级程序运行升级包中“META-INF/com/google/android/update-script 脚本来执行各种不同的自定义升级，脚本中是一组recovery 模式下系统能识别的UI 控制命令和文件系统操作命令，例如write_raw_image （烧写FLASH 分区）、copy_dir （复制目录）等等。网上搜了一下相关的博客，得知：

（1）recovery.img其实已经是进入了Linux系统 。
（2）recovery.img为了具有恢复系统的能力，比普通的boot.img目录结构中：
       1、多了/res/images目录，在这个目录下的图片 都是恢复时我们看到的背景画面。
       2、多了/sbin/recovery二进制程序 ，这个就是恢复用的程序。
       3、/sbin/adbd不一样，应该和恢复有关。
（3）Android系统中的初始化程序（init）和初始化配置文件（default.prop、init.trout.rc、init.rc、init.goldfish.rc、）都不一样。这就是系统没有进入图形界面而进入了类似文本界面，并可以通过简单的组合键进行恢复的原因。

       5.system.img 这个文件才是android的文件系统，为yaffs2或者是ext3/4的文件系统。包含了android运行时几乎所有的文件，加载后将挂载到/system目录下。至于Android的系统目录结构不在本文讨论范围内，有机会研究一下。

       6.userdata.img 为用户的文件，也是yaffs2或者ext3/4的文件系统，Android系统启动后挂载至/data目录下。存放一些预装的软件等，对用户是开放写入权限的，而位于/system下的文件是不开放用户写入权限的，需要写入必须root。这也解释了为什么手机中有些软件是可以卸载的，而有些软件没办法卸载。

       为了将以上所说的镜像都打成一个包实现一个镜像烧写即可运行Android系统。我们还需要一个整合工具，即镜像的打包工具。整合之后的镜像是这个样子的：

       首先头部信息有48字节，给出了头部信息、头部大小、CRC32校验码等信息。然后依次存放各个镜像，每个镜像都有一个16字节的头，分别表示镜像的名称和大小。有多少个镜像就有多少个头部，以此类推........

       我们在bootloader部分需要做的就是对这个巨大的镜像进行解析并且烧写到我们的NandFlash中。启动的时候再从NandFlash中读出来然后启动Android系统。