System upgrading control method, controller, vehicle and storage medium

Abstract

The invention discloses a system upgrading control method, a controller, a vehicle and a storage medium. According to the method and the device, when the target equipment loads the upgraded first mirror image file to carry out system boot, integrity verification on the first mirror image file is added. Based on the integrity verification result of the first mirror image file, starting control is conducted on the target device. Thus, in the process of system upgrading of the target device, the situation that the first mirror image file generates an updating error can be found in time, and starting control is performed on the target device based on the integrity verification result, so that the stability of system upgrading of the target device is improved.

Description

Technical Field

[0001] The present application relates to the field of device control technology, and in particular to a control method, controller, vehicle, and storage medium for system upgrades. Background Art

[0002] System upgrade refers to the process of updating the software of a computer system, mobile device or other electronic device. When a product enters the maintenance and upgrade stage after mass production and release, since on-site updates are not feasible, remote over-the-air (OTA) upgrades are usually adopted. OTA is a system upgrade method that uses wireless communication technology to transmit and update data. To ensure functional safety, dual-image technology can be used to ensure system stability when OTA is enabled for system upgrades. Dual images can usually include a main image for running the updated version of the firmware and a backup image that includes a stable standardized firmware version. If the new firmware in the main image fails to upgrade, the device can still roll back to the previous stable version and start the device through the backup image. However, when the new firmware fails to be fully updated due to power outages or other reasons during the OTA upgrade, or even updates incorrect data, it is easy to cause the device to be unable to start from the main image and unable to fall back to the backup image, causing the entire system of the device to enter a deadlock state and unable to start the device normally. Summary of the Invention

[0003] The present application provides a system upgrade control method, controller, vehicle and storage medium, which improve the stability of the system upgrade to at least partially solve the above-mentioned technical problems.

[0004] To achieve the above objectives, according to a first aspect of the present application, a system upgrade control method is provided, comprising:

[0005] When the target device loads the upgraded first image file to boot the system, performing an integrity check on the first image file;

[0006] The target device is started and controlled according to the integrity check result of the first image file.

[0007] Optionally, performing integrity verification on the first image file includes:

[0008] Obtaining first verification information according to first data in the first image file;

[0009] If the first verification information matches the pre-stored second verification information, it is determined that the integrity verification result of the first image file is that the file is complete.

[0010] Optionally, performing integrity verification on the first image file includes:

[0011] If the first verification information does not match the second verification information, it is determined that the integrity verification result of the first image file is that the file is incomplete.

[0012] Optionally, the performing startup control on the target device according to the integrity check result of the first image file includes:

[0013] If the integrity check result of the first image file is that the file is intact, the first image file is used to start the target device.

[0014] Optionally, starting the target device using the first image file includes:

[0015] Switching the boot loading address of the target device to the first address of the first partition, wherein the first address is the address of the first image file;

[0016] The target device is started according to the startup loading address.

[0017] Optionally, the performing startup control on the target device according to the integrity check result of the first image file includes:

[0018] If the integrity check result of the first image file is that the file is incomplete, the second image file is run to re-upgrade the first image file, so as to start the target device using the re-upgraded first image file.

[0019] Optionally, before running the second image file, the method includes:

[0020] A mode for running the second image file is determined according to a state of a first-stage loader of the first image file during an upgrade of the first image file.

[0021] Optionally, determining the mode of running the second image file according to a state of a first-stage loader of the first image file during the upgrade of the first image file includes:

[0022] In response to the state of the first-stage loader being a normal state, and in response to a software reset operation on the target device, the second image file is run.

[0023] Optionally, determining the mode of running the second image file according to a state of a first-stage loader of the first image file during the upgrade of the first image file includes:

[0024] If the state of the first-stage loader is an abnormal state, in response to a hardware reset operation on the target device, the second image file is run.

[0025] Optionally, before running the second image file, the method further includes:

[0026] Obtaining third verification information after the first image file is upgraded;

[0027] If the third verification information matches the pre-stored fourth verification information, it is determined that the state of the first-stage loader is normal.

[0028] Optionally, the running the second image file to re-upgrade the first image file further includes:

[0029] If the third verification information does not match the fourth verification information, it is determined that the state of the first-stage loader is an abnormal state.

