CN117573157A - A reliable remote firmware upgrade method based on ZYNQ MPSoC - Google Patents

Abstract

The invention discloses a reliable remote firmware upgrading method based on ZYNQ MPSoC. The method uses a FLASH memory (FLASH) chip as a storage medium by partitioning the storage medium of the ZYNQ system, and divides the storage medium into a main partition, a backup partition and a log partition. And establishing communication with the server by using a TFTP protocol, and receiving, checking and programming the upgrade firmware data to the main partition according to the communication protocol. The boot loader selects the corresponding partition to start according to the flag bit in the log partition. In addition, in the process of communication protocol analysis and firmware data integrity detection, it is necessary to define the communication protocol and analyze it, and calculate the cyclic redundancy check code to ensure the correctness and integrity of the firmware data. And finally, by adopting a multi-partition starting scheme, the backup partition starting when the main partition fails to upgrade is realized, and the main partition firmware data is upgraded remotely again, so that the reliability and the safety of remote firmware upgrading are improved.

Description

A reliable remote firmware upgrade method based on ZYNQ MPSoC

Technical field

The invention belongs to the technical field of remote firmware upgrade, and is specifically a reliable remote firmware upgrade method based on ZYNQ MPSoC.

Background technique

In the current ZYNQ MPSoC (multi-processor system chip) embedded system, the corresponding downloader (such as JTAG) is often used for development and programming. After the development is completed, the corresponding firmware will be generated and burned into the FLASH chip in the ZYNQ device through JTAG and a specific burning program. However, since ZYNQ is usually packaged in product structural parts and used as digital signal processing equipment, if the product is still upgraded using JTAG, the product structural parts need to be dismantled. This is not only very inconvenient and lacks flexibility, but also creates problems for later stages. Maintenance brings great difficulties. Therefore, a solution for remote firmware upgrade is urgently needed.

However, during the remote firmware upgrade process, abnormal conditions may occur that cause firmware data to be lost, causing the remote upgrade to fail and the product to fail to start normally. In order to solve this problem, a fallback mechanism needs to be designed to ensure that the product can use the fallback function to boot the chip from the backup partition if the firmware upgrade fails. The design idea of the rollback mechanism is that during the firmware upgrade process, the currently running firmware is first backed up to another partition. Then, flash and update the new firmware. If the firmware upgrade is successful, the system can boot normally and use the new firmware. However, if an exception occurs during the upgrade process and causes failure, the system can automatically switch to the backup partition and restart the chip to ensure system reliability and stability.

Through such a rollback mechanism, even if a problem occurs during the remote firmware upgrade process, the normal operation of the device can be guaranteed. When it is necessary to repair or retry the upgrade, the firmware upgrade process can be retriggered remotely, thereby achieving flexible and convenient remote firmware upgrade.

Contents of the invention

The present invention proposes a reliable remote firmware upgrade method based on ZYNQ MPSoC.

The technical solution to achieve the purpose of the present invention is: a reliable remote firmware upgrade method based on ZYNQ MPSoC, including:

Step 1: Divide the storage medium of the ZYNQ MPSoC embedded system into the primary partition, backup partition, and log partition, and initialize the peripherals and clocks of the ZYNQ MPSoC embedded system;

Step 2: The ZYNQ MPSoC embedded system shakes hands with the server through the TFTP protocol to establish communication;

Step 3: After receiving the firmware upgrade instruction from the server, the ZYNQ MPSoC embedded system interrupts the current task and replies that the server is ready to upgrade;

Step 4: After receiving the preparation completion signal from ZYNQ, the server sends the upgraded firmware to the client according to the pre-agreed communication protocol;

Step 5: After ZYNQ parses the data sent from the server according to the corresponding communication protocol to obtain the upgraded firmware, it calculates the cyclic redundancy check code of the received firmware data;

Step 6: Compare the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol. If the check codes are consistent, it means that the received upgrade firmware data is correct and complete; if the check codes are inconsistent. , then the server firmware data error will be replied, and the server will re-issue the firmware upgrade instruction, that is, jump to step 3;.

