System upgrade method and device based on image file

Abstract

The present invention relates to the field of communication technology, and provides a system upgrade method and device based on an image file, the method comprising: after the current system upgrade fails, power off and restart the system, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file; based on the version and type of the factory image file, load the main boot loader of the current update image file from the external storage medium to the chip memory; run the main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file; after the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file, so as to upgrade the current system to the version corresponding to the current update image file. The present invention can greatly save the upgrade maintenance cost.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a system upgrade method and device based on an image file. Background Art

[0002] ZYNQ is a programmable SoC (System on Chip) chip, which includes PS (Processing System) and PL (Programmable Logic). The firmware of ZYNQ chip is burned into non-volatile storage media such as Flash or SD card in the form of boot image file. After the device is powered on, it starts to load PL and PS programs from the image file.

[0003] At present, when upgrading the system based on the ZYNQ image file, the updated image file (UPDATE.BIN) is usually transferred to the DDR (Double Data Rate) cache outside the ZYNQ chip through interfaces such as Ethernet or USB, and the updated image file is burned from the DDR memory to the Flash or SD card through PS. However, if an abnormality occurs during the burning process, such as severe electromagnetic interference that causes the integrity of the data written to the Flash or SD card to be destroyed or the system suddenly loses power during the burning process, the upgrade will fail. If the system starts from the wrong image file, it will cause the hardware to crash, the device will not work properly, and it cannot be re-upgraded remotely. It can only be upgraded on-site through the debugging interface. Sometimes, the on-site upgrade also requires the disassembly of the device, and the cost of upgrade and maintenance is high. Summary of the invention

[0004] The present invention provides a system upgrade method and device based on an image file, which are used to solve the defects existing in the prior art.

[0005] The present invention provides a system upgrade method based on an image file, comprising the following steps.

[0006] After the current system upgrade fails, the system is powered off and restarted, and the main boot loader of the factory image file is loaded from the external storage medium to the chip memory to obtain the version and type of the factory image file;

[0007] Based on the version and type of the factory image file, load the main boot loader of the current updated image file from the external storage medium to the chip memory;

[0008] Running the main boot loader of the current update image file on the chip memory, and verifying the integrity of the current update image file;

[0009] After the verification is passed, the main boot loader of the current update image file is stopped, and the application corresponding to the current update image file is jumped to run, so as to upgrade the current system to the version corresponding to the current update image file.

[0010] According to a system upgrade method based on an image file provided by the present invention, the currently updated image file is an image file corresponding to the latest version of the factory image file;

[0011] The method further comprises:

[0012] After the verification fails, determine whether the current updated image file has a previous version of the image file, and if so, use the previous version of the image file as the current updated image file, and fall back to the main boot loader that runs the current updated image file on the chip memory;

[0013] If not, then fall back to booting the factory image file.

[0014] According to a system upgrade method based on an image file provided by the present invention, the currently updated image file is an image file corresponding to the latest version of the factory image file;

[0015] The method further comprises:

[0016] After the verification fails, determine whether the current updated image file has a previous version of the image file, and if so, use the previous version of the image file as the current updated image file, and fall back to the main boot loader that runs the current updated image file on the chip memory;

[0017] If not, then fall back to booting the factory image file.

[0018] According to a system upgrade method based on an image file provided by the present invention, the jump to run the application corresponding to the factory image file further includes:

[0019] The system is restarted after power failure, and rolls back to the main boot loader program that loads the factory image file from the external storage medium into the chip memory.

[0020] According to a system upgrade method based on an image file provided by the present invention, the current update image file includes a startup header cumulative checksum, a hash value of a bitstream file, and a hash value of an executable file;

[0021] The checking the integrity of the current update image file includes:

[0022] Based on the hash value of the bitstream file and the hash value of the executable file, performing integrity check on each partition header data and each partition data of the current updated image file;

[0023] Based on the boot header cumulative checksum, an integrity check is performed on the boot header data of the current update image file.

[0024] According to a system upgrade method based on an image file provided by the present invention, the current update image file includes a startup header cumulative checksum, a hash value of a bitstream file, and a hash value of an executable file;

[0025] The checking the integrity of the current update image file includes:

