CN117573157A - Reliable remote firmware upgrading 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

Reliable remote firmware upgrading method based on ZYNQ MPSoC

Technical Field

The invention belongs to the technical field of remote firmware upgrading, and particularly relates to a reliable remote firmware upgrading method based on ZYNQ MPSoC.

Background

In current ZYNQ MPSoC (multiprocessor system chip) embedded systems, corresponding downloaders (e.g., JTAG) are often used for development and programming. After development is completed, corresponding firmware is generated, and the firmware is programmed into a FLASH chip in the ZYNQ device through JTAG and a specific programming program. However, since ZYNQ is typically packaged in a product structure for use as a digital signal processing device, if the product is still upgraded in JTAG mode, the product structure needs to be removed, which is not only very inconvenient and lacks flexibility, but also makes maintenance at a later stage very difficult. Thus, a solution for remote firmware upgrades is urgently needed.

However, during the remote firmware upgrade process, an abnormal situation may occur, which causes the loss of firmware data, and thus causes the remote upgrade to fail, so that the product cannot be started normally. To solve this problem, a rollback mechanism needs to be designed to ensure that the product can start the chip from the backup partition using the rollback function in case of a firmware upgrade failure. The design idea of the rollback mechanism is that during the firmware upgrade process, the currently running firmware is backed up to another partition first. Then, the new firmware is programmed and updated. If the firmware upgrade is successful, the system may start up normally and use the new firmware. However, if an abnormality occurs during the upgrade process to cause failure, the system may automatically switch to the backup partition and restart the chip to ensure the reliability and stability of the system.

Through the rollback mechanism, even if problems occur in the remote firmware upgrading process, the normal operation of the equipment can be ensured. When the firmware is required to be repaired or re-tried to be upgraded, the firmware upgrading process can be triggered again in a remote mode, so that flexible and convenient remote firmware upgrading is realized.

Disclosure of Invention

The invention provides a reliable remote firmware upgrading method based on ZYNQ MPSoC.

The technical scheme for realizing the purpose of the invention is as follows: a reliable remote firmware upgrading method based on ZYNQ MPSoC comprises the following steps:

step 1: dividing a storage medium of the ZYNQ MPSoC embedded system into a main partition, a backup partition and a log partition, and initializing peripheral equipment and a clock for the ZYNQ MPSoC embedded system;

step 2: the ZYNQ MPSoC embedded system performs handshake with the server through a TFTP protocol to establish communication;

step 3: after receiving the firmware upgrading instruction sent by the server, the ZYNQ MPSoC embedded system interrupts the current task and replies that the server is ready for upgrading;

step 4: after receiving the preparation completion signal sent by ZYNQ, the server sends the updated firmware to the client according to a communication protocol agreed in advance;

step 5: ZYNQ analyzes data transmitted by a server according to a corresponding communication protocol to obtain updated firmware, and calculates a cyclic redundancy check code of the received firmware data;

step 6: comparing the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol, and if the check codes are consistent, representing that the received upgrade firmware data is correct and complete; if the check codes are inconsistent, replying to the data errors of the firmware of the server, and re-sending a firmware upgrading instruction by the server, namely jumping to the step 3; .

Step 7: the received upgrade firmware data is programmed into a main partition of a FLASH chip through a FLASH controller, and upgrade flag positions in a log partition are set;

step 8: after the burning is finished, the ZYNQ realizes soft reset of the embedded system through a watchdog, and the restarting system enters a guiding program for solidifying the ZYNQ chip; loading a first stage boot loader;

step 9: the first stage boot loader guides the starting of the main partition according to the zone bit in the log partition and sets the first starting zone bit in the log partition; if the main partition is failed to be started, the first-stage boot loader is used for rebooting the backup partition to start, the step 1 is skipped, and the ZYNQ embedded system is upgraded again; if the main partition is successfully started, the upgrading is completed.

Preferably, the main partition is used for storing normal working firmware data, and is always a target partition for remote upgrading; the backup partition is used for storing firmware data in a safe mode, the firmware data can realize a basic function of remote upgrading, and the firmware data of the backup partition is in a write-protection state, so that the firmware data in the backup partition is not changed; the log partition stores the flag bit information during upgrading and starting, and the first-stage boot loader FSBL selects a corresponding partition for starting according to the flag bit information.