Step 7: Burn the received upgraded firmware data into the main partition of the FLASH chip through the FLASH controller, and set the upgrade flag in the log partition;

Step 8: After the burning is completed, ZYNQ implements a soft reset of the embedded system through the watchdog, restarts the system and enters the boot program solidified by the ZYNQ chip; loads the first-stage boot loader;

Step 9: The first-stage boot loader boots the primary partition according to the flag bit in the log partition and sets the first boot flag in the log partition; if the primary partition fails to start, the first-stage boot loader reboots the backup Start the partition, jump to step 1, and re-upgrade the ZYNQ embedded system; if the main partition starts successfully, the upgrade is complete.

Preferably, the primary partition is used to store normal working firmware data, and the primary partition is always the destination partition for remote upgrade; the backup partition is used to store firmware data in safe mode, and this firmware data can realize the basic functions of remote upgrade, and the backup partition The firmware data is in a write-protected state to ensure that the firmware data is not changed; the log partition stores the flag information during upgrade and startup. The first-stage boot loader FSBL will select the corresponding partition to start based on the flag information.

Preferably, the firmware data consists of Boot Header, Partition Header, FSBL Image, xxx.bit, u-boot.elf and xxx.elf.

Preferably, when the ZYNQ MPSoC embedded system shakes hands with the server through the TFTP protocol, the ZYNQ embedded system acts as a TFTP client.

Preferably, the communication protocol data consists of a start bit, data length, firmware version number, firmware data, cyclic redundancy check code, and end bit.

Preferably, in step 7, the specific steps of burning the received upgraded firmware data into the main partition of the FLASH chip through the FLASH controller, and setting the upgrade flag bit in the log partition are:

Step 7.1: Read the FLASH chip ID and read the corresponding flash memory page size according to the FLASH chip ID number;

Step 7.2: Write the upgrade flag bit to the log partition in the FLASH chip, and set the upgrade flag bit to 1;

Step 7.3: Erase the main firmware data of the main partition in the FLASH chip;

Step 7.4: Divide the upgraded firmware data into several parts according to the flash memory page size, and burn them into the main partition of the FLASH chip in sequence;

Step 7.5: Read the firmware data written in the primary partition from the FLASH chip and compare it with the firmware data parsed by the communication protocol. If they are consistent, the written firmware data is correct; if they are inconsistent, jump to step 7.3.

Preferably, the first-stage boot loader FSBL selects the corresponding partition to start based on the flag information of the log partition, which specifically includes the following steps:

Step 9.1: After the first boot loader is loaded, load the first-stage boot loader program into the on-chip RAM;

Step 9.2: The first-stage boot loader reads the boot flag in the log partition;

Step 9.3: According to the flag information, the first-stage boot loader sets the value of the Multiboot register;

Step 9.4: According to the value of the Multiboot register, jump to the corresponding address of FLASH to load the bit stream file and executable file.

Compared with the existing technology, the significant advantages of the present invention are: the present invention uses an external communication interface (such as an Ethernet port) to realize remote upgrade of product firmware, avoids the complicated steps of using a downloader to program firmware, and greatly improves efficiency. Convenience and efficiency of upgrade; in order to solve problems such as firmware data errors or loss that may occur during the general remote firmware upgrade process, the present invention also adopts a multi-partition startup solution. By setting a backup partition in the system, when a problem occurs during the upgrade process, the system can reboot to the backup partition and re-upgrade the firmware, thereby ensuring the reliability and security of the entire upgrade process.

The present invention will be described in further detail below in conjunction with the accompanying drawings.

Description of the drawings

Figure 1 is a schematic flowchart of the remote firmware upgrade method provided by the present invention.

Figure 2 is a schematic structural diagram of the upgraded firmware data.

Figure 3 is a schematic diagram of the process of programming the flash memory chip (FLASH) after receiving the upgraded firmware.

Figure 4 is a schematic flow diagram of the first stage boot loader FSBL of the multi-partition boot system provided by the present invention.

Detailed ways

Specific implementation modes of the embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific implementations described here are only used to illustrate and explain the embodiments of the present invention, and are not used to limit the embodiments of the present invention.

