androidbootloader过程分析.docVIP

Mtk的android boot.img在第一个2048后，多了512byte的数据，用ultraedit删掉后即可正常解压，重新生成boot.img后，要用ultraedit在同样位置十六进制插入512byte，然后用winhex在原boot.img中复制原来的512byte数据进去。 三星内核（zImage或者boot.img）用xiaolu的unpack解，他们的kernel和recovery是放在一起的，都刷入/dev/block/mmcblk0p5。 P1的boot.img，recover.img用split_bootimg解。Kernel和recovery在不同的分区。 刷recovery，fastboot flash recovery recovery-new.img 卡刷kernel， package_extract_file(boot.img, /dev/block/platform/omap/omap_hsmmc.1/by-name/boot); Boot.img little-endian lsb 第一行：前8字节，android!,8位 kernal_size, long int 482f2400=00242f48=2371400， 第二行：8字节ramdisk_size，8位 second_size 第三行：8字节中后4字节 page_size00000800=2048，8字节unuse 第四行：16字节product_name， 第5-36行：512字节，BOOT_ARGS 第37-38行：32字节，ID 一个字节等于8位二进制数，一位十六进制的数等于四位二进制的数，等于半个字节。 2048 2560 2373632 2666336 2666495 2666332 pit 分区配置文件，odin用 zimage linux内核文件 boot.bin param.lfs sbl.bin bootloader #1，整个系统的引导是从boot.bin开始的 #2，boot完成必要的初始化以后，通过pit信息找到sbl分区 #3，sbl在引导过程中，检测是否存在满足要求的按键组合，如果满足进入download模式（俗称挖煤）的条件，就进入download，如果是进入recovery模式的按键组合，就传递参数给kernel，也就是zImage分区，进入recovery模式，如果都没有，就传递参数给kernel，正常启动系统。 e2fsck功能说明： 检查ext2、ext3、ext4等文件系统的正确性 mke2fs 建立Linux的ext2文件系统 zclp5线刷包 zImage解压后，得到二进制的init，可能三星把正常启动和进入recovery，都放在一个程序里了。根据不同的启动模式，加载init.rc或者recovery.rc root后的zImage跟原来的内核区别 1、msic里多了recovery.fstab，提供能够加载的文件系统及对应的mount node Cm10卡刷包，recovery是cwm v6.0.1.5 updater-script里write_raw_image(/tmp/boot.img, /dev/block/mmcblk0p5) bootimg 解压，根目录得到init，此init链接到了/stage1/init,/stage1/init脚本，init通过busybox运行，根据传入的启动模式，选择boot.cpio或recovery.cpio解压，得到不同的新的init并执行。 #!/stage1/busybox sh _PATH=$PATH export PATH=/stage1 busybox cd / busybox date boot.txt exec boot.txt 21 busybox rm init busybox mount -t proc proc /proc busybox mount -t sysfs sysfs /sys load_image=/stage1/boot.cpio if busybox grep -q bootmode=2 /proc/cmdline ; then # recovery boot load_image=/stage1/recovery.cpio fi busybox cpio -i ${load_image} busybox umount /sys busybox umount /proc busybox date boot.txt busybox rm -fr /stage1 /dev/* export PATH=${_PATH} exec /init 新的init文件，就可以引导至