CN114265606B - 固件升级方法、装置、设备及存储介质 - Google Patents

固件升级方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN114265606B
CN114265606B CN202210194739.5A CN202210194739A CN114265606B CN 114265606 B CN114265606 B CN 114265606B CN 202210194739 A CN202210194739 A CN 202210194739A CN 114265606 B CN114265606 B CN 114265606B
Authority
CN
China
Prior art keywords
firmware
upgraded
upgrading
upgrade
decompression
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
Application number
CN202210194739.5A
Other languages
English (en)
Other versions
CN114265606A (zh
Inventor
张黎明
杜军红
葛振纲
路广
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Longcheer Electronics Huizhou Co Ltd
Original Assignee
Longcheer Electronics Huizhou Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Longcheer Electronics Huizhou Co Ltd filed Critical Longcheer Electronics Huizhou Co Ltd
Priority to CN202210194739.5A priority Critical patent/CN114265606B/zh
Publication of CN114265606A publication Critical patent/CN114265606A/zh
Application granted granted Critical
Publication of CN114265606B publication Critical patent/CN114265606B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本申请提供了一种固件升级方法、装置、设备及存储介质,通过获取一个或多个待升级终端的目标存储容量以及固件升级需求,根据各个待升级固件之间的功能关联程度确定解压粒度上限值,该解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量,根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式,根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。解决了现有技术中存在固件升级方式灵活性较差需要用户手动腾出存储空间的技术问题。

Description

固件升级方法、装置、设备及存储介质
技术领域
本申请涉及智能电子产品领域,尤其涉及一种固件升级方法、装置、设备及存储介质。
背景技术
随着科技的发展,各式各样的电子产品已经融入了人们的工作和日常生活当中。然而随着各类电子产品的更新和发布速度越来越快,难免会存在某些缺陷,或者是制造商研发出了更优良的功能需要更新到已经发布的电子产品上。
目前,电子产品可以通过在线固件升级的方式来修复终端使用中的一些缺陷,或者是通过固件升级来更新更具优势的功能。一般现有技术都是在网站上为每种类型的终端,或者是使用相同固件的多种终端发布与固件对应的固定大小的固件升级数据包,然后由用户自己下载固件升级数据包来进行固件升级,或者是由终端自动从网络下载升级。
但是,由于不同的终端其内部存储状态是不同的,无论是其本身固有的总存储容量,还是被用户使用后剩余的存储容量,都造成了不同的终端其存储状态的差异,这就导致固件升级时需要用到的存储容量超过了终端可以分配给固件升级的存储容量,从而造成固件升级失败。此时用户只能够选择删除部分数据来腾出足够的存储容量进行固件升级。这就严重影响了用户的使用体验。
因此,现有技术中存在固件升级方式升级灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。
发明内容
本申请提供一种固件升级方法、装置、设备及存储介质,以解决现有技术中存在固件升级方式灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。
第一个方面,本申请提供一种固件升级方法,包括:
获取一个或多个待升级终端的目标存储容量以及固件升级需求,目标存储容量为待升级终端在进行固件升级时临时存放升级数据的存储空间大小,升级数据是从固件升级包中解压出的;
根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量;
根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式;
根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
在一种可能的设计中,根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,包括:
判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能;
若两个或两个以上的待升级固件在待升级终端上配合完成同一个或多个功能,则将存在功能关联的各个待升级固件对应的升级数据集所占用的存储容量之和作为解压粒度上限值。
在一种可能的设计中,在判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能之后,还包括:
若否,则从各个升级数据集对应的各个存储容量中选出最大存储容量作为解压粒度上限值。
在一种可能的设计中,根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,包括:
根据固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量,升级数据集用于将待升级固件升级到目标版本,每个升级数据集与一个待升级固件相对应;
根据预设压缩率对总数据量进行压缩,以确定压缩总数据量;
判断压缩总数据量与解压粒度上限值之和是否大于目标存储容量;
若是,则以升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有分包单元打包成多个固件升级包;
若否,则将所有升级数据集打包成一个固件升级包。
在一种可能的设计中,预设分包要求,包括:将具有功能关联的各个分包单元打包到同一个固件升级包中。
在一种可能的设计中,预设分包要求,包括:各个固件升级包所占存储空间的差值小于预设分包阈值。
在一种可能的设计中,以升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有分包单元打包成多个固件升级包,包括:
根据预设分包要求对各个分包单元进行分组,以确定预设数量个数据组,每个数据组对应一个固件升级包;
根据预设压缩率以及在同一个数据组中的各个分包单元的数据量,确定各个固件升级包所占的存储空间;
判断存储空间与解压粒度上限值之和是否大于目标存储容量;
若是,则增大预设数量,并重新进行分组,直至存储空间与解压粒度上限值之和小于或等于目标存储容量;
若否,则根据预设压缩率将各个数据组封装成各个固件升级包。
在一种可能的设计中,固件升级包中包括:至少一个升级数据集;待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件,包括:
待升级终端根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来,并存储到待升级终端的临时存储空间中,每次解压出来的所有升级数据集的存储容量之和小于或等于解压粒度上限值;
其中,在每次从固件升级包中解压出一个或多个升级数据集时,同时将上一次解压出来的升级数据集从临时存储空间中删除,在待升级终端利用本次解压的一个或多个升级数据集升级对应的待升级固件之后,再执行下一次解压,直至所有的待升级固件都升级为目标固件。
在一种可能的设计中,固件升级包中还包括:升级管理程序,在待升级终端根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来之前,还包括:
待升级终端将升级管理程序从固件升级包中解压出来,并存储到临时存储空间中,升级管理程序文件用于统一管理各个目标固件的升级过程。
在一种可能的设计中,获取一个或多个待升级终端的目标存储容量以及固件升级需求,包括:
获取一个或多个待升级终端能够分配给固件升级使用的空闲存储容量以及固件升级需求;
根据回滚文件的第一存储容量以及空闲存储容量确定目标存储容量,回滚文件用于在固件升级失败时将待升级固件回滚到原来的版本。
第二个方面,本申请提供一种固件升级装置,包括:
获取模块,用于获取一个或多个待升级终端的目标存储容量以及固件升级需求,目标存储容量为待升级终端在进行固件升级时临时存放升级数据的存储空间大小,升级数据是从固件升级包中解压出的;
处理模块,用于:
根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量;
根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式;
根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
在一种可能的设计中,处理模块,用于:
判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能;
若两个或两个以上的待升级固件在待升级终端上配合完成同一个或多个功能,则将存在功能关联的各个待升级固件对应的升级数据集所占用的存储容量之和作为解压粒度上限值。
在一种可能的设计中,处理模块,还用于:
若否,则从各个升级数据集对应的各个存储容量中选出最大存储容量作为解压粒度上限值。
在一种可能的设计中,处理模块,用于:
根据固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量,升级数据集用于将待升级固件升级到目标版本,每个升级数据集与一个待升级固件相对应;
根据预设压缩率对总数据量进行压缩,以确定压缩总数据量;
判断压缩总数据量与解压粒度上限值之和是否大于目标存储容量;
若是,则以升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有分包单元打包成多个固件升级包;
若否,则将所有升级数据集打包成一个固件升级包。
在一种可能的设计中,预设分包要求,包括:将具有功能关联的各个分包单元打包到同一个固件升级包中。
在一种可能的设计中,预设分包要求,包括:各个固件升级包所占存储空间的差值小于预设分包阈值。
在一种可能的设计中,处理模块,用于:
根据预设分包要求对各个分包单元进行分组,以确定预设数量个数据组,每个数据组对应一个固件升级包;
根据预设压缩率以及在同一个数据组中的各个分包单元的数据量,确定各个固件升级包所占的存储空间;
判断存储空间与解压粒度上限值之和是否大于目标存储容量;
若是,则增大预设数量,并重新进行分组,直至存储空间与解压粒度上限值之和小于或等于目标存储容量;
若否,则根据预设压缩率将各个数据组封装成各个固件升级包。
在一种可能的设计中,固件升级包中包括:至少一个升级数据集;处理模块,用于:
根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来,并存储到待升级终端的临时存储空间中,每次解压出来的所有升级数据集的存储容量之和小于或等于解压粒度上限值;
其中,在每次从固件升级包中解压出一个或多个升级数据集时,同时将上一次解压出来的升级数据集从临时存储空间中删除,在待升级终端利用本次解压的一个或多个升级数据集升级对应的待升级固件之后,再执行下一次解压,直至所有的待升级固件都升级为目标固件。
在一种可能的设计中,固件升级包中还包括:升级管理程序,处理模块,还用于:
将升级管理程序从固件升级包中解压出来,并存储到临时存储空间中,升级管理程序文件用于统一管理各个目标固件的升级过程。
在一种可能的设计中,获取模块,还用于获取一个或多个待升级终端能够分配给固件升级使用的空闲存储容量以及固件升级需求;
处理模块,还用于根据回滚文件的第一存储容量以及空闲存储容量确定目标存储容量,回滚文件用于在固件升级失败时将待升级固件回滚到原来的版本。
第三个方面,本申请提供一种电子设备,包括:
存储器,用于存储程序指令;
处理器,用于调用并执行所述存储器中的程序指令,执行第一方面所提供的任意一种可能的固件升级方法。
第四个方面,本申请提供一种存储介质,所述可读存储介质中存储有计算机程序,所述计算机程序用于执行第一方面所提供的任意一种可能的固件升级方法。
第五个方面,本申请还提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的固件升级系统方法。
本申请提供了一种固件升级方法、装置、设备及存储介质,通过获取一个或多个待升级终端的目标存储容量以及固件升级需求,根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,该解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量,根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式,根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。解决了现有技术中存在固件升级方式灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。自动根据每个待升级终端的存储空间来分配不同的固件升级方式,达到了有效减少固件升级所需存储空间,无需用户或研发人员手动参与即可自动调整升级方式,且提高了升级成功率和升级效率的技术效果。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1为本申请提供的一种固件升级方法的应用场景示意图;
图2为本申请实施例提供的一种固件升级方法的流程示意图;
图3为本申请实施例提供的另一种固件升级方法的流程示意图;
图4为本申请实施例提供的一种固件升级装置的结构示意图;
图5为本申请提供的一种电子设备的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,包括但不限于对多个实施例的组合,都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
下面先对本申请所涉及到的专业名词作介绍:
固件:指设备内部保存的设备“驱动程序”,通过固件,操作系统才能按照标准的设备驱动实现特定机器的运行动作。固件是担任着一个系统最基础最底层工作的软件。而在硬件设备中,固件就是硬件设备的灵魂,因为一些硬件设备除了固件以外没有其它软件组成,因此固件也就决定着硬件设备的功能及性能。固件一般是写入EPROM(可擦写可编程只读存储器)或EEPROM(电可擦可编程只读存储器)中的程序。
AT指令是应用于终端设备与PC应用之间的连接与通信的指令。AT 即Attention。每个AT命令行中只能包含一条AT指令;对于AT指令的发送,除AT两个字符外,最多可以接收1056个字符的长度(包括最后的空字符)。AT指令集是从终端设备(Terminal Equipment,TE)或数据终端设备(Data Terminal Equipment,DTE)向终端适配器(Terminal Adapter,TA)或数据电路终端设备(Data Circuit Terminal Equipment,DCE)发送的。其对所传输的数据包大小有定义:即对于AT指令的发送,除AT两个字符外,最多可以接收1056个字符的长度(包括最后的空字符)。每个AT命令行中只能包含一条AT指令;对于由终端设备主动向PC端报告的URC指示或者response响应,也要求一行最多有一个,不允许上报的一行中有多条指示或者响应。AT指令以回车作为结尾,响应或上报以回车换行为结尾。
由于不同的终端其内部存储状态是不同的,有些终端其本身固有的存储器的存储空间较大,而另一些终端其本身固有的存储器的存储空间较小,而如果固件升级所需要的空间较大时,很可能由于存储器的存储空间不足而造成升级失败。为了避免升级失败,或者说降低升级失败的可能性,现有技术一般通过以下三种方式来解决:第一种是增加终端的存储器(如EPROM或EEPROM)的存储空间大小,但是这样会大大增加终端的成本和售价;第二种是在下载固件升级包前检测存储器的剩余存储容量,在剩余存储容量不足时可以提醒用户结束某些进程来增加存储器的剩余存储容量,但是这就会导致用户必须中断正在进行的业务,流出专门的时间来进行固件升级,影响用户的使用体验感;第三种是对于某些存储器本身存储空间就较小的终端,让终端制造商的研发人员设置专门的固件升级方式,如进一步精简固件升级包中的数据,如使用差分处理,重复利用旧版本中与新版本相同的数据文件,从而减少固件升级包的大小,但是这就大大增加了研发人员的工作量,可能为了升级一个固件需要配置很多种不同版本的固件升级包,也会导致用户在手动下载时可能不知道应该下载哪个版本的固件升级包。
总的来说,上述现有技术的固件升级方式灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。
为解决上述的技术问题,本申请的发明构思是:
在下载固件升级包前,首先根据待升级终端中能够供固件升级使用的存储容量,来对固件升级的所有数据进行容量评估,通过拆分多个固件升级包,将固件升级分成几次完成,每次仅对具有功能关联性的几个待升级固件进行升级。根据不同的待升级终端的存储容量,个性化自动决定分成几个固件升级包,每次从固件升级包中解压出多少数据,进一步地还可以根据是否需要配置升级失败时的回滚文件,和/或,升级管理程序来对固件升级中的各项事件进行管理。这样就使得固件升级包不再是单一的一个,或者几个,而是能够灵活变化的,并且也不需要研发人员预先构件多个固件升级包版本。采用此方法后,还可以批量化地对数据量庞大的各个终端的固件升级进行统一管理,简化了需要对大量的终端进行固件升级时的工作量。
下面对本申请如何实现通过触觉来传递信息进行详细介绍。
图1为本申请提供的一种固件升级方法的应用场景示意图。如图1所示,待升级终端10可以包括多个相同或不同的终端设备,如IoT物联网设备、智能手机、智能手表、智能手环等等,服务端20包括:云端服务器201以及个人电脑202中的任意一个。
在待升级终端10检测到存在需要升级的至少一个固件时,向服务端20上报其可用存储空间和固件升级需求。服务端20再根据这些数据自动为其分配打包个性化固件升级包。该这些固件升级包是可以根据每个待升级终端而动态变化的,并且实现了自动化管理固件升级,节省了人力物力。
图2为本申请实施例提供的一种固件升级方法的流程示意图。如图2所示,该固件升级方法的具体步骤,包括:
S201、获取一个或多个待升级终端的目标存储容量以及固件升级需求。
在本步骤中,待升级终端包括:移动终端(如智能手机、智能手表、智能手环等)、IoT(Internet of Things,物联网)终端等等,目标存储容量为待升级终端在进行固件升级时临时存放升级数据的存储空间大小,升级数据是从固件升级包中解压出的。
需要说明的是,本申请实施例所提供的固件升级方法,即可以针对一个待升级终端的固件升级,也可以针对多个或者说批量化的待升级终端的固件升级。该固件升级方法可以应用于PC(Personal Computer,个人电脑)端,也可以应用于云端服务器。
具体的,每个待升级固件在检测到需要对固件进行升级,或者是接收到了固件升级指令后,每个待升级终端根据自身的工作情况和工作状态为固件升级分配对应的存储器容量,如EPROM或EEPROM或其它内部存储器的空闲存储空间,并且将固件升级需求,即每个待升级终端中的一个或多个待升级固件的名称或编码,以及待升级固件的当前版本号,需要升级到的目标版本号等等发送给PC端或者云端服务器。
S202、根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值。
在本步骤中,解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量。
可以先判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能;
若两个或两个以上的待升级固件在待升级终端上配合完成同一个或多个功能,则将存在功能关联的各个待升级固件对应的升级数据集所占用的存储容量之和作为解压粒度上限值。
具体的,PC端或者云端服务器先分析两个或两个以上的待升级固件之间是否具有功能关联关系,例如A固件和B固件共同配合完成待升级终端的某个功能,那么A固件和B固件之间就存在功能关联关系。
在一种可能的实现方式中,在PC端或者云端服务器的数据库中可以预先存放各种待升级设备中的功能与固件关联表,PC端或者云端服务器就可以根据此功能与固件关联表确定待升级固件之间是否具备功能关联,并且多个待升级固件之间与多个功能都有关联,或者说关联的功能数量越多,那么这些待升级固件间的关联程度就越高。
S203、根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式。
在本步骤中,预设压缩率是指数据压缩后所占的存储容量与压缩前的所占的存储容量之比。
具体的,首先判断各个待升级固件的目标升级版本的所有升级数据所占的初始存储容量(即没有压缩时的数据量大小)是否大于目标存储容量。接下来根据判断结果会分成两个不同的处理方式:
第一种处理方式:
若初始存储容量小于目标存储容量,则继续判断目标存储容量是否大于或等于初始存储容量的两倍;
若是,则证明此时目标存储容量足够大,那么此时可以将预设压缩率设置为1即不压缩,解压粒度上限值设置为初始存储容量,固件升级包数量为1,解压方式设置为每次解压时将全部数据一次解压出来,对应的传输方式是直接一次传输所有固件升级包;
若否,则证明此时目标存储容量一般,此时预设压缩率可以先设置为第一压缩率,如50%,然后根据预设压缩率和初始存储容量计算压缩后的第一压缩容量,并判断第一压缩容量与初始存储容量之和是否小于或等于目标存储容量;若是,则以第一压缩率将升级数据打包成一个固件升级包,解压粒度上限值设置为初始存储容量,传输方式为直接一次传输所有固件升级包,解压方式设置为每次解压时将全部数据一次解压出来;若否,则又可以分成两个方向:
第一个方向是:
保持解压粒度上限值和固件升级包的数量不变,尝试减小预设压缩率,如从第一压缩率提高到第二压缩率,如40%,重复判断第一压缩容量与初始存储容量之和是否小于或等于目标存储容量,若是则直接生成一个固件升级包,并一次传输该固件升级包,若否,则重复减小预设压缩率,直至预设压缩率达到最小压缩值,如30%。
如果预设压缩率达到最小压缩值后,第一压缩容量与初始存储容量之和依然大于目标存储容量,那么就需要尝试第二个方向。
第二个方向是:
将预设压缩率设置为最小压缩值,如30%,然后将固件升级包的数量从2开始增加,分包的原则是将有功能关联的多个待升级固件对应的升级数据分到同一个固件升级包中,并且每个待升级固件对应的升级数据不可拆分到不同的固件升级包中。接下来判断每个固件升级包的第二压缩容量与完全解压后的存储容量之和是否小于或等于目标存储容量,若是,则解压方式可以设置为一次解压固件升级包中所有的数据文件,若否,则可以将解压方式设置为,每次只从固件升级包中解压一部分数据文件,使得解压出来的数据所占存储容量和第二压缩容量之和不大于目标存储容量。这样就能够实现边解压边升级的同时,严格控制所使用的存储空间。在一个固件升级包的升级数据都使用完毕后,删除该固件升级包,再传输下一个固件升级包进行边解压边升级的操作。需要说明的是,根据上述方式确定的固件升级包的数量大于或等于2.
第二种处理方式:
若初始存储容量大于或等于目标存储容量,则直接按照上述的两个方向来设置固件升级包,及其传输方式、解压方式,在此不再赘述。
S204、根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
在本步骤中,待升级终端根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来,并存储到待升级终端的临时存储空间中,每次解压出来的所有升级数据集的存储容量之和小于或等于解压粒度上限值;
其中,在每次从固件升级包中解压出一个或多个升级数据集时,同时将上一次解压出来的升级数据集从临时存储空间中删除,在待升级终端利用本次解压的一个或多个升级数据集升级对应的待升级固件之后,再执行下一次解压,直至所有的待升级固件都升级为目标固件。
本实施例提供了一种固件升级系统方法,通过获取一个或多个待升级终端的目标存储容量以及固件升级需求,根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,该解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量,根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式,根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。解决了现有技术中存在固件升级方式灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。自动根据每个待升级终端的存储空间来分配不同的固件升级方式,达到了有效减少固件升级所需存储空间,无需用户或研发人员手动参与即可自动调整升级方式,且提高了升级成功率和升级效率的技术效果。
图3为本申请实施例提供的另一种固件升级方法的流程示意图。如图3所示,该固件升级方法的具体步骤包括:
S301、获取一个或多个待升级终端能够分配给固件升级使用的空闲存储容量以及固件升级需求。
在本步骤中,待升级终端在检测到有固件需要升级时,或者是接收到云端服务器发送的固件升级指令后,根据自身的工作状态和存储器的使用情况,为固件升级分配空闲存储容量。固件升级需求则包括:待升级固件的名称、当前版本号和目标升级版本号。
S302、根据回滚文件的第一存储容量以及空闲存储容量确定目标存储容量。
在本步骤中,回滚文件用于在固件升级失败时将待升级固件回滚到原来的版本。为了避免升级过程中出现意外错误,造成升级失败,导致固件无法使用的情况,需要在升级的同时保证待升级设备的存储器中保存有待升级固件升级前的固件版本的数据文件,即回滚文件,因此回滚文件需要占据一定的存储容量。
用Rtarget表示目标存储容量,用Rdis表示分配的空闲存储容量,用Rback表示回滚文件所占据的存储容量,则可以用公式(1)来表示三者之间的关系:
Figure 182194DEST_PATH_IMAGE001
(1)
S303、判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能。
在本步骤中,若是,则执行S304,若否,则执行S305。
S304、将存在功能关联的各个待升级固件对应的升级数据集所占用的存储容量之和作为解压粒度上限值。
在本步骤中,假设具有两个或两个以上的功能关联固件,则这两个固件的升级数 据集之和占到了升级所用总数据量或者是单个固件升级包的存储容量的比例为
Figure 512681DEST_PATH_IMAGE002
,那么
Figure 567224DEST_PATH_IMAGE002
与总数据量或者单个固件升级包的存储容量的乘积即为解压粒度上限值。
需要说明的是,本步骤的作用是保证多个固件分多次升级时,各个固件之间的配合关系不会以为固件版本不匹配而造成预设功能无法实现,影响用户的使用体验。
在一种可能的设计中,为了简化固件升级数据,节省其占有的存储容量,可以选择对升级数据进行差分处理。所谓差分处理是指,使用差分算法脚本计算升级前版本和升级后版本的数据差异,只将差异部分作为升级数据。进一步的,由于差分后的数据量可能较小,因此可以不对差分后的升级数据集进行压缩,或者说将预设压缩率设置为1。
S305、从各个升级数据集对应的各个存储容量中选出最大存储容量作为解压粒度上限值。
S306、根据固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量。
在本步骤中,升级数据集用于将待升级固件升级到目标版本,每个升级数据集与一个待升级固件相对应。
由于每个待升级终端中可能存在多个模块,每个模块都有一个固件与之对应,以驱动该模块完成预设的功能,所以每个待升级终端中可能会有多个待升级固件,因此需要从固件升级需求中确定每个待升级固件的升级数据集,将所有这些升级数据集的总数据量表示所有未经压缩的升级数据所占的存储空间。其可以用公式(2)来表示:
Figure 731490DEST_PATH_IMAGE003
(2)
其中,X表示总数据量,Xn表示每个升级数据集所对应的数据量。
S307、根据预设压缩率对总数据量进行压缩,以确定压缩总数据量。
在本步骤中,假设预设压缩率为
Figure 628907DEST_PATH_IMAGE004
,那么压缩总数据量Xp。可以用公式(3)来表示:
Figure 435189DEST_PATH_IMAGE005
(3)
S308、判断压缩总数据量与解压粒度上限值之和是否大于目标存储容量。
在本步骤中,若是,则执行S309,若否,则执行S310。
具体的,在判断时可以用公式(4)来进行计算:
Figure 485185DEST_PATH_IMAGE006
(4)
S309、以升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有分包单元打包成多个固件升级包。
在本步骤中,预设分包要求,包括:(1)将具有功能关联的各个分包单元打包到同一个固件升级包中;(2)各个固件升级包所占存储空间的差值小于预设分包阈值。预设分包要求包括这两个要求中的至少一个。
在本实施例中,本步骤具体包括:
根据预设分包要求对各个分包单元进行分组,以确定预设数量个数据组,每个数据组对应一个固件升级包;
根据预设压缩率以及在同一个数据组中的各个分包单元的数据量,确定各个固件升级包所占的存储空间;
判断存储空间与解压粒度上限值之和是否大于目标存储容量;
若是,则增大预设数量,并重新进行分组,直至存储空间与解压粒度上限值之和小于或等于目标存储容量;
若否,则根据预设压缩率将各个数据组封装成各个固件升级包。
对于固件升级包的打包过程,其可以分为两次打包,具体如下:
将差分目录(即差分处理后的升级数据)或压缩目录(即各个数据组)或整包目录(即所有升级数据只打一个固件升级包)进行打包,每个固件升级包格式为“包头信息+固件集”,包头信息主要为每个固件的说明信息和升级操作命令,固件集为每个固件和该固件CRC值。该包命令为packet.bin,实际名称依据项目为准。
每个固件升级包第一次打包的具体打包格式,如表1所示:
Figure 351510DEST_PATH_IMAGE007
表1
表2为固件类型索引表:
Figure 739153DEST_PATH_IMAGE008
表2
需要说明的是,在本实施例中,在每个固件升级包中包括:至少一个升级数据集。并且当存在多个固件升级包时,在第一个传输给待升级终端的固件升级包中还包括升级管理程序,升级管理程序用于统一管理各个目标固件的升级过程。
第二次打包的过程就是将升级管理程序ota.bin与packet.bin合并为最终的固件升级包update_packet.bin。如表3所示:
Figure 349126DEST_PATH_IMAGE009
表3
S310、将所有升级数据集打包成一个固件升级包。
本步骤的实现可以参考S309,在此不再赘述。
S311、根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
在本步骤中,待升级终端将升级管理程序从固件升级包中解压出来,并存储到临时存储空间中,然后,待升级终端根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来,并存储到待升级终端的临时存储空间中,每次解压出来的所有升级数据集的存储容量之和小于或等于解压粒度上限值;
其中,在每次从固件升级包中解压出一个或多个升级数据集时,同时将上一次解压出来的升级数据集从临时存储空间中删除,在待升级终端利用本次解压的一个或多个升级数据集升级对应的待升级固件之后,再执行下一次解压,直至所有的待升级固件都升级为目标固件。
具体的,固件升级过程如下:
1简单解包
根据打包方式,解出ota.bin与packet.bin。
2 拆包解压固件或差分恢复
首先对packet.bin包头进行解析,根据压缩包标志进行判断是否需要解压,如果是压缩包,则拆解出各个子固件后再进行单独解压到临时目录,解压后对固件进行CRC校验,验证无误后得到升级包进行后面升级。
若是差分包则与原始备份包对比,进行差分恢复,恢复到临时目录。
3 升级
所有固件拆分完成后,其临时目录包含主MCU boot固件,主MCU APP系统固件,蓝牙固件,NFC固件,TP固件,GPS固件等。注意,当使用压缩方式时,这里只拆解固件不拆解资源,整个升级包中,固件占用升级包的容量通常不到5%,固件升级无异常后才进行资源的拆解,这样做是为了支持小容量设备的升级失败回滚功能,当此步骤升级失败时,
4 压缩方式再次拆解
若打包方式是压缩而不是差分时,升级各个固件无误后,将临时文件夹中各个固件复制到备份目录,并继续拆解资源直接到备份目录。
5 升级结束
若升级过程中某个固件升级失败,可根据升级包打包时的设置,设备端自动决定是否需要回滚回升级前的固件,确保产品的可用性。
若升级成功,则会将升级成功的固件进行备份,用作下一次升级失败时的回滚恢复。
需要说明的是,在一种可能的设计中,可以实时加载运行升级程序,即将OTA(Over-the-Air Technology,空中下载技术)升级程序ota.bin与升级包打包在一起,这样OTA升级程序可在每次升级之前自由替换,简单解包解出来ota.bin后,系统重启,boot直接将ota.bin加载到RAM中运行,这样可以使用最新的升级程序进行此次升级,避免不同版本间因版本变化较大的过渡包,且升级程序ota.bin稳定后几乎不会修改,能保证升级的稳定性。
还需要说明的是,对于小容量产品升级回滚机制,本申请的固件升级方法与现有技术的对比效果如下:
因产品功能以及体验度要求的越来越高与成本控制相矛盾,这就要求在存储容量不变的情况下提升产品功能,升级包也会越来愈大。
例如,针对128MB的存储器,正常升级时,其设备内部要保留一套完整的升级包A用于回滚,外界传输过来的压缩包C,与压缩包解压后的包B,需要满足:
A+B+C <= 128MB
若压缩率为30%,A与B相等,且大小为x,则:
A+B+C = x+x+0.3x <= 128MB
可求得x约等于55MB,也就是说,针对存储器大小为128MB,在保证回滚功能的同时,其整包大小不能大于55MB,这就限制了产品的定义以及功能的添加或成本的控制。
下面讲述如何在保证升级稳定性(具有回滚功能)的同时,提升整包大小,仍依据128MB的存储器为例
升级过程包括:
1.升级时使用压缩方式打包,得到压缩包C(压缩率设30%),原始备份包为A;
2.传输压缩包至设备,解包时只解出固件到临时目录B,设固件占升级包总容量5%;
3.升级各个固件,若升级失败,则回滚备份目录的文件,若成功,继续;
4.继续解包,解出剩余资源文件直接覆盖到备份目录,结束;
若原始包A大小为x,则:
A+B+C = x+0.05x+0.3x <= 128MB
可求得x约等于94MB,也就是说,针对存储器大小为128MB,在保证回滚功能的同时,其整包大小从之前的方案55MB,增加到94MB,这种方式对于成本的节省无疑是最大的。
本实施例提供了一种固件升级系统方法,通过获取一个或多个待升级终端的目标存储容量以及固件升级需求,根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,该解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量,根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式,根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。解决了现有技术中存在固件升级方式灵活性较差,需要用户手动腾出存储空间或者是需要研发人员手动定制多种不同版本的升级数据包的技术问题。自动根据每个待升级终端的存储空间来分配不同的固件升级方式,达到了有效减少固件升级所需存储空间,无需用户或研发人员手动参与即可自动调整升级方式,且提高了升级成功率和升级效率的技术效果。
对于上述两个实施例所提供的固件升级方法,其有益效果总结如下:
本方案有以下优点:
1. 可以根据需要自动识别并选择差分、压缩或者无操作的方式打包固件升级包。
2. 可以根据需要选择是否需要打包某个固件(如GPS、NFC),待升级终端在解压固件升级包时,仅升级打包的固件。
3. 可以根据需要选择某个固件升级后是否重启系统。
4. 可以根据需要选择是否在设备中新建目录或删除某个目录或执行某个AT指令。
5. 将OTA升级程序与升级包打包在一起,这样OTA升级程序可在每次升级之前自由替换,避免不同版本间的过渡包,且升级程序修改较少,防止应用程序修改对升级程序的影响(若将应用程序与升级程序放在一起,某个版本应用程序异常,会造成无法升级,系统变砖)。
6. 升级出现异常时,通过回滚设置,可回滚至升级前的固件。
7. 升级方式不依赖平台以及产品,可根据实际需要移植。
8. 本方案可以作为统一的标准化方案。
9. 可以对多子模块的产品进行整体的升级。
10.对于小容量设备,仍可实现升级失败时版本回退的功能。
图4为本申请实施例提供的一种固件升级装置的结构示意图。该固件升级装置400可以通过软件、硬件或者两者的结合实现。如图4所示,该固件升级装置400包括:
获取模块401,用于获取一个或多个待升级终端的目标存储容量以及固件升级需求,目标存储容量为待升级终端在进行固件升级时临时存放升级数据的存储空间大小,升级数据是从固件升级包中解压出的;
处理模块402,用于:
根据固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量;
根据固件升级需求、目标存储容量、预设压缩率以及解压粒度上限值,确定一个或多个固件升级包,以及各个固件升级包的传输方式和解压方式;
根据传输方式向各个待升级终端传输对应的固件升级包,以使待升级终端根据解压方式以及固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
在一种可能的设计中,处理模块402,用于:
判断各个待升级固件在待升级终端上能否配合完成同一个或多个功能;
若两个或两个以上的待升级固件在待升级终端上配合完成同一个或多个功能,则将存在功能关联的各个待升级固件对应的升级数据集所占用的存储容量之和作为解压粒度上限值。
在一种可能的设计中,处理模块402,还用于:
若否,则从各个升级数据集对应的各个存储容量中选出最大存储容量作为解压粒度上限值。
在一种可能的设计中,处理模块402,用于:
根据固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量,升级数据集用于将待升级固件升级到目标版本,每个升级数据集与一个待升级固件相对应;
根据预设压缩率对总数据量进行压缩,以确定压缩总数据量;
判断压缩总数据量与解压粒度上限值之和是否大于目标存储容量;
若是,则以升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有分包单元打包成多个固件升级包;
若否,则将所有升级数据集打包成一个固件升级包。
在一种可能的设计中,预设分包要求,包括:将具有功能关联的各个分包单元打包到同一个固件升级包中。
在一种可能的设计中,预设分包要求,包括:各个固件升级包所占存储空间的差值小于预设分包阈值。
在一种可能的设计中,处理模块402,用于:
根据预设分包要求对各个分包单元进行分组,以确定预设数量个数据组,每个数据组对应一个固件升级包;
根据预设压缩率以及在同一个数据组中的各个分包单元的数据量,确定各个固件升级包所占的存储空间;
判断存储空间与解压粒度上限值之和是否大于目标存储容量;
若是,则增大预设数量,并重新进行分组,直至存储空间与解压粒度上限值之和小于或等于目标存储容量;
若否,则根据预设压缩率将各个数据组封装成各个固件升级包。
在一种可能的设计中,固件升级包中包括:至少一个升级数据集;处理模块402,用于:
根据解压粒度上限值将各个升级数据集分多次从固件升级包中解压出来,并存储到待升级终端的临时存储空间中,每次解压出来的所有升级数据集的存储容量之和小于或等于解压粒度上限值;
其中,在每次从固件升级包中解压出一个或多个升级数据集时,同时将上一次解压出来的升级数据集从临时存储空间中删除,在待升级终端利用本次解压的一个或多个升级数据集升级对应的待升级固件之后,再执行下一次解压,直至所有的待升级固件都升级为目标固件。
在一种可能的设计中,固件升级包中还包括:升级管理程序,处理模块402,还用于:
将升级管理程序从固件升级包中解压出来,并存储到临时存储空间中,升级管理程序文件用于统一管理各个目标固件的升级过程。
在一种可能的设计中,获取模块401,还用于获取一个或多个待升级终端能够分配给固件升级使用的空闲存储容量以及固件升级需求;
处理模块402,还用于根据回滚文件的第一存储容量以及空闲存储容量确定目标存储容量,回滚文件用于在固件升级失败时将待升级固件回滚到原来的版本。
值得说明的是,图4所示实施例提供的装置,可以执行上述任一方法实施例中所提供的方法,其具体实现原理、技术特征、专业名词解释以及技术效果类似,在此不再赘述。
图5为本申请实施例提供的一种电子设备的结构示意图。如图5所示,该电子设备500,可以包括:至少一个处理器501和存储器502。图5示出的是以一个处理器为例的电子设备。
存储器502,用于存放程序。具体地,程序可以包括程序代码,程序代码包括计算机操作指令。
存储器502可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
处理器501用于执行存储器502存储的计算机执行指令,以实现以上各方法实施例所述的方法。
其中,处理器501可能是一个中央处理器(central processing unit,简称为CPU),或者是特定集成电路(application specific integrated circuit,简称为ASIC),或者是被配置成实施本申请实施例的一个或多个集成电路。
可选地,存储器502既可以是独立的,也可以跟处理器501集成在一起。当所述存储器502是独立于处理器501之外的器件时,所述电子设备500,还可以包括:
总线503,用于连接所述处理器501以及所述存储器502。总线可以是工业标准体系结构(industry standard architecture,简称为ISA)总线、外部设备互连(peripheralcomponent, PCI)总线或扩展工业标准体系结构(extended industry standardarchitecture, EISA)总线等。总线可以分为地址总线、数据总线、控制总线等,但并不表示仅有一根总线或一种类型的总线。
可选的,在具体实现上,如果存储器502和处理器501集成在一块芯片上实现,则存储器502和处理器501可以通过内部接口完成通信。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质可以包括:U盘、移动硬盘、只读存储器(read-only memory ,ROM)、随机存取存储器(randomaccess memory,RAM)、磁盘或者光盘等各种可以存储程序代码的介质,具体的,该计算机可读存储介质中存储有程序指令,程序指令用于上述各方法实施例中的方法。
本申请实施例还提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述各方法实施例中的方法。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种固件升级方法,其特征在于,包括:
获取一个或多个待升级终端的目标存储容量以及固件升级需求,所述目标存储容量为所述待升级终端在进行固件升级时临时存放升级数据的存储空间大小,所述升级数据是从固件升级包中解压出的;
根据所述固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,所述解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量;
根据所述固件升级需求、所述目标存储容量、预设压缩率以及所述解压粒度上限值,确定一个或多个所述固件升级包,以及各个所述固件升级包的传输方式和解压方式,包括:
根据所述固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量,所述升级数据集用于将所述待升级固件升级到目标版本,每个所述升级数据集与一个所述待升级固件相对应;
根据所述预设压缩率对所述总数据量进行压缩,以确定压缩总数据量;
判断所述压缩总数据量与所述解压粒度上限值之和是否大于所述目标存储容量;
若否,则将所有所述升级数据集打包成一个所述固件升级包;
若是,则以所述升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有所述分包单元打包成多个所述固件升级包,包括:
根据所述预设分包要求对各个所述分包单元进行分组,以确定预设数量个数据组,每个所述数据组对应一个所述固件升级包;根据所述预设压缩率以及在同一个所述数据组中的各个所述分包单元的数据量,确定各个所述固件升级包所占的所述存储空间;判断所述存储空间与所述解压粒度上限值之和是否大于所述目标存储容量;若是,则增大所述预设数量,并重新进行分组,直至所述存储空间与所述解压粒度上限值之和小于或等于所述目标存储容量;若否,则根据所述预设压缩率将各个所述数据组封装成各个所述固件升级包;
根据所述传输方式向各个所述待升级终端传输对应的所述固件升级包,以使所述待升级终端根据所述解压方式以及所述固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
2.根据权利要求1所述的固件升级方法,其特征在于,所述根据所述固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,包括:
判断各个所述待升级固件在所述待升级终端上能否配合完成同一个或多个功能;
若两个或两个以上的所述待升级固件在所述待升级终端上配合完成同一个或多个功能,则将存在功能关联的各个所述待升级固件对应的升级数据集所占用的存储容量之和作为所述解压粒度上限值。
3.根据权利要求2所述的固件升级方法,其特征在于,在所述判断各个所述待升级固件在所述待升级终端上能否配合完成同一个或多个功能之后,还包括:
若否,则从各个所述升级数据集对应的各个所述存储容量中选出最大存储容量作为所述解压粒度上限值。
4.根据权利要求1所述的固件升级方法,其特征在于,所述预设分包要求,包括:将具有功能关联的各个所述分包单元打包到同一个所述固件升级包中。
5.根据权利要求1所述的固件升级方法,其特征在于,所述预设分包要求,包括:各个所述固件升级包所占存储空间的差值小于预设分包阈值。
6.根据权利要求1所述的固件升级方法,其特征在于,所述固件升级包中包括:至少一个升级数据集;所述待升级终端根据所述解压方式以及所述固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件,包括:
所述待升级终端根据所述解压粒度上限值将各个所述升级数据集分多次从所述固件升级包中解压出来,并存储到所述待升级终端的临时存储空间中,每次解压出来的所有所述升级数据集的存储容量之和小于或等于所述解压粒度上限值;
其中,在每次从所述固件升级包中解压出一个或多个所述升级数据集时,同时将上一次解压出来的所述升级数据集从所述临时存储空间中删除,在所述待升级终端利用本次解压的一个或多个所述升级数据集升级对应的所述待升级固件之后,再执行下一次解压,直至所有的所述待升级固件都升级为所述目标固件。
7.根据权利要求6所述的固件升级方法,其特征在于,所述固件升级包中还包括:升级管理程序,在所述待升级终端根据所述解压粒度上限值将各个所述升级数据集分多次从所述固件升级包中解压出来之前,还包括:
所述待升级终端将所述升级管理程序从固件升级包中解压出来,并存储到所述临时存储空间中,所述升级管理程序文件用于统一管理各个目标固件的升级过程。
8.根据权利要求1-7中任意一项所述的固件升级方法,其特征在于,所述获取一个或多个待升级终端的目标存储容量以及固件升级需求,包括:
获取一个或多个所述待升级终端能够分配给固件升级使用的空闲存储容量以及所述固件升级需求;
根据回滚文件的第一存储容量以及所述空闲存储容量确定所述目标存储容量,所述回滚文件用于在固件升级失败时将待升级固件回滚到原来的版本。
9.一种固件升级装置,其特征在于,包括:
获取模块,用于获取一个或多个待升级终端的目标存储容量以及固件升级需求,所述目标存储容量为所述待升级终端在进行固件升级时临时存放升级数据的存储空间大小,所述升级数据是从固件升级包中解压出的;
处理模块,用于:
根据所述固件升级需求中各个待升级固件之间的功能关联程度确定解压粒度上限值,所述解压粒度上限值用于确定在固件升级时每次能从固件升级包中解压出来的最大数据量;
根据所述固件升级需求、所述目标存储容量、预设压缩率以及所述解压粒度上限值,确定一个或多个所述固件升级包,以及各个所述固件升级包的传输方式和解压方式,包括:
根据所述固件升级需求中各个待升级固件的当前版本确定各个升级数据集的总数据量,所述升级数据集用于将所述待升级固件升级到目标版本,每个所述升级数据集与一个所述待升级固件相对应;
根据所述预设压缩率对所述总数据量进行压缩,以确定压缩总数据量;
判断所述压缩总数据量与所述解压粒度上限值之和是否大于所述目标存储容量;
若否,则将所有所述升级数据集打包成一个所述固件升级包;
若是,则以所述升级数据集作为分包单元,根据预设压缩率以及预设分包要求,将所有所述分包单元打包成多个所述固件升级包,包括:
根据所述预设分包要求对各个所述分包单元进行分组,以确定预设数量个数据组,每个所述数据组对应一个所述固件升级包;根据所述预设压缩率以及在同一个所述数据组中的各个所述分包单元的数据量,确定各个所述固件升级包所占的所述存储空间;判断所述存储空间与所述解压粒度上限值之和是否大于所述目标存储容量;若是,则增大所述预设数量,并重新进行分组,直至所述存储空间与所述解压粒度上限值之和小于或等于所述目标存储容量;若否,则根据所述预设压缩率将各个所述数据组封装成各个所述固件升级包;
根据所述传输方式向各个所述待升级终端传输对应的所述固件升级包,以使所述待升级终端根据所述解压方式以及所述固件升级包,分多次将一个或多个待升级固件升级为对应的目标固件。
10.一种电子设备,其特征在于,包括:
处理器;以及,
存储器,用于存储所述处理器的计算机程序;
其中,所述处理器配置为经由执行所述计算机程序来执行权利要求1至8任一项所述的固件升级方法。
11.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至8任一项所述的固件升级方法。
CN202210194739.5A 2022-03-02 2022-03-02 固件升级方法、装置、设备及存储介质 Active CN114265606B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210194739.5A CN114265606B (zh) 2022-03-02 2022-03-02 固件升级方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210194739.5A CN114265606B (zh) 2022-03-02 2022-03-02 固件升级方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN114265606A CN114265606A (zh) 2022-04-01
CN114265606B true CN114265606B (zh) 2022-05-10

Family

ID=80833913

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210194739.5A Active CN114265606B (zh) 2022-03-02 2022-03-02 固件升级方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN114265606B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110737455A (zh) * 2019-10-29 2020-01-31 迈普通信技术股份有限公司 固件的更新方法、装置及电子设备
CN112148337A (zh) * 2020-09-09 2020-12-29 杭州涂鸦信息技术有限公司 一种固件升级方法及装置
CN113704177A (zh) * 2021-07-30 2021-11-26 苏州浪潮智能科技有限公司 一种服务器固件升级文件的存储方法、系统及相关组件
CN114020526A (zh) * 2021-10-22 2022-02-08 深圳市有方科技股份有限公司 一种固件升级方法、装置及计算机存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10521213B2 (en) * 2015-12-17 2019-12-31 Time Warner Cable Enterprises Llc Technique for efficiently upgrading software in a video content network
CN110865837B (zh) * 2019-11-14 2023-08-18 青岛海信移动通信技术有限公司 一种进行系统升级的方法和终端
CN113127028A (zh) * 2020-01-14 2021-07-16 启碁科技股份有限公司 固件更新方法和固件更新系统
CN111796853A (zh) * 2020-07-16 2020-10-20 深圳市千分一智能技术有限公司 固件升级方法、系统、设备及计算机存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110737455A (zh) * 2019-10-29 2020-01-31 迈普通信技术股份有限公司 固件的更新方法、装置及电子设备
CN112148337A (zh) * 2020-09-09 2020-12-29 杭州涂鸦信息技术有限公司 一种固件升级方法及装置
CN113704177A (zh) * 2021-07-30 2021-11-26 苏州浪潮智能科技有限公司 一种服务器固件升级文件的存储方法、系统及相关组件
CN114020526A (zh) * 2021-10-22 2022-02-08 深圳市有方科技股份有限公司 一种固件升级方法、装置及计算机存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"一种改进的固件增量更新算法";王豫新 等;《计算机工程》;20201031;第46卷(第10期);第210-215页 *

Also Published As

Publication number Publication date
CN114265606A (zh) 2022-04-01

Similar Documents

Publication Publication Date Title
US8719810B2 (en) Program upgrade system and method for over the air-capable mobile terminal
US7793283B2 (en) Communication terminal software updating method, communication terminal, and software updating method
CN110597542B (zh) 软件自动ota升级方法及装置、电子设备
CN111414185B (zh) 一种终端升级方法、装置、终端及存储介质
CN109558160A (zh) 升级方法、嵌入式系统
CN103353844A (zh) 一种软件开发工具包升级方法和系统
CN104375849A (zh) 加载内核的方法及装置
CN106951284B (zh) 基于安卓系统应用的用户界面升级方法、装置及智能终端
CN111427596A (zh) 一种软件升级的方法、装置及终端设备
CN114257551A (zh) 一种分布式限流的方法及系统、存储介质
CN112152846B (zh) 一种基于物联网的计量仪表远程升级方法
CN112988169A (zh) 应用安装方法、装置、终端设备、服务器及存储介质
CN114265606B (zh) 固件升级方法、装置、设备及存储介质
KR100653280B1 (ko) 어플리케이션의 업데이트 가능한 휴대전화 및 업데이트 방법
CN107124446A (zh) 应用程序下载方法、服务器及终端
CN110007946B (zh) 一种算法模型的更新方法、装置、设备及介质
CN107908430B (zh) 一种配置pos文件系统的方法及pos机
CN115878226A (zh) 一种h5离线包加载方法及装置
CN115357260A (zh) 终端设备的程序升级方法、装置、终端设备和存储介质
CN111176693B (zh) 一种数字电视系统的升级方法
CN114296764A (zh) 系统升级方法、装置、存储介质和电子设备
CN112379902A (zh) 适配多种末端设备的方法、设备和计算机可读存储介质
CN110825406A (zh) 一种软件升级的方法及相关设备
CN111142913A (zh) 面向iOS系统应用程序的热更新方法和设备
KR100762618B1 (ko) 이동통신 단말기에서 펌웨어 업그레이드 엔진을업그레이드하는 방법 및 시스템

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant