Multi-core automotive SoC software upgrade partition switching method and storage media

Abstract

This invention discloses a method for multi-core automotive SoC software upgrade partition switching, comprising: determining the ID of the core to be upgraded and reading the upgrade configuration parameters corresponding to the ID; determining the active partition and the partition to be upgraded of the current upgrade core; verifying the upgrade file, and if the verification is successful, the core upgrade is considered complete; first backing up the original configuration parameters to the parameter backup area, and then updating the original configuration parameters to perform partition switching; reading the original configuration parameters and verifying them; if the original configuration parameters are verified successfully, starting each core of the SoC one by one; if the original configuration parameters are verified unsuccessfully, reading the backup configuration parameters and verifying them; if the backup configuration parameters are verified successfully, determining the startup partition of each core, and starting each core of the SoC one by one according to the startup sequence; if the backup configuration parameters are verified unsuccessfully, attempting to repair the configuration parameters based on the read original configuration parameters and backup configuration parameters; if the verification is successful after repair, the parameter repair is considered successful, otherwise exiting the multi-core SoC system startup process.

Description

Technical Field

[0001] This invention relates to the automotive field, and in particular to a method for switching partitions during a multi-core automotive SoC software upgrade, and a computer-readable storage medium for performing the steps of the method. Background Technology

[0002] OTA (Over-The-Air) upgrade is a technology that downloads upgrade packages to devices via a wireless network to update the device's system firmware or application software. Currently, OTA upgrade technology is widely used in the computer and smartphone industries for firmware upgrades. However, during OTA upgrades on PCs or smartphones, after the firmware upgrade package is downloaded, the system restarts into a minimal system mode to complete the installation. Only after installation is complete and the system restarts again can it enter normal user application mode. During the firmware upgrade process, users cannot use the device's functions normally, degrading the user experience.

[0003] With the development of automotive intelligence and connectivity, OTA (Over-The-Air) upgrade technology has been widely applied in the field of vehicle controllers. Currently, to improve the stability and user experience during upgrades of the Electronic Control Unit (ECU), a seamless A / B partition upgrade method is generally adopted. This means the upgrade partition is typically set up as two partitions, A and B, with identical partition types and sizes. One partition, the active partition, stores the currently running program; during an OTA upgrade, the application to be upgraded is installed to the other partition, the inactive partition. After the upgrade is complete, the system will boot from the upgraded partition upon restart. Compared to a single-partition system with only one partition, the A / B dual-partition system ensures that the system does not need to switch to a minimal mode during OTA upgrades, and can complete the upgrade in normal operating mode, improving the user experience during OTA upgrades. Furthermore, in the event of an upgrade failure, the A / B dual-partition system can still boot from the previously working partition, avoiding the situation where the terminal cannot function properly after a failed upgrade in a single-partition system, significantly improving upgrade stability.

[0004] Currently, there are many upgrade methods and solutions available for single-partition or multi-partition OTA upgrades of single-core SoCs. In order to meet the increasingly complex needs of intelligent driving scenarios in automobiles, high-performance multi-core SoCs are gradually being used in the automotive field. When multi-core SoCs are upgraded via OTA, it involves partition upgrades and switching of multiple cores, and the partition switching and management issues are becoming increasingly important.

[0005] Therefore, OTA software upgrades for multi-core SoCs require a complete and reliable partition switching method and system. Summary of the Invention

[0006] The summary of this invention introduces a series of simplified concepts, all of which are simplifications of existing technologies in the field, and will be further explained in detail in the detailed description section. This summary is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0007] The technical problem to be solved by the present invention is to provide a partition switching method that can perform single-core and / or multi-core automotive SoC software upgrades as needed.

[0008] The present invention also provides a storage medium for performing the steps in the multi-core automotive SoC software upgrade partition switching method.

[0009] To address the aforementioned technical problems, the present invention provides a multi-core automotive SoC software upgrade partition switching method, comprising the following steps:

[0010] S1 assigns an ID to each core that supports upgrades in a multi-core SoC, and each core forms an independent upgrade configuration parameter;

[0011] S2, When an upgrade request is received, determine the ID of the core to be upgraded and read the upgrade configuration parameters corresponding to that ID;

[0012] S3, determine the active partition and the partition to be upgraded for the current upgrade core;

