6852
- 收藏
- 点赞
- 分享
- 举报
flash USB升级包制作工具mkRecoveryBin,海思方案应该都能用
本帖最后由 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,以便生成符合要求的ENV环境变量,并且产生CRC,替换ENV板块,开头的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,以便生成符合要求的ENV环境变量,并且产生CRC,替换ENV板块,开头的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]
文件: mkRecoveryBin.tar.gz
下载
文件: mkRecoveryBin.tar.gz
下载
文件: bootEnv3520D_256_16M.Cfg.tar.gz
下载
文件: recovery3520D_QT_OUT.cfg.tar.gz
下载
我来回答
回答20个
时间排序
认可量排序
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
认可0
或将文件直接拖到这里
悬赏:
E币
网盘
* 网盘链接:
* 提取码:
悬赏:
E币
Markdown 语法
- 加粗**内容**
- 斜体*内容*
- 删除线~~内容~~
- 引用> 引用内容
- 代码`代码`
- 代码块```编程语言↵代码```
- 链接[链接标题](url)
- 无序列表- 内容
- 有序列表1. 内容
- 缩进内容
- 图片![alt](url)
相关问答
-
2020-11-02 11:09:38
-
2023-03-28 15:58:34
-
2008-07-20 00:24:03
-
2019-01-21 10:49:08
-
2020-11-12 16:05:52
-
2024-11-18 22:03:12
-
2019-01-03 15:32:36
-
2019-10-14 10:15:37
-
2023-06-17 08:57:57
-
2017-03-03 10:43:17
-
2018-06-21 10:56:00
-
2022-06-14 16:40:08
-
2016-06-22 09:53:21
-
2020-09-12 14:42:46
-
12020-08-05 20:42:37
-
2019-09-20 11:06:51
-
2012-12-05 14:38:22
-
2021-12-10 14:38:55
-
2013-07-10 11:03:45
无更多相似问答 去提问
点击登录
-- 积分
-- E币
提问
—
收益
—
被采纳
—
我要提问
切换马甲
上一页
下一页
悬赏问答
-
5Hi3516CV610 如何使用SD卡升级固件
-
5cat /dev/logmpp 报错 <3>[ vi] [func]:vi_send_frame_node [line]:99 [info]:vi pic queue is full!
-
50如何获取vpss chn的图像修改后发送至vo
-
5FPGA通过Bt1120传YUV422数据过来,vi接收不到数据——3516dv500
-
50SS928 运行PQtools 拼接 推到设备里有一半画面会异常
-
53536AV100的sample_vdec输出到CVBS显示
-
10海思板子mpp怎么在vi阶段改变视频数据尺寸
-
10HI3559AV100 多摄像头同步模式
-
9海思ss928单路摄像头vio中加入opencv处理并显示
-
10EB-RV1126-BC-191板子运行自己编码的程序
举报反馈
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明
提醒
你的问题还没有最佳答案,是否结题,结题后将扣除20%的悬赏金
取消
确认
提醒
你的问题还没有最佳答案,是否结题,结题后将根据回答情况扣除相应悬赏金(1回答=1E币)
取消
确认