As shown in Figure 1, a reliable remote firmware update method based on ZYNQ MPSoC requires partitioning the storage medium of the ZYNQ system. In this embodiment, the storage medium uses a flash memory (FLASH) chip. Divide the FLASH chip into three partitions, namely the main partition, the backup partition, and the log partition. Among them, the main partition stores normal working firmware data, and this partition is always the destination partition for remote upgrade; the backup partition stores firmware data in safe mode. This firmware data can realize the basic functions of remote upgrade, and the backup partition's firmware data It is in a write-protected state to ensure that the firmware data in it is not changed; the log partition stores the flag information during upgrade and startup. The first-stage boot loader FSBL will select the corresponding partition to start based on the flag information. The significance of the existence of backup partitions and log partitions is that when problems such as firmware data errors or loss, sudden power outages, etc. occur during the upgrade process, the ZYNQ system can still be booted from the backup partition to avoid the problem of the device being unable to start due to upgrade failure. Specifically, it includes the following steps:

Step 1: ZYNQ MPSoC embedded system initializes peripherals and clocks.

Step 2: ZYNQ shakes hands with the server through the TFTP protocol to establish communication, in which the ZYNQ embedded system serves as the TFTP client.

Step 3: After receiving the firmware upgrade instruction from the server, ZYNQ interrupts the current task and replies that the server is ready to upgrade.

Step 4: After receiving the preparation completion signal from ZYNQ, the server sends the upgraded firmware to the client according to the pre-agreed communication protocol.

Further, this step needs to agree in advance on the communication protocol used to upgrade the firmware. Specifically in this embodiment, the communication protocol data consists of start bit, data length, firmware version number, firmware data, cyclic redundancy check code ( CRC), end bit, etc. Among them, the start bit and the end bit are fixed 8-byte data, the data length indicates the number of bytes of the firmware data, and the cyclic redundancy check code is the cyclic redundancy check code calculated by the server based on the firmware data.

Step 5: After ZYNQ parses the data sent from the server according to the corresponding communication protocol to obtain the upgraded firmware, it calculates the cyclic redundancy check code (CRC) of the received firmware data.

Further, after parsing the firmware data, the ZYNQ system calculates the cyclic redundancy check code of the received firmware data, and compares the cyclic redundancy check code with the cyclic redundancy check code parsed in the communication protocol. If If they are consistent, the firmware data is complete. Among them, the cyclic redundancy check code can be replaced by a message digest algorithm or other customized check codes. Specifically, as shown in Figure 2, the complete firmware data consists of boot header, partition table header, FSBL image, bitstream file, u-boot file and executable file packaging.

Step 6: Compare the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol. If the check codes are consistent, it means that the received upgrade firmware data is correct and complete; if the check codes are inconsistent. , then the server firmware data error will be replied, and the server will re-issue the firmware upgrade instruction, that is, jump to step 3.

This step uses CRC check to ensure the correctness and integrity of the firmware data. ZYNQ parses the data sent from the server according to the predetermined communication protocol. The communication protocol data consists of start bit, data length, firmware version number, firmware data, cyclic redundancy It is composed of remainder check code (CRC), end bit, etc. The ZYNQ system can parse out the firmware data and cyclic redundancy check codes that need to be upgraded based on this communication protocol. The ZYNQ system calculates the cyclic redundancy check code of the received firmware data, and compares the cyclic redundancy check code with the cyclic redundancy check code parsed in the communication protocol. If they are consistent, the integrity of the firmware data is ensured. Among them, the cyclic redundancy check code can be replaced by a message digest algorithm or other customized check codes.

Step 7: Program the received upgraded firmware data into the main partition of the FLASH chip through the FLASH controller, and set the upgrade flag in the log partition.

In a further embodiment, as shown in Figure 3, the specific steps of programming the FLASH chip through the FLASH controller in step 7 are as follows:

Step 7.1: Read the FLASH chip ID and read the corresponding flash memory page size according to its ID number;

Step 7.2: Write the upgrade flag bit to the log partition in the FLASH chip and set it to 1;

Step 7.3: Erase the main firmware data of the main partition in the FLASH chip;