[0013] S4. Check if the corresponding upgrade file exists. If it exists, install the program to be upgraded to the inactive partition of the upgrade partition. After the installation is completed, verify the upgrade file. If the verification is successful, the core upgrade is considered to be completed. Otherwise, the upgrade is considered to have failed and the upgrade mode is exited directly.

[0014] S5, after the core upgrade is completed, if an upgrade request for other cores is received, repeat the above steps to upgrade other cores until all cores are upgraded;

[0015] S6: First, back up the original configuration parameters to the parameter backup area, then update the original configuration parameters to switch partitions;

[0016] S7: Upon receiving a reset command, the system restarts; after restarting, it reads and verifies the original configuration parameters.

[0017] S8: If the original configuration parameters are successfully verified, determine the boot partition of each core and start each core of the SoC one by one according to the boot sequence.

[0018] If the original configuration parameters fail to be verified, read the backup configuration parameters and verify them.

[0019] S9: If the backup configuration parameters are successfully verified, determine the boot partition of each core and start each core of the SoC one by one according to the boot sequence.

[0020] If the backup configuration parameter verification fails, attempt to repair the configuration parameters based on the original configuration parameters and the backup configuration parameters read.

[0021] S10 If the verification is successful after repair, the parameter repair is considered successful, and the partition boot process is performed according to the original configuration parameters; otherwise, the configuration parameter repair is considered to have failed, and the multi-core SoC system boot process is exited.

[0022] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved, and the upgrade configuration parameters include:

[0023] (1) ValidFlag, which indicates the validity of the kernel upgrade configuration parameter data;

[0024] (2)CrcH, the Cr check value for each kernel parameter region;

[0025] (3) Counter, upgrade the loop counter value, and add 1 to the original value for each successful upgrade;

[0026] (4) Part indicates that all partitions of this core are currently in partition A or partition B.

[0027] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved, with each core having a unique identifier ID.

[0028] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved. In step S6, the Counter upgrade loop count value is increased by 1 based on the original value, the Part parameter value is updated to complete the partition switching, and the Crc check value is recalculated to complete the update of the CrcH field.

[0029] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved by performing parameter verification on the ValidFlag field and the CrcH field.

[0030] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved, and the configuration parameters can be fixed, including:

[0031] (a) If the ValidFlag field of the original configuration parameter and the backup configuration parameter are invalid or the Part field is invalid, all configuration parameters are considered invalid, and the parameter repair process is exited directly.

[0032] (b) If the parameter repair process is initiated, the Counter parameter in the original parameter area is repaired using the Counter parameter in the backup parameter area;

[0033] (c) Calculate the CRC of the repaired fields and verify them with the CrcH field of the original parameter area. If the verification is successful, the parameter repair is considered successful and the multi-core boot system performs the partition boot process according to the Part parameter of the original parameter area. Otherwise, the configuration parameter repair is considered to have failed and the multi-core SoC system boot process is exited.

[0034] The present invention provides a computer-readable storage medium having a program stored therein, which, when executed, is used to implement the steps in any of the above-described multi-core automotive SoC software upgrade partition switching methods.

[0035] The multi-core automotive SoC software upgrade partition switching method provided by this invention can effectively solve the partition switching problem of each core after a multi-core automotive SoC OTA upgrade. The method includes verification and repair mechanisms. If the upgraded boot parameters are found to be incorrect after the upgrade restart, the backup parameters are read and the system switches to the original partition before the upgrade for booting. If both the original and backup parameters are unsuccessful in verification, the parameters are repaired through a repair scheme, which can effectively improve the reliability and stability of multi-core SoC system OTA upgrades. Attached Figure Description

[0036] The accompanying drawings are intended to illustrate the general characteristics of the methods, structures, and / or materials used in specific exemplary embodiments of the invention, supplementing the description in the specification. However, the drawings are schematic diagrams not drawn to scale and may not accurately reflect the precise structural or performance characteristics of any of the given embodiments. The drawings should not be construed as limiting or restricting the range of numerical values ​​or properties covered by exemplary embodiments of the invention. The invention will now be described in further detail with reference to the accompanying drawings and specific embodiments:

[0037] Figure 1 This is a schematic diagram of the principle of the first embodiment of the present invention.

[0038] Figure 2 This is a schematic diagram of the principle of the second embodiment of the present invention. Detailed Implementation