[0030] Optionally, the control method further includes:

[0031] If the integrity check result of the first image file is that the file is incomplete, a first error prompt is generated.

[0032] Optionally, the control method further includes:

[0033] Verifying the write permission of the target partition of the target device, and controlling the first image file upgrade process according to the verification result of the write permission;

[0034] The target partition includes a first partition and / or a second partition, wherein the first partition is the partition where the first image file is located, and the second partition is the partition where the second image file is located.

[0035] Optionally, the verifying the write permission of the target partition of the target device and controlling the first image file upgrade process according to the verification result of the write permission further includes:

[0036] Receiving input first verification information, and matching the first verification information with pre-stored second verification information;

[0037] If the first verification information matches the second verification information, the verification result is verification passed, and the upgrade file package of the first image file is written into the target partition to upgrade the first image file.

[0038] Optionally, the verifying the write permission of the target partition of the target device and controlling the first image file upgrade process according to the verification result of the write permission further includes:

[0039] If the first verification information does not match the second verification information, the verification result is verification failure, and a second error prompt is generated.

[0040] Optionally, the target device is an FPGA chip.

[0041] According to a second aspect of the present application, a controller is provided, comprising:

[0042] a memory configured to store instructions; and

[0043] The processor is configured to call the instructions from the memory and implement the above-mentioned system upgrade control method when executing the instructions.

[0044] According to a third aspect of the present application, a vehicle is provided, comprising the above-mentioned controller.

[0045] According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which instructions are stored. When the instructions are executed by a processor, the processor is configured to execute the above-mentioned system upgrade control method.

[0046] According to a fifth aspect of the present application, a computer program product is provided, the computer program product comprising a computer program, and the computer program implements the above-mentioned system upgrade control method when executed by a processor.

[0047] In summary, the present application adds an integrity check on the first image file when the target device loads the upgraded first image file for system booting. Based on the integrity check result of the first image file, the target device is controlled for startup. This allows timely detection of update errors in the first image file during the target device's system upgrade process, and control of the target device's startup based on the integrity check result, thereby improving the stability of the target device's system upgrade.

[0048] Other features and advantages of the present application will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] To more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0050] In order to more completely understand the present application and its beneficial effects, the following description will be given in conjunction with the accompanying drawings, wherein the same drawing numbers represent the same parts in the following description.

[0051] Figure 1 A schematic diagram of an application environment of a system upgrade control method provided in an embodiment of the present application;

[0052] Figure 2 A schematic diagram of the internal design of a verification module provided in an embodiment of the present application;

[0053] Figure 3 A flowchart of a system upgrade control method provided in an embodiment of the present application;

[0054] Figure 4 A flowchart of a method for performing a system upgrade through a second mirror module provided in a specific embodiment of the present application is shown;

[0055] Figure 5 A flowchart of a method for performing a system upgrade through a first mirror module provided in a specific embodiment of the present application;

[0056] Figure 6 A flowchart of a verification method for a verification module provided in a specific embodiment of the present application is shown;

[0057] Figure 7 This is a flow chart of a system upgrade control method provided in a specific embodiment of the present application;

[0058] Figure 8 This is a schematic diagram of the structure of a controller provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0060] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly specifying the number of the technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the described features. In the description of this application, "plurality" means two or more, unless otherwise specifically qualified. In this application, the word "exemplary" is used to mean "serving as an example, illustration, or illustration." Any embodiment described in this application as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. The following description is provided to enable anyone skilled in the art to implement and use the present application. In the following description, details are listed for illustrative purposes. It should be understood that one of ordinary skill in the art will recognize that the present application can be implemented without these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0061] In embedded systems, dual images are usually started through multi-boot system technology to perform OTA system upgrades on the target device, thereby realizing the management and switching of multiple firmware images. Among them, the target device refers to the device to be upgraded. As an example, the target device can be a field programmable gate array (FPGA) chip. By maintaining two independent firmware images, a fallback option can be provided during the system upgrade process to ensure the normal operation of the device. The embodiment of the present application takes a dual image including a golden (G) image and an upgrade (U) image as an example. The G image is a backup image that includes a standardized firmware version that has been fully tested and verified. The U image is a main image for running an updated version of firmware. The new firmware for OTA upgrade is downloaded and written to the U image. The U image can upgrade the current version firmware according to OTA to obtain the updated version firmware.

