一种基于双系统升级包共享的升级方法

技术领域

本发明涉及虚拟机技术领域，尤其涉及一种基于双系统升级包共享的升级方法。

背景技术

基于QNX Hyperviosr(QNX虚拟机)方案，用单个soc芯片集成实现IVI(车载信息娱乐系统)、CLUSTER(集群)、HUD(平视显示器)、HAVC(空气调节系统)的智能座舱，将成为车载影音娱乐系统下一代产品发展的趋势。

现有的QNX虚拟机的升级过程如下：

启动客户机端的Android操作系统，在Android系统下载完OTA升级包后，或者通过U盘读取升级包后，普遍通过双系统之间的通讯，传输QNX系统需要的升级包数据给宿主机端。但是，在升级包比较大的情况下，将存在两个问题：(一)传输效率低；(二)还需要在宿主机端的QNX操作系统下再增加分区来进行接收存储，会造成整机系统磁盘存储空间的浪费。

因此，现有技术有待进一步改进。

发明内容

本发明提供一种基于双系统升级包共享的升级方法，解决了现有的QNX虚拟机双系统升级方案不合理，升级效率低且存在磁盘存储空间浪费的技术问题。

为解决以上技术问题，本发明提供一种基于双系统升级包共享的升级方法，包括步骤：

S1、划分存储设备得到预设存储分区并配置；

S2、将所述预设存储分区挂载到宿主机端的升级共享区域中；

S3、客户机端根据预设机制共享所述升级共享区域，并将所述预设存储分区挂载到目标存储区域；

S4、当所述客户机端检测到新版本推送时，将获得的升级数据包存储到所述目标存储区域，并向所述宿主机端发送共享指令；

S5、所述宿主机端根据所述共享指令，从所述升级共享区域中获取所述升级数据包，并执行相应操作。

本基础方案在存储设备中划分出一个磁盘存储分区，作为可共享的预设存储分区，并由宿主机端、客户机端同时挂载；在新版本更新检测之前，先将预设存储分区依次挂载到宿主机端的升级共享区域、目标存储区域，当客户机端检测到新版本推送时，自动完成升级数据包的下载并存储到目标存储区域后，无需将升级数据包下载到宿主机端的存储中，宿主机端可从升级共享区域中直接读取升级数据包，既节约了主机存储的磁盘空间，又提高了双系统(例如QNX操作系统、Android操作系统)的升级效率。

在进一步的实施方案中，所述步骤S1包括：

S11、在存储模块中划分一存储区域作为预设存储分区；

S12、将所述预设存储分区格式化为目标升级系统均支持的文件系统格式。

本方案在存储模块中划分一存储区域作为预设存储分区，仅用于存储升级数据包，便于系统进行管理；将预设存储分区格式化为宿主机端(例如QNX系统)中或客户机端(例如Android系统)中均支持的文件系统格式(例如EXT2)，可支持宿主机端(例如QNX系统)以及客户机端(例如Android系统)直接读取。

在进一步的实施方案中，所述步骤S3包括：

S31、启动所述客户机端操作系统；

S32、所述客户机端采用预设机制进行磁盘块数据共享，共享所述升级共享区域，并将所述预设存储分区挂载到所述客户机端操作系统中的目标存储区域。

在进一步的实施方案中，所述步骤S5包括：

S51、所述宿主机端获取所述共享指令，并在通过所述升级共享区域访问所述目标存储区域；

S52、从所述目标存储区域读取所述升级数据包，并执行相应操作。

在进一步的实施方案中，所述预设机制为VIRTIO-BLK机制；

本方案采用VIRTIO-BLK机制进行磁盘块数据共享，使得客户机端的操作系统可以挂载访问宿主机端的磁盘分区，从而达到双系统磁盘数据共享。

所述目标存储区域为所述客户机端操作系统中的升级包存储区域。

在进一步的实施方案中，在所述步骤S1中，当所述存储模块为车机内部的eMMC存储芯片时，所述步骤S11具体为：采用GPT分区，将存储模块划分为多个存储分区，从中选择一个所述存储分区作为预设存储分区。

在进一步的实施方案中，在所述步骤S11中：当所述存储模块为外接存储设备时，将所述外接存储设备的内部存储区域作为预设存储分区；

所述外接存储设备包括TF卡、U盘、移动硬盘。

本方案根据不同的存储设置，设置了对应的预设存储分区获取机制，当存储模块为车机内部的eMMC存储芯片时，采用GPT分区获取到的预设存储分区，仅作用于存储升级数据包，便于系统进行管理；而当存储模块为外接存储设备时，基于其使用场景的单一性，无需进行分区操作，即可直接进行升级数据包的存储。

在进一步的实施方案中，所述升级数据包为OTA升级包，包括宿主机端系统升级包或/和客户机端系统升级包。

在进一步的实施方案中，所述宿主机端系统为QNX操作系统，所述客户机端系统为Android操作系统。

在进一步的实施方案中，所述文件系统格式为EXT2。

附图说明

图1是本发明实施例提供的一种基于双系统升级包共享的升级方法的工作流程图。

具体实施方式

