升级方法、设备及存储介质转让专利

申请号 : CN202210390468.0

文献号 : CN115562697B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 赵文振

申请人 : 荣耀终端有限公司

摘要 :

本申请提供了一种升级方法、设备及存储介质。通过设置内卡升级条件,并在确定本次升级是否满足内卡升级条件时,先根据第一分区表将第一升级包中的除用户数据之外的分区对应的镜像文件写入存储器中对应的分区,再根据第二分区表升级第一分区表,并根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系,进而在格式用户数据分区后,根据映射关系创建格式化后的用户数据分区对应的文件系统,从而克服了内卡升级需要克服分区变化之后第一升级包无法找到的问题,使得电子设备从烧片版本升级到用户版时,既可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,又可以克服外部存储设备传输速度的限制。

权利要求 :

1.一种升级方法,其特征在于,应用于电子设备,所述方法包括:

响应于接收到的升级指令,进入工程模式;

获取升级标志位,所述升级标志位用于指示本次升级的升级方式;

在所述升级标志位指示本次升级的升级方式为外卡升级,且所述电子设备的存储器的用户数据分区中存在第一升级包时,根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级,所述内卡升级为从所述用户数据分区加载升级数据的升级方式,所述外卡升级为从挂载在所述电子设备的外部存储设备中加载升级数据的升级方式;

在确定本次升级满足内卡升级时,根据所述第一分区表,将所述第一升级包中除所述用户数据分区之外的分区对应的镜像文件写入所述存储器中对应的分区;

根据所述第二分区表升级所述第一分区表;

根据升级后的所述第一分区表重新创建所述存储器中分区的设备节点与所述存储器之间的映射关系;

格式化所述用户数据分区,并根据所述映射关系创建格式化后的所述用户数据分区对应的文件系统。

2.根据权利要求1所述的方法,其特征在于,

所述第一分区表中记录了系统分区的分区信息、烧片版本对应的专有分区的分区信息和所述用户数据分区的分区信息,所述系统分区的分区信息、所述专有分区的分区信息和所述用户数据分区的分区信息,按照所述系统分区、所述专有分区、所述用户数据分区的顺序记录在所述第一分区表中;

所述第二分区表中记录了所述系统分区的分区信息和所述用户数据分区的分区信息,所述系统分区的分区信息和所述用户数据分区的分区信息,按照所述系统分区、所述用户数据分区的顺序记录在所述第二分区表中;

其中,所述第一分区表对应于烧片版本,所述第二分区表对应于用户版本,所述系统分区为所述烧片版本和所述用户版本均有的分区。

3.根据权利要求2所述的方法,其特征在于,所述根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级,包括:根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的所述系统分区的分区信息是否与所述第一分区表中记录的所述系统分区的分区信息相同;

在所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息相同时,确定本次升级满足所述内卡升级;

在所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息不相同时,确定本次升级不满足所述内卡升级。

4.根据权利要求3所述的方法,其特征在于,所述根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的所述系统分区的分区信息是否与所述第一分区表中记录的所述系统分区的分区信息相同,包括:根据所述存储器中存储的第一分区表中记录的分区信息,确定所述第一分区表中记录的所述系统分区的第一起始位置和占用的第一空间大小;

根据所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的所述系统分区的第二起始位置和占用的第二空间大小;

在所述第一起始位置与所述第二起始位置相同,且所述第一空间大小与所述第二空间大小相同时,确定所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息相同;

否则,确定所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息不相同。

5.根据权利要求3所述的方法,其特征在于,所述根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的所述系统分区的分区信息是否与所述第一分区表中记录的所述系统分区的分区信息相同,包括:根据所述存储器中存储的第一分区表中记录的分区信息,确定所述第一分区表中记录的所述系统分区的第一起始位置和第一结束位置;

根据所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的所述系统分区的第二起始位置和第二结束位置;

在所述第一起始位置与所述第二起始位置相同,且所述第一结束位置与所述第二结束位置相同时,确定所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息相同;

否则,确定所述第二分区表中记录的所述系统分区的分区信息与所述第一分区表中记录的所述系统分区的分区信息不相同。

6.根据权利要求2所述的方法,其特征在于,所述根据升级后的所述第一分区表重新创建所述存储器中分区的设备节点与所述存储器之间的映射关系,包括:根据升级后的所述第一分区表中记录的所述系统分区的分区信息,重新创建所述存储器中的所述系统分区的设备节点与所述存储器之间的映射关系;

根据升级后的所述第一分区表中记录的所述用户数据分区的分区信息,重新创建所述存储器中的所述用户数据分区的设备节点与所述存储器之间的映射关系,将所述专有分区所占的空间合并到所述用户数据分区。

7.根据权利要求1至6任一项所述的方法,其特征在于,所述升级标志位记录在所述存储器的misc分区中,所述misc分区用于记录系统设置信息;

在所述根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级之前,所述方法还包括:对所述misc分区中记录的所述升级标志位进行替换,替换后的所述升级标志位用于指示本次升级的升级方式为所述内卡升级。

8.根据权利要求7所述的方法,其特征在于,所述方法还包括:

在确定本次升级不满足所述内卡升级时,结束本次升级;

在结束本次升级后,若重新接收到所述升级指令,响应于所述升级指令,重新进入所述工程模式;

从所述misc分区中读取替换后的所述升级标志位,从所述用户数据分区获取所述第一升级包,执行所述根据所述存储器中存储的第一分区表中记录的分区信息和所述第一升级包中存储的第二分区表中记录的分区信息,确定所述第二分区表中记录的系统分区的分区信息是否与所述第一分区表中记录的系统分区的分区信息相同的步骤。

9.根据权利要求8所述的方法,其特征在于,在所述根据所述映射关系创建格式化后的所述用户数据分区对应的文件系统之后,所述方法还包括:清除所述misc分区中记录的所述升级标志位。

10.根据权利要求1至6任一项所述的方法,其特征在于,所述方法还包括:在所述升级标志位指示本次升级的升级方式为所述外卡升级,且所述用户数据分区中不存在所述第一升级包时,挂载外部存储设备;

在所述外部存储设备挂载成功后,从所述外部存储设备中加载第二升级包中的第三分区表;

根据所述第三分区表升级所述第一分区表;

根据升级后的所述第一分区表中记录的分区信息重新创建所述存储器中分区的设备节点与所述存储器之间的映射关系;

将所述第二升级包中每一个分区对应的镜像文件写入所述存储器中对应的分区。

11.一种电子设备,其特征在于,所述电子设备包括:存储器和处理器,所述存储器和所述处理器耦合;所述存储器存储有程序指令,所述程序指令由所述处理器执行时,使得所述电子设备执行如权利要求1至10任意一项所述的升级方法。

12.一种计算机可读存储介质,其特征在于,包括计算机程序,当所述计算机程序在电子设备上运行时,使得所述电子设备执行如权利要求1至10任意一项所述的升级方法。

说明书 :

升级方法、设备及存储介质

技术领域

[0001] 本申请涉及电子技术领域,尤其涉及一种升级方法、设备及存储介质。

背景技术

[0002] 众所周知,目前的电子设备,例如智慧屏、手机、平板电脑、个人计算机(Personal Computer,PC设备)等都有内部存储器(俗陈:闪存)。根据不同产品的配置和需求,闪存的容量大小不等,为了方便管理和维护,在使用时,闪存通常会被分成多个区域,这个过程我们把它叫做“分区”。分区既可以让系统分区和用户数据分区相互隔离,也可以增强系统稳定性。以Android平台设计开发的电子设备为例,目前对此类电子设备的闪存进行分区时,通常是依据全局唯一标识分区表(GUID Partition Table,GPT分区表)。
[0003] 对于以Android平台设计开发的电子设备,例如智慧屏,其在生产线上使用的版本(后续称为:烧片版本)和出厂时的商用版本(后续称为:用户版本)的GPT分区表是不一致的,因此在从烧片版本升级到用户版本时,为了保证升级包中的各个分区的镜像文件能够准确的写入对应的分区,目前采用的升级方案是将升级包存储在外部存储设备,例如安全数码卡(Secure Digital Memory Card,SD卡)、USB闪存盘(U盘)中,然后根据外部存储设备中升级包的分区表对设备中存储的分区表进行升级,再将升级包中各分区的镜像文件写入设备中重新划分的分区中。虽然这种方案可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,但是由于SD卡、U盘等外部存储设备的读取速度有限,特别是许多芯片不支持USB3.0接口,这就导致实际的读取速度只有20MB/s,而升级包的大小通常约2G左右。并且对于智慧屏这种体积较大,且没有内置电池的电子设备,在从烧片版本升级到用户版本时,一条流水线能同时摆放的智慧屏数量有限,因此会影响单位小时产能(units per hour,UPH),进而导致生产成本提高。
[0004] 因此,亟需提供一种升级方案,以使电子设备从烧片版本升级到用户版时,能够解决上述技术问题。