[0026] Based on the hash value of the bitstream file and the hash value of the executable file, performing integrity check on each partition header data and each partition data of the current updated image file;

[0027] Based on the boot header cumulative checksum, an integrity check is performed on the boot header data of the current update image file.

[0028] According to a system upgrade method based on an image file provided by the present invention, the method of stopping the main boot loader of the current updated image file and jumping to run the application corresponding to the current updated image file includes:

[0029] Based on the information contained in each partition header in the current update image file, load the bitstream file and the executable file configuring the current update image file;

[0030] If the loading configuration is successful, the main boot loader of the current updated image file is stopped, and then the application corresponding to the current updated image file is jumped to run.

[0031] The present invention also provides a system upgrade device based on an image file, comprising the following modules.

[0032] A first loading unit is used to power off and restart the system after the current system upgrade fails, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file;

[0033] A second loading unit, configured to load a main boot loader of a current updated image file from the external storage medium to the chip memory based on the version and type of the factory image file;

[0034] An operation verification unit, configured to run a main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file;

[0035] The system upgrade unit is used to stop running the main boot loader of the current update image file after the verification is passed, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0036] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the system upgrade method based on the image file as described above is implemented.

[0037] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the system upgrade method based on the image file as described in any one of the above is implemented.

[0038] The present invention also provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the system upgrade method based on the image file as described above is implemented.

[0039] The system upgrade method and device based on image files provided by the present invention can use the factory image file as a backup image when the current system upgrade fails, and continue to search and load the complete current update image file from the external storage medium based on the version and type of the factory image file, so that when it is determined that the data of the current update image file is complete, it can jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file, avoiding the problem of hardware downtime caused by system upgrade failure in traditional methods. That is to say, the present invention still supports remote upgrade based on the factory image file when the current system upgrade fails, thereby greatly saving upgrade and maintenance costs such as manpower, material resources and financial resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0041] Figure 1 It is a schematic diagram of a system upgrade framework based on an image file provided by the prior art.

[0042] Figure 2 This is one of the flow charts of the system upgrade method based on the image file provided by the present invention.

[0043] Figure 3 It is a structural schematic diagram of the factory image file and the current updated image file provided by the present invention.

[0044] Figure 4 This is the second flow chart of the system upgrade method based on the image file provided by the present invention.

[0045] Figure 5 This is the third flow chart of the system upgrade method based on the image file provided by the present invention.

[0046] Figure 6 It is a structural schematic diagram of a system upgrade device based on image files provided by the present invention.

[0047] Figure 7 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0049] Figure 1 It is a schematic diagram of a system upgrade framework based on an image file provided by the prior art, such as Figure 1 As shown, when the system is upgraded based on the image file of the system-on-chip chip (such as the ZYNQ chip), the updated image file is transmitted to the double data rate memory (DDR) cache outside the ZYNQ chip through interface 1 (such as Ethernet or USB interfaces), and the processor system (PS) burns the updated image file to the non-volatile flash memory (Flash) or storage card (SD card) outside the ZYNQ chip to replace the previous image file. After the next power-on, the ZYNQ chip will start the loader with the updated image file to complete the system upgrade of ZYNQ, thereby achieving the purpose of system function upgrade, performance index optimization or problem repair.

[0050] However, if an abnormality occurs during the process of PS burning the updated image file from DDR memory to Flash or SD card, such as severe electromagnetic interference that damages the integrity of the data written to Flash or SD card or a sudden power failure of the system during the burning process, the image file update will fail. If the system starts from the wrong image file, the hardware will crash, the device will not work properly, and it cannot be re-upgraded remotely. It can only be upgraded on-site through the debugging interface (i.e. interface 2, such as SPI, GPIO, etc.). Sometimes, the on-site upgrade also requires the disassembly of the device, and the upgrade and maintenance cost is high.

[0051] Figure 2 This is one of the flow charts of the system upgrade method based on the image file provided by the present invention, such as Figure 2 As shown, the method includes step 210 , step 220 , step 230 and step 240 .

[0052] Step 210: After the current system upgrade fails, the system is powered off and restarted, and the main boot loader of the factory image file is loaded from the external storage medium to the chip memory to obtain the version and type of the factory image file.