Preferably, the firmware data is composed of Boot loader, partition loader, FSBL Image, xxx.bit, u-boot.elf and xxx.elf.

Preferably, the ZYNQ MPSoC embedded system is used as a client of the TFTP when the ZYNQ MPSoC embedded system performs handshake with the server through the TFTP protocol.

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

Preferably, in step 7, the specific steps of writing the received upgrade 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 as follows:

step 7.1: reading the FLASH chip ID, and reading the corresponding FLASH memory page size according to the FLASH chip ID number;

step 7.2: writing an upgrade flag bit into a log partition in a FLASH chip, and setting an upgrade flag position 1;

step 7.3: main firmware data of a main partition in the FLASH chip are erased;

step 7.4: dividing the upgrade firmware data into a plurality of parts according to the size of a FLASH memory page, and sequentially programming the upgrade firmware data into a main partition of a FLASH chip;

step 7.5: the firmware data written in the main partition is read from the FLASH chip and compared with the firmware data analyzed by the communication protocol, and if the firmware data is consistent with the firmware data, the firmware data is written correctly; if not, the process jumps to step 7.3.

Preferably, the first stage boot loader FSBL selects a corresponding partition to be started according to flag bit information of the log partition, and specifically includes the following steps:

step 9.1: after the first boot loader is loaded, loading the program of the first stage boot loader into the on-chip RAM;

step 9.2: the first stage boot loader reads a start flag bit in the log partition;

step 9.3: according to the flag bit information, the first stage boot loader sets the value of the Multiboot register;

step 9.4: and according to the value of the Multiboot register, jumping to the FLASH corresponding address to load the bit stream file and the executable file.

Compared with the prior art, the invention has the remarkable advantages that: according to the invention, an external communication interface (such as an Ethernet port) is adopted to realize remote upgrading of the product firmware, so that the complex step of firmware programming by using a downloader is avoided, and the convenience and efficiency of upgrading are greatly improved; aiming at the problems of firmware data errors or loss and the like possibly occurring in the general remote firmware upgrading process, the invention also adopts a scheme of multi-partition starting. By setting the backup partition in the system, when a problem occurs in the upgrading process, the system can restart to the backup partition and update the firmware, thereby ensuring the reliability and safety of the whole upgrading process.

The present invention will be described in further detail with reference to the accompanying drawings.

Drawings

Fig. 1 is a flow chart of a remote firmware upgrading method provided by the invention.

Fig. 2 is a schematic diagram of the structure of the upgrade firmware data.

Fig. 3 is a flow chart of writing a FLASH memory chip (FLASH) after receiving the updated firmware.

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

Detailed Description

The following describes the detailed implementation of the embodiments of the present invention with reference to the drawings. It should be understood that the detailed description and specific examples, while indicating and illustrating the invention, are not intended to limit the invention.

As shown in fig. 1, a method for reliably updating remote firmware based on ZYNQ MPSoC requires partitioning a storage medium of the ZYNQ system, and in this embodiment, the storage medium adopts a FLASH memory (FLASH) chip. Dividing the FLASH chip into three partitions, namely a main partition, a backup partition and a log partition. The main partition stores normal working firmware data, and the partition is always a target partition for remote upgrading; the firmware data of the safe mode is stored in the backup partition, the firmware data can realize the basic function of remote upgrading, and the firmware data of the backup partition is in a write-protection state, so that the firmware data in the backup partition is ensured not to be changed; the log partition stores the flag bit information during upgrading and starting, and the first-stage boot loader FSBL selects a corresponding partition for starting according to the flag bit information. The backup partition and the log partition have the significance that when the problems of firmware data error or loss, sudden power failure and the like occur in the upgrading process, the ZYNQ system can still be started from the backup partition, and the problem that equipment cannot be started due to upgrading failure is avoided. The method specifically comprises the following steps:

