最新消息: USBMI致力于为网友们分享Windows、安卓、IOS等主流手机系统相关的资讯以及评测、同时提供相关教程、应用、软件下载等服务。

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

IT圈 admin 101浏览 0评论

2023年12月7日发(作者:锺离天纵)

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

本文将对android刷机包的刷机步骤进行简单的解释,本人用的设备是7寸山寨的flytouch,CPU为威盛8505,本次用的固件包为1.7.2,之所以用这个是因为这个固件包的scriptcmd比较完善,在2.0.88中scriptcmd被封装到中了,其实效果应该是一样的。

在此想先提一下Android的启动方式:1.u-boot启动2.加载linux内核内核进行系统初始化4.在内核的start_kernel()函数的kernel_init()中设定ramdisk_execute_command = "/init";最终在init_post()函数中调用init程序,而这个init程序就是Android编译好的在根目录下的init程序。明白了这个过程,对于接下来的刷机就方便多了。

下面用红框圈起来的是本刷机包中主要用到的几个文件:

各文件用途:

Android_ 整个Android的文件系统,里面文件虽然多,但主要的就是根目录下的文件和System文件夹里的文件,System文件夹里的文件又和Android编译出来的里面的文件类似,所以这里推测,如果修改自己的刷机包,把自己修改好的System文件夹进行一下替换即可,当然要注意驱动的问题。

应该是linux的根文件系统镜像

用户数据的部分,里面主要是各种用户程序和安装包,对应编译好的

linux内核镜像

u-boot启动文件

不知道

pre_****_disk文件夹 是可用这里面的文件来替代android_ 和里面的文件的,因为在后面判断若存在这几个文件夹,会进行相同目录的合并工作,这时肯定要发生替换了。

常用命令格式:

fatload [bytes] 仅限内存中

cp source target count

nand write addr off size Nand Flash烧写命令,将SDRAM的 addr地址处的size 字节的数据烧写到Nand的 off 偏移地址。

Scriptcmd中的文件拷贝地址:

nandrw erase all

d mmc 0 0 script/(u-boot)

erase ffff0000 +10000

cp.b 0 ffff0000 10000

cp source target count

即将拷贝到内存ffff0000的位置,count=10000

d mmc 0 0 script/

erase fff80000 +50000

cp.b 0 fff80000 50000 5+8 = D < F, OK

d mmc 0 0 script/(这个应该是linux根文件系统的镜像)

nand write 0 C00000 $(filesize)

d mmc 0 0 script/(这个是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_(这个类似linux启动时的initrd文件,mmc代表接口(类似usb)),就是从设备0拷贝,拷到内存地址0x01000000处,不是和以前一样拷到内存地址0处。

0 (bootm [addr [arg ...]] addr是地址,arg是传递给内核的参数)bootm命令可以引导启动存储在内存中的程序映像。这些内存包括RAM和可以永久保存的Flash。作用是从内存地址0处启动,在上面第四点中把拷贝在内存地址0处,所以这里bootm 0就是执行,在bootargs中还设置了initrd,所以刷机时第一次加载时是需要initrd来执行的,这里initrd就是mvl5_v5t_ramdisk_这个文件,先用gzip解压再挂载,就可以看出它其实就是个临时的linux文件系统。

bootm 指令是专门用于启动在SDRAM中的用U-boot的mkimage工具处理过的内核映像。

可以看出scriptcmd只负责文件拷贝,文件拷贝完打印"",之后就bootm,所以这里出错的可能性很小,有一点是这个刷机包只是支持nand flash的,还有一种是udisk的,所以进行nand write时可能会不行。

之后就要执行文件了,是怎么被执行的呢?

解释: 常用命令格式:

if [ -f /mnt/mmcblk0p1/script/android_ ] ; 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_ ] ; 先判断这个压缩文件是否存在,因为这个文件时超重要的,没有肯定要退出了~~ 这里不知何故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_ -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_ -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/ /mnt/mtd/restore cp /mnt/mmcblk0p1/script/

