Android平板电脑刷机包简单解释

Android 平板手机刷机包简单解释本文将对 android 刷机包的固件步骤进行简洁的解释，本人用的设备是 7 寸山寨的 flytouch， CPU 为威盛 8505，本次用的固件包为 1.7.2，之所以用这个是因为这个固件包的 scriptcmd 比较建立，在 2.0.88 中 scriptcmd 被封装到 prepare.bin 中了，其实效果需要是一样的。 在此想先提一下 Android 的开启模式：1.u-boot 启动 2.加载 linux 内核 3.linux 内核进行平台 初始化 4.在内核的 start_kernel()函数的 kernel_init()中设定 ramdisk_execute_command = "/init"; 最终在 init_post()函数中读取 init 程序， 而这个 init 程序就是 Android 编译好的在根目录下的 init 程序。明白了这个过程，对于接下来的刷机就方便多了。 下面用黑框圈出来的是本刷机包中主要用到的几个文件：各文件功能： Android_fs.tgz 整个 Android 的文件系统，里面文件仍然多，但主要的就是根目录下的文件 和 System 文件夹里的文件，System 文件夹里的文件又跟 Android 编译出来的 System.img 里 面的文件类似，所以此处推测，如果更改自己的刷机包，把自己修改好的 System 文件夹进 行一下替换就能，当然应留意驱动的问题。

Ramdisk.gz 应该是 linux 的根文件系统镜像 Data.tgz 用户数据的个别，里面主要是各类客户程序跟安装包，对应编译好的 Data.img uzImage.bin linux 内核镜像 u-boot.bin u-boot 启动文件 wload.bin 不知道 pre_****_disk 文件夹 是可用这上面的文件来替代 android_fs.tgz 和 data.tgz 里面的文件的， 因为在上面判断若存在这几个文件夹， 会进行同样目录的合并工作， 这时显然应出现更换了。常用命令格式： fatload <interface> <dev[:part]> <addr（目的地址）> <filename> [bytes] 仅限内存中 cp source target countnand write addr off size Nand Flash 烧写命令，将 SDRAM 的 addr 地址处的 size 字节的数据读入到 Nand 的 off 偏移地址。Scriptcmd 中的文件拷贝地址： nandrw erase all 1.fatload mmc 0 0 script/wload.bin（u-boot） erase ffff0000 +10000 cp.b 0 ffff0000 10000 cp source target count 即将 wload.bin 拷贝到硬盘 ffff0000 的位置，count=10000 2.fatload mmc 0 0 script/u-boot.bin erase fff80000 +50000 cp.b 0 fff80000 50000 5+8 = D < F， OK 3.fatload mmc 0 0 script/ramdisk.gz（这个需要是 linux 根文件系统的镜像） nand write 0 C00000 $(filesize) 4.fatload mmc 0 0 script/uzImage.bin（这个是 linux 内核的镜像，u 代表是 u-boot 模式） nand write 0 0 $(filesize)5. 设置环境变量：setenv bootargs mem=237M root=/dev/ram rw initrd=0x01000000,32M console=ttyS0,115200n8 init=/linuxrc lcdid=1 fatload mmc 0 1000000 script/mvl5_v5t_ramdisk_WM8505.090922.loop.gz（这个类似 linux 启动时的 initrd 文件，mmc 代表接口（类似 usb）），就是从设备 0 拷贝，拷到内存地址 0x01000000 处，不是和当时一样拷到内存地址 0 处。

6.bootm 0 （bootm [addr [arg ...]] addr 是地址，arg 是释放给内核的参数）bootm 命令可以引导启动传输在存储中的程序映像。这些存储比如 RAM 和可以永久保存的 Flash。作用是从内存地 址 0 处开启平板rom下载，在里面第四点中把 uzImage.bin 拷贝在内存地址 0 处，所以此处 bootm 0 就是执行 uzImage.bin，在 bootargs 中还修改了 initrd，所以刷机时第一次加载时是必须 initrd 来执行的， 这里 initrd 就是 mvl5_v5t_ramdisk_WM8505.090922.loop.gz 这个文件，先用 gzip 解压再挂载，就可以看出它似乎就是个临时的 linux 文件系统。bootm 指令是专门用于推进在 SDRAM 中的用 U-boot 的 mkimage 工具处理过的内核映像。 可以看出 scriptcmd 只负责文件拷贝，文件拷贝完打印"Please wait..."，之后就 bootm，所以 这里错误的可能性很小，有一点是这个刷机包也是支持 nand flash 的，还有一种是 udisk 的， 所以进行 nand write 时可能会不行。