step 1: the ZYNQ MPSoC embedded system initializes the peripheral and clock.

Step 2: ZYNQ carries out handshake with the server through TFTP protocol to establish communication, wherein the ZYNQ embedded system is used as a client of TFTP.

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

Step 4: after receiving the preparation completion signal sent by ZYNQ, the server sends the updated firmware to the client according to a communication protocol agreed in advance.

Further, the communication protocol used for upgrading the firmware needs to be pre-defined in this step, specifically, in this embodiment, the communication protocol data is composed of a start bit, a data length, a firmware version number, firmware data, a Cyclic Redundancy Check (CRC), an end bit, and the like. The starting bit and the ending bit are fixed 8 bytes of data, the data length represents the byte number of the firmware data, and the cyclic redundancy check code is calculated by the server according to the firmware data.

Step 5: ZYNQ analyzes the data transmitted by the server according to the corresponding communication protocol to obtain the updated firmware, and then calculates the Cyclic Redundancy Check (CRC) of the received firmware data.

Further, after the firmware data is analyzed, the ZYNQ system calculates a cyclic redundancy check code of the received firmware data, compares the cyclic redundancy check code with the cyclic redundancy check code analyzed in the communication protocol, and ensures the integrity of the firmware data if the cyclic redundancy check code is consistent with the cyclic redundancy check code analyzed in the communication protocol. The cyclic redundancy check code can be replaced by a message digest algorithm or other customized check codes. Specifically, as shown in fig. 2, the complete firmware data is formed by packing a boot header, a partition header, an FSBL image, a bitstream file, a u-boot file, and an executable file.

Step 6: comparing the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol, and if the check codes are consistent, representing that the received upgrade firmware data is correct and complete; if the check codes are inconsistent, the server replies the firmware data error, and the server will reissue the firmware upgrading instruction, namely jump to step 3.

The method adopts CRC check to ensure the correctness and the integrity of the firmware data, ZYNQ analyzes the data transmitted by the server according to a pre-determined communication protocol, and the communication protocol data consists of a start bit, a data length, a firmware version number, the firmware data, a cyclic redundancy check code (CRC), an end bit and the like. The ZYNQ system can analyze the firmware data and the cyclic redundancy check code which need to be upgraded according to the communication protocol. The ZYNQ system calculates the cyclic redundancy check code of the received firmware data, compares the cyclic redundancy check code with the cyclic redundancy check code analyzed in the communication protocol, and ensures the integrity of the firmware data if the cyclic redundancy check code is consistent with the cyclic redundancy check code analyzed in the communication protocol. The cyclic redundancy check code can be replaced by a message digest algorithm or other customized check codes.

Step 7: and programming the received upgrade firmware data into a main partition of the FLASH chip through the FLASH controller, and setting an upgrade flag bit in the log partition.

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

step 7.1: reading the FLASH chip ID, and reading the corresponding FLASH memory page size according to the ID number;

step 7.2: writing an upgrade flag bit into a log partition in a FLASH chip, and setting the upgrade flag bit to 1;

step 7.3: main firmware data of a main partition in the FLASH chip are erased;

step 7.4: dividing the upgrade firmware data into a plurality of parts according to the size of a FLASH memory page, and sequentially programming the upgrade firmware data into a main partition of a FLASH chip;

step 7.5: the firmware data written in the main partition is read from the FLASH chip and compared with the firmware data analyzed by the communication protocol, and if the firmware data is consistent with the firmware data, the firmware data is written correctly; if not, the process jumps to step 7.3.

Step 8: after the burning is finished, the ZYNQ realizes soft reset of the embedded system through a watchdog, and the restarting system enters a boot loader (BootRom) for solidifying the ZYNQ chip, and loads a first-stage boot loader (FSBL).

Step 9: a First Stage Boot Loader (FSBL) boots the primary partition and sets a first boot flag bit in the log partition based on the flag bit in the log partition. If the main partition is failed to be started, the First Stage Boot Loader (FSBL) is used for rebooting the backup partition to start, the step 1 is skipped, and the ZYNQ embedded system is upgraded again; if the main partition is successfully started, the upgrading is completed.

Further, as shown in fig. 4, the First Stage Boot Loader (FSBL) determines to boot the primary partition to boot or the backup partition to boot by the flag bit in the log partition, and implements the following steps:

step 9.1: after the first boot loader (BootRom) is loaded, loading the program of the First Stage Boot Loader (FSBL) into an on-chip RAM (OCM);

step 9.2: a First Stage Boot Loader (FSBL) reads a start flag bit in a log partition;

step 9.3: according to the flag bit information, a First Stage Boot Loader (FSBL) sets the value of a Multiboot register;

step 9.4: and according to the value of the Multiboot register, jumping to the FLASH corresponding address to load the bit stream file and the executable file.

The ZYNQ system can analyze the firmware data and the cyclic redundancy check code which need to be upgraded according to the communication protocol.

Preferably, the reliable remote firmware upgrading method based on ZYNQ provided by the invention adopts a multi-partition scheme, and particularly relates to a multi-partition starting method.

When some uncontrollable factors appear in the upgrading process, the main firmware data are wrong, the upgrading is failed, after the main partition cannot be started, ZYNQ can jump to the backup partition to be started through a first-stage boot loader (FSBL), the firmware of the main partition can be upgraded again from the backup partition, the risk that a product structural member needs to be removed after the upgrading is failed is avoided, and the reliability and the safety of the whole upgrading process are greatly improved.

The reliable remote firmware upgrading method based on ZYNQ provided by the embodiment adopts a multi-partition scheme, in particular to a multi-partition starting method, and the starting flow of ZYNQ is described as follows:

ZYNQ will first retrieve a valid boot-head from the FLASH chip from boot-up in the cured boot-up program (BootRom) after power-up, adding 32KB each time the search address until a valid boot-head is retrieved. After reading a valid boot-strap header, the First Stage Boot Loader (FSBL) code is loaded into on-chip RAM (OCM). Therefore, when dividing the head address of the backup partition, it should be ensured 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 head of the backup firmware data.

Specifically, in steps 8 and 9, the flag bit change in the log partition is shown in the following table, and after the first loading, the First Stage Boot Loader (FSBL) reads the upgrade flag bit as 1, and in order to prevent the main partition from upgrading in error, the backup partition flag bit 1 is pre-started and the upgrade flag bit is cleared. If the main partition is successfully started, after the main partition is successfully started, the pre-starting backup partition flag bit is cleared and the main partition flag bit 1 is started. If the primary partition fails to be started, the primary partition is powered on again, after the secondary FSBL reads that the zone bit of the pre-started backup partition is 1, the value of a Multiboot register is reset, the chip is reset, a bootstrap program (BootRom) is restarted, the bootstrap program (BootRom) finds the bootstrap head of the backup partition according to the value of the Multiboot register, and therefore the backup partition is started, and after the backup partition is started successfully, the zone bit of the pre-started backup partition is cleared and the zone bit of the backup partition is started.

Table 1 flag bit change in log partition

The reliable remote firmware upgrading method based on ZYNQ can effectively avoid the problem that the main partition cannot be started normally due to unexpected situations in the upgrading process, and firmware data in the main partition can be upgraded remotely again by using the programs of the backup partition after the backup partition is started, so that the safety and reliability of products are greatly improved.

The foregoing examples have shown only the preferred embodiments of the invention, which are described in more detail and are not to be construed as limiting the scope of the invention. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the invention, which are all within the scope of the invention.

Claims (7)

1. A reliable remote firmware upgrade method based on ZYNQ MPSoC, comprising:

step 1: dividing a storage medium of the ZYNQ MPSoC embedded system into a main partition, a backup partition and a log partition, and initializing peripheral equipment and a clock for the ZYNQ MPSoC embedded system;

step 2: the ZYNQ MPSoC embedded system performs handshake with the server through a TFTP protocol to establish communication;

step 3: after receiving the firmware upgrading instruction sent by the server, the ZYNQ MPSoC embedded system interrupts the current task and replies that the server is ready for upgrading;

step 4: after receiving the preparation completion signal sent by ZYNQ, the server sends the updated firmware to the client according to a communication protocol agreed in advance;