[0053] Considering that if an error or unexpected power outage occurs during the system upgrade process, the image file may be incomplete or unusable. If the system is started based on an incomplete or unusable image file, it may cause hardware downtime and the device cannot work properly. The power-off and restart system in step 210 can ensure that the system can be restored to a known and stable state, such as loading the factory image file, to avoid continuing to operate in an unstable or erroneous state and causing more serious problems. Therefore, after the current system upgrade fails, the system is restarted to maintain system stability.

[0054] After the system is restarted after power failure, the main boot loader of the factory image file is loaded from the external storage medium (such as Flash, SD card, etc.) to the chip memory (such as OCM, On-Chip Memory) to obtain the version and type of the factory image file. Among them, the factory image file usually refers to the operating system or software image pre-loaded into the device or electronic product by the manufacturer when the product is manufactured. Since the factory image file is a read-only file, it will not be modified or updated during the system upgrade, and the data integrity of the factory image file can be guaranteed during the system upgrade process. The main boot loader can be understood as the first startup program in the image file startup process, which can be FSBL (First Stage Boot Loader).

[0055] Since the master boot loader usually contains code and logic for reading and parsing the metadata of the factory image file, and the metadata usually includes the version number, type identifier and other important configuration information of the factory image file, when the master boot loader of the factory image file is loaded from the external storage medium to the chip memory, the metadata of the factory image file can be parsed by the master boot loader to obtain the version and type of the factory image file. Among them, the version of the factory image file is the version number of the factory image file, and the version number indicates the specific version of the software, firmware or operating system contained in the factory image file. The type of the factory image file usually describes the purpose of the factory image file. For example, the factory image file can be an operating system image, a firmware image, etc.

[0056] Step 220: Based on the version and type of the factory image file, load the main boot loader of the current update image file from the external storage medium to the chip memory.

[0057] Specifically, the current update image file can be understood as the latest image file used to update the system or device. The current update image file usually contains a new software version, function improvement, bug fix, security update or other types of system update content. The type of the current update image file is the same as the type of the factory image file.

[0058] Optionally, after the version and type of the factory image file are determined, an image file of the same type as the factory image file may be used as a candidate image file, and the latest version of the candidate image file may be used as the current update image file.

[0059] It should be noted that since the factory image file is a read-only file, the data in the factory image file is complete. Therefore, even if the current system upgrade fails and the image file in the system is damaged, the complete current update image file can be searched and loaded from the external storage medium based on the complete factory image file after power failure and restart.

[0060] Step 230: Run the main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file.

[0061] Specifically, the integrity check of the current update image file is used to confirm whether the current update image file has been tampered with or damaged during the transmission or storage process. Considering that the actual executable file can only be obtained when the current update image file is running, after the main boot loader of the current update image file is loaded into the chip memory, the main boot loader of the current update image file is run on the chip memory, so that all executable files of the current update image file can be obtained, and then the integrity check of the current update image file is performed on this basis to confirm whether the current update image file has been tampered with or damaged.

[0062] Optionally, the integrity of the current update image file can be verified by using the hash value of the current image file (such as the MD5 checksum). Figure 1 Interface 1 in receives the current image file and the MD5 checksum of the current image file, and when running the main boot loader of the current updated image file, calculates the MD5 checksum of the received current updated image file through PS. If the calculated MD5 checksum is consistent with the received MD5 checksum, it indicates that the data of the current image file is complete. If they are inconsistent, it indicates that the data of the current image file has been tampered with or damaged.

[0063] Step 240: After the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0064] Specifically, the verification is passed to indicate that the data of the current update image file is complete and has not been tampered with or damaged. Considering that if the main boot loader continues to run during the update process, it may cause a competition condition with the current update image file, which may cause data write conflicts, resource access conflicts or inconsistent system states, thereby affecting the success of the update and the stability of the system. In this regard, after the verification is passed, the embodiment of the present invention stops running the main boot loader of the current update image file, and jumps to run the application program (i.e., PS program) corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file, thereby completing the system upgrade.

[0065] The image file-based system upgrade method provided by the embodiment of the present invention can use the factory image file as a backup image when the current system upgrade fails, and continue to search and load the complete current update image file from the external storage medium based on the version and type of the factory image file. Therefore, when it is determined that the data of the current update image file is complete, the application corresponding to the current update image file can be jumped to run to upgrade the current system to the version corresponding to the current update image file, thereby avoiding the problem of hardware downtime caused by system upgrade failure in traditional methods. That is to say, in the case of the current system upgrade failure, the embodiment of the present invention still supports remote upgrade based on the factory image file, thereby greatly saving upgrade and maintenance costs such as manpower, material resources and financial resources.

[0066] Based on the above embodiment, the current updated image file is an image file corresponding to the latest version of the factory image file;

[0067] The method further comprises:

[0068] After the verification fails, determine whether there is a previous version of the image file for the current update image file. If so, use the previous version of the image file as the current update image file and fall back to the main boot loader running the current update image file on the chip memory;

[0069] If not, it will fall back to booting the factory image file.

[0070] Specifically, after the verification fails, it indicates that the current update image file may be tampered with or damaged. If the tampered or damaged current update image file is started for system upgrade, it may cause hardware downtime. In this regard, after the verification fails, the embodiment of the present invention determines whether there is a previous version of the image file of the current update image file. If so, the previous version of the image file is used as the current update image file, and falls back to the main boot loader that runs the current update image file on the chip memory, that is, falls back to the above step 230, and repeats steps 230-240 until the verification passes or the previous version of the image file does not exist. Among them, the version of the previous version of the image file is lower than the current update image file. For example, the version of the current update image file is 3.0, and the version of the previous version of the image file can be 2.0.

[0071] When there is no previous version of the image file, since the factory image file is a read-only file, the data of the factory image file is complete. In addition, the main boot loader of the current updated image file has been run before, and some system parameters may have been modified. In order to maintain the stability of the system, it is rolled back to the factory image file to restore the system to the factory settings to keep the system stable. Among them, the FsblFallback rollback function can be used to roll back to the factory image file, and feedback the error status to request a system upgrade again.

[0072] Based on any of the above embodiments, starting the factory image file includes:

[0073] Run the main boot loader of the factory image file on the chip memory and verify the integrity of the factory image file;

[0074] After the verification is passed, the main boot loader of the factory image file is stopped, and then the application corresponding to the factory image file is jumped to run.

[0075] Specifically, the integrity check of the factory image file is used to confirm whether the factory image file has been tampered with or damaged during the transmission or storage process. Considering that the actual executable file can only be obtained when the factory image file is running, after the main boot loader of the factory image file is loaded into the chip memory, the main boot loader of the factory image file is run on the chip memory, so that all executable files of the factory image file can be obtained, and then the integrity check of the factory image file is performed on this basis to confirm whether the factory image file has been tampered with or damaged.

[0076] Optionally, the integrity of the factory image file can be verified by the hash value of the current image file (such as the MD5 checksum). Figure 1 Interface 1 in receives the current image file and the MD5 checksum of the current image file, and when running the main boot loader of the factory image file, calculates the MD5 checksum of the received factory image file through PS. If the calculated MD5 checksum is consistent with the received MD5 checksum, it indicates that the data of the current image file is complete. If they are inconsistent, it indicates that the data of the current image file has been tampered with or damaged.

[0077] The verification is passed to indicate that the data of the factory image file is complete and has not been tampered with or damaged. Considering that if the main boot loader continues to run during the update process, it may cause data write conflicts, resource access conflicts or inconsistent system states, thereby affecting the system from being restored to the factory state. In this regard, after the verification is passed, the embodiment of the present invention stops running the main boot loader of the factory image file and jumps to run the application (i.e., the PS program) corresponding to the factory image file to restore the current system to the factory setting state.

[0078] Based on any of the above embodiments, the process jumps to run the application corresponding to the factory image file, and then further includes:

[0079] Power off to restart the system and fall back to the main boot loader that loads the factory image file from the external storage medium into the chip memory.

[0080] Specifically, after jumping to run the application corresponding to the factory image file, it can ensure that the factory image file is correctly configured in the current system. After the power is off and the system is restarted, the system can reload these configurations and clear possible temporary states or error states, thereby ensuring that the system returns to a known stable state (factory setting state) to start running, ensuring that the system can run stably and avoiding hardware downtime.