[0039] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can fully understand other advantages and technical effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through different specific embodiments, and the details in this specification can also be applied based on different viewpoints, with various modifications or changes made without departing from the overall design concept of the invention. It should be noted that, unless otherwise specified, the following embodiments and features can be combined with each other. The following exemplary embodiments of the present invention can be implemented in many different forms and should not be construed as being limited to the specific embodiments set forth herein. It should be understood that these embodiments are provided to make the disclosure of the present invention thorough and complete, and to fully convey the technical solutions of these exemplary embodiments to those skilled in the art.

[0040] First embodiment;

[0041] refer to Figure 1 As shown, the multi-core automotive SoC software upgrade partition switching method provided by the present invention includes the following steps:

[0042] S1 assigns an ID to each core of the multi-core SoC that supports upgrades: Core1, Core2, Core3…, creating independent upgrade configuration parameters for each core; see reference Figure 2 As shown, the upgrade configuration parameters include:

[0043] (1) ValidFlag, which indicates the validity of the kernel upgrade configuration parameter data;

[0044] (2)CrcH, the Cr check value for each kernel parameter region;

[0045] (3) Counter, upgrade the loop counter value, and add 1 to the original value for each successful upgrade;

[0046] (4) Part indicates that all partitions of this core are currently in partition A or partition B;

[0047] S2, the SoC upgrade engine module receives a request from the upper-layer application to upgrade Core1 and reads the configuration parameters corresponding to Core1 in the original upgrade parameter area;

[0048] S3 determines the current active partition and the partition to be upgraded of Core1 based on the read configuration parameters;

[0049] S4. Check if the corresponding upgrade file exists. If it exists, install the program to be upgraded to the inactive partition of the upgrade partition. After the installation is completed, verify the upgrade file. If the verification is successful, the core upgrade is considered to be completed. Otherwise, the upgrade is considered to have failed and the upgrade mode is exited directly.

[0050] Install the files to be upgraded to the Core1 partition to be upgraded and verify the integrity of the files after installation. If the installation fails, exit directly.

[0051] Upon receiving a request from the upper-layer application to upgrade to Core2, read the configuration parameters corresponding to Core2 in the original upgrade parameter area;

[0052] Based on the read configuration parameters, determine the current active partition and the partition to be upgraded in Core2;

[0053] Install the files to be upgraded to the Core2 partition to be upgraded and verify the integrity of the files after installation. If the installation fails, exit directly.

[0054] S5, after the core upgrade is completed, if an upgrade request for other cores is received, repeat the above steps to upgrade other cores until all cores are upgraded;

[0055] S6, first back up the original data of the configuration parameter storage area to the backup parameter area, and then update the original configuration parameters of the upgraded core: the Counter upgrade loop count value is increased by 1 based on the original value, the parameter Part value is updated (if Part is currently 0x01, then it is updated to 0x02; if Part is currently 0x02, then it is updated to 0x01) to complete the partition switching, and the Crc check value is recalculated to complete the update of the CrcH field;

[0056] S7, upon receiving a reset command, the system restarts; after restarting, it reads the original configuration parameters of the multi-core boot system and performs validation of the ValidFlag and CrcH fields;

[0057] S8: If the original configuration parameters are successfully verified, determine the boot partition of each core and start each core of the SoC one by one according to the boot sequence.

[0058] If the original configuration parameters fail to be validated, the backup configuration parameters are read and the ValidFlag and CrcH fields are validated.

[0059] S9: If the backup configuration parameters are successfully verified, determine the boot partition of each core and start each core of the SoC one by one according to the boot sequence.

[0060] If the backup configuration parameter verification fails, the system will attempt to repair the configuration parameters based on the original and backup configuration parameters read, including:

[0061] (a) If the ValidFlag field of the original configuration parameter and the backup configuration parameter are invalid or the Part field is invalid, all configuration parameters are considered invalid, and the parameter repair process is exited directly.

[0062] (b) If the parameter repair process is initiated, the Counter parameter in the original parameter area is repaired using the Counter parameter in the backup parameter area;

[0063] (c) Calculate the CRC of the repaired fields and verify them with the CrcH field of the original parameter area. If the verification is successful, the parameter repair is considered successful and the multi-core boot system performs the partition boot process according to the Part parameter of the original parameter area. Otherwise, the configuration parameter repair is considered to have failed and the multi-core SoC system boot process is exited.

[0064] S10 If the verification is successful after repair, the parameter repair is considered successful, and the partition boot process is performed according to the original configuration parameters; otherwise, the configuration parameter repair is considered to have failed, and the multi-core SoC system boot process is exited.

