CN102622280B - 一种基于双文件系统的软件版本升级的控制方法及装置 - Google Patents
一种基于双文件系统的软件版本升级的控制方法及装置 Download PDFInfo
- Publication number
- CN102622280B CN102622280B CN201110001467.4A CN201110001467A CN102622280B CN 102622280 B CN102622280 B CN 102622280B CN 201110001467 A CN201110001467 A CN 201110001467A CN 102622280 B CN102622280 B CN 102622280B
- Authority
- CN
- China
- Prior art keywords
- subregion
- aku
- file
- upgrading
- attribute field
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供基于双文件系统的嵌入式软件版本升级的控制方法,包括步骤:II.在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态;c.将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统;d.判断所写入升级包的正确性;e.若所写入升级包是正确的,则在所述升级标志字段中写入升级成功标志。还提供了相应的控制装置。本发明在保证了升级文件与设备匹配、升级文件正确、并且写入正确的前提供下,仍出现了版本不能使用的情况还可以进行回滚到上一版本,让用户重新进行升级。
Description
技术领域
本发明涉及软件版本升级系统,尤其是嵌入式软件版本升级系统,具体地,涉及在软件升级意外失败时,提供恢复原来正常版本的基于双文件系统的软件版本升级的控制方法及装置。
背景技术
目前大多数嵌入式设备都支持版本在线升级,实现设备功能的更新。传统的升级方式采用覆盖原有版本的模式,若升级失败,该设备不仅无法获得设备功能的更新,同时也失去了原有的版本功能。
综合分析升级出错的原因主要有以下几点:
1、升级文件错误。
a) 升级文件不是被指定设备的升级文件。
b) 升级文件网络传输错误,文件不完整。
c) 升级文件本身错误。
2、升级过程中出现错误。
a) 将文件写入到Flash时系统复位(断电或异常)。
b) 文件写入到Flash后,文件不完整或错误。
3、升级文件与硬件设备版本不匹配。
a) 同一设备有不同的硬件版本,当版本不兼容时。
针对升级出错的原因,需要在升级过程中保证:
(1) 升级文件与设备匹配(由发布保证);
(2) 传到设备本地文件系统中的升级文件的正确性;
(3) 升级文件写入Flash后的数据正确性;
(4) 升级错误可以回滚到上一版本。
这些技术问题都需要予以完善地解决。
发明内容
针对现有技术中的缺陷,本发明的目的是提供一种基于双文件系统的嵌入式软件版本升级的控制方法以及相应的控制装置。
根据本发明的一个方面,提供基于双文件系统的嵌入式软件版本升级的控制方法,包括步骤:II. 在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态;c. 将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统;d. 判断所写入升级包的正确性;e. 若所写入升级包是正确的,则在所述升级标志字段中写入升级成功标志。
根据本发明的另一个方面,还提供基于双文件系统的嵌入式软件版本升级的控制装置,包括装置:第一设置装置,其用于在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态;第一写入装置,其用于将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统;第一判断装置,其用于判断所写入升级包的正确性;第二写入装置,其用于当所写入升级包是正确的时,在所述升级标志字段中写入升级成功标志。
本发明主要考虑在操作系统下的在线升级及版本回滚。用户通过网络将升级文件传到设备本地文件系统中,然后通过升级命令或调用升级接口将升级文件更新到内存(Flash)。升级之前对升级文件进行合法性验证,升级之后对升级的内容(只对UBOOT进行正确性验证)进行正确性验证,复位系统即应用新的操作系统,若升级的操作系统存在问题,则恢复到上一版本。
即使在保证了升级文件与设备匹配、升级文件正确、并且写入正确的前提供下,仍出现了版本不能使用的情况(例如,新升级的应用程序存在问题),本发明还可以进行回滚到上一版本,让用户重新进行升级。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
图1示出根据本发明的第一实施例的,基于双文件系统的嵌入式软件版本升级的控制方法的流程图;
图2示出根据本发明的第二实施例的,基于双文件系统的嵌入式软件版本升级的控制方法的流程图;
图3示出根据本发明的第三实施例的,基于双文件系统的嵌入式软件版本升级的控制装置的结构图;
图4示出根据本发明的第四实施例的,基于双文件系统的嵌入式软件版本升级的控制装置的结构图;
图5示出根据本发明的一个具体实施方式的,基于双文件系统的嵌入式软件版本升级的升级包的存储布局图;
图6示出根据本发明的另一个具体实施方式的,基于双文件系统的嵌入式软件版本升级的分区设置的原理示意图;以及
图7示出根据本发明的又一个具体实施方式的,基于双文件系统的嵌入式软件版本升级的分区表的结构示意图。
具体实施方式
图1示出根据本发明的第一实施例的,基于双文件系统的嵌入式软件版本升级的控制方法的流程图。具体地,在本实施例中,首先执行步骤S2101,根据所述备份支持字段判断所述非易失性内存是否支持分区备份。更为具体地,在非易失性内存(也可称为FLASH)的分区表头中增加“backup_flag”字段,所述“backup_flag”字段作为所述备份支持字段用于标识该系统是否支持分区备份,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“backup_flag”字段:
/* backup_flags */
#define MTD_BACKUP_DISABLED 0x00
#define MTD_BACKUP_ENABLED 0x01
若所述“backup_flag”字段中的值为0x00,则判断所述非易失性内存不支持分区备份;若所述“backup_flag”字段中的值为0x01,则判断所述非易失性内存支持分区备份。进一步地,若所述步骤S2101的判断结果是肯定的,即所述非易失性内存支持分区备份,则接下来进行步骤S2102继续执行;若所述步骤S2101的判断是否定的,即所述非易失性内存不支持分区备份,则结束本流程。
接下来执行步骤S2102,在所述非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在所述非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态。更为具体地,在非易失性内存的分区表头中增加“update_flag”字段,所述“update_flag”字段作为所述升级标志字段用于指示升级状态,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag“字段:
进一步地,为避免在保证了升级文件的正常之后,仍然出现了升级失败的问题,可以将所述非易失性内存中的分区设计成如图6所示。在uboot中可根据相关信息决定启动所述第一分区或第二分区。其中,分区中各个数据区的描述说明如下:
①PARTITION_TABLE分区主要包括分区表信息、启动控制信息、升级控制信息。
②IOS分区包括两部分的内容:内核镜像(uImage)和根文件系统镜像(Rootfs),它的大小设为5MB,有所述第一分区和第二分区两个分区。
③APP分区主要是上层业务程序及相关组件,大小高为15MB,有所述第一分区和第二分区两个分区。所述IOS和APP分区都采用主备方式,即同时存在两个系统,但同一时间只可运行一个系统,在此系统下进行升级时,本系统所在的分区即为所述第一分区,进行升级将文件写入到所述第二分区,复位系统后试图运行所述第二分区的系统,若系统运行正常,则完成升级;若启动失败,则自动复位系统或用户远程复位系统后,回滚到前一版本。优选地,若在升级操作系统之后的启动过程,只要由于异常而没成功调到接口api_sys_running_success(),则都会恢复成原来版本。
④USER0和USER1分区留给上层存放裸数据,它们之间本来就是互为备份的。
⑤JFFS2分区即用户分区,主要保存经常修改的内容,如配置文件,用户保存的配置、图片等。
接下来执行步骤S2103,将所述升级包写入非易失性内存的用户分区。具体地,所述升级包可以包括BOOT文件、OS文件、APP文件以及FPGA文件。例如,所述升级包的结构优选地如图5所示,其中,为保证升级包的合法性、正确性,所述升级包需要加入一些冗余信息。升级包主要包括:内核镜像(uImage)、根文件系统镜像文件(Rootfs.image)、上层业务程序及相关组件(app.image)、启动控制信息(uboot)。其中uImage和Rootfs.image先打成一个OS包,然后与app.image、uboot制作成一个系统升级包。在系统升级包制作时加入版本冗余信息,校验信息等,以便在升级时对文件的合法性、正确性进行检查。
接下来执行步骤S2104,判断所述升级包的合法性。具体地,将文件拆分出OS升级包和APP镜像升级包,然后对分别两个升级包进行合法性校验。优选地,可以判断所述升级包中的各个组件(例如BOOT文件、APP文件以及FPGA文件)、整个升级包、以及OS文件与所述升级包的文件头中的信息是否一致,若一致,则判断所述升级包具有合法性;否则,则判断所述升级包不具有合法性。进一步地,若所述步骤S2104的判断结果是肯定的,即所述升级包是合法的,则接下来进入步骤S2105继续执行;若所述步骤S2104的判断结果是否定的,即所述升级包不是合法的,则接下来进入步骤S2108继续执行。
其中,通过执行所述步骤S2105,将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统,其中,所述第一版本系统为原系统,所述第二版本系统为将要升级到的系统。
其中,通过执行步骤S2108,若所写入升级包是错误的,则在所述升级标志字段中写入升级失败标志。具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0004”以实现向所述升级标志字段中写入升级失败信息。
通过所述步骤S2105将所述升级包写入所述第二分区中后,接下来执行步骤S2106,判断所写入升级包的正确性。优选地,通过CRC 校验算法重新计算写入所述升级包的CRC值,若该值与事先写入的CRC字段一致,则确定所述写入升级包是正确的。具体地,在生成升级包的过程中会产生一个CRC校验字段,并将此字段保存在升级包的特定位置;在写入之后,会通过CRC校验算法重新计算写入文件的CRC值,如果该值与于事先写入的CRC字段一致则说明此升级包是正确无误的,反之则反。
进一步地,若所述步骤S2106的判断结果是肯定的,即所写入升级包是正确的,则接下来进入步骤S2107继续执行;若所述步骤S2106的判断结果是否定的,即所写入升级包不是正确的,则接下来进入步骤S2108。
其中,通过所述步骤S2107,在所述升级标志字段中写入升级成功标志,具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0001”以实现向所述升级标志字段中写入升级成功信息。通过所述步骤S2107或者所述步骤S2108对所述升级标志字段写入后,接下来进入步骤S2109继续执行,将系统复位。然后进入步骤S2110,BOOT引导时检查所述升级标志字段。具体地,若所述通过所述步骤S2110检查到所述升级标志字段内的内容为升级成功标志,则接下来进入步骤S2112继续执行;若所述通过所述步骤S2110检查到所述升级标志字段内的内容为升级失败标志,则接下来进入步骤S2113继续执行;若所述通过所述步骤S2110检查到所述升级标志字段内的内容为版本转换标识,则接下来进入步骤S2114继续执行。
其中,通过执行所述步骤S2112,在所述加载标志字段中写入第二分区标识信息,并在所述升级标志字段中写入版本转换信息,具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0002”以实现向所述升级标志字段中写入版本转换信息。进一步具体地,在非易失性内存的分区表头中增加所述“load_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“load_flag”字段:
/* Load_flags */
#define MTD_LOAD_FIRST_SYS 0x00 /* Load First system */
#define MTD_LOAD_SECOND_SYS 0x01 /* Load Second system */
更为具体地,将所述非易失性内存上的两个分区分为主分区和从分区,设定“Load_flags”字段内的值“0x00”用于指示该主分区,值“0x01”用于指示该从分区。若所述主分区上存储有所述第一版本系统,所述从分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x01”以实现在所述加载标志字段中写入第二分区标识信息。若所述从分区上存储有所述第一版本系统,所述主分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x00”以实现在所述加载标志字段中写入第二分区标识信息。
其中,通过执行所述步骤S2113,在所述加载标志字段中写入第一分区标识信息。具体地,在非易失性内存的分区表头中增加所述“load_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“load_flag”字段:
/* Load_flags */
#define MTD_LOAD_FIRST_SYS 0x00 /* Load First system */
#define MTD_LOAD_SECOND_SYS 0x01 /* Load Second system */
更为具体地,将所述非易失性内存上的两个分区分为主分区和从分区,设定“Load_flags”字段内的值“0x00”用于指示该主分区,值“0x01”用于指示该从分区。若所述主分区上存储有所述第一版本系统,所述从分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x00”以实现在所述加载标志字段中写入第二分区标识信息。若所述从分区上存储有所述第一版本系统,所述主分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x01”以实现在所述加载标志字段中写入第二分区标识信息。
其中,通过执行所述步骤S2114,在所述加载标志字段中写入第一分区标识信息,在所述升级标志字段中写入升级失败信息。具体地,本领域技术人员可以通过参照所述步骤S2113实现在所述加载标志字段中写入第一分区标识信息,在此不予赘述。进一步地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0004”以实现向所述升级标志字段中写入升级失败信息。
通过所述步骤S2112、步骤S2113或步骤S2114对所述加载标志字段和/或所述升级标志字段进行写入操作后,接下来进入步骤S2115继续执行,判断BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是否成功。进一步地,若所述步骤S2115的判断结果是肯定的,即BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是成功的,则接下来进入步骤S2116继续执行;若所述步骤S2115的判断结果是否定的,即BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件没有成功,则接下来进入所述步骤S2109继续执行。
其中,通过执行所述步骤S2116,判断调用接口是否成功。具体地,系统再次启动的时候,判断非易失性内存上分区表结构中update_flag的数值(如上定义),如果为0x0004则为失败。
进一步地,若所述步骤S2116的判断结果是肯定的,即调用接口成功,则接下来进入步骤S2117继续执行;若所述步骤S2116的判断结果是否定的,即调用接口没有成功,则接下来进入步骤S2109继续执行。
其中,通过执行步骤S2117,调用接口在所述升级标志字段中写入常态信息。具体地,通过系统提供的API,该API的主要功能就是将update_flag置为某一个特定值,如果整套升级成功,系统复位,会尝试新的升级软件进行启动,如果一切都是正确的,则所运行的新的软件程序会调用该API来标记当前的新的软件系统是可以正确运行的。
优选地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0000”以实现向所述升级标志字段中写入常态信息。
在本实施例的一个变化例中,所述步骤S2101可以被省略。在本实施例的另一个变化例中,所述步骤S2103以及步骤S2104可以被省略,即,所述步骤S2102执行后接下来进入所述步骤S2105继续执行,此时,所述控制方法不对所述升级包的合法性进行判断。在本实施例的又一个变化例中,所述步骤S2106以及步骤S2108可以被省略,即,所述步骤S2105执行后接下来进入所述步骤S2107继续执行,此时,所述控制方法不对所述升级包的正确性进行判断。
图2示出根据本发明的第二实施例的,基于双文件系统的嵌入式软件版本升级的控制方法的流程图。本领域技术人员可以将本实施例中的步骤S2201、步骤S2202、步骤S2203、步骤S2204以及步骤S2205中的任一个或任多个步骤理解为图1所示实施例中的所述步骤S2104的一个具体实施方式;将本实施例中的步骤S2206、步骤S2207、步骤S2208以及步骤S2209中的任一个或任多个步骤理解为图1所示实施例中的所述步骤S2105的一个具体实施方式;将本实施例中的步骤S2210、步骤S2211以及步骤S2212理解为图1所示实施例中的所述步骤S2105的一个具体实施方式。
具体地,在本实施例中,首先执行步骤S2201,判断所述升级包的合法性,具体地,对整个升级包的合法性进行校验。进一步地,若所述步骤S2201的判断结果是肯定的,即所述升级包具有合法性,则接下来进入步骤S2202继续执行;若所述步骤S2201的判断结果是否定的,即所述升级包不具有合法性,则结束本流程。
其中,通过执行所述步骤S2202,判断所述升级包中的BOOT文件的合法性。进一步地,若所述步骤S2202的判断结果是肯定的,即所述升级包中的BOOT文件具有合法性,则接下来进入步骤S2203继续执行;若所述步骤S2202的判断结果是否定的,即所述升级包中的BOOT文件不具有合法性,则结束本流程。
其中,通过执行所述步骤S2203,判断所述升级包中的OS文件的合法性。进一步地,若所述步骤S2203的判断结果是肯定的,即升级包中的OS文件具有合法性,则接下来进入步骤S2204继续执行;若所述步骤S2203的判断结果是否定的,即升级包中的OS文件不具有合法性,则结束本流程。
其中,通过执行所述步骤S2204,判断所述升级包中的APP文件的合法性。进一步地,若所述步骤S2204的判断结果是肯定的,即所述升级包中的APP文件具有合法性,则接下来进入步骤S2205继续执行;若所述步骤S2204的判断结果是否定的,即所述升级包中的APP文件不具有合法性,则结束本流程。
其中,通过执行所述步骤S2205,判断所述升级包中的FPGA文件的合法性。进一步地,若所述步骤S2205的判断结果是肯定的,即所述升级包中的FPGA文件具有合法性,则接下来进入步骤S2206继续执行;若所述步骤S2205的判断结果是否定的,即所述升级包中的FPGA文件不具有合法性,则结束本流程。
其中,通过执行所述步骤S2206,将所述升级包中的APP文件写入所述第二分区的APP备份分区。接下来执行步骤S2207,将所述升级包中的OS文件写入所述第二分区的OS备份分区。接下来进入步骤S2208,判断所述升级包中是否包含FPGA文件,进一步地,若所述步骤S2208的判断结果是肯定的,即所述升级包中包含FPGA文件,则接下来进入步骤S2210继续执行;若所述步骤S2208的判断结果是否定的,即所述升级包中不包含FPGA文件,则接下来进入步骤S2209继续执行。
其中,通过执行步骤S2209,将所述升级包中的FPGA文件写入所述第二分区的FPGA备份分区。接下来进入步骤S2210,判断是否需要升级BOOT ,具体地,若所述步骤S2210的判断结果是肯定的,即需要升级BOOT,则接下来进入步骤S2211继续执行;若所述步骤S2210的判断结果是否定的,即不需要升级BOOT,则接下来进入步骤S2106继续执行。
其中,通过执行所述步骤S2211,判断BOOTROM中的BOOT与所述升级包中的BOOT升级文件是否相同,具体地,若所述步骤S2211的判断结果是肯定的,即BOOTROM中的BOOT与所述升级包中的BOOT升级文件相同,则接下来进入步骤S2106继续执行;若所述步骤S2211的判断结果是否定的,即BOOTROM中的BOOT与所述升级包中的BOOT升级文件不相同,则接下来进入步骤S2212继续执行。其中,通过执行所述步骤S2212,将所述升级包中的BOOT升级文件写入BOOTROM。
图3示出根据本发明的第三实施例的,基于双文件系统的嵌入式软件版本升级的控制装置的结构图。具体地,所述控制装置4包括第十一判断装置401、第一设置装置402、第四写入装置403、第二判断装置404、第一写入装置405、第五写入装置406、第一判断装置407、第三写入装置408、第二写入装置409、第一复位装置410、第一检查装置411、第九写入装置412、第十写入装置413、第十二写入装置414、第十判断装置415、第一确定装置416以及第十一写入装置417。
其中,第十一判断装置401用于根据所述备份支持字段判断所述非易失性内存是否支持分区备份,若所述第十一判断装置401的判断结果是肯定的,即所述非易失性内存支持分区备份,则触发所述第一设置装置402。具体地,在非易失性内存(也可称为FLASH)的分区表头中增加“backup_flag”字段,所述“backup_flag”字段作为所述备份支持字段用于标识该系统是否支持分区备份,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“backup_flag”字段:
/* backup_flags */
#define MTD_BACKUP_DISABLED 0x00
#define MTD_BACKUP_ENABLED 0x01
若所述“backup_flag”字段中的值为0x00,则所述第十一判断装置401判断所述非易失性内存不支持分区备份;若所述“backup_flag”字段中的值为0x01,则第十一判断装置401判断所述非易失性内存不支持分区备份。
所述第一设置装置402用于在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态。具体地,在非易失性内存的分区表头中增加“update_flag”字段,所述“update_flag”字段作为所述升级标志字段用于指示升级状态,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
进一步地,为避免在保证了升级文件的正常之后,仍然出现了升级失败的问题,可以将所述非易失性内存中的分区设计成如图6所示。在uboot中可根据相关信息决定启动所述第一分区或第二分区。其中,分区中各个数据区的描述说明如下:
① PARTITION_TABLE分区主要包括分区表信息、启动控制信息、升级控制信息。
② IOS分区包括两部分的内容:内核镜像(uImage)和根文件系统镜像(Rootfs),它的大小设为5MB,有所述第一分区和第二分区两个分区。
③ APP分区主要是上层业务程序及相关组件,大小高为15MB,有所述第一分区和第二分区两个分区。所述IOS和APP分区都采用主备方式,即同时存在两个系统,但同一时间只可运行一个系统,在此系统下进行升级时,本系统所在的分区即为所述第一分区,进行升级将文件写入到所述第二分区,复位系统后试图运行所述第二分区的系统,若系统运行正常,则完成升级;若启动失败,则自动复位系统或用户远程复位系统后,回滚到前一版本。优选地,若在升级操作系统之后的启动过程,只要由于异常而没成功调到接口api_sys_running_success(),则都会恢复成原来版本。
④ USER0和USER1分区留给上层存放裸数据,它们之间本来就是互为备份的。
⑤ JFFS2分区即用户分区,主要保存经常修改的内容,如配置文件,用户保存的配置、图片等。
所述第四写入装置403用于将所述升级包写入非易失性内存的用户分区。具体地,所述升级包可以包括BOOT文件、OS文件、APP文件以及FPGA文件。例如,所述升级包的结构优选地如图5所示,其中,为保证升级包的合法性、正确性,所述升级包需要加入一些冗余信息。升级包主要包括:内核镜像(uImage)、根文件系统镜像文件(Rootfs.image)、上层业务程序及相关组件(app.image)、启动控制信息(uboot)。其中uImage和Rootfs.image先打成一个OS包,然后与app.image、uboot制作成一个系统升级包。在系统升级包制作时加入版本冗余信息,校验信息等,以便在升级时对文件的合法性、正确性进行检查。
所述第二判断装置404用于判断所述升级包的合法性。具体地,将文件拆分出OS升级包和APP镜像升级包,然后对分别两个升级包进行合法性校验。优选地,可以判断所述升级包中的各个组件(例如BOOT文件、APP文件以及FPGA文件)、整个升级包、以及OS文件与所述升级包的文件头中的信息是否一致,若一致,则判断所述升级包具有合法性;否则,则判断所述升级包不具有合法性。
所述第一写入装置405用于将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统,其中,所述第一版本系统为原系统,所述第二版本系统为将要升级到的系统。
所述第五写入装置406用于当所述第二判断装置404的判断结果是否定的时,在所述升级标志字段中写入升级失败标志。具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0004”以实现向所述升级标志字段中写入升级失败信息。
所述第一判断装置407用于判断所写入升级包的正确性。优选地,所述第一判断装置407包括第一处理装置,其用于通过CRC 校验算法重新计算写入所述升级包的CRC值,若该值与事先写入的CRC字段一致,则确定所述写入升级包是正确的。具体地,在生成升级包的过程中会产生一个CRC校验字段,并将此字段保存在升级包的特定位置;在写入之后,所述第一处理装置会通过CRC校验算法重新计算写入文件的CRC值,如果该值与于事先写入的CRC字段一致则说明此升级包是正确无误的,反之则反。
所述第三写入装置408用于当所写入升级包是错误的时,在所述升级标志字段中写入升级失败标志。具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0004”以实现向所述升级标志字段中写入升级失败信息。
所述第二写入装置409用于当所写入升级包是正确的时,在所述升级标志字段中写入升级成功标志。具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0001”以实现向所述升级标志字段中写入升级成功信息。
通过所述第五写入装置406、第三写入装置408或者所述第二写入装置409对所述升级标志字段写入后,接下来通过所述第一复位装置410将系统复位。带系统复位后,触发所述第一检查装置411,其中,所述第一检查装置411用于BOOT引导时检查所述升级标志字段。具体地,若所述通过所述第一检查装置411检查到所述升级标志字段内的内容为升级成功标志,则接下来触发所述第九写入装置412执行;若所述通过所述第一检查装置411检查到所述升级标志字段内的内容为升级失败标志,则接下来触发所述第十写入装置413执行;若所述通过所述第一检查装置411检查到所述升级标志字段内的内容为版本转换标识,则接下来触发所述第十二写入装置414执行。
其中,所述第九写入装置412用于当所述升级标志字段内的信息为所述升级成功信息时,在所述加载标志字段中写入第二分区标识信息,并在所述升级标志字段中写入版本转换信息。具体地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0002”以实现向所述升级标志字段中写入版本转换信息。进一步具体地,在非易失性内存的分区表头中增加所述“load_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“load_flag”字段:
/* Load_flags */
#define MTD_LOAD_FIRST_SYS 0x00 /* Load First system */
#define MTD_LOAD_SECOND_SYS 0x01 /* Load Second system */
更为具体地,将所述非易失性内存上的两个分区分为主分区和从分区,设定“Load_flags”字段内的值“0x00”用于指示该主分区,值“0x01”用于指示该从分区。若所述主分区上存储有所述第一版本系统,所述从分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x01”以实现在所述加载标志字段中写入第二分区标识信息。若所述从分区上存储有所述第一版本系统,所述主分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x00”以实现在所述加载标志字段中写入第二分区标识信息。
所述第十写入装置413用于当所述升级标志字段内的信息为所述升级失败信息,在所述加载标志字段中写入第一分区标识信息。具体地,在非易失性内存的分区表头中增加所述“load_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“load_flag”字段:
/* Load_flags */
#define MTD_LOAD_FIRST_SYS 0x00 /* Load First system */
#define MTD_LOAD_SECOND_SYS 0x01 /* Load Second system */
更为具体地,将所述非易失性内存上的两个分区分为主分区和从分区,设定“Load_flags”字段内的值“0x00”用于指示该主分区,值“0x01”用于指示该从分区。若所述主分区上存储有所述第一版本系统,所述从分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x00”以实现在所述加载标志字段中写入第二分区标识信息。若所述从分区上存储有所述第一版本系统,所述主分区上存储有所述第二版本系统,则在所述“load_flag”字段中写入“0x01”以实现在所述加载标志字段中写入第二分区标识信息。
所述第十二写入装置414用于当所述升级标志字段内的信息为所述版本转换信息时,在所述加载标志字段中写入第一分区标识信息,在所述升级标志字段中写入升级失败信息,然后触发所述第十判断装置415。具体地,本领域技术人员可以通过参照所述第十写入装置413实现在所述加载标志字段中写入第一分区标识信息,在此不予赘述。进一步地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0004”以实现向所述升级标志字段中写入升级失败信息。
通过所述第九写入装置412、第十写入装置413或第十二写入装置414对所述加载标志字段和/或所述升级标志字段进行写入操作后,接下来触发所述第十判断装置415用于判断BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是否成功。
进一步地,若所述第十判断装置415的判断结果是肯定的,即BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是成功的,则接下来触发所述第一确定装置416继续执行;若所述第十判断装置415的判断结果是否定的,即BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件没有成功,则接下来触发所述第一复位装置410继续执行。
其中,所述第一确定装置416用于当所述第十判断装置415的判断结果是肯定的时,确定调用接口成功。具体地,系统再次启动的时候,判断非易失性内存上分区表结构中update_flag的数值(如上定义),如果为0x0004则为失败。
进一步地,若所述第一确定装置416的判断结果是肯定的,即调用接口成功,则接下来触发所述第十一写入装置417继续执行;若所述第一确定装置416的判断结果是否定的,即调用接口没有成功,则接下来触发所述第一复位装置410继续执行。
所述第十一写入装置417用于当调用接口成功时,调用接口在所述升级标志字段中写入常态信息。具体地,通过系统提供的API,该API的主要功能就是将update_flag置为某一个特定值,如果整套升级成功,系统复位,会尝试新的升级软件进行启动,如果一切都是正确的,则所运行的新的软件程序会调用该API来标记当前的新的软件系统是可以正确运行的。
优选地,在非易失性内存的分区表头中增加所述“update_flag”字段,例如,所述非易失性内存上分区表结构可以采用如图7示出的结构,其中,可以按照以下形式定义所述“update_flag”字段:
/* update_flags */
#define MTD_SYS_NORMAL 0x0000
#define MTD_SYS_UPDATE 0x0001
#define MTD_SYS_SWITCH 0x0002
#define MTD_SYS_UPFAILE 0x0004
更为具体地,在所述“update_flag”字段中写入“0x0000”以实现向所述升级标志字段中写入常态信息。
在本实施例的一个变化例中,所述第十一判断装置401可以被省略。在本实施例的另一个变化例中,所述第四写入装置403、第五写入装置406以及第二判断装置404可以被省略,即,所述第一设置装置402执行后接下来触发所述第一写入装置405继续执行,此时,所述控制装置4不对所述升级包的合法性进行判断。在本实施例的又一个变化例中,所述第一判断装置407以及第三写入装置408可以被省略,即,所述第一写入装置40执行后接下来触发所述第二写入装置409继续执行,此时,所述控制装置不对所述升级包的正确性进行判断。
在本实施例的一个优选例中,所述第二判断装置404可以包括第三判断装置、第四判断装置、第五判断装置、第六判断装置以及第七判断装置。其中,所述第三判断装置,其用于判断所述升级包的合法性;所述第四判断装置,其用于判断所述升级包中的BOOT文件的合法性;所述第五判断装置,其用于判断所述升级包中的OS文件的合法性;所述第六判断装置,其用于判断所述升级包中的APP文件的合法性;所述第七判断装置,其用于判断所述升级包中的FPGA文件的合法性。优选地,所述第三判断装置、第四判断装置、第五判断装置、第六判断装置以及第七判断装置可以被并行触发进行判断,还可以被逐个触发进行判断,只有当这些判断装置的判断结果都为肯定的时,所述第二判断装置404的判断结果才为肯定的,否则,所述第二判断装置404的判断结果为否定的。
图4示出根据本发明的第四实施例的,基于双文件系统的嵌入式软件版本升级的控制装置的结构图。本领域技术人员可以将本实施例理解为图3所示实施例中的所述第一写入装置405的一个具体实施方式。具体地,所述第一写入装置405包括第六写入装置4051、第七写入装置4052、第十二判断装置4053、第十三写入装置4054、第八判断装置4055、第九判断装置4056以及第八写入装置4057。
其中,通过所述第六写入装置4051将所述升级包中的APP文件写入所述第二分区的APP备份分区。接下来触发所述第七写入装置4052,将所述升级包中的OS文件写入所述第二分区的OS备份分区。接下来触发所述第十二判断装置4053,判断所述升级包中是否包含FPGA文件,进一步地,若所述第十二判断装置4053的判断结果是肯定的,即所述升级包中包含FPGA文件,则接下来触发所述第八判断装置4055继续执行;若所述第十二判断装置4053的判断结果是否定的,即所述升级包中不包含FPGA文件,则接下来触发所述第十三写入装置4054继续执行。
其中,通过触发所述第十三写入装置4054,将所述升级包中的FPGA文件写入所述第二分区的FPGA备份分区。接下来触发所述第八判断装置4055,判断是否需要升级BOOT ,具体地,若所述第八判断装置4055的判断结果是肯定的,即需要升级BOOT,则接下来触发所述第九判断装置40556继续执行;若所述第八判断装置4055的判断结果是否定的,即不需要升级BOOT,则接下来触发所述第一判断装置407继续执行。
其中,通过所述第九判断装置4056,判断BOOTROM中的BOOT与所述升级包中的BOOT升级文件是否相同,具体地,若所述第九判断装置4056的判断结果是肯定的,即BOOTROM中的BOOT与所述升级包中的BOOT升级文件相同,则接下来触发所述第一判断装置407继续执行;若所述第九判断装置4056的判断结果是否定的,即BOOTROM中的BOOT与所述升级包中的BOOT升级文件不相同,则接下来触发所述第八写入装置4057继续执行。其中,通过所述第八写入装置4057将所述升级包中的BOOT升级文件写入BOOTROM。
以上对本发明的具体实施例进行了描述。需要理解的是,本发明并不局限于上述特定实施方式,本领域技术人员可以在权利要求的范围内做出各种变形或修改,这并不影响本发明的实质内容。
Claims (24)
1.一种基于双文件系统的嵌入式软件版本升级的控制方法,其特征在于,包括如下步骤:
a.在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态;
b.将升级包写入非易失性内存的用户分区;
c.判断所述升级包的合法性;
d.若所述升级包是合法的,则将所述升级包写入所述第二分区,其中,所述升级包包括第二版本系统;
e.判断所写入升级包的正确性;
f.若所写入升级包是正确的,则在所述升级标志字段中写入升级成功标志;若所写入升级包是错误的,则在所述升级标志字段中写入升级失败标志。
2.根据权利要求1所述的控制方法,其特征在于,还包括如下步骤:
-若所述步骤c的判断结果是否定的,则在所述升级标志字段中写入升级失败标志。
3.根据权利要求1或2所述的控制方法,其特征在于,所述步骤c包括如下步骤中的任一个或任多个步骤:
-判断所述升级包的合法性;
-判断所述升级包中的BOOT文件的合法性;
-判断所述升级包中的OS文件的合法性;
-判断所述升级包中的APP文件的合法性;及
-判断所述升级包中的FPGA文件的合法性。
4.根据权利要求3所述的控制方法,其特征在于,所述步骤d包括如下步骤中的任一个或任多个步骤:
-将所述升级包中的APP文件写入所述第二分区的APP备份分区;
-将所述升级包中的OS文件写入所述第二分区的OS备份分区。
5.根据权利要求4所述的控制方法,其特征在于,所述步骤d包括如下步骤:
d1.判断是否需要升级BOOT;
d2.若需要升级BOOT,则判断BOOTROM中的BOOT与所述升级包中的BOOT升级文件是否相同;
d3.若所述步骤d2的判断结果是否定的,则将所述升级包中的BOOT升级文件写入BOOTROM。
6.根据权利要求5所述的控制方法,其特征在于,所述步骤e包括如下步骤:
e1.通过CRC校验算法重新计算写入所述升级包的CRC值,若该值与事先写入的CRC字段一致,则确定所述写入升级包是正确的。
7.根据权利要求1或2或4至6中任一项所述的控制方法,其特征在于,在非易失性内存的分区表头中设置加载标志字段,其中,所述加载标志字段用于指示加载哪个分区中的系统,其中,所述控制方法还包括如下步骤:
g.将系统复位;
h.BOOT引导时检查所述升级标志字段;
i.若所述升级标志字段内的信息为所述升级成功标志,则在所述加载标志字段中写入第二分区标识信息,并在所述升级标志字段中写入版本转换信息;
i'.若所述升级标志字段内的信息为所述升级失败标志,则在所述加载标志字段中写入第一分区标识信息;
j.判断BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是否成功;
k.若所述步骤j的判断结果是肯定的,则判断调用接口是否成功;
l.若调用接口成功,则调用接口在所述升级标志字段中写入常态信息;
l'.若调用接口失败,则执行所述步骤g。
8.根据权利要求7所述的控制方法,其特征在于,还包括如下步骤:
i″.若所述升级标志字段内的信息为所述版本转换信息,则在所述加载标志字段中写入第一分区标识信息,在所述升级标志字段中写入升级失败标志,然后执行所述步骤j。
9.根据权利要求8所述的控制方法,其特征在于,若所述步骤j的判断结果是否定的,则执行所述步骤g。
10.根据权利要求1或2或4至6或8或9中任一项所述的控制方法,其特征在于,在非易失性内存的分区表头中设置备份支持字段,其中,所述备份支持字段用于指示所述非易失性内存是否支持分区备份,所述步骤a之前还包括如下步骤:
m.根据所述备份支持字段判断所述非易失性内存是否支持分区备份,若所述步骤m的判断结果是肯定的,则执行所述步骤a。
11.根据权利要求1或2或4至6或8或9中任一项所述的控制方法,其特征在于,所述步骤d包括如下步骤:
-判断所述升级包中是否包含FPGA文件;
-若所述升级包中包含FPGA文件,则将所述升级包中的FPGA文件写入所述第二分区的FPGA备份分区。
12.一种基于双文件系统的嵌入式软件版本升级的控制装置,其特征在于,包括如下装置:
第一设置装置,其用于在非易失性内存中设置第一分区、第二分区,其中,所述第一分区内存储有第一版本系统,并在非易失性内存的分区表头中设置升级标志字段,其中,所述升级标志字段用于指示升级状态;
第一写入装置,其用于将升级包写入所述第二分区,其中,所述升级包包括第二版本系统;
第一判断装置,其用于判断所写入升级包的正确性;
第二写入装置,其用于当所写入升级包是正确的时,在所述升级标志字段中写入升级成功标志。
13.根据权利要求12所述的控制装置,其特征在于,还包括如下装置:
第三写入装置,其用于当所写入升级包是错误的时,在所述升级标志字段中写入升级失败标志。
14.根据权利要求12或13所述的控制装置,其特征在于,还包括如下装置:
第四写入装置,其用于将所述升级包写入非易失性内存的用户分区;
第二判断装置,其用于判断所述升级包的合法性,
其中,若所述第二判断装置的判断结果是肯定的,则触发所述第一写入装置。
15.根据权利要求14所述的控制装置,其特征在于,还包括如下装置:
-第五写入装置,其用于当所述第二判断装置的判断结果是否定的时,在所述升级标志字段中写入升级失败标志。
16.根据权利要求14所述的控制装置,其特征在于,所述第二判断装置包括如下装置中的任一个或任多个装置:
-第三判断装置,其用于判断所述升级包的合法性;
-第四判断装置,其用于判断所述升级包中的BOOT文件的合法性;
-第五判断装置,其用于判断所述升级包中的OS文件的合法性;
-第六判断装置,其用于判断所述升级包中的APP文件的合法性;及
-第七判断装置,其用于判断所述升级包中的FPGA文件的合法性。
17.根据权利要求12或13或15或16中任一项所述的控制装置,其特征在于,所述第一写入装置包括如下装置中的任一个或任多个装置:
-第六写入装置,其用于将所述升级包中的APP文件写入所述第二分区的APP备份分区;
-第七写入装置,其用于将所述升级包中的OS文件写入所述第二分区的OS备份分区。
18.根据权利要求12或13或15或16中任一项所述的控制装置,其特征在于,所述第一写入装置包括如下装置:
第八判断装置,其用于判断是否需要升级BOOT;
第九判断装置,其用于当需要升级BOOT时,判断BOOTROM中的BOOT与所述升级包中的BOOT升级文件是否相同;
第八写入装置,其用于当所述第九判断装置的判断结果是否定的时,将所述升级包中的BOOT升级文件写入BOOTROM。
19.根据权利要求18所述的控制装置,其特征在于,所述第一判断装置包括如下装置:
第一处理装置,其用于通过CRC校验算法重新计算写入所述升级包的CRC值,若该值与事先写入的CRC字段一致,则确定所述写入升级包是正确的。
20.根据权利要求13或15所述的控制装置,其特征在于,在非易失性内存的分区表头中设置加载标志字段,其中,所述加载标志字段用于指示加载哪个分区中的系统,其中,所述控制装置还包括如下装置:
第一复位装置,其用于将系统复位;
第一检查装置,其用于BOOT引导时检查所述升级标志字段;
第九写入装置,其用于当所述升级标志字段内的信息为所述升级成功标志时,在所述加载标志字段中写入第二分区标识信息,并在所述升级标志字段中写入版本转换信息;
第十写入装置,其用于当所述升级标志字段内的信息为所述升级失败标志,在所述加载标志字段中写入第一分区标识信息;
第十判断装置,其用于判断BOOT根据所述加载标志字段中的信息加载所述第一分区或所述第二分区中的OS文件以及APP文件是否成功;
第一确定装置,其用于当所述第十判断装置的判断结果是肯定的时,确定调用接口成功;
第十一写入装置,其用于当调用接口成功时,调用接口在所述升级标志字段中写入常态信息,
其中,若调用接口失败,则触发所述第一复位装置。
21.根据权利要求20所述的控制装置,其特征在于,还包括如下装置:
第十二写入装置,其用于当所述升级标志字段内的信息为所述版本转换信息时,在所述加载标志字段中写入第一分区标识信息,在所述升级标志字段中写入升级失败信息,然后触发所述第十判断装置。
22.根据权利要求21所述的控制装置,其特征在于,若所述第十判断装置的判断结果是否定的,则触发所述第一复位装置。
23.根据权利要求22所述的控制装置,其特征在于,在非易失性内存的分区表头中设置备份支持字段,其中,所述备份支持字段用于指示所述非易失性内存是否支持分区备份,所述控制装置还包括如下装置:
第十一判断装置,其用于根据所述备份支持字段判断所述非易失性内存是否支持分区备份,若所述第十一判断装置的判断结果是肯定的,则触发所述第一设置装置。
24.根据权利要求12或13或15或16或19或21或23中任一项所述的控制装置,其特征在于,所述第一写入装置包括如下装置:
-第十二判断装置,其用于判断所述升级包中是否包含FPGA文件;
-第十三写入装置,其用于当所述升级包中包含FPGA文件时,将所述升级包中的FPGA文件写入所述第二分区的FPGA备份分区。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110001467.4A CN102622280B (zh) | 2011-01-06 | 2011-01-06 | 一种基于双文件系统的软件版本升级的控制方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110001467.4A CN102622280B (zh) | 2011-01-06 | 2011-01-06 | 一种基于双文件系统的软件版本升级的控制方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102622280A CN102622280A (zh) | 2012-08-01 |
CN102622280B true CN102622280B (zh) | 2014-10-15 |
Family
ID=46562207
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110001467.4A Active CN102622280B (zh) | 2011-01-06 | 2011-01-06 | 一种基于双文件系统的软件版本升级的控制方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102622280B (zh) |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103778026B (zh) * | 2012-10-24 | 2017-03-01 | 阿里巴巴集团控股有限公司 | 对象调用方法和装置 |
CN103077048B (zh) * | 2012-12-28 | 2016-02-10 | 东莞宇龙通信科技有限公司 | 通信模块的运行参数更新方法及通信终端 |
CN104049985A (zh) * | 2013-03-12 | 2014-09-17 | 中兴通讯股份有限公司 | 一种跨文件系统的版本在线升级方法和装置 |
CN104063238A (zh) * | 2013-03-21 | 2014-09-24 | 苏州方位通讯科技有限公司 | 一种有限存储空间下的系统升级备份机制 |
CN104375844A (zh) * | 2013-08-12 | 2015-02-25 | 中兴通讯股份有限公司 | 固件升级方法及装置 |
CN104461595B (zh) * | 2013-09-23 | 2017-11-28 | 联想(北京)有限公司 | 应用软件升级回滚方法、装置及电子设备 |
CN103810004B (zh) * | 2013-11-22 | 2017-03-22 | 小米科技有限责任公司 | 嵌入式系统升级的方法、装置及设备 |
CN104780057A (zh) * | 2014-01-13 | 2015-07-15 | 中兴通讯股份有限公司 | 版本升级处理方法及装置 |
CN105224352A (zh) * | 2014-06-26 | 2016-01-06 | 中兴通讯股份有限公司 | 软件版本升级方法和单板 |
CN105468383A (zh) * | 2014-07-21 | 2016-04-06 | 上海庆科信息技术有限公司 | 一种数据升级方法及装置 |
CN105786547A (zh) * | 2014-12-26 | 2016-07-20 | 中兴通讯股份有限公司 | 一种实现操作系统重启的方法和装置 |
CN106293786A (zh) * | 2015-05-25 | 2017-01-04 | 特变电工新疆新能源股份有限公司 | 一种fpga配置文件更新方法及设备 |
CN106325916A (zh) * | 2016-01-27 | 2017-01-11 | 上海华测导航技术股份有限公司 | 一种gnss接收机系统升级方法 |
CN106547596B (zh) * | 2016-11-07 | 2019-07-26 | 天津津航计算技术研究所 | 一种fpga远程升级方法 |
CN106598650A (zh) * | 2016-11-25 | 2017-04-26 | 积成电子股份有限公司 | 基于光纤通信的fpga程序在线升级的装置及方法 |
CN107967141B (zh) * | 2017-11-27 | 2021-04-13 | 北京小米移动软件有限公司 | 操作系统升级方法、装置及终端 |
CN108121621A (zh) * | 2017-12-27 | 2018-06-05 | 北京卓越信通电子股份有限公司 | 一种交换机等设备软件升级过程中断电不死机的解决方法 |
CN109101279B (zh) * | 2018-06-26 | 2021-08-24 | 珠海全志科技股份有限公司 | 一种多版本系统的兼容性启动方法 |
CN109491951B (zh) * | 2018-09-28 | 2022-05-10 | 超聚变数字技术有限公司 | 一种配置数据的方法以及计算设备 |
CN109710297B (zh) * | 2019-01-07 | 2022-06-21 | 郑州天迈科技股份有限公司 | 一种设备整体或分模块进行升级和回退方法 |
CN110597542B (zh) * | 2019-09-17 | 2023-01-31 | Oppo(重庆)智能科技有限公司 | 软件自动ota升级方法及装置、电子设备 |
CN110825407A (zh) * | 2019-10-28 | 2020-02-21 | 上海大郡动力控制技术有限公司 | 新能源汽车电机控制器的程序更新回滚方法 |
CN111104186A (zh) * | 2019-12-26 | 2020-05-05 | 惠州Tcl移动通信有限公司 | 蓝牙配置文件的加载方法及装置、存储介质、终端设备 |
CN111131861B (zh) * | 2019-12-31 | 2022-03-01 | 深圳Tcl新技术有限公司 | 恢复分区的升级方法、终端和存储介质 |
WO2024000535A1 (zh) * | 2022-06-30 | 2024-01-04 | 北京小米移动软件有限公司 | 分区表更新方法、装置、电子设备及存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6425125B1 (en) * | 1999-03-30 | 2002-07-23 | Microsoft Corporation | System and method for upgrading client software |
CN1581101A (zh) * | 2003-08-12 | 2005-02-16 | 联想(北京)有限公司 | 一种嵌入式系统升级的方法 |
KR20080066381A (ko) * | 2007-01-12 | 2008-07-16 | 엘지전자 주식회사 | 소프트웨어의 업그레이드 방법 |
CN101436138A (zh) * | 2007-11-16 | 2009-05-20 | 苏州科达通信技术发展有限公司 | 一种用于软件升级且动态回滚的控制装置以及控制方法 |
CN101477471A (zh) * | 2009-01-07 | 2009-07-08 | 杭州海康威视数字技术股份有限公司 | 一种嵌入式系统固件在线升级方法 |
-
2011
- 2011-01-06 CN CN201110001467.4A patent/CN102622280B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6425125B1 (en) * | 1999-03-30 | 2002-07-23 | Microsoft Corporation | System and method for upgrading client software |
CN1581101A (zh) * | 2003-08-12 | 2005-02-16 | 联想(北京)有限公司 | 一种嵌入式系统升级的方法 |
KR20080066381A (ko) * | 2007-01-12 | 2008-07-16 | 엘지전자 주식회사 | 소프트웨어의 업그레이드 방법 |
CN101436138A (zh) * | 2007-11-16 | 2009-05-20 | 苏州科达通信技术发展有限公司 | 一种用于软件升级且动态回滚的控制装置以及控制方法 |
CN101477471A (zh) * | 2009-01-07 | 2009-07-08 | 杭州海康威视数字技术股份有限公司 | 一种嵌入式系统固件在线升级方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102622280A (zh) | 2012-08-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102622280B (zh) | 一种基于双文件系统的软件版本升级的控制方法及装置 | |
CN102662701B (zh) | Cpld在线升级方法、装置及业务单板 | |
CN102289397B (zh) | 一种机顶盒的嵌入式系统自动恢复方法及装置 | |
US10860302B2 (en) | Memory-efficient upgrade staging | |
WO2017067448A1 (zh) | 一种无线固件升级方法、系统及计算机存储介质 | |
CN102650947B (zh) | 一种Android手持设备连续增量的空中升级方法 | |
CN102270144B (zh) | 嵌入式网络设备及其更新固件的方法 | |
CN104133709B (zh) | 嵌入式系统的升级方法和装置 | |
CN103530150A (zh) | 一种Linux操作系统远程更新的方法 | |
CN102609304B (zh) | 一种Android手机内置第三方应用的管理方法 | |
CN106325929A (zh) | 一种固件升级方法、固件升级装置、冰箱和服务端 | |
CN109062598A (zh) | 一种安全的ota升级方法及系统 | |
CN102073517A (zh) | 一种嵌入式系统的升级、备份方法和装置 | |
CN107493290A (zh) | Android智能电视系统软件进行OTA升级的方法 | |
CN111309354A (zh) | 联网设备的ota升级方法及装置 | |
CN106951284B (zh) | 基于安卓系统应用的用户界面升级方法、装置及智能终端 | |
CN106331862A (zh) | 一种机顶盒的软件升级方法及机顶盒 | |
CN107608705A (zh) | 一种无线wifi视频设备及其固件升级方法 | |
CN106775610A (zh) | 一种电子设备启动方法及一种电子设备 | |
CN102346673A (zh) | 一种手机系统升级的方法及装置 | |
CN104915226A (zh) | 一种网络设备软件启动方法、装置及网络设备 | |
CN104281479A (zh) | 一种固件升级方法及装置 | |
CN108874582A (zh) | 一种系统恢复方法、装置及终端 | |
CN103186390A (zh) | 家庭网关及其软件升级方法 | |
CN109360029A (zh) | 一种远程终端广告机的自我管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C53 | Correction of patent for invention or patent application | ||
CB02 | Change of applicant information |
Address after: 215011 No. 131 Jin Shan Road, Suzhou hi tech Industrial Development Zone, Jiangsu, Suzhou Applicant after: Suzhou Keda Technology Co., Ltd. Address before: 215011 No. 131 Jin Shan Road, Suzhou hi tech Industrial Development Zone, Jiangsu, Suzhou Applicant before: Suzhou Keda Technology Co., Ltd. |
|
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |