CN117348939A - 一种基于多核的软件刷新方法、系统、设备及介质、车辆 - Google Patents

一种基于多核的软件刷新方法、系统、设备及介质、车辆 Download PDF

Info

Publication number
CN117348939A
CN117348939A CN202311244569.8A CN202311244569A CN117348939A CN 117348939 A CN117348939 A CN 117348939A CN 202311244569 A CN202311244569 A CN 202311244569A CN 117348939 A CN117348939 A CN 117348939A
Authority
CN
China
Prior art keywords
core
refreshing
software
emergency
boot loader
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.)
Pending
Application number
CN202311244569.8A
Other languages
English (en)
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.)
United Automotive Electronic Systems Co Ltd
Original Assignee
United Automotive Electronic Systems 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 United Automotive Electronic Systems Co Ltd filed Critical United Automotive Electronic Systems Co Ltd
Priority to CN202311244569.8A priority Critical patent/CN117348939A/zh
Publication of CN117348939A publication Critical patent/CN117348939A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4405—Initialisation of multiprocessor systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本发明提供一种基于多核控制器的软件刷新方法、系统、设备及介质、一种车辆，包括：对第一核软件和第二核软件的引导加载程序进行存储部署，并读取启动第一核软件的引导加载程序时以及启动第二核软件的引导加载程序时的标志位，以及根据标志位读取结果确定刷新场景；正常启动场景时，对第一核软件和第二核软件进行正常启动；紧急刷新场景时，对第一核软件进行紧急刷新，和/或，对第二核软件进行紧急刷新。其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。与面向非多核控制器的紧急刷新方案相比，本发明支持在一次刷新操作中对部署在多核的软件同时进行刷新，无需切换刷新设备、上位机程序和多次重启等操作，提升了刷新效率。

Description