Step 7.4: Divide the upgraded firmware data into several parts according to the flash memory page size, and burn them into the main partition of the FLASH chip in sequence;

Step 7.5: Read the firmware data written in the primary partition from the FLASH chip and compare it with the firmware data parsed by the communication protocol. If they are consistent, the written firmware data is correct; if they are inconsistent, jump to step 7.3.

Step 8: After the burning is completed, ZYNQ implements a soft reset of the embedded system through the watchdog, restarts the system and enters the boot program (BootRom) solidified by the ZYNQ chip, and loads the first-stage boot loader (FSBL).

Step 9: The first-stage boot loader (FSBL) boots the main partition according to the flag bit in the log partition and sets the first boot flag bit in the log partition. If the primary partition fails to start, the first-stage boot loader (FSBL) will reboot the backup partition and jump to step 1 to re-upgrade the ZYNQ embedded system; if the primary partition starts successfully, the upgrade is complete.

Further, as shown in Figure 4, the first-stage boot loader (FSBL) determines whether to boot the primary partition or boot the backup partition through the flag bit in the log partition. The implementation steps are as follows:

Step 9.1: After the first boot program (BootRom) is loaded, the first-stage boot loader (FSBL) program will be loaded into the on-chip RAM (OCM);

Step 9.2: The first-stage boot loader (FSBL) reads the boot flag in the log partition;

Step 9.3: Based on the flag information, the first-stage boot loader (FSBL) sets the value of the Multiboot register;

Step 9.4: According to the value of the Multiboot register, jump to the corresponding address of FLASH to load the bit stream file and executable file.

The ZYNQ system can parse out the firmware data and cyclic redundancy check codes that need to be upgraded based on this communication protocol.

Preferably, the reliable remote firmware upgrade method based on ZYNQ proposed by the present invention adopts a multi-partition solution, and specifically relates to a multi-partition startup method.

When some uncontrollable factors occur during the upgrade process, causing the main firmware data to be incorrect, the upgrade fails, and the main partition cannot be started, ZYNQ can jump to the backup partition through the first-stage boot loader (FSBL) and start from the backup Re-upgrading the firmware of the main partition by partition avoids the risk of needing to dismantle product structural parts after an upgrade fails, greatly improving the reliability and security of the entire upgrade process.

The reliable remote firmware upgrade method based on ZYNQ proposed in this embodiment adopts a multi-partition solution, specifically involving a multi-partition startup method. The ZYNQ startup process is described below:

After powering on, ZYNQ will first start from the solidified boot program (BootRom) and retrieve a valid boot header from the FLASH chip. The search address increases by 32KB each time until a valid boot header is retrieved. After reading a valid boot header, the first-stage boot loader (FSBL) code is loaded into on-chip RAM (OCM). Therefore, when dividing the first address of the backup partition, you should ensure that the backup firmware data starts from an integer multiple of the 32KB address so that the program in the boot program (BootRom) can retrieve the boot header of the backup firmware data.

Specifically, the flag bit changes in the log partition in steps 8 and 9 are as shown in the table below. After the first stage boot loader (FSBL) is loaded for the first time, it reads that the upgrade flag bit is 1. In order to prevent the main An error occurred during partition upgrade. Set the pre-boot backup partition flag to 1 and clear the upgrade flag. If the primary partition starts successfully, the pre-boot backup partition flag will be cleared and the primary partition flag will be set to 1. If the primary partition fails to start, power on again. After reading the pre-boot backup partition flag bit to 1 for the second time, FSBL will reset the value of the Multiboot register and reset the chip to re-run the boot program (BootRom). (BootRom) Find the boot header of the backup partition based on the value of the Multiboot register to start the backup partition. After the backup partition is successfully started, the pre-start backup partition flag will be cleared and the startup backup partition flag will be set to 1.

Table 1 Flag bit changes in log partition

Through the reliable remote firmware upgrade method based on ZYNQ proposed in this embodiment, the problem of the main partition being unable to start normally due to unexpected situations encountered during the upgrade process can be effectively avoided. After the backup partition is started, the program of the backup partition can still be used to remotely restart the firmware. Upgrading the firmware data in the primary partition greatly improves product security and reliability.