[0062] When the target device's system is powered on or reset, the First Stage Boot Loader (FSBL) begins to execute. FSBL is the first stage of the boot process, responsible for initializing the target device's hardware and loading subsequent boot images. FSBL can load the U image from the target device's storage medium, which may include a bitstream file (BIT) file on the programmable logic (PL) side and an executable and linkable format (ELF) file on the processing system (PS) side. Then, the image to be run is selected through Multiboot, and FSBL transfers control to the selected image. In the related art, the method of starting dual images through Multiboot only verifies the integrity of the BIT file on the PL side and the ELF file on the PS side. If there is damage, the FSBL is reset to switch to the backup image for operation, but it does not take into account the situation where there is an abnormality in the FSBL.

[0063] Based on this, the present embodiment introduces a Verification (VFC) module. When Multiboot is started, the VFC is entered to verify the integrity of the upgraded primary image. If the upgraded primary image is detected to be incomplete, the boot process switches to the backup image. This can resolve the issue of system deadlock caused by FSBL anomalies preventing the primary image from being reset and switched to the backup image, thereby enhancing the stability of the target device's operation.

[0064] In order to more clearly describe the control method for performing system upgrade on the target device in the embodiment of the present application, the application environment of the control method in the embodiment of the present application is first illustrated by examples. Figure 1 Schematic diagram of the application environment of a system upgrade control method provided in an embodiment of the present application. Figure 1 As shown, the application environment includes a boot module 1, a first mirror module 2, a second mirror module 3, and a verification module 4. The boot module 1 communicates with the first mirror module 2, the second mirror module 3, and the verification module 4 respectively. The first mirror module 2 and the second mirror module 3 communicate with the verification module 4 respectively.

[0065] The boot module 1 may include an FSBL unit 11, a PL unit 12, and a PS unit 13. The boot module 1 typically completes the initial state configuration of the target device's system. The first mirror module 2 primarily runs the actual product functions, integrates multiple peripheral implementation frameworks, and may include a first OTA upgrade unit 21 for self-upgrade. As an example, the first mirror module 2 may include a first mirror file, such as a boot file for a U mirror. The second mirror module 3 primarily runs the basic functions of the product and may include a second OTA upgrade unit 31, which is used to upgrade the first mirror file when running the second mirror module 3. As an example, the second mirror module 3 may include a second mirror file, such as a file in a G mirror used to upgrade the first mirror file. The verification module 4 is used to determine whether the upgraded first mirror file is complete. The first mirror file refers to the upgraded mirror file. Taking the U mirror as an example, the upgraded mirror file may be a U mirror boot file. The first mirror file may be self-upgraded by the first OTA upgrade unit 21 in the first mirror module 2, or it may be upgraded by the second OTA upgrade unit 31 in the second mirror module 3.

[0066] Figure 2 Schematic diagram of the internal design of a verification module 4 provided in the embodiment of the present application. Figure 2 As shown, the verification module 4 can be a VFC module, and an embedded system using a memory of a serial communication protocol (Quad Serial Peripheral Interface, QSPI) is used as an example. The verification module 4 first reads data from the QSPI memory. The QSPI address can indicate where to start reading the data. Then, the CRC value read from the QSPI is calculated in combination with the CRC length, that is, the Boot key. The Boot key is compared with the CRC key stored in advance. If the Boot key matches the CRC key, the startup load address of the target register where multiboot is located is determined, thereby determining the image loaded and run after reset.

[0067] based on Figure 1 and Figure 2 The application environment described above, the control method for system upgrade in the embodiment of the present application is described in detail below. Figure 3 As shown, Figure 3 This is a flow chart of a control method for system upgrade provided in an embodiment of the present application. The control method may include steps 301-302, etc., which are described in detail below.

[0068] Step 301: When a target device loads the upgraded first image file to boot the system, an integrity check is performed on the first image file.

[0069] Step 302: Control the startup of the target device according to the integrity check result of the first image file.