一种基于多核的软件刷新方法、系统、设备及介质、车辆
技术领域
本发明涉及软件技术领域，特别是涉及一种基于多核控制器的软件刷新方法、系统、设备及介质、一种车辆。
背景技术
当电子控制器产品的出现软件失效无法正常启动，或因为人为需要，需要强制手动更新系统时，通常需要用特殊的方法对本地的软件进行刷新，该过程通常被称作紧急刷新。
目前，普通的MCU(Microcontroller Unit，微控制器，简称MCU)架构的车载网关控制器一般采用自带引导加载程序Bootloader刷新存储在NVM(Non-Volatile Memory，非易失性存储器，简称NVM)的软件；有文件系统的网关控制器(例如Linux系统的MPU(Microprocessor Unit，微处理器，简称MPU))则需要有备份的最小系统，通过引导加载程序恢复软件。
随着目前汽车领域的跨域融合SoC(System on Chip，系统级芯片，简称SoC)芯片将替代原先的MCU&MPU设计，此时需要按照SoC多核的启动链路设计刷新流程，并且考虑不同的软件失效场景的刷新策略，部署多个引导加载程序的部署和软件分区。目前现有的车载电子控制器的紧急刷新或者系统复位方案，一般只面向单一构型的MCU或MPU，或只针对固件部署在单一NVM上的系统，刷新时也不考虑多核软件启动链路依赖关系，因此无法用来紧急刷新存在异构多核的SoC系统。
发明内容
鉴于以上所述现有技术的缺点，本发明的目的在于提供一种基于多核控制器的软件刷新方法、系统、设备及介质、一种车辆，用于解决现有技术中存在的技术问题。
为实现上述目的及其他相关目的，本发明提供一种基于多核的软件刷新方法，包括以下步骤：
对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器；
读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
在所述刷新场景为正常启动场景时，对所述第一核软件和所述第二核软件进行正常启动；或者，在所述刷新场景为紧急刷新场景时，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，和/或，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新。
于本发明的一实施例中，对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：
将第一核软件、第一核软件的引导加载程序和第二核软件的引导加载程序部署至非易失性闪存中，并将第二核软件部署至嵌入式多媒体卡中；以及，
将预设操作系统和刷写脚本部署至所述嵌入式多媒体卡中。
于本发明的一实施例中，读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景的过程包括：
将第一核软件的引导加载程序记为客户引导加载程序，以及，将第二核软件的引导加载程序记为通用引导加载程序；
读取启动所述客户引导加载程序时的标志位，并确定启动所述客户引导加载程序时的标志位是否为紧急刷新标志位；以及，读取启动所述客户引导加载程序时的标志位，并确定启动所述客户引导加载程序时的标志位是否为紧急刷新标志位；
若启动所述客户引导加载程序时的标志位为非紧急刷新标志位，且启动所述客户引导加载程序时的标志位为非紧急刷新标志位，则确定当前时刻的刷新场景为正常启动场景；
若启动所述客户引导加载程序时的标志位为紧急刷新标志位，和/或，启动所述客户引导加载程序时的标志位为紧急刷新标志位，则确定当前时刻的刷新场景为紧急刷新场景；
其中，如果启动引导加载程序时的标志位为紧急刷新标志位，则对应的核软件等待进行紧急刷新。
于本发明的一实施例中，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，以及，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新的过程包括：
在读取到紧急刷新标志位时，通过所述预设操作系统运行所述刷写脚本，从上位机中下载配置文件和镜像文件；
通过非易失性闪存驱动擦除所述第一核软件的原始数据，并在所述第一核软件的原始数据对应地址按照所述配置文件写入所述镜像文件，以对所述第一核软件进行刷新；以及，
通过嵌入式多媒体卡驱动擦除所述第二核软件的原始数据，并在所述第二核软件的原始数据对应地址按照所述配置文件写入所述镜像文件，以对所述第二核软件进行刷新。
于本发明的一实施例中，在读取启动第一核软件的引导加载程序时的标志位前，所述方法还包括：
接收上位机基于互联网协议的诊断协议，向第一核中的网关核发送的诊断指令，在双倍速率同步动态随机存储器中设置非紧急刷新标志位和紧急刷新标志位；或者，
接收上位机基于控制器域网协议的诊断协议，向第一核中的网关核发送的诊断指令，在双倍速率同步动态随机存储器中设置非紧急刷新标志位和紧急刷新标志位；
其中，所述第一核、所述第二核均与所述双倍速率同步动态随机存储器连接。
于本发明的一实施例中，对所述第一核软件和/或所述第二核软件进行紧急刷新时，所述方法还包括：生成紧急刷新时的日志文件，并将所述日志文件上传至所述上位机，以通过所述日志文件进行刷新错误检查。
本发明还提供一种基于多核的软件刷新系统，所述系统包括有：
存储部署模块，用于对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器；
标志位读取模块，用于读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
软件刷新模块，用于在所述刷新场景为正常启动场景时，对所述第一核软件和所述第二核软件进行正常启动；或者，在所述刷新场景为紧急刷新场景时，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，和/或，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新。
本发明还提供一种车辆，所述车辆包括有应用于如上述中任一所述的基于多核的软件刷新方法中的目标芯片。
本发明还提供一种基于多核的软件刷新设备，包括：
处理器；和，
存储有指令的计算机可读介质，当所述处理器执行所述指令时，使得所述设备执行如上述中任一所述的基于多核的软件刷新方法。
本发明还提供一种计算机可读介质，其上存储有指令，所述指令由处理器加载并执行如上述中任一所述的基于多核的软件刷新方法。
如上所述，本发明提供一种基于多核控制器的软件刷新方法、系统、设备及介质、一种车辆，具有以下有益效果：本发明通过对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；再读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；在刷新场景为正常启动场景时，对第一核软件和第二核软件进行正常启动；或者，在刷新场景为紧急刷新场景时，通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，和/或，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新。其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。由此可知，与面向非多核控制器的紧急刷新方案相比，本发明支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本发明考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。此外，本发明可以通过上位机操作触发紧急刷新，并不局限于狭义的紧急刷新(操作系统失效后刷新)，而是可以在操作系统正常时，由于开发者需求(如软件更新/迭代后进行验证等)强制手动刷新软件。可以在控制器开发阶段使用本发明中的软件刷新方案，从而快速更新系统软件，提高开发效率，缩短开发周期。
附图说明
图1为本发明中一实施例提供的基于多核的软件刷新方法的流程示意图；
图2为本发明中一实施例提供的某一目标芯片的架构示意图；
图3为本发明中一实施例提供的对R核和A核进行紧急刷新的时序示意图；
图4为本发明中一实施例提供的基于多核的软件刷新系统的硬件结构示意图；
图5为适用于实现本发明中一个或多个实施例的基于多核的软件刷新设备的硬件结构示意图。
具体实施方式
以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
Linux，全称GNU/Linux，是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX(Portable Operating System Interface，可移植操作系统接口，简称POSIX)的多用户、多任务、支持多线程和多CPU(Central Processing Unit，中央处理器，简称CPU)的操作系统。
图1示出了本发明一实施例提供的基于多核的软件刷新方法流程示意图。具体地，在一示例性实施例中，如图1所示，本实施例提供一种基于多核的软件刷新方法，该方法包括以下步骤：
S110，对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。作为一示例，本实施例中的第一核可以为R核，第二核可以为A核，目标芯片可以为DRA821芯片。作为其他示例，本实施例中的目标芯片还可以是其他以跨域ARM(Advanced RISC Machines，简称ARM)架构的异构多核SoC芯片。在本实施例或其他实施例中，预设操作系统也被称作为最小系统，例如预设操作系统可以是EmergencyLinux系统。
S120，读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
S130，在刷新场景为正常启动场景时，对第一核软件和第二核软件进行正常启动；或者，在刷新场景为紧急刷新场景时，通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，和/或，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新。
由此可知，与面向非多核控制器的紧急刷新方案相比，本实施例支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本实施例考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。
在一示例性实施例中，步骤S110对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：将第一核软件、第一核软件的引导加载程序和第二核软件的引导加载程序部署至非易失性闪存中，并将第二核软件部署至嵌入式多媒体卡中；以及，将预设操作系统和刷写脚本部署至嵌入式多媒体卡中。具体地，作为一示例，若本实施例中的第一核为DRA821芯片中的R核，第二核为DRA821芯片中的A核，预设操作系统是Emergency Linux系统，本实施例也称Emergency Linux系统为最小系统；则本实施例对R核软件的引导加载程序和A核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：将微控制器域(或者MCU Domain)R核软件的引导加载程序Bootloader部署在非易失性闪存norflash中；主域(或者Main Domain)A核的软件部署在eMMC(Embedded Multi MediaCard，嵌入式多媒体卡，简称eMMC)，但是考虑到eMMC的失效概率大于norflash，所以本实施例为了提升紧急刷新功能的可靠性，将主域A核软件的引导加载程序uboot也部署在norflash；同时在norflash存放最小系统(Emergency Linux)和刷写脚本，借助上位机可以用来操作恢复eMMC中A核软件，也可以在最小系统中配置相应的norflash驱动，同时用来恢复norflash的R核软件。在本实施例中，R核软件的引导加载程序Bootloader也可以被称作为客户引导加载程序，即Customer Bootloader，简称CB；A核软件的引导加载程序uboot也可以被称作为通用引导加载程序，即universal bootloader，简称uboot。
在一示例性实施例中，步骤S120读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景的过程包括：将第一核软件的引导加载程序记为客户引导加载程序，以及，将第二核软件的引导加载程序记为通用引导加载程序。读取启动客户引导加载程序时的标志位，并确定启动客户引导加载程序时的标志位是否为紧急刷新标志位；以及，读取启动客户引导加载程序时的标志位，并确定启动客户引导加载程序时的标志位是否为紧急刷新标志位。其中，如果启动引导加载程序时的标志位为紧急刷新标志位，则对应的核软件等待进行紧急刷新。若启动客户引导加载程序时的标志位为非紧急刷新标志位，且启动客户引导加载程序时的标志位为非紧急刷新标志位，则确定当前时刻的刷新场景为正常启动场景。若启动客户引导加载程序时的标志位为紧急刷新标志位，和/或，启动客户引导加载程序时的标志位为紧急刷新标志位，则确定当前时刻的刷新场景为紧急刷新场景。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。如果读取启动R核软件的引导加载程序时的标志位为紧急刷新标志位，则将会对R核软件进行紧急刷新；如果读取启动A核软件的引导加载程序时的标志位为紧急刷新标志位，则将会对A核软件进行紧急刷新。
在一示例性实施例中，步骤S130通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，以及，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过非易失性闪存驱动擦除第一核软件的原始数据，并在第一核软件的原始数据对应地址按照配置文件写入镜像文件，以对第一核软件进行刷新；以及，通过嵌入式多媒体卡驱动擦除第二核软件的原始数据，并在第二核软件的原始数据对应地址按照配置文件写入镜像文件，以对第二核软件进行刷新。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核，预设操作系统可以是EmergencyLinux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，步骤S130通过预设操作系统和刷写脚本对第一核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过非易失性闪存驱动擦除第一核软件的原始数据，并在第一核软件的原始数据对应地址按照配置文件写入镜像文件，以对第一核软件进行刷新。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，预设操作系统可以是Emergency Linux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，步骤S130通过预设操作系统和刷写脚本对第二核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过嵌入式多媒体卡驱动擦除第二核软件的原始数据，并在第二核软件的原始数据对应地址按照配置文件写入镜像文件，以对第二核软件进行刷新。具体地，作为一示例，本实施例中的第二核可以为DRA821芯片中的A核，预设操作系统可以是Emergency Linux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，在读取启动第一核软件的引导加载程序时的标志位前，本实施例还可以还包括：接收上位机基于互联网协议的诊断协议(Diagnostic OverInternet Protocol，基于互联网协议的诊断协议，简称DoIP)，向第一核中的网关核发送的诊断指令，在DDR(Double Data Rate Synchronous Dynamic Random Access Memory，双倍速率同步动态随机存储器，简称DDR)中设置非紧急刷新标志位和紧急刷新标志位。或者，在读取启动第一核软件的引导加载程序时的标志位前，本实施例还可以还包括：接收上位机基于控制器域网协议的诊断协议(Diagnostic over Controller Area Network，基于控制器域网协议的诊断协议，简称DoCAN)，向第一核中的网关核发送的诊断指令，在DDR中设置非紧急刷新标志位和紧急刷新标志位；其中，第一核、第二核均与双倍速率同步动态随机存储器连接。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。
在一示例性实施例中，对第一核软件和/或第二核软件进行紧急刷新时，本实施例还可以包括：生成紧急刷新时的日志文件，并将日志文件上传至上位机，以通过日志文件进行刷新错误检查。作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。
在本发明一具体实施例中，该实施例以DRA821芯片为示例，提供一种基于多核控制器的软件刷新方法。其中，DRA821芯片的架构如图2所示。该软件刷新方法包括以下步骤：
步骤1：引导加载程序和最小系统的部署。
根据DRA821芯片提供的数据存储资源，将MCU Domain(微控制器域)R核软件的引导加载程序Bootloader(这里也称作客户引导加载程序，Customer Bootloader，简称CB)部署在norflash(非易失性闪存)中；Main Domain(主域)A核的软件部署在eMMC，但是考虑到eMMC的失效概率大于norflash，所以为了提升紧急刷新功能的可靠性，将Main Domain(主域)A核软件的引导加载程序uboot也部署在norflash；同时在norflash存放最小系统和刷写脚本，借助上位机可以用来操作恢复eMMC中A核软件，也可以在最小系统中配置相应的norflash驱动，同时用来恢复norflash的R核软件。
步骤2：基本启动链路的匹配。
紧急刷新的设计需要基于正常的软件启动链路。目前DRA821启动时电源PMIC(Power Management Integrated Circuit，电源管理集成电路)先启动唤醒域，再依次启动MCU Domain(微控制器域)的引导加载程序SBL(Secondary Bootloader，次级引导加载程序，简称SBL)和CB，CB引导启动R核，R核软件再启动uboot，最后再由uboot引导A核软件启动Linux系统。紧急刷新的目标是刷新R核和A核软件，所以需要在软件启动前的CB阶段进行判断是否需要紧急刷新。实现方式为在CB阶段启动过程中设计软件读取复位reset类型标志位，在原有的类型中增加一个紧急刷新标志EB(Emergency Bootloader，紧急引导加载程序，简称EB)，当读取到紧急刷新标志时，CB会触发后续的紧急刷新流程。该标志位可以通过DoIP(Diagnostic Over Internet Protocol，基于互联网协议的诊断，简称DoIP)诊断协议栈在DDR中手动修改，以达到人为控制紧急刷新的目的。
步骤3：刷新场景及策略的设计。
由于刷新对象是多核系统的多个核软件，所以存在不同的刷新场景，主要按照核软件的失效情况进行分类。
场景一：A核软件和R核软件都可以正常运行，人为需要强制进入紧急刷新。
上位机使用DoIP诊断对R核中的网关核发送诊断指令，使其在DDR设置紧急刷新标记，并触发系统紧急reset。重启后按照正常启动流程进入CB阶段时，会判断reset类型为紧急reset，不会继续正常启动，而是进入紧急刷新模式。此时CB加载uboot，由uboot启动时需要判断DDR中是否设置了紧急刷新标记，如果有，则不会正常启动A核系统而是加载最小系统emergencylinux。这样通过上位机与最小系统交互对norflash和eMMC中的已有R核和A核软件做格式化，并执行待刷镜像的下载和刷新。此外，上位机设计可以选择只刷A核软件、只刷R核软件、A核软件和R核软件都刷新，方便开发者有针对性的执行紧急刷新。
场景二：R核系统有效但A核系统失效。
若R核支持以太网协议栈，上位机采用如场景一的方法进行标记置位和触发紧急reset；若R核仅支持CAN(Controller Area Network，控制器域网，简称CAN)协议栈，则上位机使用DoCAN诊断方式对R核网关核发送诊断指令，使其标记置位和触发紧急Reset。后续过程与场景一相同，上位机中手动选择恢复A核软件，则只下载和刷新A核软件。
场景三：R核系统失效(A核系统有效或无效)。
R核软件失效时系统会自动停留在CB阶段，由于CB支持UDS(Unified DiagnosticServices，统一诊断服务，简称UDS)诊断协议，使用上位机发送诊断指定，设置紧急刷新标标记，并使其直接进入紧急刷新模式，加载uboot，后续与场景一相同，通过上位机和最小系统刷新R核。此时最小系统中应部署R核软件所在存储norflash的驱动程序，以便在刷新时能够擦除和写入norflash中R核软件分区。若A核系统失效，可以在上位机中选择同时刷新A核，将其系统恢复。
根据上述记载，在本实施例中，以场景一中同时对A核软件和R核软件进行刷新为例，图3提供了一种对A核软件和R核软件进行紧急刷新的时序示意图。具体地，
1)在R核软件正常运行时，向R核的网关核发送诊断序列，网关核会在DDR中写入标志位，并触发紧急复位事件EB Reset，使系统复位reset。其中，本实施例发送的诊断序列可进行自定义。
2)重新启动后CB阶段中识别到是本次是EB Reset，不再按照正常启动流程加载R核功能软件，而是跳转到A核软件并加载uboot；
3)在uboot中检测到先前的DDR标志位后，不再加载正常A核软件，而是跳转加载最小系统Emergency Linux，并且跳转后将标志位清除；
4)最小系统启动后自动运行刷写脚本，刷写脚本等待上位机连接；
5)建立连接成功后，从上位机工具下载配置文件和镜像文件(包含各个核需要的软件包数据)，然后安装镜像文件；
6)对于R核软件安装，最小系统通过norflash驱动擦除原有R核软件数据，并在相应地址写入下载的R核软件数据；对于A核软件安装，最小系统通过eMMC驱动擦除原有A核软件数据，并通过Linux系统安装下载的A核软件镜像；
7)同时也可上传在刷新过程中使用上位机请求查看控制器的日志log，控制器将系统中日志模块生成的日志文件上传到上位机，以便开发者在刷新出错时进行排查；
8)刷新任务完成后，通过上位机向最小系统发送Linux reboot命令使得控制器系统重启，系统重启后，在CB阶段和Uboot启动阶段未检测到特殊标志位(如紧急刷新标志位)会正常启动已刷新的R核和A核软件，使得系统正常启动。
由此可知，与面向非多核控制器的紧急刷新方案相比，本实施例支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本实施例考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。此外，本实施例可以通过上位机操作触发紧急刷新，并不局限于狭义的紧急刷新(操作系统失效后刷新)，而是可以在操作系统正常时，由于开发者需求(如软件更新/迭代后进行验证等)强制手动刷新软件。可以在控制器开发阶段使用本实施例中的软件刷新方案，从而快速更新系统软件，提高开发效率，缩短开发周期。另外，本实施例以DRA821为例介绍了引导加载程序和最小系统的软件部署在Norflash存储中，对于其他多异构核的SoC芯片，设计时一般将引导加载程序部署在其提供的可方便多次读写的外设存储资源中，如Norflash，Nandflash，eMMC或UFS(Univeral Flash Storage，通用闪存存储器，简称UFS)等flash存储类型。本实施例中提到的Linux操作系统，仅作示例，符合POSIX标准的车载操作系统皆适用于本实施例。本实施例中提到的Customer Bootloader，仅作示例，如果系统中没有Customer Bootloader，也可以利用其他Bootloader程序(如SBL等)来集成软件刷新方案。本实施例中提到的uboot，仅作示例，车载操作系统中的其他引导加载程序皆适用于本方案。
综上所述，本发明提供一种基于多核控制器的软件刷新方法，通过对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；再读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；在刷新场景为正常启动场景时，对第一核软件和第二核软件进行正常启动；或者，在刷新场景为紧急刷新场景时，通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，和/或，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新。其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。由此可知，与面向非多核控制器的紧急刷新方案相比，本方法支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本方法考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。此外，本方法可以通过上位机操作触发紧急刷新，并不局限于狭义的紧急刷新(操作系统失效后刷新)，而是可以在操作系统正常时，由于开发者需求(如软件更新/迭代后进行验证等)强制手动刷新软件。可以在控制器开发阶段使用本方法中的软件刷新方案，从而快速更新系统软件，提高开发效率，缩短开发周期。
在本发明另一实施例中，如图4所示，该实施例提供一种基于多核的软件刷新系统，包括有：
存储部署模块410，用于对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。作为一示例，本实施例中的第一核可以为R核，第二核可以为A核，目标芯片可以为DRA821芯片。作为其他示例，本实施例中的目标芯片还可以是其他以跨域ARM(Advanced RISC Machines，简称ARM)架构的异构多核SoC芯片。在本实施例或其他实施例中，预设操作系统也被称作为最小系统，例如预设操作系统可以是Emergency Linux系统。
标志位读取模块420，用于读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
软件刷新模块430，用于在刷新场景为正常启动场景时，对第一核软件和第二核软件进行正常启动；或者，在刷新场景为紧急刷新场景时，通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，和/或，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新。
由此可知，与面向非多核控制器的紧急刷新方案相比，本实施例支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本实施例考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。
在一示例性实施例中，存储部署模块410对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：将第一核软件、第一核软件的引导加载程序和第二核软件的引导加载程序部署至非易失性闪存中，并将第二核软件部署至嵌入式多媒体卡中；以及，将预设操作系统和刷写脚本部署至嵌入式多媒体卡中。具体地，作为一示例，若本实施例中的第一核为DRA821芯片中的R核，第二核为DRA821芯片中的A核，预设操作系统是Emergency Linux系统，本实施例也称Emergency Linux系统为最小系统；则本实施例对R核软件的引导加载程序和A核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：将微控制器域(或者MCU Domain)R核软件的引导加载程序Bootloader部署在非易失性闪存norflash中；主域(或者Main Domain)A核的软件部署在eMMC(Embedded Multi MediaCard，嵌入式多媒体卡，简称eMMC)，但是考虑到eMMC的失效概率大于norflash，所以本实施例为了提升紧急刷新功能的可靠性，将主域A核软件的引导加载程序uboot也部署在norflash；同时在norflash存放最小系统(Emergency Linux)和刷写脚本，借助上位机可以用来操作恢复eMMC中A核软件，也可以在最小系统中配置相应的norflash驱动，同时用来恢复norflash的R核软件。在本实施例中，R核软件的引导加载程序Bootloader也可以被称作为客户引导加载程序，即Customer Bootloader，简称CB；A核软件的引导加载程序uboot也可以被称作为通用引导加载程序，即universal bootloader，简称uboot。
在一示例性实施例中，标志位读取模块420读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景的过程包括：将第一核软件的引导加载程序记为客户引导加载程序，以及，将第二核软件的引导加载程序记为通用引导加载程序。读取启动客户引导加载程序时的标志位，并确定启动客户引导加载程序时的标志位是否为紧急刷新标志位；以及，读取启动客户引导加载程序时的标志位，并确定启动客户引导加载程序时的标志位是否为紧急刷新标志位。其中，如果启动引导加载程序时的标志位为紧急刷新标志位，则对应的核软件等待进行紧急刷新。若启动客户引导加载程序时的标志位为非紧急刷新标志位，且启动客户引导加载程序时的标志位为非紧急刷新标志位，则确定当前时刻的刷新场景为正常启动场景。若启动客户引导加载程序时的标志位为紧急刷新标志位，和/或，启动客户引导加载程序时的标志位为紧急刷新标志位，则确定当前时刻的刷新场景为紧急刷新场景。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。如果读取启动R核软件的引导加载程序时的标志位为紧急刷新标志位，则将会对R核软件进行紧急刷新；如果读取启动A核软件的引导加载程序时的标志位为紧急刷新标志位，则将会对A核软件进行紧急刷新。
在一示例性实施例中，软件刷新模块430通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，以及，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过非易失性闪存驱动擦除第一核软件的原始数据，并在第一核软件的原始数据对应地址按照配置文件写入镜像文件，以对第一核软件进行刷新；以及，通过嵌入式多媒体卡驱动擦除第二核软件的原始数据，并在第二核软件的原始数据对应地址按照配置文件写入镜像文件，以对第二核软件进行刷新。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核，预设操作系统可以是Emergency Linux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，软件刷新模块430通过预设操作系统和刷写脚本对第一核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过非易失性闪存驱动擦除第一核软件的原始数据，并在第一核软件的原始数据对应地址按照配置文件写入镜像文件，以对第一核软件进行刷新。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，预设操作系统可以是Emergency Linux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，软件刷新模块430通过预设操作系统和刷写脚本对第二核软件进行紧急刷新的过程包括：在读取到紧急刷新标志位时，通过预设操作系统运行刷写脚本，从上位机中下载配置文件和镜像文件；通过嵌入式多媒体卡驱动擦除第二核软件的原始数据，并在第二核软件的原始数据对应地址按照配置文件写入镜像文件，以对第二核软件进行刷新。具体地，作为一示例，本实施例中的第二核可以为DRA821芯片中的A核，预设操作系统可以是Emergency Linux系统；其中，本实施例也将Emergency Linux系统称为最小系统。
在一示例性实施例中，在读取启动第一核软件的引导加载程序时的标志位前，本实施例还可以还包括：接收上位机基于互联网协议的诊断协议(Diagnostic OverInternet Protocol，基于互联网协议的诊断协议，简称DoIP)，向第一核中的网关核发送的诊断指令，在DDR(Double Data Rate Synchronous Dynamic Random Access Memory，双倍速率同步动态随机存储器，简称DDR)中设置非紧急刷新标志位和紧急刷新标志位。或者，在读取启动第一核软件的引导加载程序时的标志位前，本实施例还可以还包括：接收上位机基于控制器域网协议的诊断协议(Diagnostic over Controller Area Network，基于控制器域网协议的诊断协议，简称DoCAN)，向第一核中的网关核发送的诊断指令，在DDR中设置非紧急刷新标志位和紧急刷新标志位；其中，第一核、第二核均与双倍速率同步动态随机存储器连接。具体地，作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。
在一示例性实施例中，对第一核软件和/或第二核软件进行紧急刷新时，本实施例还可以包括：生成紧急刷新时的日志文件，并将日志文件上传至上位机，以通过日志文件进行刷新错误检查。作为一示例，本实施例中的第一核可以为DRA821芯片中的R核，第二核可以为DRA821芯片中的A核。
以DRA821芯片为示例，在本发明一具体实施例中，该实施例一种基于多核控制器的软件刷新系统，该软件刷新系统用于实施以下步骤描述的软件刷新方法。其中，DRA821芯片的架构如图2所示。具体地，该软件刷新系统实施的软件刷新方法包括以下步骤：
步骤1：引导加载程序和最小系统的部署。
根据DRA821芯片提供的数据存储资源，将MCU Domain(微控制器域)R核软件的引导加载程序Bootloader(这里也称作客户引导加载程序，Customer Bootloader，简称CB)部署在norflash(非易失性闪存)中；Main Domain(主域)A核的软件部署在eMMC，但是考虑到eMMC的失效概率大于norflash，所以为了提升紧急刷新功能的可靠性，将Main Domain(主域)A核软件的引导加载程序uboot也部署在norflash；同时在norflash存放最小系统和刷写脚本，借助上位机可以用来操作恢复eMMC中A核软件，也可以在最小系统中配置相应的norflash驱动，同时用来恢复norflash的R核软件。
步骤2：基本启动链路的匹配。
紧急刷新的设计需要基于正常的软件启动链路。目前DRA821启动时电源PMIC(Power Management Integrated Circuit，电源管理集成电路)先启动唤醒域，再依次启动MCU Domain(微控制器域)的引导加载程序SBL(Secondary Bootloader，次级引导加载程序，简称SBL)和CB，CB引导启动R核，R核软件再启动uboot，最后再由uboot引导A核软件启动Linux系统。紧急刷新的目标是刷新R核和A核软件，所以需要在软件启动前的CB阶段进行判断是否需要紧急刷新。实现方式为在CB阶段启动过程中设计软件读取复位reset类型标志位，在原有的类型中增加一个紧急刷新标志EB(Emergency Bootloader，紧急引导加载程序，简称EB)，当读取到紧急刷新标志时，CB会触发后续的紧急刷新流程。该标志位可以通过DoIP(Diagnostic Over Internet Protocol，基于互联网协议的诊断，简称DoIP)诊断协议栈在DDR中手动修改，以达到人为控制紧急刷新的目的。
步骤3：刷新场景及策略的设计。
由于刷新对象是多核系统的多个核软件，所以存在不同的刷新场景，主要按照核软件的失效情况进行分类。
场景一：A核软件和R核软件都可以正常运行，人为需要强制进入紧急刷新。
上位机使用DoIP诊断对R核中的网关核发送诊断指令，使其在DDR设置紧急刷新标记，并触发系统紧急reset。重启后按照正常启动流程进入CB阶段时，会判断reset类型为紧急reset，不会继续正常启动，而是进入紧急刷新模式。此时CB加载uboot，由uboot启动时需要判断DDR中是否设置了紧急刷新标记，如果有，则不会正常启动A核系统而是加载最小系统emergencylinux。这样通过上位机与最小系统交互对norflash和eMMC中的已有R核和A核软件做格式化，并执行待刷镜像的下载和刷新。此外，上位机设计可以选择只刷A核软件、只刷R核软件、A核软件和R核软件都刷新，方便开发者有针对性的执行紧急刷新。
场景二：R核系统有效但A核系统失效。
若R核支持以太网协议栈，上位机采用如场景一的方法进行标记置位和触发紧急reset；若R核仅支持CAN(Controller Area Network，控制器域网，简称CAN)协议栈，则上位机使用DoCAN诊断方式对R核网关核发送诊断指令，使其标记置位和触发紧急Reset。后续过程与场景一相同，上位机中手动选择恢复A核软件，则只下载和刷新A核软件。
场景三：R核系统失效(A核系统有效或无效)。
R核软件失效时系统会自动停留在CB阶段，由于CB支持UDS(Unified DiagnosticServices，统一诊断服务，简称UDS)诊断协议，使用上位机发送诊断指定，设置紧急刷新标标记，并使其直接进入紧急刷新模式，加载uboot，后续与场景一相同，通过上位机和最小系统刷新R核。此时最小系统中应部署R核软件所在存储norflash的驱动程序，以便在刷新时能够擦除和写入norflash中R核软件分区。若A核系统失效，可以在上位机中选择同时刷新A核，将其系统恢复。
根据上述记载，在本实施例中，以场景一中同时对A核软件和R核软件进行刷新为例，图3提供了一种对A核软件和R核软件进行紧急刷新的时序示意图。具体地，
1)在R核软件正常运行时，向R核的网关核发送诊断序列，网关核会在DDR中写入标志位，并触发紧急复位事件EB Reset，使系统复位reset。其中，本实施例发送的诊断序列可进行自定义。
2)重新启动后CB阶段中识别到是本次是EB Reset，不再按照正常启动流程加载R核功能软件，而是跳转到A核软件并加载uboot；
3)在uboot中检测到先前的DDR标志位后，不再加载正常A核软件，而是跳转加载最小系统Emergency Linux，并且跳转后将标志位清除；
4)最小系统启动后自动运行刷写脚本，刷写脚本等待上位机连接；
5)建立连接成功后，从上位机工具下载配置文件和镜像文件(包含各个核需要的软件包数据)，然后安装镜像文件；
6)对于R核软件安装，最小系统通过norflash驱动擦除原有R核软件数据，并在相应地址写入下载的R核软件数据；对于A核软件安装，最小系统通过eMMC驱动擦除原有A核软件数据，并通过Linux系统安装下载的A核软件镜像；
7)同时也可上传在刷新过程中使用上位机请求查看控制器的日志log，控制器将系统中日志模块生成的日志文件上传到上位机，以便开发者在刷新出错时进行排查；
8)刷新任务完成后，通过上位机向最小系统发送Linux reboot命令使得控制器系统重启，系统重启后，在CB阶段和Uboot启动阶段未检测到特殊标志位(如紧急刷新标志位)会正常启动已刷新的R核和A核软件，使得系统正常启动。
由此可知，与面向非多核控制器的紧急刷新方案相比，本实施例支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本实施例考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。此外，本实施例可以通过上位机操作触发紧急刷新，并不局限于狭义的紧急刷新(操作系统失效后刷新)，而是可以在操作系统正常时，由于开发者需求(如软件更新/迭代后进行验证等)强制手动刷新软件。可以在控制器开发阶段使用本实施例中的软件刷新方案，从而快速更新系统软件，提高开发效率，缩短开发周期。另外，本实施例以DRA821为例介绍了引导加载程序和最小系统的软件部署在Norflash存储中，对于其他多异构核的SoC芯片，设计时一般将引导加载程序部署在其提供的可方便多次读写的外设存储资源中，如Norflash，Nandflash，eMMC或UFS(Univeral Flash Storage，通用闪存存储器，简称UFS)等flash存储类型。本实施例中提到的Linux操作系统，仅作示例，符合POSIX标准的车载操作系统皆适用于本实施例。本实施例中提到的Customer Bootloader，仅作示例，如果系统中没有Customer Bootloader，也可以利用其他Bootloader程序(如SBL等)来集成软件刷新方案。本实施例中提到的uboot，仅作示例，车载操作系统中的其他引导加载程序皆适用于本方案。
综上所述，本发明提供一种基于多核控制器的软件刷新方法，通过对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；再读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；在刷新场景为正常启动场景时，对第一核软件和第二核软件进行正常启动；或者，在刷新场景为紧急刷新场景时，通过预设操作系统和刷写脚本对第一核软件进行紧急刷新，和/或，通过预设操作系统和刷写脚本对第二核软件进行紧急刷新。其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器。由此可知，与面向非多核控制器的紧急刷新方案相比，本系统支持在一次刷新操作中对部署在多核的软件同时进行刷新，而且无需切换刷新设备、上位机程序和多次重启等操作，直接提升了刷新效率；同时，本系统考虑到了多核系统运行时的多种失效场景，满足在多种失效场景下进行多核软件的刷新，相比面向单核失效的紧急刷新方向，具有更高的适用性。此外，本系统可以通过上位机操作触发紧急刷新，并不局限于狭义的紧急刷新(操作系统失效后刷新)，而是可以在操作系统正常时，由于开发者需求(如软件更新/迭代后进行验证等)强制手动刷新软件。可以在控制器开发阶段使用本系统中的软件刷新方案，从而快速更新系统软件，提高开发效率，缩短开发周期。
需要说明的是，上述实施例所提供基于多核的软件刷新系统与上述实施例所提供的基于多核的软件刷新方法属于同一构思，其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的基于多核的软件刷新系统在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。
在本发明另一实施例中，该实施例还提供一种车辆，该车辆包括有至少一个目标芯片，该目标芯片应用于上述中任一实施例中描述基于多核的软件刷新方法。需要说明的是，本实施例所提供车辆与上述实施例所提供的基于多核的软件刷新方法属于同一构思，其中软件刷新方法的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。
本发明实施例还提供了一种基于多核的软件刷新设备，该设备可以包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述设备执行图1所述的基于多核的软件刷新方法。图5示出了一种基于多核的软件刷新设备1000的结构示意图。参阅图5所示，基于多核的软件刷新设备1000包括：处理器1010、存储器1020、电源1030、显示单元1040、输入单元1060。
处理器1010是基于多核的软件刷新设备1000的控制中心，利用各种接口和线路连接各个部件，通过运行或执行存储在存储器1020内的软件程序和/或数据，执行基于多核的软件刷新设备1000的各种功能，从而对基于多核的软件刷新设备1000进行整体监控。本发明实施例中，处理器1010调用存储器1020中存储的计算机程序时执行如图1所述的基于多核的软件刷新方法。可选的，处理器1010可包括一个或多个处理单元；优选的，处理器1010可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用等，调制解调处理器主要处理无线通信。在一些实施例中，处理器、存储器、可以在单一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、各种应用等；存储数据区可存储根据基于多核的软件刷新设备1000的使用所创建的数据等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件等。
基于多核的软件刷新设备1000还包括给各个部件供电的电源1030(比如电池)，电源可以通过电源管理系统与处理器1010逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗等功能。
显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及基于多核的软件刷新设备1000的各种菜单等，本发明实施例中主要用于显示基于多核的软件刷新设备1000中各应用的显示界面以及显示界面中显示的文本、图片等对象。显示单元1040可以包括显示面板1050。显示面板1050可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置。
输入单元1060可用于接收用户输入的数字或字符等信息。输入单元1060可包括触控面板1070以及其他输入设备1080。其中，触控面板1070，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触摸笔等任何适合的物体或附件在触控面板1070上或在触控面板1070附近的操作)。
具体的，触控面板1070可以检测用户的触摸操作，并检测触摸操作带来的信号，将这些信号转换成触点坐标，发送给处理器1010，并接收处理器1010发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1070。其他输入设备1080可以包括但不限于物理键盘、功能键(比如音量控制按键、开关机按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
当然，触控面板1070可覆盖显示面板1050，当触控面板1070检测到在其上或附近的触摸操作后，传送给处理器1010以确定触摸事件的类型，随后处理器1010根据触摸事件的类型在显示面板1050上提供相应的视觉输出。虽然在图5中，触控面板1070与显示面板1050是作为两个独立的部件来实现基于多核的软件刷新设备1000的输入和输出功能，但是在某些实施例中，可以将触控面板1070与显示面板1050集成而实现基于多核的软件刷新设备1000的输入和输出功能。
基于多核的软件刷新设备1000还可包括一个或多个传感器，例如压力传感器、重力加速度传感器、接近光传感器等。当然，根据具体应用中的需要，上述基于多核的软件刷新设备1000还可以包括摄像头等其它部件。
本发明实施例还提供了一种计算机可读存储介质，该存储介质中存储有指令，当一个或多个处理器执行所述指令时，使得上述设备能够执行本发明中如图1所述的基于多核的软件刷新方法。
本领域技术人员可以理解的是，图5仅仅是基于多核的软件刷新设备的举例，并不构成对该设备的限定，该设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件。为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本发明时，可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的，应理解为可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。这些计算机程序指令可应用至通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器中以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
应当理解的是，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述预设范围等，但这些预设范围不应限于这些术语。这些术语仅用来将预设范围彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一预设范围也可以被称为第二预设范围，类似地，第二预设范围也可以被称为第一预设范围。
上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种基于多核的软件刷新方法，其特征在于，所述方法包括以下步骤：
对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器；
读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
在所述刷新场景为正常启动场景时，对所述第一核软件和所述第二核软件进行正常启动；或者，在所述刷新场景为紧急刷新场景时，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，和/或，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新。
2.根据权利要求1所述的基于多核的软件刷新方法，其特征在于，对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署的过程包括：
将第一核软件、第一核软件的引导加载程序和第二核软件的引导加载程序部署至非易失性闪存中，并将第二核软件部署至嵌入式多媒体卡中；以及，
将预设操作系统和刷写脚本部署至所述嵌入式多媒体卡中。
3.根据权利要求2所述的基于多核的软件刷新方法，其特征在于，读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景的过程包括：
将第一核软件的引导加载程序记为客户引导加载程序，以及，将第二核软件的引导加载程序记为通用引导加载程序；
读取启动所述客户引导加载程序时的标志位，并确定启动所述客户引导加载程序时的标志位是否为紧急刷新标志位；以及，读取启动所述客户引导加载程序时的标志位，并确定启动所述客户引导加载程序时的标志位是否为紧急刷新标志位；
若启动所述客户引导加载程序时的标志位为非紧急刷新标志位，且启动所述客户引导加载程序时的标志位为非紧急刷新标志位，则确定当前时刻的刷新场景为正常启动场景；
若启动所述客户引导加载程序时的标志位为紧急刷新标志位，和/或，启动所述客户引导加载程序时的标志位为紧急刷新标志位，则确定当前时刻的刷新场景为紧急刷新场景；
其中，如果启动引导加载程序时的标志位为紧急刷新标志位，则对应的核软件等待进行紧急刷新。
4.根据权利要求1或3所述的基于多核的软件刷新方法，其特征在于，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，以及，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新的过程包括：
在读取到紧急刷新标志位时，通过所述预设操作系统运行所述刷写脚本，从上位机中下载配置文件和镜像文件；
通过非易失性闪存驱动擦除所述第一核软件的原始数据，并在所述第一核软件的原始数据对应地址按照所述配置文件写入所述镜像文件，以对所述第一核软件进行刷新；以及，
通过嵌入式多媒体卡驱动擦除所述第二核软件的原始数据，并在所述第二核软件的原始数据对应地址按照所述配置文件写入所述镜像文件，以对所述第二核软件进行刷新。
5.根据权利要求1或3所述的基于多核的软件刷新方法，其特征在于，在读取启动第一核软件的引导加载程序时的标志位前，所述方法还包括：
接收上位机基于互联网协议的诊断协议，向第一核中的网关核发送的诊断指令，在双倍速率同步动态随机存储器中设置非紧急刷新标志位和紧急刷新标志位；或者，
接收上位机基于控制器域网协议的诊断协议，向第一核中的网关核发送的诊断指令，在双倍速率同步动态随机存储器中设置非紧急刷新标志位和紧急刷新标志位；
其中，所述第一核、所述第二核均与所述双倍速率同步动态随机存储器连接。
6.根据权利要求4所述的基于多核的软件刷新方法，其特征在于，对所述第一核软件和/或所述第二核软件进行紧急刷新时，所述方法还包括：生成紧急刷新时的日志文件，并将所述日志文件上传至所述上位机，以通过所述日志文件进行刷新错误检查。
7.一种基于多核的软件刷新系统，其特征在于，所述系统包括有：
存储部署模块，用于对第一核软件的引导加载程序和第二核软件的引导加载程序进行存储部署，以及，对预设操作系统和刷写脚本进行存储部署；其中，第一核和第二核为位于同一目标芯片中的两个异构核处理器；
标志位读取模块，用于读取启动第一核软件的引导加载程序时的标志位、以及读取启动第二核软件的引导加载程序时的标志位，并根据标志位读取结果确定刷新场景；
软件刷新模块，用于在所述刷新场景为正常启动场景时，对所述第一核软件和所述第二核软件进行正常启动；或者，在所述刷新场景为紧急刷新场景时，通过所述预设操作系统和所述刷写脚本对所述第一核软件进行紧急刷新，和/或，通过所述预设操作系统和所述刷写脚本对所述第二核软件进行紧急刷新。
8.一种车辆，其特征在于，所述车辆包括有应用于如权利要求1至6中任一所述基于多核的软件刷新方法中的目标芯片。
9.一种基于多核的软件刷新设备，其特征在于，包括：
处理器；和，
存储有指令的计算机可读介质，当所述处理器执行所述指令时，使得所述设备执行如权利要求1至6中任意一项所述的基于多核的软件刷新方法。
10.一种计算机可读介质，其特征在于，其上存储有指令，所述指令由处理器加载并执行如权利要求1至6中任意一项所述的基于多核的软件刷新方法。
CN202311244569.8A 2023-09-25 2023-09-25 一种基于多核的软件刷新方法、系统、设备及介质、车辆 Pending CN117348939A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311244569.8A CN117348939A (zh) 2023-09-25 2023-09-25 一种基于多核的软件刷新方法、系统、设备及介质、车辆

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311244569.8A CN117348939A (zh) 2023-09-25 2023-09-25 一种基于多核的软件刷新方法、系统、设备及介质、车辆

Publications (1)

Publication Number Publication Date
CN117348939A true CN117348939A (zh) 2024-01-05

Family

ID=89368249

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311244569.8A Pending CN117348939A (zh) 2023-09-25 2023-09-25 一种基于多核的软件刷新方法、系统、设备及介质、车辆

Country Status (1)

Country Link
CN (1) CN117348939A (zh)

Similar Documents

Publication Publication Date Title
RU2568280C2 (ru) Быстрый запуск компьютера
JP6627180B2 (ja) 改善されたハイブリッドスリープ電力管理のための技術
US10754558B2 (en) Vehicular device
US9910664B2 (en) System and method of online firmware update for baseboard management controller (BMC) devices
US7047403B2 (en) Method and system for operating system recovery and method of using build-to-configuration mode to model computer system
KR101931007B1 (ko) 컴퓨팅 디바이스의 초기화 트레이스
EP2652599B1 (en) System reset
US20120191960A1 (en) Booting computing devices
US20070174689A1 (en) Computer platform embedded operating system backup switching handling method and system
US20080010446A1 (en) Portable apparatus supporting multiple operating systems and supporting method therefor
US20110179260A1 (en) Method for integrating operating system into bios chip and method for booting operating system from server
CN104185836A (zh) 用于在系统改变之后验证计算设备的适当操作的方法和系统
TW201502764A (zh) 用以從睡眠狀態加速回復之專用啟動路徑
CN105760191A (zh) 嵌入式系统设备程序烧写量产方法
CN113703799B (zh) 计算设备及其bios更新方法和介质
CN101021797A (zh) 一种用于嵌入式系统的软件修复和升级方法
CN103514015A (zh) 一种从存储介质中启动操作系统的方法和装置
US20100049961A1 (en) Update method for basic input/output system and update system thereof
US20130080751A1 (en) Method and device for updating bios program for computer system
CN102262555B (zh) 加载java三方库的不同版本的方法和装置
US9250942B2 (en) Hardware emulation using on-the-fly virtualization
CN110096882B (zh) 一种设备运行过程中的安全度量方法
CN109634782B (zh) 一种系统健壮性的检测方法、装置、存储介质及终端
CN101923503B (zh) 调整内存内部参数的方法及使用其的电脑系统
CN117348939A (zh) 一种基于多核的软件刷新方法、系统、设备及介质、车辆

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