[0081] After the system is restarted after power failure, it returns to the main boot loader that loads the factory image file from the external storage medium to the chip memory, that is, it returns to step 210, and repeats steps 210-240 until the system upgrade is successful.

[0082] Based on any of the above embodiments, the current update image file includes the boot header cumulative checksum, the hash value of the bitstream file, and the hash value of the executable file;

[0083] Verify the integrity of the current update image file, including:

[0084] Based on the hash value of the bitstream file and the hash value of the executable file, perform integrity check on the partition header data and partition data of the current updated image file;

[0085] Based on the boot header cumulative checksum, the integrity of the boot header data of the current update image file is checked.

[0086] Specifically, the boot header cumulative checksum is used to perform integrity check on the boot header (BootHeader) in the ROM (Read-Only Memory). It can be done by adding each byte in the boot header and then taking the lower eight bits of the result (i.e., modulo 256). The calculated cumulative checksum will be stored in the boot header. When the ROM is started, the system will read the cumulative checksum stored in the boot header and recalculate it once to obtain the calculated cumulative checksum, and compare the calculated cumulative checksum with the cumulative checksum stored in the boot header. If they are consistent, it indicates that the boot header data is complete. If they are inconsistent, it indicates that the boot header data has been tampered with or damaged, that is, the boot header is an invalid boot header, and then continue to search for the next valid boot header, that is, to search for the next current update image file.

[0087] In addition, in addition to the boot header, the current update image also includes multiple partition headers (Partition Header) and multiple partitions (Partition). If any partition header data or any partition data is incomplete, the current update image file data will also be incomplete. In this regard, the embodiment of the present invention performs integrity verification on each partition header and each partition of the current update image file based on the hash value of the bitstream file and the hash value of the executable file. Among them, the bitstream file can be understood as a binary file for configuring PL, that is, a PL bit file. The executable file can be understood as a program file of PL, that is, a PS elf program file. The above hash value can be an MD5 checksum or a cumulative checksum, and the embodiment of the present invention does not specifically limit this.

[0088] In addition, the factory image file also contains the boot header cumulative checksum, the hash value of the bitstream file, and the hash value of the executable file. The integrity check of the factory image file can also be performed by referring to the above-mentioned integrity check steps for the current update image file, which will not be repeated here.

[0089] Based on any of the above embodiments, a partition for storing a primary boot loader (FSBL) of a current update image file is arranged after the boot header.

[0090] Specifically, if the partition of FSBL is set after all partition headers, FSBL will also be updated when the system is upgraded based on the current update image file. The hidden danger of updating FSBL is that if the FSBL part is not completely updated or wrong data is written during the system upgrade due to some reason such as strong electromagnetic interference or sudden power failure, the system will not be able to start normally based on the current update image file, and it will not be able to recover to the factory image file to start. The reason is that: the boot header cannot perform integrity verification on the FSBL data, and the FSBL cannot use the MD5 checksum for verification. If the boot header loads and runs the FSBL with incomplete or wrong data, the abnormal FSBL may not be able to load the PL bit file and PS elf program file normally, and it cannot be restored to the factory setting state through the FsblFallback fallback function. In this case, PS will run away in the wrong FSBL, causing the system to deadlock and the system to fail to start normally, and the Flash or SD card can only be re-burned on site through the debugging interface.

[0091] In this regard, the embodiment of the present invention moves the partition for storing FSBL to behind the boot header, and when the system is upgraded based on the current updated image file, the corresponding FSBL data is not updated or modified, which can effectively ensure the integrity of the corresponding FSBL data. In this case, if strong electromagnetic interference or sudden power failure occurs during the system upgrade process, causing incomplete data or data errors in the boot header, PLbit file or PS elf program file partition or its corresponding partition header, the above embodiment can be used to verify the integrity of each partition data and each partition header data. If the data is incomplete, it will fall back to the boot factory image file and request another system upgrade.

[0092] The structure of the factory image file is also consistent with the structure of the current update image file, that is, the partition for storing the primary boot loader (FSBL) of the factory image file is set after the boot header.

[0093] Figure 3 It is a schematic diagram of the structure of the factory image file and the current updated image file provided by the present invention, such as Figure 3As shown, the factory image file and the current update image file have the same structure, including the boot header, image header table, image header, partition header, and partition, and the bitstream file (PLbit file) hash value (such as MD5 checksum of PL bitstream) and executable file (such as PS elf program file) hash value (such as MD5 checksum) are added to the end. In addition, the partition 1 used to store FSBL is moved forward to after the boot header, the partition 2 is used to store the bitstream file, and the partition 3 is used to store the executable file.

[0094] Based on any of the above embodiments, stopping the main boot loader of the current update image file and jumping to run the application corresponding to the current update image file includes:

[0095] Based on the information contained in each partition header of the current update image file, load the bitstream file and the executable file configuring the current update image file;

[0096] If the configuration is loaded successfully, the main boot loader of the current update image file is stopped, and the application corresponding to the current update image file is jumped to run.

[0097] Specifically, the information contained in each partition header includes image size, loading address, running address, location in external storage medium, etc. Based on the information contained in each partition header, the bitstream file and executable file of the current updated image file are loaded and configured.

[0098] If the configuration is loaded successfully, it means that the corresponding parameters and options have been successfully set in the system, which can reduce the possibility of crashes and errors and improve the reliability and stability of the system. On this basis, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0099] Figure 4 FIG. 2 is a flow chart of the system upgrade method based on the image file provided by the present invention. Figure 4 As shown, the method includes:

[0100] When starting a system upgrade, the current update image file and the hash value (such as MD5 checksum) of the current update image file are transmitted through an Ethernet or USB interface, and the current update image file and the hash value of the current update image file are cached in a memory (such as DDR). The processor system (PS) calculates the hash value of the current update image file cached in the memory.

[0101] If the received hash value is consistent with the calculated hash value, the current update image file (except the boot header and FSBL part) is burned to the corresponding area of ​​the external storage medium (such as Flash, SD card), and the system is restarted after power off. If the upgrade is successful, it will start running from the current update image file. If the upgrade fails, it will fall back to running the factory image file and request another upgrade. If the received hash value is inconsistent with the calculated hash value, the system upgrade is repeated.

[0102] Figure 5 FIG. 3 is a flow chart of a system upgrade method based on an image file provided by the present invention. Figure 5 As shown, the method includes:

[0103] After the system (such as the ZYNQ chip) is powered on, the boot memory (such as BootROM, which is a read-only memory stored in the chip or processor) is started. The BootROM reads the image file from the external storage medium and searches for a valid boot header. The BootROM first finds the boot header corresponding to the factory image file (BOOT.BIN), and loads the primary boot loader (FSBL) of the factory image file into the chip memory for operation (such as the OCM on-chip RAM memory). The FSBL of the factory image file notifies the BootROM to continue searching for the next valid boot header. If a valid boot header is found, for example, the boot header corresponding to the current update image (UPDATE.BIN) file is found, the primary boot loader (FSBL) of the current update image file is loaded into the chip memory for operation (such as the OCM on-chip RAM memory). The FSBL of the current update image file will also notify the BootROM to continue searching for the next valid boot header (that is, the boot header corresponding to the updated version of the image file). If the next valid boot header cannot be found within the effective search limit of the external storage medium, the configuration bitstream file (PL bitstream) and executable file (PS elf program file) will continue to be loaded according to the image size, load address, run address, and location in the external storage medium contained in the partition headers of the current update image file. If the PL bitstream file and PS elf program file are loaded and configured successfully, the system runs normally and the ZYNQ chip successfully completes the entire boot process.

[0104] Among them, when the device leaves the factory, the PL bit stream file and PS elf program file in the current update image file are consistent with the PL bit stream file and PS elf program file in the factory image file, so running the current update image file has the same effect as running the factory image file.

[0105] In addition, the MD5 checksum of the PL bit stream file and the MD5 checksum of the PS elf program file are added to the end of all image files (including the BOOT.BIN current update image file and the factory image file). The use of the MD5 checksum allows FSBL to check the data integrity of the partitions corresponding to the PL bit stream file and the PS elf program file. In addition, the boot header contains the boot header cumulative checksum (Boot Header Checksum) to verify the data integrity of the boot header; at the same time, the end of each partition header (Partition Header) in each boot image file also contains the partition header cumulative checksum (Partition Header Checksum) to verify the integrity of the partition header.