/mnt/mtd/restore 本来还有后面这句的,但自己的刷机包里没有,也无伤大雅了

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/ -C /mnt/mtd 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 修改权限,再卸载掉

13. flash_eraseall /dev/mtd12 mount -t yaffs2 /dev/mtdblock12 /mnt/mtd

14. create_loopfile mtd12 /mnt/mtd/ bs=524288 为什么要创建这个loop文件啊

15. mkdosfs /mnt/mtd/ 格式化这个loop文件

16. losetup /dev/loop/0 /mnt/mtd/

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

17. flash_eraseall /dev/mtd12

18. mount -t yaffs2 /dev/mtdblock12 /mnt/mtd

19. cp -a /mnt/mmcblk0p1/script/pre_local_disk/* /mnt/mtd

20. echo 0 > /proc/boot-splash

21. if [ -x /mnt/mmcblk0p1/script/ ] ; then 通过判断文件还在不在来判断是否移除了SD卡

22. reboot

综上所述,所作的工作无非还是解压,复制,合并这类的工作,和scriptcmd的工作本质上一样的,不过这也像是启动过程的两层引导,stage1和stage2,stage1先把内核加载进来,之后stage2在linux内核下工作就容易多了。

看到这里,相信读者会明白刷机时怎么样会刷坏?而怎么样又不会刷坏?

在刷机的过程中只是文件的解压和复制,所以除非flash不支持或是其他硬件原因,刷机的过程一般是不会出问题的,关键是刷完之后的启动过程。

如果刷的u-boot的版本不对,连u-boot都启动不起来的话,那以后再刷也不行了;如果u-boot和linux内核的版本都正确,只是Android相关的文件运行不正确,虽然机器不能正常启动,但还是可以再刷一次的;如果u-boot正确,linux内核镜像有问题,那可能刷机过程只执行完scriptcmd就结束了,无法正确执行,但只要u-boot正确,还是可以再刷的,直到刷回好用的版本。

以上只是自己的一点认识,如有错误,欢迎指正。

2023年12月7日发(作者:锺离天纵)

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

本文将对android刷机包的刷机步骤进行简单的解释,本人用的设备是7寸山寨的flytouch,CPU为威盛8505,本次用的固件包为1.7.2,之所以用这个是因为这个固件包的scriptcmd比较完善,在2.0.88中scriptcmd被封装到中了,其实效果应该是一样的。

在此想先提一下Android的启动方式:1.u-boot启动2.加载linux内核内核进行系统初始化4.在内核的start_kernel()函数的kernel_init()中设定ramdisk_execute_command = "/init";最终在init_post()函数中调用init程序,而这个init程序就是Android编译好的在根目录下的init程序。明白了这个过程,对于接下来的刷机就方便多了。

下面用红框圈起来的是本刷机包中主要用到的几个文件:

各文件用途:

Android_ 整个Android的文件系统,里面文件虽然多,但主要的就是根目录下的文件和System文件夹里的文件,System文件夹里的文件又和Android编译出来的里面的文件类似,所以这里推测,如果修改自己的刷机包,把自己修改好的System文件夹进行一下替换即可,当然要注意驱动的问题。

应该是linux的根文件系统镜像

用户数据的部分,里面主要是各种用户程序和安装包,对应编译好的

linux内核镜像

u-boot启动文件

不知道

pre_****_disk文件夹 是可用这里面的文件来替代android_ 和里面的文件的,因为在后面判断若存在这几个文件夹,会进行相同目录的合并工作,这时肯定要发生替换了。

常用命令格式:

fatload [bytes] 仅限内存中

cp source target count

nand write addr off size Nand Flash烧写命令,将SDRAM的 addr地址处的size 字节的数据烧写到Nand的 off 偏移地址。

Scriptcmd中的文件拷贝地址:

nandrw erase all

d mmc 0 0 script/(u-boot)

erase ffff0000 +10000

cp.b 0 ffff0000 10000

cp source target count

即将拷贝到内存ffff0000的位置,count=10000

d mmc 0 0 script/

erase fff80000 +50000

cp.b 0 fff80000 50000 5+8 = D < F, OK

d mmc 0 0 script/(这个应该是linux根文件系统的镜像)

nand write 0 C00000 $(filesize)

d mmc 0 0 script/(这个是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_(这个类似linux启动时的initrd文件,mmc代表接口(类似usb)),就是从设备0拷贝,拷到内存地址0x01000000处,不是和以前一样拷到内存地址0处。

0 (bootm [addr [arg ...]] addr是地址,arg是传递给内核的参数)bootm命令可以引导启动存储在内存中的程序映像。这些内存包括RAM和可以永久保存的Flash。作用是从内存地址0处启动,在上面第四点中把拷贝在内存地址0处,所以这里bootm 0就是执行,在bootargs中还设置了initrd,所以刷机时第一次加载时是需要initrd来执行的,这里initrd就是mvl5_v5t_ramdisk_这个文件,先用gzip解压再挂载,就可以看出它其实就是个临时的linux文件系统。

bootm 指令是专门用于启动在SDRAM中的用U-boot的mkimage工具处理过的内核映像。

可以看出scriptcmd只负责文件拷贝,文件拷贝完打印"",之后就bootm,所以这里出错的可能性很小,有一点是这个刷机包只是支持nand flash的,还有一种是udisk的,所以进行nand write时可能会不行。

之后就要执行文件了,是怎么被执行的呢?

解释: 常用命令格式:

if [ -f /mnt/mmcblk0p1/script/android_ ] ; 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_ ] ; 先判断这个压缩文件是否存在,因为这个文件时超重要的,没有肯定要退出了~~ 这里不知何故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_ -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_ -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/ /mnt/mtd/restore cp /mnt/mmcblk0p1/script/

/mnt/mtd/restore 本来还有后面这句的,但自己的刷机包里没有,也无伤大雅了

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/ -C /mnt/mtd 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 修改权限,再卸载掉

13. flash_eraseall /dev/mtd12 mount -t yaffs2 /dev/mtdblock12 /mnt/mtd

14. create_loopfile mtd12 /mnt/mtd/ bs=524288 为什么要创建这个loop文件啊

15. mkdosfs /mnt/mtd/ 格式化这个loop文件

16. losetup /dev/loop/0 /mnt/mtd/

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

17. flash_eraseall /dev/mtd12

18. mount -t yaffs2 /dev/mtdblock12 /mnt/mtd

19. cp -a /mnt/mmcblk0p1/script/pre_local_disk/* /mnt/mtd

20. echo 0 > /proc/boot-splash

21. if [ -x /mnt/mmcblk0p1/script/ ] ; then 通过判断文件还在不在来判断是否移除了SD卡

22. reboot

综上所述,所作的工作无非还是解压,复制,合并这类的工作,和scriptcmd的工作本质上一样的,不过这也像是启动过程的两层引导,stage1和stage2,stage1先把内核加载进来,之后stage2在linux内核下工作就容易多了。

看到这里,相信读者会明白刷机时怎么样会刷坏?而怎么样又不会刷坏?

在刷机的过程中只是文件的解压和复制,所以除非flash不支持或是其他硬件原因,刷机的过程一般是不会出问题的,关键是刷完之后的启动过程。

如果刷的u-boot的版本不对,连u-boot都启动不起来的话,那以后再刷也不行了;如果u-boot和linux内核的版本都正确,只是Android相关的文件运行不正确,虽然机器不能正常启动,但还是可以再刷一次的;如果u-boot正确,linux内核镜像有问题,那可能刷机过程只执行完scriptcmd就结束了,无法正确执行,但只要u-boot正确,还是可以再刷的,直到刷回好用的版本。

以上只是自己的一点认识,如有错误,欢迎指正。

发布评论

评论列表 (0)

  1. 暂无评论