发明内容

[0005] 为了解决上述技术问题,本申请提供一种升级方法、设备及存储介质,旨在使电子设备从烧片版本升级到用户版时,既可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,又可以克服SD卡、U盘等外部存储设备传输速度的限制。
[0006] 第一方面,本申请提供一种升级方法。该方法应用于电子设备,包括:响应于接收到的升级指令,进入工程模式;获取升级标志位,升级标志位用于指示本次升级的升级方式;在升级标志位指示本次升级的升级方式为外卡升级,且电子设备的存储器的用户数据分区中存在第一升级包时,根据储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级,内卡升级为从用户数据分区加载升级数据的升级方式,外卡升级为从挂载在电子设备的外部存储设备中加载升级数据的升级方式;在确定本次升级满足内卡升级时,根据第一分区表,将第一升级包中除用户数据分区之外的分区对应的镜像文件写入存储器中对应的分区;根据第二分区表升级第一分区表;根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系;格式化用户数据分区,并根据映射关系创建格式化后的用户数据分区对应的文件系统。由此,通过设置内卡升级条件,并在确定本次升级是否满足内卡升级条件时,先根据第一分区表将第一升级包中的除用户数据之外的分区对应的镜像文件写入存储器中对应的分区,再根据第二分区表升级第一分区表,并根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系,进而在格式用户数据分区后,根据映射关系创建格式化后的用户数据分区对应的文件系统,从而克服了内卡升级需要克服分区变化之后第一升级包无法找到的问题,使得电子设备从烧片版本升级到用户版时,既可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,又可以克服SD卡、U盘等外部存储设备传输速度的限制。
[0007] 此外,通过将第一升级包存储在电子设备的存储器的用户数据分区中,使得升级操作无需插拔外部存储设备,简化了用户操作,并且稳定性更高。
[0008] 根据第一方面,第一分区表中记录了系统分区的分区信息、烧片版本对应的专有分区的分区信息和用户数据分区的分区信息,系统分区的分区信息、专有分区的分区信息和用户数据分区的分区信息,按照系统分区、专有分区、用户数据分区的顺序记录在第一分区表中;第二分区表中记录了系统分区的分区信息和用户数据分区的分区信息,系统分区的分区信息和用户数据分区的分区信息,按照系统分区、用户数据分区的顺序记录在第二分区表中;其中,第一分区表对应于烧片版本,第二分区表对应于用户版本,系统分区为烧片版本和用户版本均有的分区。这样,通过将烧片版本中特有的专有分区放到用户数据分区前面,并紧挨着用户数据分区,其余的系统分区保持和用户版本的位置一直,从而在采用内卡升级升级用户数据分区前的系统分区时就可以保证即使不升级第一分区表,升级到用户版本后也不会出现分区和镜像文件位置不匹配的问题。
[0009] 根据第一方面,或者以上第一方面的任意一种实现方式,根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级,包括:根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同;在第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同时,确定本次升级满足内卡升级;在第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同时,确定本次升级不满足内卡升级。
[0010] 根据第一方面,或者以上第一方面的任意一种实现方式,根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同,包括:根据存储器中存储的第一分区表中记录的分区信息,确定第一分区表中记录的系统分区的第一起始位置和占用的第一空间大小;根据第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的第二起始位置和占用的第二空间大小;在第一起始位置与第二起始位置相同,且第一空间大小与第二空间大小相同时,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同;否则,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同。这样,根据每个系统分区的起始位置和空间大小便可以确定第一分区表中记录的系统分区的分区信息和第二分区表中记录的系统分区的分区信息是否相同。
[0011] 根据第一方面,或者以上第一方面的任意一种实现方式,根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同,包括:根据储器中存储的第一分区表中记录的分区信息,确定第一分区表中记录的系统分区的第一起始位置和第一结束位置;根据第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的第二起始位置和第二结束位置;在第一起始位置与第二起始位置相同,且第一结束位置与第二结束位置相同时,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同;否则,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同。这样,根据每个系统分区的起始位置和结束位置便可以确定第一分区表中记录的系统分区的分区信息和第二分区表中记录的系统分区的分区信息是否相同。
[0012] 根据第一方面,或者以上第一方面的任意一种实现方式,根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系,包括:根据升级后的第一分区表中记录的系统分区的分区信息,重新创建存储器中的系统分区的设备节点与存储器之间的映射关系;根据升级后的第一分区表中记录的用户数据分区的分区信息,重新创建存储器中的用户数据分区的设备节点与存储器之间的映射关系,将专有分区所占的空间合并到用户数据分区。由于,用户数据分区可以不升级镜像文件,直接格式化并创建文件系统,因此通过将烧片版本下特有的专有分区合并到用户数据分区,就可以采用内卡升级快速、高效的完成烧片版本到用户版本的升级。
[0013] 根据第一方面,或者以上第一方面的任意一种实现方式,升级标志位记录在存储器的misc分区中,misc分区用于记录系统设置信息;在根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级之前,方法还包括:对misc分区中记录的升级标志位进行替换,替换后的升级标志位用于指示本次升级的升级方式为内卡升级。这样,如果中断了从烧片版本升级到用户版本的流程,在下次重新触发后,便可以按照内卡升级流程进行升级,无需再次判断,简化了处理流程。
[0014] 根据第一方面,或者以上第一方面的任意一种实现方式,在确定本次升级不满足内卡升级时,结束本次升级;在结束本次升级后,若重新接收到升级指令,响应于升级指令,重新进入工程模式;从misc分区中读取替换后的升级标志位,从用户数据分区获取第一升级包,执行根据储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同的步骤。这样,如果中断了从烧片版本升级到用户版本的流程,在下次重新触发后,便可以按照内卡升级流程进行升级,无需再次判断,简化了处理流程。
[0015] 根据第一方面,或者以上第一方面的任意一种实现方式,在根据映射关系创建格式化后的用户数据分区对应的文件系统之后,方法还包括:清除misc分区中记录的升级标志位。这样,在从烧片版本升级到用户版本后,通过清除misc分区中记录的升级标志位,在电子设备出厂投入使用后,就不会因为用户的操作,导致电子设备执行该升级流程。
[0016] 根据第一方面,或者以上第一方面的任意一种实现方式,该方法还包括:在升级标志位指示本次升级的升级方式为外卡升级,且用户数据分区中不存在第一升级包时,挂载外部存储设备;在外部存储设备挂载成功后,从外部存储设备中加载第二升级包中的第三分区表;根据第三分区表升级第一分区表;根据升级后的第一分区表中记录的分区信息重新创建存储器中分区的设备节点与存储器之间的映射关系;将第二升级包中每一个分区对应的镜像文件写入存储器中对应的分区。这样,在无法采用内卡升级时,通过加载外部存储设备,从外部存储设备中读取升级包中的升级数据,如第三分区表、分区的镜像文件,从而能够保证电子设备无论是否支持内卡升级,都能够将电子设备从烧片版本升级到用户版本,保证升级成功。
[0017] 第二方面,本申请提供了一种电子设备。该电子设备包括:存储器和处理器,存储器和处理器耦合;存储器存储有程序指令,程序指令由处理器执行时,使得所述电子设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
[0018] 第三方面,本申请提供了一种计算机可读介质,用于存储计算机程序,该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
[0019] 第四方面,本申请提供了一种计算机程序,该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
[0020] 第五方面,本申请提供了一种芯片,该芯片包括处理电路、收发管脚。其中,该收发管脚、和该处理电路通过内部连接通路互相通信,该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法,以控制接收管脚接收信号,以控制发送管脚发送信号。

附图说明

