boot.img的分析

1 boot.img 
boot.img是由文件头信息，内核数据以及文件系统数据组成，它们之间非页面对齐部分用0填充
文件头信息的具体结构可以在system/core/mkbootimg/bootimg.h中看到：
struct boot_img_hdr  
{  
    unsigned char magic[BOOT_MAGIC_SIZE];  
    unsigned  kernel_size;  
    unsigned  kernel_addr;  
    unsigned  ramdisk_size;  
    unsigned  ramdisk_addr;  
    unsigned  second_size;  
    unsigned  second_addr;  
    unsigned  tags_addr;  
    unsigned  page_size;  
    unsigned  unused[2];  
    unsigned  char  name[BOOT_NAME_SIZE]  
    unsigned  char cmdline[BOOT_ARGS_SIZE]  
    unsigned  id[8]; //存放时间戳，校验和，SHA加密等内容  
}

2 生成boot.img 
在build/core/Makefile里，INSTALLED_BOOTIMAGE_TARGET 是生成boot.img ,其中参数为INTERNAL_BOOTIMAGE_ARGS ,该参数
主要是--kernel , 用到了BOARD_KERNEL_BASE ，而在device/qcom/BoardConfig.mk中，会定义 BOARD_KERNEL_BASE 
这样mkbootimg :
--kernel     kernel   --ramdisk   ramdisk.img  --cmdline $(BOARD_KERNEL_CMDLINE) 
--base $(BOARD_KERNEL_BASE)  --pagesize 2048 
 
mkbootimg的代码在system/core/mkbootimg 它分析参数后，依次写入header, kernel ,ramdisk . 
header参数为：
 kernel_addr  = base 0x8000  --- 内核加载的基地址
 ramdisk_addr = base 0x01100000
 tags_addr    = base 0x1000

确认 boot loader 所用的内核基地址必须和内核映像在编译时所用的运行基地址一致，假设你的内核映像在
编译时用的基地址是 0xc0008000，但你的 boot loader 却将它加载到 0xc0010000 处去执行，那么内核映像
当然不能正确地执行了。

在Kernel/arch/arm 下面的Makefile.boot 中指定了内核编译链接的基地址。
zreladdr    ---- kernel_addr
params_phys ---- tags_addr

3 boot.img的加载
 在lk 中， smem_ptable_init 函数中会初始化 smem_apps_flash_start ，它通过读share memory ,也就是ARM9端传入的0:APPS 
 这样在targe_init函数中，会将offset = smem_apps_flash_start , 然后ptable_add将第一个分区的地址设置为offset .
 
 在ARM9 中 有两个文件 partition.h 和 partition.c 
 partition.h  中定义了：
   FLASH_PARTI_APPS  "0:APPS" --- 对于boot.img 
 partition.c  中定义了所有的分区的大小， 这样smem_apps_flash_start 其实就为ARM9的所有image的大小。
 
 4 ARM9中的实现
   函数smem_retrieve_mibib 中将分配 smem_alloc , 也就是有512 字节的 MIBIB区 
   
   MIBIB区 ： 16个字节是header 
              每个分区 28个字节
              这样共有16个分区
  每个分区信息，flash_partition_entry 包括了name 和 offset .
  这样ARM11 测 根据name 为0:APPS 得到offset ，也就是该分区的起始地址。
  MIBIB 分区 是通过根据 mjnand -c mibib_xxx.cfg 得到 

转载于:https://www.cnblogs.com/LoongEmbedded/p/5298424.html