[0070] In an embodiment of the present application, the first image file refers to the image file included in the main image in the target device. In one example, the first image file may include the boot file of the main image, for example, the boot file of the U image, that is, the U-boot file. Usually, when performing an OTA update, the first image file is first self-upgraded to obtain the upgraded first image file. For example, the upgrade is performed through the main image. After the first image file is self-upgraded, the target device is reset. When the upgraded first image file is loaded for system booting after the target device is reset, the integrity of the first image file must first be checked to determine whether the self-upgrade of the first image file is successful.

[0071] In an embodiment of the present application, the integrity check result of the first image file can include two situations: the file is complete and the file is incomplete. If the integrity check result of the first image file is complete, it means that the first image file self-upgrade is successful, and the first image file can be directly used to start the target device. Conversely, if the integrity check result of the first image file is incomplete, it means that the first image file self-upgrade is unsuccessful. In this case, it is necessary to upgrade the first image file by running the second image file until the first image file upgrade is successful, and then start the target device by running the second image file.

[0072] In the embodiments of the present application, when a target device loads the upgraded first image file and boots the system, an integrity check is performed on the first image file. The target device's startup is controlled based on the integrity check result of the first image file. This allows timely detection of update errors in the first image file during the target device's system upgrade process, and control of the target device's startup is performed based on the integrity check result, thereby improving the stability of the target device's system upgrade.

[0073] Specifically, in step 301, first verification information may be obtained according to first data in the first image file.

[0074] The first verification information refers to the verification information obtained by verifying and calculating the first data in the upgraded first image file. The first data refers to the data in the first image file. For example, the first data can be the upgraded U-boot data, and the CRC corresponding to the U-boot data is calculated for the upgraded U-boot data. The first verification information can be a calculated CRC value, for example, it can be a Boot key. The first verification information is then compared with the pre-stored second verification information to determine the integrity verification result of the first image file. The second verification information refers to the setting verification information formulated by the developer for performing VFC verification. For example, it can be a CRC key stored in the system of the target device.

[0075] The first verification information can then be compared with the pre-stored second verification information to determine whether the first verification information matches the pre-stored second verification information. A match can refer to whether the first verification information and the second verification information are identical in length and data content. For example, a Boot key can be compared with a CRC key.

[0076] In one example, if the first verification information matches the pre-stored second verification information, the integrity check result of the first image file can be determined to be intact. If the integrity check result of the first image file is determined to be intact, it indicates that the first image file self-upgrade was successful, and the first image file can be directly used to boot the target device.

[0077] Specifically, the first image file can be written to the first partition of the target device first. The first partition refers to the area in the target device where the first image file is stored. Then the boot load address in the target device is switched to the first address of the first partition, and then the target device is started according to the boot load address. The first address is the address of the first image file. As an example, the boot load address of the target register in the target device can be switched to the first address. The target register is a memory for loading image files. For example, the target register can be a Multiboot register. The target register can include a boot load address. When the first image file needs to be used to start the target device, the boot load address can be pointed to the first partition, so that the target device uses the first image file to start the target device.

[0078] In another example, if the first verification information and the second verification information do not match, the integrity check result of the first image file is determined to be incomplete. If the integrity check result of the first image file is determined to be incomplete, it indicates that the self-upgrade of the first image file has failed. In this case, the second image file can be run to re-upgrade the first image file. Specifically, after the first image file is re-upgraded, the re-upgraded first image file is used to boot the target device.

[0079] In an embodiment of the present application, the target device may further be provided with a second partition, and the second partition refers to a storage area in the target device where the second image file is stored. The second image file may be an upgrade file for upgrading the first image file. When the second image file is run, the first image file may also be OTA upgraded. Specifically, by running the second image file, after the first image file is OTA upgraded, the boot loading address is switched to the first address of the first partition, and then the target device is started according to the boot loading address. In this way, when the first image file is self-upgrading the device, the upgrade of the first image file can be completed by running the second image file.

[0080] In the embodiment of the present application, if the integrity check result of the first image file is that the file is incomplete, a first error prompt may be generated, thereby prompting that the current self-upgrade of the first image file fails and needs to be processed.

[0081] When the self-upgrade of the first image file fails, there may be a power outage or other conditions, which makes it impossible to use the first image file in the first partition to start the target device. In order to ensure that after the self-upgrade of the first image file fails, it is possible to fall back to the second image file for OTA upgrade operation. The embodiment of the present application can determine the way to run the second image file according to the status of the FSBL of the first image file during the upgrade of the first image file. As an example, before running the second image file, the status of the FSBL can be determined first. For example, the verification of the FSBL can be performed by calculating a verification value on the FSBL, and then comparing it with a pre-stored verification value.