[0106] The BootROM verifies the correctness of the boot header by accumulating the checksum of the boot header. If the boot header accumulating checksum is inconsistent, it will be regarded as an illegal and invalid boot header, and the BootROM will continue to search for the next valid boot header.

[0107] During the operation of the FSBL corresponding to the current update image file, the cumulative checksum of each partition header and the MD5 checksum of each partition will be used to determine whether there is an exception or error in the loading process. Once a problem occurs during the loading of the configuration PL bit stream file or the PS elf program file, resulting in a loading failure, the FSBL will call the FsblFallback fallback function and update the relevant registers, and then reset the ZYNQ chip to make the BootROM run again and search for the factory image file to achieve the boot jump. If the checksum of any partition header or any partition in the current update image file is inconsistent, it means that the integrity of the update data has been destroyed. The FSBL will implement the multi-boot image function through the FsblFallback fallback function to make the chip jump back to the factory image file to start.

[0108] When the factory image file is started, the boot header, each partition header, and each partition checksum will also be checked for integrity to ensure the integrity of the data in each part.

[0109] In addition, the embodiment of the present invention adjusts and reorganizes the image file structure, and moves the partition 1 of the image file, i.e., the FSBL main boot loader, to behind the boot header. The FSBL part is separated from the image file and placed in an independent area of ​​the external storage medium. The boot header and the FSBL part are not updated when the image file is upgraded, so that during the upgrade process, the data in the area where the FSBL of the currently updated image file is located will not be erased or written, and will not change, thereby ensuring the data integrity of the FSBL part corresponding to the currently updated image file.

[0110] The embodiment of the present invention can effectively ensure that in the case of a system upgrade failure, the ZYNQ chip can be started from the factory image file through the multi-boot image function. The embodiment of the present invention can effectively avoid the problem of hardware downtime caused by upgrade failure in the prior art. The method provided by the embodiment of the present invention is more reliable and robust. In the case of an upgrade failure, the program can be started, configured, and run from the factory image file, and the remote upgrade function is still supported, which can greatly save the upgrade and maintenance costs such as manpower, material resources, and financial resources. In addition, the embodiment of the present invention can also support system upgrades based on 3 or more image files.

[0111] The following is a description of a system upgrade device based on an image file provided by the present invention. The system upgrade device based on an image file described below and the system upgrade method based on an image file described above can be referred to each other.

[0112] Based on any of the above embodiments, Figure 6 : is a schematic diagram of the structure of the system upgrade device based on the image file provided by the present invention, such as Figure 6 As shown, the device comprises:

[0113] The first loading unit 610 is used to power off and restart the system after the current system upgrade fails, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file;

[0114] The second loading unit 620 is used to load the main boot loader of the current updated image file from the external storage medium to the chip memory based on the version and type of the factory image file;

[0115] An operation verification unit 630 is used to run the main boot loader of the current update image file on the chip memory and verify the integrity of the current update image file;

[0116] The system upgrade unit 640 is used to stop running the main boot loader of the current update image file after the verification is passed, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0117] Figure 7 is a schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 7 As shown, the electronic device may include: a processor 710, a communication interface 720, a memory 730 and a communication bus 740, wherein the processor 710, the communication interface 720 and the memory 730 communicate with each other through the communication bus 740. The processor 710 may call the logic instructions in the memory 730 to execute the system upgrade method based on the image file, the method comprising: after the current system upgrade fails, power off and restart the system, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file; based on the version and type of the factory image file, load the main boot loader of the current update image file from the external storage medium to the chip memory; run the main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file; after the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0118] In addition, the logic instructions in the above-mentioned memory 730 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0119] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the system upgrade method based on the image file provided by the above methods, the method including: after the current system upgrade fails, power off and restart the system, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file; based on the version and type of the factory image file, load the main boot loader of the current update image file from the external storage medium to the chip memory; run the main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file; after the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0120] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the system upgrade method based on the image file provided by the above-mentioned methods, the method comprising: after the current system upgrade fails, powering off and restarting the system, and loading the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file; based on the version and type of the factory image file, loading the main boot loader of the current update image file from the external storage medium to the chip memory; running the main boot loader of the current update image file on the chip memory, and verifying the integrity of the current update image file; after the verification passes, stopping the running of the main boot loader of the current update image file, and jumping to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file.