[0065] Optionally, the multi-core automotive SoC software upgrade partition switching method can be further improved.

[0066] The present invention provides a computer-readable storage medium having a program stored therein, which, when executed, is used to implement the steps in the above-described multi-core automotive SoC software upgrade partition switching method.

[0067] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It will also be understood that, unless expressly defined herein, terms such as those defined in a general dictionary shall be interpreted as having the meaning consistent with their meaning in the relevant field context, and not as having an idealized or overly formal meaning.

[0068] The present invention has been described in detail above through specific embodiments and examples, but these are not intended to limit the invention. Many modifications and improvements can be made by those skilled in the art without departing from the principles of the invention, and these should also be considered within the scope of protection of the present invention.

Claims

1. A multi-core in-vehicle SoC software upgrade partition switching method, characterized in that, The method comprises the following steps: S1, marking each core of a multi-core SoC supporting upgrade with an ID respectively, and each core forms an independent upgrade configuration parameter; S2, when receiving an upgrade request, judging the ID of the core to be upgraded and reading the upgrade configuration parameter corresponding to the ID; S3, determining the active partition and the partition to be upgraded of the current core; S4, checking whether the corresponding upgrade file exists, and if yes, installing the program to be upgraded to the non-active partition of the upgrade partition; After the installation, the upgrade file is checked, and if the check is successful, the core is considered to be upgraded, otherwise, the upgrade is considered to fail and the upgrade mode is directly exited; S5, after the core is upgraded, if an upgrade request of another core is received, the above steps are repeated to upgrade the other core until all the cores are upgraded; S6, backing up the original configuration parameter to a parameter backup area, and then updating the original configuration parameter to switch the partition; S7, when receiving a reset instruction, the system is restarted; After the restart, the original configuration parameter is read and checked; S8, if the original configuration parameter is checked successfully, the start partition of each core is judged, and each core of the SoC is started according to the start timing; If the original configuration parameter is checked unsuccessfully, the backup configuration parameter is read and checked; S9, if the backup configuration parameter is checked successfully, the start partition of each core is judged, and each core of the SoC is started according to the start timing; If the backup configuration parameter is checked unsuccessfully, the configuration parameter is repaired according to the read original configuration parameter and the backup configuration parameter; S10, if the repair is checked successfully, the parameter repair is considered to be successful, the partition start process is performed according to the original configuration parameter, otherwise, the configuration parameter repair is considered to fail, and the multi-core SoC system start process is exited.

2. The multi-core automotive SoC software upgrade partition switching method as described in claim 1, characterized in that, The upgrade configuration parameter comprises: (1) ValidFlag, representing the validity of the core upgrade configuration parameter data; (2) CrcH, the Crc check value of each core parameter area; (3) Counter, the upgrade cycle count value, which is increased by 1 based on the original value each time the upgrade is successful; (4) Part, indicating that all partitions of the core are currently in A partition or B partition.

3. The method of claim 1, wherein: The marking ID of each core is unique.

4. The method of claim 2, wherein: When the step S6 is implemented, the Counter upgrade cycle count value is increased by 1 based on the original value, the parameter Part value is updated to complete the partition switching, and the Crc check value is recalculated to complete the update of the CrcH field.

5. The method of claim 2, wherein: The parameter check is the check of the ValidFlag field and the CrcH field.

6. The method of claim 2, wherein the software upgrade partition switching of the multi-core in-vehicle SoC is performed by a software upgrade partition switching module. The repaired configuration parameter comprises: (a) if the original configuration parameter and the backup configuration parameter ValidFlag field are invalid values or the Part field is an invalid value, all the configuration parameters are considered to be invalid, and the parameter repair process is directly exited; (b) if the parameter repair process is entered, the Counter parameter of the original parameter area is repaired by using the Counter parameter of the backup parameter area. (c) performing crc calculation on the repaired field and checking with the CrcH field of the original parameter area, if the checking is successful, it is considered that the parameter repair is successful, and the multi-core starts the system startup process according to the Part parameter of the original parameter area, otherwise, it is considered that the configuration parameter repair fails, and the multi-core SoC system startup process is exited.

7. A computer-readable storage medium having stored therein a program, characterized by: The program is executed to implement the steps in the multi-core vehicle-mounted SoC software upgrade partition switching method of any one of claims 1-6.

Images