flash USB升级包制作工具mkRecoveryBin，海思方案应该都能用
5 E币
成为会员，免费下载资料
文件大小：33.39 KB
上传者：ngswfx
时间：2016-07-27 11:05:06
下载量：12
本帖最后由 ngswfx 于 2016-7-27 11:18 编辑
/////////按照自己的理解写的，还在实际使用优化中.......
/////////目前使用很不错，发上来，大家参考一下。已经利用这个工具，成功自动升级了8M flash的3520D以及32M flash的3520D
我先描述一下我自己的flash上几个部分情况：
uboot 一般从0x0--------0x20000
ENV 从0x20000 -------0x30000
kernel 从0x30000------ 0x180000
rootfs 采用squashfs文件格式，支持压缩，我把比较大的文件，以及调试中不会变的放到这里了，例如QT的库等等，然后采用XZ方式压缩，效果还不错。16Mflash有点吃紧，但基本源码工程，也能装下了。
APP,名字叫APP，其实里面也有etc目录，这么做的目的主要为了，支持可读写问题。APP采用Jffs2文件系统，由于可能中途修改程序，替换某些文件或者修改某些文件。所以这里放的基本是随时要变化的程序以及库。
Config，固定512K，jffs2就是用来放配置的。如果升级时这部分不升级，配置就在。
logo，64K，纯二进制，没有文件系统，开机画面
/////////////cfg例子中，除了logo没升级，都配置升级了，而且由于config文件很小，APP文件也很小，需要指定结束位置外，其他的模块是根据实际文件大小，紧接着排列的，代码中以及考虑了flash的block问题。
/////////////
/////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////
以前，通过USB在uboot升级，采用的是每种数据包一个文件的方式，海思的例子也是这么写的，如果中途需要调整，要改uboot源码中的相应地址，或者修改env中几个升级包的地址。
前期看了相关文章，可以把几个文件打包在一块升级，前几天也和论坛上的朋友交流了一下，思路是比较清晰的，只是感觉自己还没到需要做的时候，这几天自己弄产品，如果还按照以前做法，升级各个模块，的确感觉有些繁琐，哎，还是合并到一起升级吧。
/////于是干脆自己写一个相关的打包工具吧。附件中的源码是一个打包工具，配置文件格式下面有。uboot里面实现方法，见2层。
写完之后，感觉方法还比较简单：
1、通过ini文件格式，自己写一个cfg配置文件。mkRecoveryBin工具读取相关配置。之所以采用这种ini方法，是因为容易随时修改，每个芯片，采用的DDR容量以及Flash容量可能有些差异，肯定要支持自定义才行，为此这个cfg文件肯定经常变。但基本思路是，配置变，工具尽量不变。当然因为有源码，一旦发现某些功能实现不了，到时再来改源码。
2、打包工具mkRecoveryBin按照配置文件cfg的内容，分别读取uboot,kernel,rootfs,app,config等几个模块。按照写入flash的位置要求，进行组合，最终产生一个.bin文件。
3、Uboot端，前期代码不变，还是支持各个模块升级，只是在子模块升级前，先查看有没有recovery.bin全局升级文件，如果有，先尝试读取配置头（程序中，这个大小是832字节，随着结构变化可能有改变），然后简单检查环境和Uboot当前环境是否一致，例如芯片型号，flash，ddr等，也就是
判断出，能否在当前板子上升级。
4、如果可以升级，就把整个文件recovery.bin读取到内存中，先升级uboot，然后跳过flash上的ENV部分，擦除其他部分，读取内存中相应部分，然后写入flash。
5、按照配置头结构中保留的CONFIG_BOOTARGS以及CONFIG_BOOTCOMMAND，写入环境变量，重新计算CRC，保存ENV到flash,升级结束。
////我的做法目前还不够智能化：每种升级包，需要仔细检查CFG配置是否合适。CONFIG_BOOTARGS以及CONFIG_BOOTCOMMAND两个命令需要和实际配合。目前没有实现自动适配，你可以加强一下这方面，我这里由于总体方法还在调整，所以暂没有自动生成
////好处还是显而易见的：支持从kernel到APP，各种包的组合，以及哪个包采用什么文件系统，其实都没关系。我这里文件系统使用了2个包，主要的rootfs采用squashfs，主要是压缩率高，这部分是按照文件大小来定的flash上的空间占用。为了使系统正常，APP包里面还包括了etc等内容，采用了jffs2格式，
空间会按照配置的结尾，也就是实际空间大于APP程序本身，通过mount，将系统需要读写的目录，都放倒了APP包当中。
///配置文件cfg:
[setting]
SPI_NAND_BLOCK_SIZE=64 //实际是64K 内部做计算吧
OUT_FILE_NAME=recovery3520D_8M.bin //输出文件名称，可以自定义
MEM_SIZE=256 //板子内存大小，作为能否升级的一个依据
FLASH_SIZE=8 //不同的flash不同，也可以作为升级依据
UBOOT_START_POS=0
UBOOT_END_POS=20000 //16进制地址
UBOOT_ENV_SIZE=10000 //16进制地址
RECOVERY_START_POS=30000 //16进制地址
RECOVERY_END_POS=7f0000 //16进制地址
CONFIG_BOOTARGS=mem=64M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1344K(kernel),3008K(rootfs),3072K(APP),512K(Config),64K(LOGO)
CONFIG_BOOTCOMMAND=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x817F0000 0x7F0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x84fe0000 2048 0 0 1024 768;bootm 0x81000000
MAX_LOAD_SUB_FILE_NUM=5
//////////其实就是Uboot
SUB_FILE_0=mini-boot_256M_8M.bin
//////////kernel
SUB_FILE_1=3520D_uImage_mini.bin
////////rootfs
SUB_FILE_2=squashfs_NGS-root_256_MINI.img
/////////APP
SUB_FILE_3=APP_3520D_MINI.img
SUB_FILE_END_3=770000
/////////config
SUB_FILE_4=Config.img
SUB_FILE_END_4=7f0000
////////对于不可读写的部分，按照blocksize紧密排列即可，对于可读写有固定大小的分区，不是按照文件，而是按照最大值
////////主要是可读写的APP以及config部分 logo部分
IS_PART_MAX_SIZE_3=1
////////////////////////////////////////////////////////////////////////////////////////
//////////2016_7_27 通过读取另外一个bootarg方式，自动产生env部分，并且计算crc，不写入或者写入开始的头，这样可以产生2种类型的bin包，一种用来升级，还有一种用来直接生产使用。
//实现命令：
sudo -S ./mkRecoveryBin recovery3520D_QT_OUT.cfg
//////程序内部会按照recovery3520D_QT_OUT.cfg里面的配置要求，是否去读取bootEnv3520D_256_16M.Cfg，以便生成符合要求的ＥＮＶ环境变量，并且产生ＣＲＣ，替换ＥＮＶ板块，开头的4个字节。
///经过实际使用测试，通过修改recovery3520D_QT_OUT.cfg里面，使FOR_PRODUCTION=1，产生的recovery.bin其实就是整个flash的镜像包，直接一对一全部刷入，系统运行正常，加载uboot时，也没有提示env错误，说明crc部分也正常。
///////////////////////////////////////////////
///////bootEnv3520D_256_16M.Cfg 内容如下：
[code]bootdelay=1
baudrate=115200
ethaddr=10:20:33:34:45:66
bootfile="uImage"
filesize=458
fileaddr=82F70000
netmask=255.255.255.0
ipaddr=192.168.2.10
gatewayip=192.168.2.1
serverip=192.168.2.245
IVHI_VERSION=1469476386
bootcmd=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x82FF0000 0xFF0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x86fe0000 2048 0 0 1024 768;bootm 0x81000000
bootargs=mem=96M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1280K(kernel),11840K(rootfs),2496K(APP),512K(Config),64K(LOGO)
jpeg_addr=0x82FF0000
jpeg_size=0x10000
vobuf=0x86fe0000
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 26 2016 - 03:52:41)[/code]
/////////////////////////////////////////
//////////////总配置：recovery3520D_QT_OUT.cfg，内容如下：
[code][setting]
///////////////////生产使用，没有头，会处理ENV内容，直接从0刷写即可
FOR_PRODUCTION=1
OS_MEM_SIZE=96
ROOTFS_MTD_NUM=3
ROOTFS_TYPE=squashfs
SPI_NAND_BLOCK_SIZE=64
OUT_FILE_NAME=recovery3520D_256_16M_.bin
bootEnv_input=bootEnv3520D_256_16M.Cfg
jpeg_addr=82FF0000
jpeg_size=10000
vobuf=86fe0000
MEM_SIZE=256
FLASH_SIZE=16
UBOOT_START_POS=0
UBOOT_END_POS=20000
UBOOT_ENV_SIZE=10000
RECOVERY_START_POS=30000
RECOVERY_END_POS=1000000
CONFIG_BOOTARGS=mem=96M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1280K(kernel),11840K(rootfs),2496K(APP),512K(Config),64K(LOGO)
CONFIG_BOOTCOMMAND=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x82FF0000 0xFF0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x86fe0000 2048 0 0 1024 768;bootm 0x81000000
updateCMD=setenv jpeg_addr 0x82FF0000;setenv jpeg_size 0x10000;setenv vobuf 0x86fe0000;
MAX_LOAD_SUB_FILE_NUM=6
//////////其实就是Uboot
SUB_FILE_0=mini-boot_256M_16M.bin
//////////kernel
SUB_FILE_1=3520D_uImage_mini.bin
////////rootfs
SUB_FILE_2=squashfs_NGS-root_256_QT_OUT.img
/////////APP
SUB_FILE_3=APP_3520D_QT_OUT.img
SUB_FILE_END_3=f70000
/////////config
SUB_FILE_4=Config.img
SUB_FILE_END_4=ff0000
/////////logo
SUB_FILE_5=TV_BK_1024.jpg
SUB_FILE_END_5=1000000
////////对于不可读写的部分，按照blocksize紧密排列即可，对于可读写有固定大小的分区，不是按照文件，而是按照最大值
////////主要是可读写的APP以及config部分 logo部分[/code]
/////////按照自己的理解写的，还在实际使用优化中.......
/////////目前使用很不错，发上来，大家参考一下。已经利用这个工具，成功自动升级了8M flash的3520D以及32M flash的3520D
我先描述一下我自己的flash上几个部分情况：
uboot 一般从0x0--------0x20000
ENV 从0x20000 -------0x30000
kernel 从0x30000------ 0x180000
rootfs 采用squashfs文件格式，支持压缩，我把比较大的文件，以及调试中不会变的放到这里了，例如QT的库等等，然后采用XZ方式压缩，效果还不错。16Mflash有点吃紧，但基本源码工程，也能装下了。
APP,名字叫APP，其实里面也有etc目录，这么做的目的主要为了，支持可读写问题。APP采用Jffs2文件系统，由于可能中途修改程序，替换某些文件或者修改某些文件。所以这里放的基本是随时要变化的程序以及库。
Config，固定512K，jffs2就是用来放配置的。如果升级时这部分不升级，配置就在。
logo，64K，纯二进制，没有文件系统，开机画面
/////////////cfg例子中，除了logo没升级，都配置升级了，而且由于config文件很小，APP文件也很小，需要指定结束位置外，其他的模块是根据实际文件大小，紧接着排列的，代码中以及考虑了flash的block问题。
/////////////
/////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////
以前，通过USB在uboot升级，采用的是每种数据包一个文件的方式，海思的例子也是这么写的，如果中途需要调整，要改uboot源码中的相应地址，或者修改env中几个升级包的地址。
前期看了相关文章，可以把几个文件打包在一块升级，前几天也和论坛上的朋友交流了一下，思路是比较清晰的，只是感觉自己还没到需要做的时候，这几天自己弄产品，如果还按照以前做法，升级各个模块，的确感觉有些繁琐，哎，还是合并到一起升级吧。
/////于是干脆自己写一个相关的打包工具吧。附件中的源码是一个打包工具，配置文件格式下面有。uboot里面实现方法，见2层。
写完之后，感觉方法还比较简单：
1、通过ini文件格式，自己写一个cfg配置文件。mkRecoveryBin工具读取相关配置。之所以采用这种ini方法，是因为容易随时修改，每个芯片，采用的DDR容量以及Flash容量可能有些差异，肯定要支持自定义才行，为此这个cfg文件肯定经常变。但基本思路是，配置变，工具尽量不变。当然因为有源码，一旦发现某些功能实现不了，到时再来改源码。
2、打包工具mkRecoveryBin按照配置文件cfg的内容，分别读取uboot,kernel,rootfs,app,config等几个模块。按照写入flash的位置要求，进行组合，最终产生一个.bin文件。
3、Uboot端，前期代码不变，还是支持各个模块升级，只是在子模块升级前，先查看有没有recovery.bin全局升级文件，如果有，先尝试读取配置头（程序中，这个大小是832字节，随着结构变化可能有改变），然后简单检查环境和Uboot当前环境是否一致，例如芯片型号，flash，ddr等，也就是
判断出，能否在当前板子上升级。
4、如果可以升级，就把整个文件recovery.bin读取到内存中，先升级uboot，然后跳过flash上的ENV部分，擦除其他部分，读取内存中相应部分，然后写入flash。
5、按照配置头结构中保留的CONFIG_BOOTARGS以及CONFIG_BOOTCOMMAND，写入环境变量，重新计算CRC，保存ENV到flash,升级结束。
////我的做法目前还不够智能化：每种升级包，需要仔细检查CFG配置是否合适。CONFIG_BOOTARGS以及CONFIG_BOOTCOMMAND两个命令需要和实际配合。目前没有实现自动适配，你可以加强一下这方面，我这里由于总体方法还在调整，所以暂没有自动生成
////好处还是显而易见的：支持从kernel到APP，各种包的组合，以及哪个包采用什么文件系统，其实都没关系。我这里文件系统使用了2个包，主要的rootfs采用squashfs，主要是压缩率高，这部分是按照文件大小来定的flash上的空间占用。为了使系统正常，APP包里面还包括了etc等内容，采用了jffs2格式，
空间会按照配置的结尾，也就是实际空间大于APP程序本身，通过mount，将系统需要读写的目录，都放倒了APP包当中。
///配置文件cfg:
[setting]
SPI_NAND_BLOCK_SIZE=64 //实际是64K 内部做计算吧
OUT_FILE_NAME=recovery3520D_8M.bin //输出文件名称，可以自定义
MEM_SIZE=256 //板子内存大小，作为能否升级的一个依据
FLASH_SIZE=8 //不同的flash不同，也可以作为升级依据
UBOOT_START_POS=0
UBOOT_END_POS=20000 //16进制地址
UBOOT_ENV_SIZE=10000 //16进制地址
RECOVERY_START_POS=30000 //16进制地址
RECOVERY_END_POS=7f0000 //16进制地址
CONFIG_BOOTARGS=mem=64M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1344K(kernel),3008K(rootfs),3072K(APP),512K(Config),64K(LOGO)
CONFIG_BOOTCOMMAND=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x817F0000 0x7F0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x84fe0000 2048 0 0 1024 768;bootm 0x81000000
MAX_LOAD_SUB_FILE_NUM=5
//////////其实就是Uboot
SUB_FILE_0=mini-boot_256M_8M.bin
//////////kernel
SUB_FILE_1=3520D_uImage_mini.bin
////////rootfs
SUB_FILE_2=squashfs_NGS-root_256_MINI.img
/////////APP
SUB_FILE_3=APP_3520D_MINI.img
SUB_FILE_END_3=770000
/////////config
SUB_FILE_4=Config.img
SUB_FILE_END_4=7f0000
////////对于不可读写的部分，按照blocksize紧密排列即可，对于可读写有固定大小的分区，不是按照文件，而是按照最大值
////////主要是可读写的APP以及config部分 logo部分
IS_PART_MAX_SIZE_3=1
////////////////////////////////////////////////////////////////////////////////////////
//////////2016_7_27 通过读取另外一个bootarg方式，自动产生env部分，并且计算crc，不写入或者写入开始的头，这样可以产生2种类型的bin包，一种用来升级，还有一种用来直接生产使用。
//实现命令：
sudo -S ./mkRecoveryBin recovery3520D_QT_OUT.cfg
//////程序内部会按照recovery3520D_QT_OUT.cfg里面的配置要求，是否去读取bootEnv3520D_256_16M.Cfg，以便生成符合要求的ＥＮＶ环境变量，并且产生ＣＲＣ，替换ＥＮＶ板块，开头的4个字节。
///经过实际使用测试，通过修改recovery3520D_QT_OUT.cfg里面，使FOR_PRODUCTION=1，产生的recovery.bin其实就是整个flash的镜像包，直接一对一全部刷入，系统运行正常，加载uboot时，也没有提示env错误，说明crc部分也正常。
///////////////////////////////////////////////
///////bootEnv3520D_256_16M.Cfg 内容如下：
[code]bootdelay=1
baudrate=115200
ethaddr=10:20:33:34:45:66
bootfile="uImage"
filesize=458
fileaddr=82F70000
netmask=255.255.255.0
ipaddr=192.168.2.10
gatewayip=192.168.2.1
serverip=192.168.2.245
IVHI_VERSION=1469476386
bootcmd=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x82FF0000 0xFF0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x86fe0000 2048 0 0 1024 768;bootm 0x81000000
bootargs=mem=96M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1280K(kernel),11840K(rootfs),2496K(APP),512K(Config),64K(LOGO)
jpeg_addr=0x82FF0000
jpeg_size=0x10000
vobuf=0x86fe0000
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Jul 26 2016 - 03:52:41)[/code]
/////////////////////////////////////////
//////////////总配置：recovery3520D_QT_OUT.cfg，内容如下：
[code][setting]
///////////////////生产使用，没有头，会处理ENV内容，直接从0刷写即可
FOR_PRODUCTION=1
OS_MEM_SIZE=96
ROOTFS_MTD_NUM=3
ROOTFS_TYPE=squashfs
SPI_NAND_BLOCK_SIZE=64
OUT_FILE_NAME=recovery3520D_256_16M_.bin
bootEnv_input=bootEnv3520D_256_16M.Cfg
jpeg_addr=82FF0000
jpeg_size=10000
vobuf=86fe0000
MEM_SIZE=256
FLASH_SIZE=16
UBOOT_START_POS=0
UBOOT_END_POS=20000
UBOOT_ENV_SIZE=10000
RECOVERY_START_POS=30000
RECOVERY_END_POS=1000000
CONFIG_BOOTARGS=mem=96M lpj=5996544 console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs mtdparts=hi_sfc:128K(boot),64K(UB_ENV),1280K(kernel),11840K(rootfs),2496K(APP),512K(Config),64K(LOGO)
CONFIG_BOOTCOMMAND=sf probe 0;sf read 0x81000000 0x30000 0x180000;sf read 0x82FF0000 0xFF0000 0x10000;decjpg;setvobg 0 0x0;startvo 0 36 14;startgx 0 0x86fe0000 2048 0 0 1024 768;bootm 0x81000000
updateCMD=setenv jpeg_addr 0x82FF0000;setenv jpeg_size 0x10000;setenv vobuf 0x86fe0000;
MAX_LOAD_SUB_FILE_NUM=6
//////////其实就是Uboot
SUB_FILE_0=mini-boot_256M_16M.bin
//////////kernel
SUB_FILE_1=3520D_uImage_mini.bin
////////rootfs
SUB_FILE_2=squashfs_NGS-root_256_QT_OUT.img
/////////APP
SUB_FILE_3=APP_3520D_QT_OUT.img
SUB_FILE_END_3=f70000
/////////config
SUB_FILE_4=Config.img
SUB_FILE_END_4=ff0000
/////////logo
SUB_FILE_5=TV_BK_1024.jpg
SUB_FILE_END_5=1000000
////////对于不可读写的部分，按照blocksize紧密排列即可，对于可读写有固定大小的分区，不是按照文件，而是按照最大值
////////主要是可读写的APP以及config部分 logo部分[/code]
展开》
折叠》
微信扫码分享
QQ好友
暂无数据
我上传的资料