[0082] Specifically, third verification information after the first image file is upgraded is first obtained. The third verification information refers to verification information calculated by the FSBL during internal verification after the first image file is upgraded. If the third verification information matches pre-stored fourth verification information, the state of the first-stage loader is determined to be normal. The fourth verification information is pre-stored verification information indicating that the FSBL state is normal. Conversely, if the third verification information does not match the fourth verification information, the state of the first-stage loader is determined to be abnormal.

[0083] Then, based on the state of the FSBL, a method for running the second image file can be selected. In one example, in response to the first-stage loader being in a normal state, a software reset can be performed to switch to the second image file. For example, a switch instruction can be generated first. Then, according to the switch instruction, the second image file is run.

[0084] In another example, if the FSBL is in an abnormal state, it indicates that the second image file cannot be reset via software. Therefore, the second image file can be run in response to a hardware reset operation on the target device. For example, a hardware reset can be performed using a watchdog timer (WDG). This can reduce the possibility of being unable to reset to the second image file due to system deadlock.

[0085] In order to protect the Boot partition under the storage area (such as flash memory) of the target device from being destroyed, the embodiment of the present application can also perform write permission verification, for example, setting a key matching mechanism, and only after the match is successful can operations such as writing to the storage area of the target device be performed. Among them, the storage area of the target device may include multiple partitions, such as a first partition and a second partition. In the embodiment of the present application, the first partition and / or the second partition can be used as the target partition. Before writing to the target partition, it is necessary to verify the write permission of the target partition of the target device, and control the first image file upgrade process according to the verification result of the write permission.

[0086] Specifically, the first verification information input can be received and matched with the pre-stored second verification information. The first verification information is information input by the user to verify the write permission. The second verification information is verification information that the target partition has the write permission.

[0087] If the first verification information matches the second verification information, the verification result is verification passed, and the upgrade file package of the first image file is written to the target partition to upgrade the first image file. If the first verification information does not match the second verification information, the verification result is verification failed, indicating that the write operation to the target partition is currently unavailable, and a second error prompt may also be generated.

[0088] The following example uses an FPGA as the target device, a U image file as the first image file, a G image file as the second image file, and a Multiboot register as the target register.

[0089] First, take the second mirror module G mirror system upgrade method as an example. Figure 4 As shown, the method may include steps 401-416.

[0090] S401: Before the FPGA chip is powered on, the internal potential changes are uncertain and uncontrollable. This phenomenon can easily lead to errors in the operating state after power-on. Therefore, to ensure that the system can enter a reliable working state, the FPGA must be reset after power-on.

[0091] S402: To eliminate the jitter effect during the power on / off process, the reset must be canceled after a period of time after the power is stable. The reliability and stability of the reset signal must be ensured.

[0092] S403: The Boot Read-Only Memory (BOOTROM) is embedded in the non-volatile memory inside the chip and is used to start and boot the FSBL code. After power-on, the hardware starts without initialization. The BOOTROM is responsible for initializing basic peripherals such as the Memory Management Unit (MMU), NAND (Not AND) flash memory, NOR (Not OR) flash memory, and QSPI, while also completing the FSBL loading task.

[0093] S404: When the Multiboot register is not set, the BootROM searches for the Boot image from the QSPI header space. When the register is preset, the search starts according to the specified address and jumps to the FSBL after finding it.

[0094] S405: After entering FSBL, the Boot image related verification is completed here, the BIT and ELF file first addresses are searched, and subsequent processing is performed.

[0095] S406: Check the integrity of the BIT and ELF files. If there is an error, the FsblFallback function can be called to return to the G image. Error diagnosis can be performed here and relevant information can be returned.

[0096] S407: Load the BIT file and complete the PL side related configuration.

[0097] S408: Load the ELF file and complete the relevant configuration on the PS side.