下面结合附图具体阐明本发明的实施方式，实施例的给出仅仅是为了说明目的，并不能理解为对本发明的限定，包括附图仅供参考和说明使用，不构成对本发明专利保护范围的限制，因为在不脱离本发明精神和范围基础上，可以对本发明进行许多改变。

本发明实施例提供的一种基于双系统升级包共享的升级方法，如图1所示，在本实施例中，包括步骤：

S1、划分存储设备得到预设存储分区并配置，包括：

S11、在存储模块中划分一存储区域作为预设存储分区，具体为：

当存储模块为车机内部的eMMC存储芯片时，采用GPT分区，将存储模块划分为多个存储分区，从中选择一个存储分区作为预设存储分区。

其中，eMMC(Embedded Multi Media Card)，是“嵌入式多媒体控制器”的缩写，是指由闪存和集成在同一硅片上的闪存控制器组成的封装结构；采用GPT分区后，存储模块还包括存储QNX内核的DOS分区、存储QNX应用的BASE分区，以及存储安卓(Android)系统的分区。

当存储模块为外接存储设备时，将外接存储设备的内部存储区域作为预设存储分区；

在本实施例中，外接存储设备包括但不限于TF卡、U盘、移动硬盘。

本发明根据不同的存储设置，设置了对应的预设存储分区获取机制，当存储模块为车机内部的eMMC存储芯片时，采用GPT分区获取到的预设存储分区，仅作用于存储升级数据包，便于系统进行管理；而当存储模块为外接存储设备时，基于其使用场景的单一性，无需进行分区操作，即可直接进行升级数据包的存储。

S12、将预设存储分区格式化为目标升级系统均支持的文件系统格式。

在本实施例中，文件系统格式优选为EXT2。

本发明在存储模块中划分一存储区域作为预设存储分区，仅用于存储升级数据包，便于系统进行管理；将预设存储分区格式化为与宿主机端(例如QNX系统)中或客户机端(例如Android系统)中对应的EXT2文件系统格式，可支持宿主机端系统以及客户机端系统的直接读取。

应当理解，宿主机端系统并不一定是QNX，客户端系统也不一定是Android系统，可根据实际情况进行设置。

S2、将预设存储分区挂载到宿主机端(HOST端)的升级共享区域中。

S3、客户机端(GUEST客户端)根据预设机制共享升级共享区域，并将预设存储分区挂载到目标存储区域，包括：

S31、控制宿主机端的QNX操作系统启动客户机端的Android操作系统；

S32、客户机端采用预设机制进行磁盘块数据共享，共享升级共享区域，并将预设存储分区挂载到Android操作系统中的目标存储区域。

在本实施例中，预设机制为VIRTIO-BLK机制；

本发明采用VIRTIO-BLK机制进行磁盘块数据共享，使得客户机端的操作系统可以挂载访问宿主机端的磁盘分区，从而达到双系统磁盘数据共享。

在本实施例中，目标存储区域为Android操作系统中的升级包存储区域。

S4、当客户机端检测到新版本推送时，将获得的升级数据包存储到目标存储区域，并向宿主机端发送共享指令；

在本实施例中，升级数据包OTA升级包，包括QNX系统升级包或/和Android系统升级包。

S5、宿主机端根据共享指令，从升级共享区域中获取升级数据包，并执行相应操作，包括：

S51、宿主机端获取共享指令，并在通过升级共享区域访问目标存储区域；

S52、从目标存储区域读取升级数据包，并执行相应操作。

其中，所述相应操作包括直接读取升级数据包进行系统升级，或者，当检测到升级包版本已升级过后，忽略本次升级。

在本实施例中，以宿主机端系统为QNX操作系统、客户机端系统为Android操作系统为例，双系统升级的过程如下：宿主机端的QNX操作系统启动后，对存储模块进行挂载处理，将存储模块中的预设存储分区挂载到宿主机端的升级共享区域中。

随后，QNX操作系统通过QNX Hypervisor的QVM虚拟机启动客户机端的Android操作系统。

客户机端对存储模块进行挂载处理，将存储模块中的预设存储分区挂载到Android操作系统的目标存储区域中。

此时，当客户机端检测到新版本推送时，则先将升级数据包存储到目标存储区域，再向宿主机端发送共享指令，若Android操作系统需要升级，则直接从升级数据包中读取Android系统升级包进行升级。

宿主机端接收到共享指令时，通过QNX操作系统的升级共享区域路径，即可同步访问该升级数据包，读取其中的QNX系统升级包即可进行升级。

本发明实施例在存储设备中划分出一个磁盘存储分区，作为可共享的预设存储分区，并由宿主机端、客户机端同时挂载；在新版本更新检测之前，先将预设存储分区依次挂载到宿主机端的升级共享区域、目标存储区域，当客户机端检测到新版本推送时，自动完成升级数据包的下载并存储到目标存储区域后，无需将升级数据包下载到宿主机端的存储中，宿主机端可从升级共享区域中直接读取升级数据包，既节约了主机存储的磁盘空间，又提高了双系统(例如QNX操作系统、Android操作系统)的升级效率。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。