[0121] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0122] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A system upgrade method based on an image file, characterized in that: include: After the current system upgrade fails, the system is powered off and restarted, and the main boot loader of the factory image file is loaded from the external storage medium to the chip memory to obtain the version and type of the factory image file; Based on the version and type of the factory image file, load the main boot loader of the current updated image file from the external storage medium to the chip memory; Running the main boot loader of the current update image file on the chip memory, and verifying the integrity of the current update image file; After the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file to upgrade the current system to the version corresponding to the current update image file; The currently updated image file is an image file corresponding to the latest version of the factory image file; The method further comprises: After the verification fails, determine whether the current updated image file has a previous version of the image file, and if so, use the previous version of the image file as the current updated image file, and fall back to the main boot loader that runs the current updated image file on the chip memory; If not, fall back to starting the factory image file; The starting of the factory image file includes: Running the main boot loader of the factory image file on the chip memory and verifying the integrity of the factory image file; After the verification is passed, the main boot loader of the factory image file is stopped, and the application corresponding to the factory image file is jumped to run; The jump to run the application corresponding to the factory image file further includes: The system is restarted after power failure, and rolls back to the main boot loader program that loads the factory image file from the external storage medium into the chip memory.

2. The system upgrade method based on image file according to claim 1, characterized in that: The current update image file includes a startup header cumulative checksum, a hash value of a bitstream file, and a hash value of an executable file; The checking the integrity of the current update image file includes: Based on the hash value of the bitstream file and the hash value of the executable file, performing integrity check on each partition header data and each partition data of the current updated image file; Based on the boot header cumulative checksum, an integrity check is performed on the boot header data of the current update image file.

3. The system upgrade method based on image file according to claim 1, characterized in that: The partition for storing the main boot loader of the current update image file is arranged after the boot header.

4. The system upgrade method based on image file according to claim 1, characterized in that: The method of stopping the main boot loader of the current updated image file and jumping to run the application corresponding to the current updated image file includes: Based on the information contained in each partition header in the current update image file, load the bitstream file and the executable file configuring the current update image file; If the loading configuration is successful, the main boot loader of the current updated image file is stopped, and then the application corresponding to the current updated image file is jumped to run.

5. A system upgrade device based on an image file, characterized in that: include: A first loading unit is used to power off and restart the system after the current system upgrade fails, and load the main boot loader of the factory image file from the external storage medium to the chip memory to obtain the version and type of the factory image file; A second loading unit, configured to load a main boot loader of a current updated image file from the external storage medium to the chip memory based on the version and type of the factory image file; An operation verification unit, configured to run a main boot loader of the current update image file on the chip memory, and verify the integrity of the current update image file; A system upgrade unit, configured to, after the verification is passed, stop running the main boot loader of the current update image file, and jump to run the application corresponding to the current update image file, so as to upgrade the current system to the version corresponding to the current update image file; The currently updated image file is an image file corresponding to the latest version of the factory image file; Also includes: After the verification fails, determine whether the current updated image file has a previous version of the image file, and if so, use the previous version of the image file as the current updated image file, and fall back to the main boot loader that runs the current updated image file on the chip memory; If not, fall back to starting the factory image file; The starting of the factory image file includes: Running the main boot loader of the factory image file on the chip memory and verifying the integrity of the factory image file; After the verification is passed, the main boot loader of the factory image file is stopped, and the application corresponding to the factory image file is jumped to run; The jump to run the application corresponding to the factory image file further includes: The system is restarted after power failure, and rolls back to the main boot loader program that loads the factory image file from the external storage medium into the chip memory.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the system upgrade method based on the image file as described in any one of claims 1 to 4 is implemented.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the system upgrade method based on an image file as described in any one of claims 1 to 4 is implemented.

Images