之后将要执行 update.sh 文件了，是如何被执行的呢？ Update.sh 解释：常用命令格式： if [ -f /mnt/mmcblk0p1/script/android_fs.tgz ] ; then （-f 表示判定该文件名是否存在且为文件，-d 表示 directory，文件夹） string="Update filesystem Start ......" echo $string gui-echo $pointX $pointY "$string" 这里显示字符串要用两个 echo，不知道 else exit 0 退出 fi 结束 if 条件 将 if 反过来写，挺好玩的 if [ $? -ne 0 ] ; then ……else……： $?是上一个操作的返回值，-ne 是 not equal 的意思，因 为 linux 中返回 0 代表错误，所以前面的操作就是若不错误，就执行 else 中的内容。 猜测： /dev/mtdblock9 为 nand flash 闪存，因为根文件系统在这里 1. if [ -f /mnt/mmcblk0p1/script/android_fs.tgz ] ; 先判定这个压缩文件是否存在，因为这个 文 件 时 超 重 要 的 ， 没 有 肯 定 要 退 出 了 ~~ 这 里 不 知 何 故 sd 卡 已 经 自 动 挂 载 到 /mnt/mmcblk0p1/了，又是看不见的操作…………,我的设想是这种的，在 scriptcmd 中， 已经把 ramdisk 加载到 sd 卡了，这是个可以运行的 linux 根文件目录，这里肯定有/mnt/ 这个目录的 2. flash_eraseall /dev/mtd9 不解释 3. mount -t yaffs2 /dev/mtdblock9 /mnt/mtd -t 只是表示我现在挂载要制定文件类型，文 件类型自然为 yaffs2 了，把/dev/mtdblock9 挂载到/mnt/mtd 上 4. tar zxvf /mnt/mmcblk0p1/script/android_fs.tgz -C /mnt/mtd 解压到/mnt/mtd 上，实际上是 解压到/dev/mtdblock9 上了，但这个东西是啥还不知道，算是耗时最长的一步了。

5. if [ -d /mnt/mmcblk0p1/script/driver ] ; cp -a /mnt/mmcblk0p1/script/driver/* /mnt/mtd 实际还是把驱动拷到设备里，这样才对嘛 6. tar zxvf /mnt/mmcblk0p1/script/busybox_1.16.tgz -C /mnt/mtd ， if [ -x /mnt/mtd/busybox/bin/ash ] ; then mv /mnt/mtd/system/bin/sh /mnt/mtd/system/bin/sh-org ln -s /busybox/bin/busybox /mnt/mtd/system/bin/sh 用 busybox(不是 busybox 的 sh)把 system 原来的 sh 替换掉，不知为什么 if [ -d /mnt/mmcblk0p1/script/pre_root_disk ] ; then 7. cp -a /mnt/mmcblk0p1/script/pre_root_disk/* /mnt/mtd /pre_root_disk 下的文 件跟 andorid 根目录的文件合并（其实没几个文件的，但可以自己添加定制了） 8. cp /mnt/mmcblk0p1/script/data.tgz /mnt/mtd/restore cp /mnt/mmcblk0p1/script/cache.tgz /mnt/mtd/restore 本来也有中间这句的，但自己的刷机包里没有 cache.tgz，也无伤大雅 了 9. chmod 777 -R /mnt/mtd chown root:0 /mnt/mtd/system/bin/preboot umount /mnt/mtd 改变根文件系统的权限，改变 preboot 的拥有者和权限，最后卸载 /mnt/mtd，终于完成使命了？ 10. flash_eraseall /dev/mtd10 从那既冒出来个 mtd10？ 可能都是临时的吧。

11. mount -t yaffs2 /dev/mtdblock10 /mnt/mtd 这是 Data 部分的挂载点。 12. tar zxvf /mnt/mmcblk0p1/script/data.tgz -C /mnt/mtd13. 14. 15. 16.17. 18. 19. 20. 21. 22.cp -a /mnt/mmcblk0p1/script/etc/* /mnt/mtd/wmtpref cp -a /mnt/mmcblk0p1/script/pre_data_disk/* /mnt/mtd chmod 777 -R /mnt/mtd sync umount /mnt/mtd 修改权限，再删除掉 flash_eraseall /dev/mtd12 mount -t yaffs2 /dev/mtdblock12 /mnt/mtd create_loopfile mtd12 /mnt/mtd/vfat.bin bs=524288 为什么要创建这个 loop 文件啊 mkdosfs /mnt/mtd/vfat.bin 格式化这个 loop 文件 losetup /dev/loop/0 /mnt/mtd/vfat.bin mount -o iocharset=gb2312 -t vfat /dev/loop/0 /LocalDisk cp -a /mnt/mmcblk0p1/script/pre_local_disk/* /LocalDisk losetup -d /dev/loop/0 chmod 777 -R /mnt/mtd sync umount /mnt/mtd flash_eraseall /dev/mtd12 mount -t yaffs2 /dev/mtdblock12 /mnt/mtd cp -a /mnt/mmcblk0p1/script/pre_local_disk/* /mnt/mtd echo 0 > /proc/boot-splash if [ -x /mnt/mmcblk0p1/script/update.sh ] ; then 通过判断 update.sh 文件还在不在来判定 是否移除了 SD 卡 reboot综上所述，update.sh 所作的工作仅仅还是解压，复制，合并这类的工作，和 scriptcmd 的工 作本质上一样的，不过这也像是推进过程的两层引导，stage1 和 stage2，stage1 先把内核加 载进来，之后 stage2 在 linux 内核下工作就容易多了。

看到这儿，相信观众会知道刷机时怎么样会刷坏？而怎么样又不会刷坏？ 在刷机的过程中也是文件的解压和复制，所以如果 flash 不支持或是其它软件因素，刷机的 过程通常是不会出难题的，关键是刷完以后的开启过程。 如果刷的 u-boot 的版本不对， u-boot 都开启不出来的话， 连 那之后再刷也不行了； 如果 u-boot 和 linux 内核的版本都正确，只是 Android 相关的文件运行不恰当，虽然机器不能正常开启， 但而是可以再刷一次的；如果 u-boot 正确，linux 内核镜像有问题，那也许刷机过程只执行 完 scriptcmd 就结束了平板rom下载，update.sh 无法恰当执行，但即使 u-boot 正确，还是可以再刷的，直 到刷回好用的版本。以上也是自己的一点认识，如有错误，欢迎指正。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shouji/article-143530-1.html