[0098] S409: The PS boots up and enters the product operating system. The G image contains only basic functions, such as OTA functionality. Specifically, the QSPI module is enabled for reading and writing the target device's Flash memory; the Universal Asynchronous Receiver-Transmitter (UART) module is enabled for pre-shipment debugging and error reporting. The OTA unit in the G image is used to write to the U image, supporting subsequent resolution of U image FSBL anomalies during remote OTA.

[0099] S410: After the PS is started, it executes basic functions, initializes QSPI, Light Weight Internet Protocol (LWIP) and other related drivers, monitors the network port Transmission Control Protocol (TCP) communication, and waits for subsequent instructions.

[0100] S411: The G image is not used as the main execution system of the product and is verified by the VFC module after entering.

[0101] S412: Check whether the CRC check code is correct.

[0102] S413: CRC verification failed, indicating that the burned U image has errors and cannot run normally. At this time, the error is reported through TCP or serial port to facilitate debugging and resolution by developers.

[0103] S414: After the CRC check passes, the Multiboot register is modified, a soft reset is triggered, and the system is switched to the U image to run the actual system.

[0104] S415: After the error is reported, the G image is continued to be executed, and basic functions are run at this time without switching to the U image.

[0105] S416: The OTA upgrade module is used to support developers to remotely resolve errors and re-write the correct USB image to the FLash partition to resolve system startup failures.

[0106] The above describes the role of G mirror in the embodiment of the present application. On the one hand, the integrity of the U mirror partition is verified by the VFC module, and the system is switched to avoid system deadlock. On the other hand, OTA remote upgrade is supported to solve the problem of U mirror self-upgrade failure and FSBL abnormality. The U mirror startup is similar to the G mirror, but there are some differences in error handling. Figure 5 As shown, the method may include steps 501-509.

[0107] S501: The PS system starts and completes the initialization of peripherals and hardware.

[0108] S502: Reset the Multiboot register to ensure that the reset boot uses the G image as the entry program.

[0109] S503: Execute product functions. The system runs product extension functions, which takes up a large amount of Flash space.

[0110] S504: The product is remotely upgraded via OTA.

[0111] S505: When the OTA upgrade is successful, the software is reset and the system returns to the PS startup state.

[0112] S506: When the OTA upgrade fails, determine the FSBL status.

[0113] S507: The FSBL status is abnormal and cannot switch to the G image normally. In this case, a WDG hardware reset can be performed. This module is used to avoid the system being unable to reset due to a system deadlock.

[0114] S508: The FSBL status is normal. The FSBL internal verification is passed and the G image can be actively switched.

[0115] S509: Switch to G image to complete the subsequent processing of OTA upgrade failure.

[0116] The above describes the OTA upgrade status of the U image under normal circumstances. It can be seen that when the FSBL is damaged, the WDG module is required for passive reset and switching to the G image. Without the VFC module, the system is prone to deadlock. Figure 6 The verification method of the VFC module in the embodiment of the present application may include steps 601-609.

[0117] S601: The VFC check module first reads the CRC checksum of the currently running U-image Boot file. This CRC is stored in a specific partition in Flash, specified by the developer. This area, like the Boot area, is protected and cannot be written to by the user. Before the product ships, the developer performs an OTA upgrade using the G image and deploys the U image in the Flash area. When the OTA is successful, the current U image CRC checksum, Boot length, and U image version number are written for version rollback.

[0118] S602: At this time, the CRC length is read, which is the number of bytes of the U image Boot.

[0119] S603: Obtain the first address of the U image Boot. After the address is determined, it is not changed and is written to the user invisible area.

[0120] S604: The VFC module is used in two situations, one is OTA upgrade, and the other is self-checking the U mirror state for system switching. There are two types of OTA upgrades under the G mirror: one is the first writing of the U mirror, and the other is the failure of the U mirror self-OTA upgrade, resulting in an FSBL abnormality. Self-OTA upgrades under the U mirror still require VFC module verification. In the above cases, the CRC check bits are all calculated for the U mirror to be updated. The self-check U mirror state is deployed after the G mirror completes the peripheral initialization. This module avoids the deadlock state caused by the FSBL abnormality and realizes the system switching by judging whether the Boot is complete. At this time, the CRC is calculated for the currently running U mirror.

[0121] S605: Perform CRC check, compare the CRC stored in the Flash partition with the calculated CRC code, and the comparison result affects subsequent branches.

