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 得到 
<think>我们正在讨论Android启动镜像的相关概念。用户之前询问了vendor_dlkm和vendor_boot.img的区别,现在转向询问init_boot.imgboot.img和vendor_boot.img的顺序及区别。根据引用资料[1][2][3],我们可以这样分析: 1. **boot.img**: - 传统的主要启动镜像,包含Linux内核和初始根文件系统(ramdisk)[^3]。 - 结构:boot header + kernel + ramdisk + (可选的second stage loader)[^3]。 - 作用:初始化硬件和启动Android系统的核心服务。 2. **vendor_boot.img**: -boot.img结构类似,但专注于vendor-specific的组件[^1]。 - 包含:vendor ramdisk、vendor相关的DTB(设备树)等[^1]。 - 作用:加载厂商特定的硬件驱动和配置(如专有的WiFi/摄像头驱动)。 3. **init_boot.img**: - 在Android 13引入的新镜像(作为boot.img的替代方案)[^2]。 - 结构:只包含ramdisk(其中包含init可执行文件)而不包含内核[^2]。 - 作用:专注于init进程的启动,分离内核更新和系统初始化。 启动顺序: 1. Bootloader加载**boot.img**(内核+基础ramdisk)或**init_boot.img**(纯ramdisk)。 2. 若使用**vendor_boot.img**,则bootloader会同时加载它(提供vendor ramdisk)。 3. 内核启动后,首先执行ramdisk中的init进程(来自boot.img或init_boot.img)。 4. vendor_boot.img中的模块稍后由init进程加载(例如通过init.rc脚本)。 关键区别: - **boot.img**:完整的启动镜像(内核+ramdisk),适用于旧版Android。 - **init_boot.img**:仅含ramdisk(无内核),内核独立更新(如GKI设备)。 - **vendor_boot.img**:厂商定制内容(独立于系统通用部分)。 验证方法(引用[2]): ```bash # 解包init_boot.img unpack_bootimg --boot_img init_boot.img --out init_boot_unpacked # 解包vendor_boot.img unpack_bootimg --boot_img vendor_boot.img --out vendor_boot_unpacked ``` --- §§相关问题§§ 1. Android 13中init_boot.img如何与GKI(Generic Kernel Image)配合? 2. vendor_boot.img中的设备树(DTB)如何被内核使用? 3. 如何向vendor_boot.img的ramdisk中添加新驱动模块? </think>### init_boot.imgboot.img 和 vendor_boot.img 的顺序及区别 #### **一、启动顺序(时间轴)** ```mermaid flowchart LR Bootloader -->|首加载| init_boot.img -->|初始化init进程| kernel kernel -->|加载| boot.img -->|挂载系统服务| Android Android -->|按需加载| vendor_boot.img -->|厂商硬件驱动| 设备 ``` 1. **init_boot.img** - **最先加载**:由 bootloader 直接加载 - **唯一作用**:启动 `init` 进程(PID=1 的根进程)[^2] - 例如:Android 13+ 设备启动时优先加载此镜像 2. **boot.img** - **第二阶段加载**:内核启动后加载 - **核心组件**:通用内核 + 基础 ramdisk(含系统服务)[^3] - 例如:传统 Android 设备的主启动镜像 3. **vendor_boot.img** - **最后加载**:系统初始化后按需加载 - **厂商定制**:专有硬件驱动(WiFi/摄像头等)和设备树[^1] - 例如:高通设备的 Adreno GPU 驱动加载 > **关键顺序公式**: > $$ \text{init\_boot} \rightarrow \text{kernel} \rightarrow \text{boot} \rightarrow \text{vendor\_boot} $$ --- #### **二、功能区别对比** | 特性 | init_boot.img | boot.img | vendor_boot.img | |---------------------|--------------------------------|-------------------------------|-------------------------------| | **加载时机** | Bootloader 阶段[^2] | 内核启动后 | 系统服务初始化后[^1] | | **核心内容** | `init` 可执行文件 | 通用内核 + 基础 ramdisk[^3] | 厂商 DTB + vendor ramdisk | | **设计目标** | 分离 init 进程与内核更新 | 提供通用 Android 启动环境 | 实现硬件厂商定制化 | | **解包内容示例** | `/init` | `kernel`,`ramdisk/init.rc` | `dtb`,`vendor_ramdisk/lib` | | **Android 版本** | 13+ 引入 | 所有版本 | 10+ 强化 | --- #### **三、技术验证(解包命令)** 1. **init_boot.img 解包** ```bash unpack_bootimg --boot_img init_boot.img --out init_unpacked # 输出:init 可执行文件(位于 ramdisk 根目录)[^2] ``` 2. **boot.img 解包** ```bash unpack_bootimg --boot_img boot.img --out boot_unpacked # 输出:kernel (zImage) + ramdisk (系统服务脚本)[^3] ``` 3. **vendor_boot.img 解包** ```bash unpack_bootimg --boot_img vendor_boot.img --out vendor_unpacked # 输出:vendor_dtb + vendor_ramdisk (硬件驱动)[^1] ``` --- #### **四、协作关系** ```mermaid graph TD A[Bootloader] -->|加载| B(init_boot.img) B --> C[启动 init 进程] C --> D[加载 kernel] D --> E[boot.img] E --> F[挂载/system] F --> G{检测硬件} G -->|需要厂商驱动| H[vendor_boot.img] G -->|通用驱动| I[系统继续启动] ``` - **依赖逻辑**: vendor_boot.img 的驱动 **依赖** boot.img 提供的系统环境 init_boot.img **完全不依赖** 其他镜像(独立加载)[^2] - **更新隔离**: 更新 vendor_boot.img **不影响** boot.img 的通用内核 更新 init_boot.img **仅影响** init 进程初始化[^1] --- #### **五、典型应用场景** 1. **init_boot.img** Android 13 设备修复 init 进程崩溃(无需刷完整系统) 2. **boot.img** 自定义 ROM 开发(如替换内核启用 CPU 超频) 3. **vendor_boot.img** 更新手机摄像头的专有驱动(如索尼 IMX989 传感器优化) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值