[0021] 图1是示例性示出的一种电子设备的硬件结构示意图;
[0022] 图2是示例性示出的本申请的一种实施例提供的升级方法的流程示意图;
[0023] 图3是示例性示出的本申请的又一种实施例提供的升级方法的流程示意图;
[0024] 图4是示例性示出的外卡升级的流程示意图;
[0025] 图5是示例性示出的满足内卡升级条件的示意图;
[0026] 图6是示例性示出的第一分区表中记录的分区信息的示意图;
[0027] 图7是示例性示出的解析前第二分区表内分区信息格式的示意图;
[0028] 图8是示例性示出的解析后第二分区表内分区信息格式的示意图;
[0029] 图9是示例性示出的根据第二分区表对第一分区表升级的示意图。

具体实施方式

[0030] 下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
[0031] 本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。
[0032] 本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象,而不是用于描述对象的特定顺序。例如,第一目标对象和第二目标对象等是用于区别不同的目标对象,而不是用于描述目标对象的特定顺序。
[0033] 在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
[0034] 在本申请实施例的描述中,除非另有说明,“多个”的含义是指两个或两个以上。例如,多个处理单元是指两个或两个以上的处理单元;多个系统是指两个或两个以上的系统。
[0035] 为了更好的理解本申请提供的技术方案,在对本申请实施例的技术方案说明之前,首先对当前将电子设备,例如智慧屏(以开机无广告为前提的涵盖芯片、画质、音质、内容和智慧在内电子设备)从烧片版本升级到用户版本的升级流程进行说明。具体的,在烧片版本下,智慧屏因为涉及到测试流程,因此智慧屏的分区表中除了会记录与用户版本均有的系统分区的分区信息、用户数据分区的分区信息,还会记录专门记录这些测试信息的分区(后续称为:专有分区)的分区信息,即在烧片版本下,智慧屏的存储器(后续称为:闪存,或flash)除了划分有系统分区、用户数据分区,还会划分有专有分区。而这些专有分区在出厂后,即升级到用户版本后是不需要有的,所以在出厂前必须将智慧屏从烧片版本升级到用户版本,去掉这些专有分区。也就是说,烧片版本下的分区表中记录的分区信息和用户版本下的分区表中记录的分区信息是不一致的,因此在将各分区的镜像文件写入flash中的分区前,需要将智慧屏中的分区表更新成用户版本对应的分区表,再进行镜像文件的写入,这样才能保证将镜像文件写入到正确的位置。由于智慧屏内只有用户数据分区(userdata分区)可以存放升级包,而userdata分区通常是最后一个分区,在userdata分区之前,烧片版本比用户版本多了几个专有分区,并且这些专有分区占用的空间较大,在升级到用户版本的时候必须对这些专有分区进行回收(回收后这些专有分区占用的空间就作为userdata分区的一部分),因此烧片版本和用户版本的userdata分区的位置肯定是不一样的,一旦在升级前进行分区的变更,就会导致重新挂载userdata分区之后新的文件系统无法找到旧的文件系统下的文件,因此当前采用USB口插U盘(或者外部存储且接口插SD卡)的方式(后续称为外卡升级)进行升级,将升级包放置到U盘、SD卡等外部存储设备中,这样即使分区位置发生变化也可以进行升级。
[0036] 需要说明的是,虽然采用外卡升级可以实现分区表的变化(因为升级包不在userdata分区,分区表更新后,依旧是从外部存储设备读取升级数据,如镜像文件,因此不会存在找不到升级包的情况),但是由于外部存储设备,如U盘的读取速度有限,特别是许多芯片不支持USB3.0接口,这就导致实际的读取速度只有20MB/s,而升级包的大小通常约2G左右。并且在升级的过程中,需要先对升级包进行校验再进行升级,这就需要对升级包进行两次读取操作,20MB/s的读写速度就会导致升级时间过长,进而影响产线的升级效率。此外,对于智慧屏这种体积较大,且没有内置电池的电子设备,在从烧片版本升级到用户版本时,一条流水线能同时摆放的智慧屏数量有限,因此会影响单位小时产能(units per hour,UPH),进而导致生产成本提高。但是智慧屏内的flash,不论是嵌入式多媒体卡(Embedded Multi Media Card,emmc)flash,还是通用闪存(Univeral Flash Storage,ufs)flash,均具有较高的读写速度(通常可以达到100MB/s,甚至更快),因此,将升级包放到flash中进行升级(后续称为:内卡升级),便可以克服外部存储设备传输速度的限制,同时减少外部存储设备的插拔,使得用户操作更加方便,稳定性更高。但是内卡升级需要克服分区变化之后升级包无法找到的问题。
[0037] 故而,为了解决这一问题,提出了本申请提供的升级方法,以使电子设备从烧片版本升级到用户版时,既可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,又可以克服SD卡、U盘等外部存储设备传输速度的限制。
[0038] 示例性的,关于本申请提供的技术方案适用于的电子设备,例如可以是智慧屏、手机、平板、PC机等,其硬件结构例如图1所示。
[0039] 示例性的,参见图1,电子设备100可以包括:处理器110,外部存储器接口120,内部存储器121,通用串行总线(universal serial bus,USB)接口130,充电管理模块140,电源管理模块141,电池142,天线1,天线2,移动通信模块150,无线通信模块160,音频模块170,传感器模块180,按键190,马达191,指示器192,摄像头193,显示屏194,以及用户标识模块(subscriber identification module,SIM)卡接口195等。
[0040] 示例性的,具体到本申请实施例提供的技术方案中,将电子设备在生产线上使用的烧片版本升级到用户版本时,升级包具体是预先存储在内部存储器121,即flash中的。
[0041] 此外,为了保证在内部存储器121中存储的升级包无法使用,或者没有存在升级包的情况下,依旧能将电子设备从烧片版本升级到用户版本,也可以预先在外部存储设备中存储升级包。
[0042] 示例性的,在实际应用中,外部存储设备例如可以是安全数码卡(Secure Digital Memory Card,SD卡)、USB闪存盘(U盘)、OTG(Over‑the‑Go)等。
[0043] 示例性的,在外部存储设备为SD卡时,SD卡可以通过外部存储器接口120接入电子设备,以使升级过程中,电子设备能够从SD卡读取到升级包中的数据,例如分区表,以及分区表中记录的分区对应的配置信息。
[0044] 示例性的,在外部存储设备为U盘时,U盘可以通过USB接口130接入电子设备,以使升级过程中,电子设备能够从U盘读取到升级包中的数据,例如分区表,以及分区表中记录的分区对应的配置信息。
[0045] 此外,需要说明的是,所谓OTG,具体是指应用于不同的设备或移动设备间的联接,主要用于进行数据交互,在本申请中,OTG可以理解为U盘。故而,关于使用OTG完成升级的方式,可以参见使用U盘完成升级的方式,此处不再赘述。
[0046] 此外,应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0047] 此外,需要说明的是,在实际应用中,音频模块170例如可以包括扬声器170A、受话器170B、麦克风170C、耳机接口170D等。
[0048] 示例性的,传感器模块180例如可以包括压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器等。
[0049] 此外,还需要说明的是,在实际应用中,按键190例如可以包括电源键(开机键),起始键(home键)、音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入,产生与电子设备100的用户设置以及功能控制有关的键信号输入。
[0050] 示例性的,具体到本申请实施例提供的技术方案中,触发电子设备进入工程模式(Recovery模式)从烧片版本升级到用户版本的方式,例如可以是同时长按home键和开机键(例如同时长按5秒),或者通过建立通信连接的PC设备向电子设备发送升级指令,此处不再一一列举,本申请对此不做限制。
[0051] 示例性的,在实际应用中,PC设备与电子设备之间建立的通信连接,例如可以是通过网线、USB数据线等有线连接方式建立,或者是通过蓝牙、无线保真(WI‑FI)、近场通讯(Near Field Communication,NFC)等无线链接方式建立,此处不再一一列举,本申请对此不做限制。
[0052] 此外,还需要说明的是,在实际应用中,处理器110可以包括一个或多个处理单元,例如:处理器110可以包括应用处理器(application processor,AP),调制解调处理器,图形处理器(graphics processing unit,GPU),图像信号处理器(image signal processor,ISP),控制器,存储器,视频编解码器,数字信号处理器(digital signal processor,DSP),基带处理器,和/或神经网络处理器(neural‑network processing unit,NPU)等。
[0053] 可理解的,在具体实现中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
[0054] 此外,在一些实现方式中,控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
[0055] 此外,处理器110中的存储器主要用于存储指令和数据。在一些实现方式中,处理器110中的存储器为高速缓冲存储器。
[0056] 此外,可理解的,在实际的应用场景中,触发电子设备100实现各种功能应用以及数据处理的可执行程序代码是存储在内部存储器121中的,这些可执行程序代码包括指令。
[0057] 关于电子设备100的硬件结构就介绍到此,应当理解的是,图1所示电子设备100仅是一个范例,在具体实现中,电子设备100可以具有比图中所示的更多的或者更少的部件,可以组合两个或多个的部件,或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
[0058] 下面对本申请提供的技术方案的实现细节进行说明,以下内容仅为方便理解而提供的实现细节,并非实施本方案的必须。
[0059] 示例性的,参见图2,本实施例的具体实现步骤包括:
[0060] 步骤101,响应于接收到的升级指令,进入工程模式。
[0061] 可理解的,本实施例中的升级指令具体是用于触发电子设备进入工程模式(Recovery模式,也称恢复模式)的指令。在实际应用中,升级指令例如可以是由与电子设备建立通信连接的PC设备发送给电子设备的,或者可以是电子设备的特定按键组合生成,例如home键和开机键被同时长按时,电子设备生成的。
[0062] 示例性的,在实际应用中,当电子设备响应于接收到的升级指令时,会重启电子设备,并在重启过程中选择进入Recovery模式。
[0063] 相应地,在进入Recovery模式后,电子设备便可以根据升级标志位指示的升级方式从对应的存储位置(如外部存储设备,或者用户数据分区)中存储的升级包中获取用户版本对应的分区表,从而根据用户版本对应的分区表和当前存储的烧片版本对应的分区表,将电子设备从烧片版本升级到用户版本。
[0064] 示例性的,在实际应用中,外部存储设备例如可以是安全数码卡(Secure Digital Memory Card,SD卡)、USB闪存盘(U盘)、OTG等。
[0065] 此外,需要说明的是,在进入Recovery模式后,Recovery进程会被启动,即本实施提供的升级方法具体是由Recovery进程完成的。
[0066] 此外,为了便于说明本实施例提供的技术方案,后续将存储在电子设备的存储器中的分区表称为第一分区表,将存储在内部存储器121的升级包称为第一升级包,将第一升级包中的分区表称为第二分区表,将存储在外部存储器中的升级包称为第二升级包,将第二升级包中的分区表称为第三分区表。
[0067] 步骤102,获取升级标志位。
[0068] 具体的说,本实施例中所说的升级标志位是记录在flash的misc分区中的,其用于指示本次升级的升级方式。
[0069] 可理解的,misc分区中有引导加载程序控制块(Bootloader Control Block,BCB),主要是用于存放Recovery引导信息,以及ON/OFF开关的系统设置信息等。因此,电子设备进入Recovery模式后,Recovery进程便会从misc分区读取存放的Recovery引导信息,也就是本实施例中所说的升级标志位。
[0070] 此外,需要说明的是,关于电子设备首次进入Recovery模式,Recovery进程从misc分区读取的升级标志位是电子设备在正常启动模式(依次加载基础分区(common分区)的数据、静态分区的数据、动态分区(super分区)的数据使电子设备运行到升级前的烧片版本对应的操作系统)下写入misc分区的。
[0071] 示例性的,在一些实现方式中,可以约定不同的升级标志位对应不同的升级方式,例如约定升级标志位“factory_sd_update”指示升级方式为外卡升级,即从烧片版本升级到用户版本的过程中,Recovery进程需要从挂载在电子设备的外部存储设备,例如SD卡、U盘、OTG中加载升级数据(分区表、分区对应的镜像文件等)的升级方式。
[0072] 示例性的,在另一些实现方式中,可以约定升级标志位“factory_flash_update”指示升级方式为内卡升级,即从烧片版本升级到用户版本的过程中,Recovery进程需要从flash的用户数据分区加载升级数据(分区表、分区对应的镜像文件等)的升级方式。
[0073] 示例性的,在另一些实现方式中,可以约定升级标志位“factory_ota_update”指示升级方式为OTA升级,这种升级方式通常是在电子设备升级到用户版本后,对用户版本的迭代升级,或者是在烧片版本下对烧片版本的迭代升级。
[0074] 示例性的,在另一些实现方式中,可以约定升级标志位“factory_reset”指示工厂复位。
[0075] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0076] 此外,需要说明的是,为了使得本实施例提供的升级方案能够兼容现有通过挂载外部存储设备,并加载外部存储设备中的升级数据将电子设备从烧片版本升级到用户版本的方式,可以约定电子设备首次进入Recovery模式,Recovery进程从misc分区读取的升级标志位不包括“factory_flash_update”这一针对本实施例提供的内卡升级的升级标志位,而是在升级标志位是指示外卡升级的“factory_sd_update”时,进一步判断用户数据分区是否存在升级使用的第一升级包来确定本次升级是否可以从外卡升级改为内卡升级。这样,无需改变现有进入Recovery模式,触发从烧片版本升级到用户版本的流程便可以做到既兼顾外卡升级的方案,又兼顾内卡升级的方案。
[0077] 步骤103,在升级标志位指示本次升级的升级方式为外卡升级,且电子设备的存储器的用户数据分区中存在第一升级包时,根据储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级。
[0078] 示例性的,在本实施例中,第一分区表中记录了系统分区的分区信息、烧片版本对应的专有分区(例如版本测试时需要用到的分区)的分区信息和用户数据分区的分区信息,系统分区的分区信息、专有分区的分区信息和用户数据分区的分区信息,按照系统分区、专有分区、用户数据分区的顺序记录在第一分区表中;第二分区表中记录了系统分区的分区信息和用户数据分区的分区信息,系统分区的分区信息和用户数据分区的分区信息,按照系统分区、用户数据分区的顺序记录在第二分区表中。
[0079] 此外,可理解的,在本实施例中,第一分区表对应于烧片版本,第二分区表对应于用户版本,系统分区为烧片版本和用户版本均有的分区。
[0080] 示例性的,在一些实现方式中,系统分区例如可以包括存放引导程序的mboot分区、存放启动项的设置信息的boot分区、存放系统核心数据的super分区、存放版本信息的version分区、存放预加载信息的preload分区等,此处不再一一列举。
[0081] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0082] 示例性的,为了保证采用内卡升级时,能够克服分区变化之后升级包无法找到的问题,本实施例规定第一分区表中记录的分区信息和第二分区表中记录的分区信息按照上述规定顺序记录,并且由于用户数据分区可以不进行镜像文件的写入,因此在确定本次升级是否满足内卡升级时,可以直接根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同。
[0083] 相应地,在第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同时,确定本次升级满足内卡升级;在第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同时,确定本次升级不满足内卡升级。
[0084] 可理解的,关于判定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同的方式,可以遵循两个分区表中记录的系统分区所在位置和所占的空间大小相同。
[0085] 示例性的,在一些实现方式中,可以通过比较两个分区表中记录的每一系统分区的起始位置和所占的空间大小来确定两个分区表中记录的系统分区的分区信息是否相同。具体的实现方式,例如可以是:先根据存储器中存储的第一分区表中记录的分区信息,确定第一分区表中记录的系统分区的第一起始位置和占用的第一空间大小,以及根据第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的第二起始位置和占用的第二空间大小;然后分别比较两个起始位置和空间大小,在第一起始位置与第二起始位置相同,且第一空间大小与第二空间大小相同时,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同;否则,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同。
[0086] 示例性的,在另一些实现方式中,可以通过比较两个分区表中记录的每一系统分区的起始位置和结束位置来确定两个分区表中记录的系统分区的分区信息是否相同。具体的实现方式,例如可以是:先根据储器中存储的第一分区表中记录的分区信息,确定第一分区表中记录的系统分区的第一起始位置和第一结束位置,以及根据第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的第二起始位置和第二结束位置;而安好分别比较两个起始位置和结束位置,在第一起始位置与第二起始位置相同,且第一结束位置与第二结束位置相同时,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息相同;否则,确定第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息不相同。
[0087] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0088] 此外,需要说明的是,考虑到实际应用中可能存在升级过程中因为断电、升级包异常等原因导致升级中断,因此为了在已经确定用户数据分区存在升级包的情况下,在电子设备重新上电,更新升级包后,电子设备能够直接跳过前面步骤的判断,从用户数据分区获取第一升级包,进而判断第二分区表中记录的系统分区的分区信息与第一分区表中记录的系统分区的分区信息是否相同,以便直接采用内卡升级的方式完成后续升级,从而简化了处理流程。在升级标志位指示本次升级为外卡升级,且用户数据分区存在第一升级包时,Recovery进程在根据存储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定本次升级是否满足内卡升级之前,可以先对misc分区中记录的升级标志位进行替换。
[0089] 可理解的,在本实施例中,替换后的升级标志位具体是用于指示本次升级的升级方式为内卡升级的。
[0090] 示例性的,如果约定指示外卡升级的升级标志位为“factory_sd_update”,指示内卡升级的升级标志位为“factory_flash_update”,则本实施例中对misc分区中记录的升级标志位的替换,实质就是将“factory_sd_update”替换为“factory_flash_update”,这样如果中断了从烧片版本升级到用户版本的流程,在下次重新触发后,便可以按照内卡升级流程进行升级,无需再次判断,简化了处理流程。
[0091] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0092] 此外,需要说明的是,如果通过上述判断确定本次升级不满足内卡升级,由于已经进入到内卡升级的流程,因此这种情况下可以结束本次升级。
[0093] 相应地,在结束本次升级后,若重新接收到升级指令,电子设备响应于升级指令,重新进入工程模式。接着,Recovery进程会从misc分区中读取替换后的升级标志位,例如“factory_flash_update”,从用户数据分区获取第一升级包,然后执行根据储器中存储的第一分区表中记录的分区信息和第一升级包中存储的第二分区表中记录的分区信息,确定第二分区表中记录的系统分区的分区信息是否与第一分区表中记录的系统分区的分区信息相同的步骤。这样就可以跳过前面判断是否为外卡升级的步骤,从而简化了处理流程。
[0094] 此外,还需要说明的是,在一些实现方式中,可以设定在确定本次升级不满足内卡升级时,触发挂载外部存储设备,进而从外部存储设备加载第二升级包中的升级数据,将电子设备从烧片版本升级到用户版本的流程。
[0095] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0096] 此外,还需要说明的是,如果在升级标志位指示本次升级的升级方式为外卡升级,且用户数据分区中不存在第一升级包时,电子设备可以挂载外部存储设备,例如SD卡,或者U盘,或者OTG。
[0097] 相应地,在外部存储设备挂载成功后(任意一个挂载成功后即可),从外部存储设备中加载第二升级包中的第三分区表;然后根据第三分区表升级第一分区表,根据升级后的第一分区表中记录的分区信息重新创建存储器中分区的设备节点与存储器之间的映射关系,将第二升级包中每一个分区对应的镜像文件写入存储器中对应的分区。
[0098] 这样,在无法采用内卡升级时,通过加载外部存储设备,从外部存储设备中读取升级包中的升级数据,如第三分区表、分区的镜像文件,从而能够保证电子设备无论是否支持内卡升级,都能够将电子设备从烧片版本升级到用户版本,保证升级成功。
[0099] 步骤104,在确定本次升级满足内卡升级时,根据第一分区表,将第一升级包中除用户数据分区之外的分区对应的镜像文件写入存储器中对应的分区。
[0100] 具体的说,在确定本次升级满足内卡升级时,即第一分区表中记录的系统分区的分区信息与第二分区表中记录的系统分区的分区信息是相同的,因此无需更新第一分区表,根据flash当前存储的第一分区表便可以实现将第一升级包中除用户数据分区之外的分区对应的镜像文件写入flash中对应的分区。
[0101] 此外,可理解的,由于第一分区表中记录的系统分区的分区信息与第二分区表中记录的系统分区的分区信息是相同的,因此在一些实现方式中,也可以根据第二分区表将第一升级包中除用户数据分区之外的分区对应的镜像文件写入flash中对应的分区。
[0102] 此外,需要说明的是,由于用户版本对应的第二分区表中记录的是系统分区的分区信息和用户数据分区的分区信息,即没有烧片版本特有的专有分区的分区信息,因此上述所说的将第一升级包中除用户数据分区之外的分区对应的镜像文件写入flash中对应的分区,具体是指将第一升级包中各个系统分区对应的镜像文件写入到flash中对应的分区。
[0103] 例如,将启动相关镜像boot.img写入boot分区,将系统镜像super.img(集成了android系统核心)写入super分区。
[0104] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0105] 步骤105,根据第二分区表升级第一分区表。
[0106] 可理解的,由于第二分区表是存放在升级包中的,故而可能存在第二分区表中记录的分区信息的格式与第一分区表中记录的分区信息的格式不相同的情况。因此,为了能够根据第二分区表升级成功第一分区表,Recovery进程在根据第二分区表升级第一分区表时,可以先对第二分区表中记录的分区信息解析,然后根据解析后的第二分区表中记录的分区信息升级第一分区表中记录的分区信息。
[0107] 示例性的,在一些实现方式中,可以先确定第一分区表中记录的分区信息的格式,然后按照第一分区表中记录的分区信息的格式对第二分区表中记录的分区信息解析。
[0108] 示例性的,在另一些实现方式中,可以预先约定一种统一的格式,然后按照约定的统一格式,分别对第一分区表中记录的分区信息解析,对第二分区表中记录的分区信息解析,从而确保两张分区表中记录的分区信息的格式相同。
[0109] 此外,需要说明的是,通常情况下,在根据解析后的第二分区表中记录的分区信息升级第一分区表中记录的分区信息时,可以是直接将第二分区表中记录的分区信息替换第一分区表中记录的全部分区信息,也可以仅替换不同部分,例如保留第一分区表中记录的系统分区的分区信息不变,将其他分区(专有分区和用户数据分区)的分区信息替换为第二分区表中用户数据分区的分区信息。
[0110] 示例性的,替换的方式可以采用覆盖写的方式,或者先删除第一分区表中记录的全部分区信息,然后再将解析后的第二分区表中记录的分区信息写入第一分区表中,还或者直接将第一分区表从存储器中删除,然后将第二分区表整个存储到存储器中。
[0111] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0112] 此外,还应当理解的是,如果将电子设备从烧片版本升级到用户版本时采用的是外卡升级方式,则对第二升级包中第三分区表同样可以先进行格式转换,然后再执行根据第三分区表升级第一分区表的操作,关于格式转换的方式可以参见第二分区表的转换方式,此处不再赘述。
[0113] 相应地,根据第三分区表升级第一分区表的操作,可以是直接将第三分区表中记录的分区信息替换第一分区表中记录的全部分区信息,关于替换的方式可以参见将第二分区表中记录的分区信息替换第一分区表中记录的全部分区信息的方式,此处不再赘述。
[0114] 步骤106,根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系。
[0115] 需要说明的,在采用内卡升级的方式对第一分区表升级后,根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系具体分为如下两个步骤:(1)根据升级后的第一分区表中记录的系统分区的分区信息,重新创建存储器中的系统分区的设备节点与存储器之间的映射关系;(2)根据升级后的第一分区表中记录的用户数据分区的分区信息,重新创建存储器中的用户数据分区的设备节点与存储器之间的映射关系,将专有分区所占的空间合并到用户数据分区。由于,用户数据分区可以不升级镜像文件,直接格式化并创建文件系统,因此通过将烧片版本下特有的专有分区合并到用户数据分区,就可以采用内卡升级快速、高效的完成烧片版本到用户版本的升级。
[0116] 此外,在实际应用中,不论是内卡升级方式,还是外卡升级方式,在对第一分区表升级后,根据升级后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系时,具体可以按照如下方式实现。
[0117] 示例性的,在一些实现方式中,关于根据据升级后的第一分区表中记录的分区信息重新创建存储器中分区的设备节点与存储器之间的映射关系的方式,例如可以是先根据升级后的第一分区表中记录的分区信息确定每一个分区的起始位置和结束位置,然后根据每一个分区的起始位置和结束位置重新创建存储器中分区的设备节点与存储器之间的映射关系。
[0118] 示例性的,在另一些实现方式中,关于根据据升级后的第一分区表中记录的分区信息重新创建存储器中分区的设备节点与存储器之间的映射关系的方式,例如可以是先根据升级后的第一分区表中记录的分区信息确定每一个分区的起始位置和偏移量;然后根据每一个分区的起始位置和偏移量重新创建存储器中分区的设备节点与存储器之间的映射关系。
[0119] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0120] 步骤107,格式化用户数据分区,并根据映射关系创建格式化后的用户数据分区对应的文件系统。
[0121] 由此,通过对用户数据分区进行格式化,并创建格式后的用户数据分区对应的文件系统,便可以完成将电子设备从烧片版本到用户版本的升级。
[0122] 此外,通过对用户数据分区进行格式化,也可以将预存在用户数据分区的第一升级包删除,从而防止升级版本流出。
[0123] 此外,在格式化用户数据分区,并根据映射关系创建格式化后的用户数据分区对应的文件系统之后,还可以清除misc分区中记录的升级标志位。这样,在从烧片版本升级到用户版本后,通过清除misc分区中记录的升级标志位,在电子设备出厂投入使用后,就不会因为用户的操作,导致电子设备执行该升级流程。
[0124] 由此,通过本实施例提供的升级方法,通过设置内卡升级条件,并在确定本次升级是否满足内卡升级条件时,先根据第一分区表将第一升级包中的除用户数据之外的分区对应的镜像文件写入存储器中对应的分区,再根据第二分区表升级第一分区表,并根据升级后的第一分区表表重新创建存储器中分区的设备节点与存储器之间的映射关系,进而在格式用户数据分区后,根据映射关系创建格式化后的用户数据分区对应的文件系统,从而克服了内卡升级需要克服分区变化之后第一升级包无法找到的问题,使得电子设备从烧片版本升级到用户版时,既可以在分区表发生变化的情况下,依旧将各分区的镜像文件写入正确的位置,又可以克服SD卡、U盘等外部存储设备传输速度的限制。
[0125] 此外,通过将第一升级包存储在电子设备的存储器的用户数据分区中,使得升级操作无需插拔外部存储设备,简化了用户操作,并且稳定性更高。
[0126] 为了更好的理解本申请提供的升级方法,下述实施例结合图3至图9对本申请提供的升级方法所适用于的各种场景进行具体说明。
[0127] 示例性的,参见图3,本实施例的具体实现步骤包括:
[0128] 步骤201,响应于接收到的升级指令,触发电子设备重启。
[0129] 示例性的,在一些实现方式中,电子设备接收到的升级指令,可以是由与电子设备建立通信连接的PC设备发送给电子设备的,或者可以是电子设备的home键和开机键被同时长按时,电子设备生成的。
[0130] 可理解的,不论是通过哪种方式接收到的升级指令,在接收到升级指令之后,电子设备均会进行重启。
[0131] 步骤202,电子设备启动时,读取misc分区记录的启动标志位。
[0132] 示例性的,在电子设备响应于接收到的升级指令,触发电子设备重启后,当电子设备进入启动程序,会先访问misc分区,读取misc分区记录的启动标志位。
[0133] 可理解的,本实施例中所说的启动标志位具体是用于指示电子设备本次的启动操作是进入哪种模式。
[0134] 示例性的,关于电子设备可以进入的模式,例如可以包括正常模式、Recovery模式等。
[0135] 需要说明的是,上述所说的正常模式,即电子设备在启动过程中依次加载基础分区的数据、静态分区的数据和动态分区的数据,进而使电子设备运行到电子设备当前安装的操作系统。
[0136] 此外,还需要说明的是,关于用于指示不同启动模式的启动标志位可以预先约定,并写入misc分区。关于启动标志位的约定形式,本实施例不作限制,关于如写入misc分区的方式,可以参见现有标准,此处不再赘述。
[0137] 步骤203,判断启动标志位是否指示进入Recovery模式。
[0138] 具体的,如果从misc分区读取的启动标志位指示本次启动电子设备不是进入Recovery模式,即是指示进入正常模式,则执行步骤204;如果从misc分区读取的启动标志位指示本次启动电子设备需要进入Recovery模式,则执行步骤205。
[0139] 步骤204,正常启动。
[0140] 可理解的,步骤204中所说的正常启动,即是让电子设备进入正常模式。因此,电子设备在启动过程中会依次加载基础分区的数据、静态分区的数据和动态分区的数据,进而使电子设备运行到电子设备当前安装的操作系统。
[0141] 关于不同系统分区结构,例如AB系统分区结构、虚拟AB系统分区结构和非AB系统分区结构的具体启动细节可以参见现有标准,此处不再赘述。
[0142] 步骤205,加载Recovery镜像,进入Recovery模式。
[0143] 可理解的,加载Recovery镜像,进入Recovery模式后,Recovery进程便会启动,也就是说,在Recovery模式下进行的升级操作,均是由,Recovery进程执行的。
[0144] 步骤206,读取misc分区记录的升级标志位。
[0145] 不难发现,本实施例中的步骤206与上述实施例中的步骤102大致相同,具体的实现细节可以参见针对步骤102的描述,此处不再赘述。
[0146] 步骤207,判断升级标志位是否指示外卡升级。
[0147] 可理解的,通过上述实施例的描述可知,在电子设备从烧片版本首次进入Recovery模式执行升级操作时,misc分区中记录的升级标志位是没有指示内卡升级的,判断是否采用内卡升级是在升级标志位指示采用外卡升级,并且满足内卡升级的条件下才会触发内卡升级流程,因此在从misc分区读取到升级标志位后,会判断升级标志位是否是指示外卡升级的升级标志位。
[0148] 相应地,如果升级标志位不是指示外卡升级的升级标志位,则执行该升级标志位指示的其他操作流程,即执行步骤208;如果升级标志位是指示外卡升级的升级标志位,,例如“factory_sd_update”,则执行步骤209。
[0149] 步骤208,其他操作流程。
[0150] 示例性的,如果升级标志位是指示OTA升级的升级标志位,例如“factory_ota_update”,则执行对当前操作系统的版本的迭代升级。具体的,如果电子设备当前已经升级到用户版本,那么要进行的操作流程便是对用户版本的迭代升级,如果电子设备当前是在烧片版本下,则是对烧片版本的迭代升级。
[0151] 示例性的,如果升级标志位是指示工厂复位的升级标志位,例如“factory_reset”,则执行恢复出厂设置的操作。
[0152] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0153] 步骤209,查找升级包。
[0154] 具体的说,由于从misc分区中读取到的升级标志位指示的是外卡升级,即正常情况下应该挂载外部存储设备,例如SD卡,或者U盘,或者OTG等,然后从挂载成功的外部存储设备中查找升级包。但是,本实施例提供的升级方案,为了在这种情况下,优先采用内卡升级方式,因此在从misc分区中读取到的升级标志位指示的是外卡升级,查找升级包时,可以先到userdata分区的指定路径下查找升级包。
[0155] 此外,需要说明的是,由于userdata分区是有文件系统的,在具体实现时,存放和查找升级包的时候不是依靠升级包所在的起始位置和结束位置来实现,而是升级包放到某一位置,例如/data/update之后,文件系统会记录升级包的实际位置,故而上述所说的去userdata分区查找升级包,实质是到文件系统中指定的位置,例如/data/update这个位置去查找。
[0156] 此外,关于上述所说的挂载,具体是指将外部存储设备挂载到指定路径下,这样电子设备才可以访问外部存储设备,从外部存储设备中读取升级包内的升级数据,例如分区表、各分区对应的镜像文件等。
[0157] 此外,需要说明的是,在具体实现时,不仅外部存储设备需要挂载,userdata分区也需要挂载,这样才能到/data/update这个位置查找升级包。
[0158] 示例性的,对于OTG,在将OTG插入电子设备上对应的数据接口,例如外部存储器接口120,或者USB接口130时,会在dev/block上创建一个设备节点,这个节点就代表这个OTG,但这只是个节点,不能去访问OTG中的内容,就向userdata分区对应的节点也是在dev/block下,访问userdata分区也不能直接去访问这个节点,需要将userdata分区挂载到data目录才能进行访问。OTG也是一样的,必须挂载才能去访问。
[0159] 此外,还需要说明的是,由于SD卡和OTG(相当于盘)分别对应的节点都是固定的,挂载的时候会先去查看节点是否存在,存在才会去挂载,都存在的话就会按照顺序去挂载,当前的顺序是先挂载OTG,挂载上了就去OTG查找升级包,找不到或挂载不上,就去挂载SD卡,SD卡挂载上了就去SD卡查找升级包。
[0160] 示例性的,基于上述挂载和查找的原理,具体到实际应用中,如果约定将电子设备从烧片版本升级到用户版本时,优先使用外卡升级,则在查找升级包时,按照为SD卡和OTG分配的顺序进行挂载,如果当前的顺序是先挂载OTG,挂载上了就去OTG查找升级包,找不到或挂载不上,就去挂载SD卡,SD卡挂载上了就去SD卡查找升级包。如果SD卡也挂载不上,或者查找不到升级包,则考虑采用内卡升级方式,即挂载userdata分区到data目录,然后到/data/update路径下查找升级包,如果挂载不上,或者查找不到升级包,则退出本次升级流程,并提示用户原因。
[0161] 示例性的,基于上述挂载和查找的原理,具体到实际应用中,如果约定将电子设备从烧片版本升级到用户版本时,优先使用内卡升级,则在查找升级包时,先挂载userdata分区到data目录,然后到/data/update路径下查找升级包,如果挂载不上,或者查找不到升级包,则考虑采用外卡升级,即按照为SD卡和OTG分配的顺序进行挂载,如果当前的顺序是先挂载OTG,挂载上了就去OTG查找升级包,找不到或挂载不上,就去挂载SD卡,SD卡挂载上了就去SD卡查找升级包,如果SD卡也挂载不上,或者查找不到升级包,则退出本次升级流程,并提示用户原因。
[0162] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0163] 步骤210,判断升级包的路径是否为/data/update。
[0164] 具体的说,如果升级包的路径不是/data/update,例如是SD卡对应的路径,或者OTG对应的路径,即表明userdata分区不存在升级包,本次升级无法采用内卡升级,只能采用外卡升级,这种情况下执行步骤211;如果升级包的路径为/data/update,即表明userdata分区存在升级包,本次升级可以采用内卡升级,这种情况下执行步骤212。
[0165] 步骤211,外卡升级流程。
[0166] 示例性的,参见图4,关于外卡升级流程的实现过程,具体包括:
[0167] 子步骤210‑1,检验第二升级包是否合格。
[0168] 需要说明的是,为了便于区分,本实施例中仍存储在flash中的分区表,即电子设备中已经存在的分区表称为第一分区表,将从userdata分区中查找到的升级包称为第一升级包,将第一升级包中的分区表称为第二分区表,将从外部存储设备查找到的升级包称为第二升级包,将第二升级包中的分区表称为第三分区表。
[0169] 故而,查找到的升级包是来自外部存储设备时,即是第二升级包时,在根据第三分区表刷新第一分区表之前,需要先校验第二升级包是否合格。
[0170] 示例性的,在一些实现方式中,可以根据第三分区表中记录的循环冗余校验码(Cyclic Redundancy Check,CRC)来校验第三分区表中记录的分区信息,以及镜像文件是否完整、无误。
[0171] 相应地,在确定第二升级包合格后,可以执行子步骤210‑2,否则执行子步骤210‑7,升级失败,例如结束本次升级,并向用户反馈升级失败的原因。
[0172] 子步骤210‑2,根据第二升级包中的第三分区表刷新第一分区表。
[0173] 示例性的,在一些实现方式中,可以先确定第一分区表中记录的分区信息的格式,然后按照第一分区表中记录的分区信息的格式对第三分区表中记录的分区信息解析。
[0174] 示例性的,在另一些实现方式中,可以预先约定一种统一的格式,然后按照约定的统一格式,分别对第一分区表中记录的分区信息解析,对第三分区表中记录的分区信息解析,从而确保两张分区表中记录的分区信息的格式相同。
[0175] 此外,需要说明的是,通常情况下,在根据解析后的第三分区表中记录的分区信息升级第一分区表中记录的分区信息时,可以是直接将第三分区表中记录的分区信息替换第一分区表中记录的全部分区信息,也可以仅替换不同部分,例如保留第一分区表中记录的系统分区的分区信息不变,将其他分区(专有分区和用户数据分区)的分区信息替换为第三分区表中用户数据分区的分区信息。
[0176] 示例性的,替换的方式可以采用覆盖写的方式,或者先删除第一分区表中记录的全部分区信息,然后再将解析后的第三分区表中记录的分区信息写入第一分区表中,还或者直接将第一分区表从存储器中删除,然后将第三分区表整个存储到存储器中。
[0177] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0178] 子步骤210‑3,根据刷新后的第一分区表重新加载分区。
[0179] 不难发现,本实施例中的子步骤210‑3与上述实施例中的步骤106大致相同,具体的实现细节可以参见针对步骤106的描述,此处不再赘述。
[0180] 子步骤210‑4,将第二升级包中各分区的镜像文件写对重新加载的对应分区。
[0181] 例如,将系统分区对应的镜像文件写入重新加载的系统分区,将用户数据分区对应的镜像文件写入重新加载的用户数据分区。
[0182] 子步骤210‑5,清除misc分区记录的升级标志位。
[0183] 这样,在从烧片版本升级到用户版本后,通过清除misc分区中记录的升级标志位,在电子设备出厂投入使用后,就不会因为用户的操作,导致电子设备执行该升级流程。
[0184] 子步骤210‑6,重启电子设备。
[0185] 由此,在重启电子设备后,电子设备便可以从烧片版本升级到用户版本。
[0186] 子步骤210‑7,升级失败。
[0187] 关于采用外卡升级的升级流程就介绍到此,未在本实施例中说明的细节可以参见现有标准,此处不再赘述。
[0188] 步骤212,修改misc分区记录的升级标志位。
[0189] 示例性的,如果约定升级标志位“factory_flash_update”用于指示本次升级的升级方式为内卡升级,约定升级标志位“factory_sd_update”用于指示本次升级的升级方式为外卡升级,则步骤212中所说的修改misc分区记录的升级标志位,例如可以是将“factory_sd_update”替换为“factory_flash_update”,这样如果中断了从烧片版本升级到用户版本的流程,在下次重新触发后,便可以按照内卡升级流程进行升级,无需再次判断,简化了处理流程。
[0190] 步骤213,检验升级包是否合格。
[0191] 可理解的,关于检验升级包(此处为第一升级包)是否合格的方式,与检验第二升级包是否合格的方式大致相同,即可以根据第二分区表中记录的循CRC来校验第二分区表中记录的分区信息,以及镜像文件是否完整、无误。
[0192] 相应地,在确定第一升级包合格后,可以执行步骤214,否则执行步骤215,升级失败,例如结束本次升级,并向用户反馈升级失败的原因。
[0193] 步骤214,判断是否满足内卡升级。
[0194] 通过上述实施例的描述可知,内卡升级的的前提是要保证第二分区表中记录的系统分区的分区信息和第一分区表中记录的系统分区的分区信息相同,并且系统分区需要放在userdata分区之前,烧片版本中特有的专有分区需要紧挨userdata分区,为了更好的理解,以下结合图5进行说明。
[0195] 示例性的,参见图5,如果电子设备当前处于烧片版本,且烧片版本包括系统分区、专有分区和用户数据分区(userdata分区),而系统分区包括mboot分区、boot分区、...、super分区、version分区、preload分区等,专有分区包括flash_ageing等。那么,需要升级到的用户版本需要包括系统分区和用户数据分区,并系统分区同样需要包括mboot分区、boot分区、...、super分区、version分区、preload分区等,且这些系统分区的位置、占用空间的大小均相同。
[0196] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。在实际应中,系统分区可以包括上述罗列的任意一种或几种分区,或者除上述罗列的分区之外的分区,此处不再一一列举,本实施例对此也不作限制。
[0197] 步骤215,升级失败。
[0198] 示例性的,在升级失败,结束升级流程时,可以向用户(例如厂商的服务器)反馈本次升级失败的具体原因,以便技术人员根据反馈的原因快速定位解决该问题。
[0199] 步骤216,根据第一分区表和升级包升级userdata分区之外的分区。
[0200] 继续参见图5,步骤216所说的根据第一分区表和升级包升级userdata分区之外的分区,具体是根据第一分区表记录的系统分区的分区信息和第一升级包中这些系统分区的镜像文件,对flash中的这些系统分区进行升级,例如将mboot分区对应的镜像文件写入mboot分区,将boot分区对应的镜像文件写入boot分区,将super分区对应的镜像文件写入super分区,将version分区对应的镜像文件写入version分区,将preload分区对应的镜像文件写入preload分区。
[0201] 此外,需要说明的是,在实际应用中,不同系统分区对应的镜像文件的写入顺序具体是根据第一升级包中的一个脚本文件确定的。
[0202] 示例性的,在一些实现方式中可以约定该脚本文件的每一行代表一个命令,在执行步骤216时,去解析该脚本文件中每一行对应的命令,然后根据命令实现升级顺序的控制。
[0203] 示例性的,在一些实现方式中可以约定该脚本文件的名称为“updater‑script”,对于该脚本文件中当前读取到的一行命令,例如“write_raw_image("tvconfig.img","/dev/block/bootdevice/by‑name/tvconfig","0")”通过解析可知,具体是将第一升级包中的tvconfig.img这个镜像文件写入到/dev/block/bootdevice/by‑name/tvconfig这个节点上。
[0204] 可理解的,上述命令中的“0”代表tvconfig.img这个镜像文件是非稀疏矩阵(sparse)格式。
[0205] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0206] 步骤217,根据升级包中的第二分区表刷新第一分区表。
[0207] 此外,通过上述描述可知,为了统一第一分区表与第二分区表的格式,可以将第二分区表解析为第一分区表的格式,或者将两个分区表解析为约定的统一格式。
[0208] 为了便于说明,本实施例以将第二分区表解析为第一分区表的格式为例进行说明。
[0209] 示例性的,假设第一分区表的格式如图6所示。其中,每一个ENTRY表示一个分区,对于不同的ENTRY按照顺序编号,例如ENTRY[1]表示第一个分区,分区名称为“super”,起始位置start为“0x00290000”,结束位置End为“0x009F3FFF”,大小Size为“3967811584Bytes”;ENTRY[2]表示第二个分区,分区名称为“version”,起始位置start为“0x009F4000”,结束位置End为“0x00A73FFF”,大小Size为“268435456Bytes”;ENTRY[3]表示第三个分区,分区名称为“preload”,起始位置start为“0x00A74000”,结束位置End为“0x00B6FFFF”,大小Size为“528482304Bytes”;ENTRY[4]表示第四个分区,分区名称为“flash_ageing”,起始位置start为“0x00B70000”,结束位置End为“0x00C6FFFF”,大小Size为“536870912Bytes”;ENTRY[5]表示第五个分区,分区名称为“userdata”,起始位置start为“0x00C70000”,结束位置End为“0x0150D7FF”,大小Size为“4625268736Bytes”。
[0210] 示例性的,参见图7为第二分区表解析前的一种数据格式,该格式下记录的是裸数据,即只是纯粹的数据,没有对数据进行简单的分析或者数据的来源并没有依据。因此,无法获知每一行数据究竟是哪个分区(分区名称)对应的分区信息,其中记录的当前分区的起始位置、结束位置,以及分区大小等信息。故而,需要对其进行解析处理,以得到每一行数据究竟是哪个分区(分区名称)对应的分区信息,其中记录的当前分区的起始位置、结束位置,以及分区大小等信息。因此,本实施例按照图6所示的格式对第二分区表解析处理后,得到的内容例如可以如图8所示。
[0211] 示例性的,参见图8。每一个ENTRY表示一个分区,对于不同的ENTRY按照顺序编号,例如ENTRY[1]表示第一个分区,分区名称为“super”,起始位置start为“0x00290000”,结束位置End为“0x009F3FFF”,大小Size为“3967811584Bytes”;ENTRY[2]表示第二个分区,分区名称为“version”,起始位置start为“0x009F4000”,结束位置End为“0x00A73FFF”,大小Size为“268435456Bytes”;ENTRY[3]表示第三个分区,分区名称为“preload”,起始位置start为“0x00A74000”,结束位置End为“0x00B6FFFF”,大小Size为“528482304Bytes”;ENTRY[4]表示第四个分区,分区名称为“userdata”,起始位置start为“0x00B70000”,结束位置End为“0x0150D7FF”,大小Size为“999397785Bytes”。
[0212] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0213] 此外,为了更加直观的理解步骤217,以下结合图9进行说明。
[0214] 示例性的,参见图9,如果电子设备中第一分区表中记录的分区信息有系统分区(起始位置A,结束位置B,SizeS1)、专有分区(起始位置C,结束位置D,SizeS2)、用户数据分区(起始位置E,结束位置F,SizeS3)这三大类分区的分区信息,而第二分区表中记录的分区信息有系统分区(起始位置A,结束位置B,SizeS1)、用户数据分区(起始位置C,结束位置F,SizeS4)这两大类分区的分区信息,并且SizeS4为Size2和SiseS的总和。如果根据第二分区表对第一分区表升级后,升级后的第一分区包中记录的分区信息为:系统分区(起始位置A,结束位置B,SizeS1)、用户数据分区(起始位置C,结束位置F,SizeS4)这两大类分区的分区信息。
[0215] 应当理解的是,上述说明仅是为了更好的理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
[0216] 步骤218,根据刷新后的第一分区表重新加载分区。
[0217] 需要说明的是,本实施例中根据刷新后的第一分区表重新加载分区,具体是指根据刷新后的第一分区表重新创建存储器中分区的设备节点与存储器之间的映射关系。
[0218] 示例性的,重新加载后的各分区的起始地址、结束地址和大小如图9所示,并且重新加载后的分区形式会从图5示出的烧片版本变更为用户版本。
[0219] 步骤219,格式化userdata,并创建文件系统。
[0220] 需要说明的是,userdata分区格式化之前会有一些生成的数据,包括设置的数据、Android应用程序安装包(Android application package,APK)的安装数据等。userdata分区格式化之后这些数据就会被清除,包括第一升级包也会被清除,从而防止版本外溢。
[0221] 相应地,在格式化userdata分区之后,当电子设备再次启动的时候会重新安装并生成这些数据。
[0222] 此外,通过上述实施例的描述可知,步骤219中创建文件系统的操作,在实际应用中具体是根据步骤218中创建的映射关系创建的,即根据映射关系创建格式化后的用户数据分区对应的文件系统。
[0223] 步骤220,清除misc分区记录的升级标志位。
[0224] 这样,在从烧片版本升级到用户版本后,通过清除misc分区中记录的升级标志位,在电子设备出厂投入使用后,就不会因为用户的操作,导致电子设备执行该升级流程。
[0225] 步骤221,重启电子设备。
[0226] 由此,在重启电子设备后,电子设备便可以从烧片版本升级到用户版本。
[0227] 关于本实施例提供的将电子设备从烧片版本升级到用户版本的具体实现流程就介绍到此,未在本实施例中记载的细节可以参见图1所示实施例的描述,此处不再赘述。
[0228] 此外,应当理解的是,电子设备为了实现上述功能,其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
[0229] 此外,需要说明的是,在实际的应用场景中由电子设备实现的上述各实施例提供的升级方法,也可以由电子设备中包括的一种芯片系统来执行,其中,该芯片系统可以包括处理器。该芯片系统可以与存储器耦合,使得该芯片系统运行时调用该存储器中存储的计算机程序,实现上述电子设备执行的步骤。其中,该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。
[0230] 另外,本申请实施例还提供一种计算机可读存储介质,该计算机存储介质中存储有计算机指令,当该计算机指令在电子设备上运行时,使得电子设备执行上述相关方法步骤实现上述实施例中的升级方法。
[0231] 另外,本申请实施例还提供了一种计算机程序产品,当该计算机程序产品在电子设备上运行时,使得电子设备执行上述相关步骤,以实现上述实施例中的升级方法。
[0232] 另外,本申请的实施例还提供一种芯片(也可以是组件或模块),该芯片可包括一个或多个处理电路和一个或多个收发管脚;其中,所述收发管脚和所述处理电路通过内部连接通路互相通信,所述处理电路执行上述相关方法步骤实现上述实施例中的升级方法,以控制接收管脚接收信号,以控制发送管脚发送信号。
[0233] 此外,通过上述描述可知,本申请实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法,因此,其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果,此处不再赘述。
[0234] 以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。