[0122] S606: CRC verification error, adopt ERROR reporting method.

[0123] S607: CRC verification is correct. The Multiboot register is modified in the G image to prepare for image switching.

[0124] S608: Execute software reset, which is achieved by writing to registers, and power on the FPGA again.

[0125] S609: Execute image switching to enter the BOOTROM, jump to the address specified by the Multiboot register, and enter the FSBL under the BOOT.

[0126] The above describes the detailed process of the VFC module in the embodiment of this application. The VFC module is applied to G image and OTA upgrade, reducing system deadlock under G image and improving product self-test capability under OTA upgrade. Figure 7 , the control method may include steps 701-80X.

[0127] S701: Enable LWIP communication and transmit instructions through the TCP protocol, including mode switching, clearing temporary data, checking CRC, entering OTA upgrade, and updating.

[0128] S702: A private key matching mechanism is used to match the first verification information with the second verification information.

[0129] S703: Key verification, comparison results determine whether the target partition of the Flash can be written, affecting OTA upgrade.

[0130] S704: The key does not match, an error is reported, and writing to the target partition of the Flash is not allowed at this time.

[0131] S705: The keys match, and the mode is switched to Security Verification Control (SVC). At this time, writing to the target partition of the Flash is allowed.

[0132] S706: LWIP transmission, writing the U image update package, at this time the OTA flag needs to be changed.

[0133] S8707: Transmission status judgment, used to determine whether there is frame loss or frame error in the transmission. For example, the judgment can be made through the CRC check code.

[0134] S708: A transmission error occurs, an error is reported, and temporary double data rate (DDR) data is cleared.

[0135] S709: The transmission is correct. Enter the update command to flash the U image Boot. Here, copy the current U image Boot to the DDR partition.

[0136] S710: VFC check verifies whether the U-image Boot written to the Flash partition is complete and passes the CRC check.

[0137] S711: CRC check, judging whether the U mirror status is updated normally.

[0138] S712: Write the U image into the G image and modify the Multiboot register. Its address points to the U image Boot start bit. The U image is upgraded by OTA, and there is no need to modify the Multiboot register.

[0139] S713: Software reset, at this time switch to the address pointed to by the Multiboot register, when the U image is normal, switch to the U image operation.

[0140] S714: Verify error, report error, and prepare to handle error U image boot.

[0141] S715: For systems running on Flash copied to RAM, a version rollback can be performed. The original DDR U image data is written to the Flash partition, re-verified, and then reset. For systems running on Flash, a version rollback is not performed; only an error report is performed and temporary DDR data is cleared.

[0142] In one embodiment of this application, a secure boot method for FPGA remote OTA upgrades based on a VFC module can address the issue of FSBL stage anomalies caused by OTA upgrade failures, which can lead to Multiboot boot failures and deadlocks. This method verifies the U image's Boot file status based on the VFC module and, upon determining whether it is functioning properly, executes the appropriate actions. This method maintains the G image running even in the event of FSBL anomalies, reducing system deadlocks and effectively improving remote OTA stability and product reliability.

[0143] Figure 8 Schematic diagram of the structure of a controller 800 provided in an embodiment of the present application. Figure 8 As shown, the controller 800 may include a memory 801 and a processor 802. The memory 801 is configured to store instructions. The processor 802 is configured to call instructions from the memory and implement the above-mentioned system upgrade control method when executing the instructions.

[0144] The present application also provides a vehicle that may include the controller 800. The vehicle in the present application may be a fuel vehicle, a plug-in hybrid vehicle, or a new energy vehicle, and the present application does not specifically limit this.

[0145] An embodiment of the present application further provides a computer-readable storage medium having instructions stored thereon. When the instructions are executed by a processor, the processor is configured to execute the above-mentioned system upgrade control method.

[0146] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the above-mentioned system upgrade control method is implemented.

[0147] Since the instructions stored in the control method, controller, computer-readable storage medium and computer program product for system upgrade can execute the steps in any system upgrade control method provided in the embodiments of the present application, the beneficial effects that can be achieved by any system upgrade control method provided in the embodiments of the present application can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0148] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0149] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0150] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0152] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0153] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0154] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated communication signals and carrier waves.