The above-mentioned embodiments only express preferred embodiments of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention. It should be noted that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention.

Claims (7)

1. A reliable remote firmware upgrade method based on ZYNQ MPSoC, which is characterized by: Step 1: Divide the storage medium of the ZYNQ MPSoC embedded system into the primary partition, backup partition, and log partition, and initialize the peripherals and clocks of the ZYNQ MPSoC embedded system; Step 2: The ZYNQ MPSoC embedded system shakes hands with the server through the TFTP protocol to establish communication; Step 3: After receiving the firmware upgrade instruction from the server, the ZYNQ MPSoC embedded system interrupts the current task and replies that the server is ready to upgrade; Step 4: After receiving the preparation completion signal from ZYNQ, the server sends the upgraded firmware to the client according to the pre-agreed communication protocol; Step 5: After ZYNQ parses the data sent from the server according to the corresponding communication protocol to obtain the upgraded firmware, it calculates the cyclic redundancy check code of the received firmware data; Step 6: Compare the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol. If the check codes are consistent, it means that the received upgrade firmware data is correct and complete; if the check codes are inconsistent. , then the server firmware data error will be replied, and the server will re-issue the firmware upgrade instruction, that is, jump to step 3; Step 7: Burn the received upgraded firmware data into the main partition of the FLASH chip through the FLASH controller, and set the upgrade flag in the log partition; Step 8: After the burning is completed, ZYNQ implements a soft reset of the embedded system through the watchdog, restarts the system and enters the boot program solidified by the ZYNQ chip; loads the first-stage boot loader; Step 9: The first-stage boot loader boots the primary partition according to the flag bit in the log partition and sets the first boot flag in the log partition; if the primary partition fails to start, the first-stage boot loader reboots the backup Start the partition, jump to step 1, and re-upgrade the ZYNQ embedded system; if the main partition starts successfully, the upgrade is complete. 2. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, characterized in that the main partition is used to store normal working firmware data, and the main partition is always the destination partition for remote upgrade; the backup partition is used to store Safe mode firmware data, this firmware data can realize the basic function of remote upgrade, and the firmware data of the backup partition is in a write-protected state to ensure that the firmware data in it is not changed; the log partition stores the flag information during upgrade and startup. The first-stage boot loader FSBL will select the corresponding partition to start based on the flag information. 3. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 2, characterized in that the firmware data consists of Boot Header, Partition Header, FSBL Image, xxx.bit, u-boot.elf and xxx.elf constitute. 4. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, characterized in that when the ZYNQMPSoC embedded system shakes hands with the server through the TFTP protocol, the ZYNQ embedded system acts as a TFTP client. 5. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, characterized in that the communication protocol data consists of a start bit, data length, firmware version number, firmware data, cyclic redundancy check code, Composed of end bits. 6. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, characterized in that in step 7, the received upgraded firmware data is burned into the main partition of the FLASH chip through the FLASH controller, and the log The specific steps to set the upgrade flag bit in the partition are: Step 7.1: Read the FLASH chip ID and read the corresponding flash memory page size according to the FLASH chip ID number; Step 7.2: Write the upgrade flag bit to the log partition in the FLASH chip, and set the upgrade flag bit to 1; Step 7.3: Erase the main firmware data of the main partition in the FLASH chip; Step 7.4: Divide the upgraded firmware data into several parts according to the flash memory page size, and burn them into the main partition of the FLASH chip in sequence; Step 7.5: Read the firmware data written in the primary partition from the FLASH chip and compare it with the firmware data parsed by the communication protocol. If they are consistent, the written firmware data is correct; if they are inconsistent, jump to step 7.3. 7. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, characterized in that the first-stage boot loader FSBL selects the corresponding partition to start based on the flag information of the log partition, specifically including the following steps: Step 9.1: After the first boot loader is loaded, load the first-stage boot loader program into the on-chip RAM; Step 9.2: The first-stage boot loader reads the boot flag in the log partition; Step 9.3: According to the flag information, the first-stage boot loader sets the value of the Multiboot register; Step 9.4: According to the value of the Multiboot register, jump to the corresponding address of FLASH to load the bit stream file and executable file.