step 5: ZYNQ analyzes data transmitted by a server according to a corresponding communication protocol to obtain updated firmware, and calculates a cyclic redundancy check code of the received firmware data;

step 6: comparing the calculated cyclic redundancy check code with the cyclic redundancy check code in the communication protocol, and if the check codes are consistent, representing that the received upgrade firmware data is correct and complete; if the check codes are inconsistent, replying to the data errors of the firmware of the server, and re-sending a firmware upgrading instruction by the server, namely jumping to the step 3;

step 7: the received upgrade firmware data is programmed into a main partition of a FLASH chip through a FLASH controller, and upgrade flag positions in a log partition are set;

step 8: after the burning is finished, the ZYNQ realizes soft reset of the embedded system through a watchdog, and the restarting system enters a guiding program for solidifying the ZYNQ chip; loading a first stage boot loader;

step 9: the first stage boot loader guides the starting of the main partition according to the zone bit in the log partition and sets the first starting zone bit in the log partition; if the main partition is failed to be started, the first-stage boot loader is used for rebooting the backup partition to start, the step 1 is skipped, and the ZYNQ embedded system is upgraded again; if the main partition is successfully started, the upgrading is completed.

2. The reliable remote firmware upgrade method based on ZYNQ MPSoC of claim 1, wherein the main partition is used for storing firmware data of normal operation, and is always a target partition of remote upgrade; the backup partition is used for storing firmware data in a safe mode, the firmware data can realize a basic function of remote upgrading, and the firmware data of the backup partition is in a write-protection state, so that the firmware data in the backup partition is not changed; the log partition stores the flag bit information during upgrading and starting, and the first-stage boot loader FSBL selects a corresponding partition for starting according to the flag bit information.

3. The ZYNQ MPSoC-based reliable remote firmware upgrade method of claim 2, wherein the firmware data is comprised of Boot Header, partition Header, FSBL Image, xxx.bit, u-boot.elf, and xxx.elf.

4. The reliable remote firmware upgrade method based on ZYNQ MPSoC of claim 1, wherein the ZYNQ MPSoC embedded system is used as a client of TFTP when handshake is performed between the ZYNQ MPSoC embedded system and the server through TFTP protocol.

5. The reliable remote firmware upgrade method based on ZYNQ MPSoC of claim 1, wherein the communication protocol data consists of a start bit, a data length, a firmware version number, firmware data, a cyclic redundancy check code, and an end bit.

6. The reliable remote firmware upgrading method based on ZYNQ MPSoC according to claim 1, wherein the specific steps of programming the received upgrading firmware data into the main partition of the FLASH chip through the FLASH controller and setting the upgrading flag bit in the log partition in step 7 are as follows:

step 7.1: reading the FLASH chip ID, and reading the corresponding FLASH memory page size according to the FLASH chip ID number;

step 7.2: writing an upgrade flag bit into a log partition in a FLASH chip, and setting an upgrade flag position 1;

step 7.3: main firmware data of a main partition in the FLASH chip are erased;

step 7.4: dividing the upgrade firmware data into a plurality of parts according to the size of a FLASH memory page, and sequentially programming the upgrade firmware data into a main partition of a FLASH chip;

step 7.5: the firmware data written in the main partition is read from the FLASH chip and compared with the firmware data analyzed by the communication protocol, and if the firmware data is consistent with the firmware data, the firmware data is written correctly; if not, the process jumps to step 7.3.

7. The reliable remote firmware upgrade method based on ZYNQ MPSoC according to claim 1, wherein the first stage boot loader FSBL selects a corresponding partition start according to the flag bit information of the log partition, comprising the steps of:

step 9.1: after the first boot loader is loaded, loading the program of the first stage boot loader into the on-chip RAM;

step 9.2: the first stage boot loader reads a start flag bit in the log partition;

step 9.3: according to the flag bit information, the first stage boot loader sets the value of the Multiboot register;

step 9.4: and according to the value of the Multiboot register, jumping to the FLASH corresponding address to load the bit stream file and the executable file.