[0155] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0156] The above are merely preferred embodiments of the present application and do not constitute any form of limitation to the present application. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present application without departing from the content of the technical solution of the present application are still within the scope of the technical solution of the present application.

Claims

1. A control method for system upgrade, characterized in that: include: When the target device loads the upgraded first image file to boot the system, performing an integrity check on the first image file; The target device is started and controlled according to the integrity check result of the first image file.

2. The control method according to claim 1, characterized in that: The performing integrity check on the first image file includes: Obtaining first verification information according to first data in the first image file; If the first verification information matches the pre-stored second verification information, it is determined that the integrity verification result of the first image file is that the file is complete.

3. The control method according to claim 2, characterized in that: The performing integrity check on the first image file includes: If the first verification information does not match the second verification information, it is determined that the integrity verification result of the first image file is that the file is incomplete.

4. The control method according to claim 1, wherein: The controlling the startup of the target device according to the integrity check result of the first image file includes: If the integrity check result of the first image file is that the file is intact, the first image file is used to start the target device.

5. The control method according to claim 4, characterized in that: The step of starting the target device by using the first image file includes: Switching the boot loading address of the target device to the first address of the first partition, wherein the first address is the address of the first image file; The target device is started according to the startup loading address.

6. The control method according to claim 1, characterized in that: The controlling the startup of the target device according to the integrity check result of the first image file includes: If the integrity check result of the first image file is that the file is incomplete, the second image file is run to re-upgrade the first image file, so as to start the target device using the re-upgraded first image file.

7. The control method according to claim 6, characterized in that: Before running the second image file, the method includes: A mode for running the second image file is determined according to a state of a first-stage loader of the first image file during an upgrade of the first image file.

8. The control method according to claim 7, characterized in that: Determining the mode of running the second image file according to the state of the first-stage loader of the first image file during the upgrade of the first image file includes: In response to the state of the first-stage loader being a normal state, and in response to a software reset operation on the target device, the second image file is run.

9. The control method according to claim 7, characterized in that: Determining the mode of running the second image file according to the state of the first-stage loader of the first image file during the upgrade of the first image file includes: If the state of the first-stage loader is an abnormal state, in response to a hardware reset operation on the target device, the second image file is run.

10. The control method according to claim 7, characterized in that: Before running the second image file, the method further includes: Obtaining third verification information after the first image file is upgraded; If the third verification information matches the pre-stored fourth verification information, it is determined that the state of the first-stage loader is normal.

11. The control method according to claim 10, characterized in that: The running of the second image file to re-upgrade the first image file further includes: If the third verification information does not match the fourth verification information, it is determined that the state of the first-stage loader is an abnormal state.

12. The control method according to any one of claims 1 to 11, characterized in that: Also includes: If the integrity check result of the first image file is that the file is incomplete, a first error prompt is generated.

13. The control method according to any one of claims 1 to 11, characterized in that: Also includes: Verifying the write permission of the target partition of the target device, and controlling the first image file upgrade process according to the verification result of the write permission; The target partition includes a first partition and / or a second partition, wherein the first partition is the partition where the first image file is located, and the second partition is the partition where the second image file is located.

14. The control method according to claim 13, characterized in that: The verifying the write permission of the target partition of the target device and controlling the first image file upgrade process according to the verification result of the write permission includes: Receiving input first verification information, and matching the first verification information with pre-stored second verification information; If the first verification information matches the second verification information, the verification result is verification passed, and the upgrade file package of the first image file is written into the target partition to upgrade the first image file.

15. The control method according to claim 14, characterized in that: The step of verifying the write permission of the target partition of the target device and controlling the first image file upgrade process according to the verification result of the write permission further includes: If the first verification information does not match the second verification information, the verification result is verification failure, and a second error prompt is generated.

16. The control method according to any one of claims 1 to 11, characterized in that: The target device is an FPGA chip.

17. A controller, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call the instructions from the memory and implement the system upgrade control method according to any one of claims 1 to 16 when executing the instructions.

18. A vehicle, characterized in that: Comprising a controller according to claim 17.

19. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, which, when executed by a processor, enable the processor to be configured to execute the system upgrade control method according to any one of claims 1 to 16.

20. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the control method for system upgrade according to any one of claims 1 to 16 is implemented.

Images