CN114968299A

CN114968299A - Multi-boot-based equipment firmware upgrading and exception handling method

Info

Publication number: CN114968299A
Application number: CN202210421772.7A
Authority: CN
Inventors: 钱宏文; 倪文龙; 吴翼虎; 刘继祥
Original assignee: CETC 58 Research Institute
Current assignee: CETC 58 Research Institute
Priority date: 2022-04-21
Filing date: 2022-04-21
Publication date: 2022-08-30

Abstract

The invention relates to a method for upgrading and exception handling of firmware of a multi-boot-based device, which realizes the image reliable handling method for upgrading and loading the exception device by using an application program of the device firmware and the dynamic update of configuration parameters of the device firmware by using a multi-boot technology, wherein the exception handling method is based on hardware adopting an acquisition control board with an SOC + FPGA architecture, a control chip adopts ZYNQ, the FPGA adopts K7, and the ZYNQ chip integrates a dual-core ARM and the FPGA and supports a serial port and a gigabit network port. The exception handling method can ensure efficient, reliable and rapid upgrading; the chip slave backup image can be started through the Multiboot function under the condition that the loading of the master image fails; and functions that can be used for device firmware configuration parameter updates to adapt to a variety of complex operating environments.

Description

Multi-boot-based equipment firmware upgrading and exception handling method

Technical Field

The invention relates to the technical field of FPGA (field programmable gate array), in particular to a firmware upgrading and exception handling method based on a Multiboot device.

Background

In the product update iteration process, the stability of the execution image needs to be ensured. However, when a single mapping file in Flash of the FPGA has an error, the Flash cannot be read and written again by using a remote update scheme, and the previous error is corrected, which may cause the remote update to be completely invalid and only arrange field update for repair. However, the equipment is often installed and disassembled on site, which brings great inconvenience to the equipment updating and maintenance. The Multiboot technology is used for upgrading and backing up Image files in products, and is allowed to reasonably partition a Flash device in a device with Flash, plan a plurality of Image file storage areas and select the value of a boot guide mark header of BootROM by using an FSBL program or a user program under a ZYNQ7000 heterogeneous processing platform, so that the device can realize free skip among a plurality of Multiboot images according to different requirements and states, thereby ensuring the upgrading stability of device application programs and the flexibility of dynamically modifying device loading parameters.

Disclosure of Invention

In order to solve the above technical problems, the method for upgrading and exception handling of firmware based on a Multiboot device according to the present invention, which uses the Multiboot technology to implement a reliable processing method for loading and upgrading an exception device image and dynamic updating of device firmware configuration parameters, includes the following steps:

step S1: under a Vivado development environment, a BLOCK part design based on ZYNQ is manufactured according to Platform hardware, a bit stream and a Platform file are led into an SDK, and a UserBoot Image, a Golden Image and a Multiboot Image are manufactured;

step S2: according to the Multiboot technical principle, combining with the use scene and the requirement of a universal test platform, reasonably dividing Flash into four areas, and downloading the images of all the parts to the corresponding areas of the Flash through a simulator program;

step S3: opening the upper computer software, connecting the serial port and the network port to the equipment, and electrifying the equipment again;

step S4: if the upgrading and related parameter changing requirements exist, after the universal test platform of the equipment receives the instruction through the network port or the serial port, ZYNQ finishes the work of the specified multi-boot Image of the test platform on upgrading or related parameter changing requirements, or else, the step S5 is continued;

step S5: and if no system upgrading or parameter configuration request exists, skipping the UserBoot Image, starting the Multiboot Image, and determining whether to start the Golden Image or the Multiboot Image by checking the integrity and the correctness of the Multiboot Image.

In an embodiment of the invention, the hardware based on the exception handling method adopts an acquisition control board with an SOC + FPGA architecture, wherein a control chip adopts ZYNQ, the FPGA adopts K7, and the ZYNQ chip integrates dual-core ARM and FPGA and supports a serial port and a gigabit network port.

In one embodiment of the present invention, in step S1, the user book Image, Golden Image multi-boot Image are generated based on the same BLOCK design and Platform file.

In an embodiment of the present invention, the Flash partition in step S2 is a work that needs to be done for a new device used for the first time, or a device that does not use a Multiboot technology before.

In an embodiment of the present invention, in step S3, after the ZYNQ Flash program is updated, before powering on, it is ensured that the software of the upper computer required for upgrading is opened, and the serial port and the network port connected to the terminal for upgrading or parameter modification are connected to the device, otherwise, the execution of the subsequent steps will be affected.

In an embodiment of the present invention, in the step S4, if the upgrade and the related parameter change are required, an upgrade instruction needs to be issued by the upper computer before the wait countdown of the user boot Image phase is finished, so as to complete the update of the specified multi boot Image of the test platform, otherwise, the test platform needs to jump to the step S3 again to start executing.

In an embodiment of the present invention, in the step S5, the checking of the integrity and correctness of the multi boot Image is mainly performed by using a check algorithm in the MD5, an MD5 check is added when the Image file is generated, and the result of the MD5 check algorithm is read when the Image file is started, so as to determine the correctness of the multi boot Image and a decision whether to jump to the Golden Image.

Compared with the prior art, the technical scheme of the invention has the following advantages: according to the method for upgrading the firmware and processing the exception based on the Multiboot device, the hardware is a heterogeneous processing platform, and the hardware processing platform makes full use of the advantages of respective architectures by utilizing the difference of processor kernels, so that the method is widely used by academics and markets. ZYNQ7000 is a heterogeneous multi-core processor with two architectures, which is introduced by Xilinx corporation, and Advanced Extensible Interface (AXI) is used for interconnection between an ARM processor and programmable logic, so that the platform can support high-bandwidth transmission between an ARM processor system and programmable logic with low power consumption. The system is electrified to firstly complete the work of loading and guiding the bit stream data, and then enters the ARM processor part to complete the work set by the processor. The ARM completes the work of control planes such as port control, peripheral driving, Ethernet data receiving and the like, the logic part completes the work of data planes such as data acquisition and algorithm processing, and the like, and the data interaction between the ARM and the logic part can be completed through a high-speed AXI bus, so that the superiority of software and hardware coordination processing of heterogeneous platform processing is fully reflected.

Drawings

In order that the present disclosure may be more readily and clearly understood, reference will now be made in detail to the present disclosure, examples of which are illustrated in the accompanying drawings.

FIG. 1 is a block diagram of a hardware platform design according to the present invention;

FIG. 2 is a Multiboot startup flow diagram according to the present invention;

FIG. 3 is a schematic diagram of Flash partition according to the present invention;

FIG. 4 is an overall flow chart of the device software of the present invention;

FIG. 5 is a flow chart of the Userboot software of the present invention;

fig. 6 is a Multiboot upgrade prompt information diagram according to the present invention.

Detailed Description

The embodiment provides a method for upgrading and exception handling of firmware based on a Multiboot device, which utilizes a Multiboot technology to realize a reliable processing method for upgrading and loading an exception device image and dynamic updating of device firmware configuration parameters, wherein the method comprises the following steps:

Fig. 1 is a block diagram of a hardware structure of a generalized test platform, wherein the hardware adopts an acquisition control board with an SOC + FPGA architecture, and the acquisition control board is composed of upper computer software, a ZYNQ, an FPGA and an ADC daughter board. And the upper computer and the universal test platform carry out data interaction through the serial port and the Ethernet.

A control chip of the system adopts ZYNQ, an FPGA adopts K7, and the ZYNQ chip integrates dual-core ARM and FPGA and supports serial ports and gigabit network ports. The upper computer software part mainly completes protocol interaction with a universal test platform, FSBL and bit stream generation, check code generation and Multiboot image file production. The FPGA is used for controlling the ADC to be tested to collect data, and the ADC/DAC data machine can be uploaded or issued through the upper computer.

Fig. 2 is a flowchart of software boot based on a multi boot, which essentially directly operates a plurality of images, and for convenience of description, the images in the multi boot are Golden (G image) and multi boot (M image), respectively.

In the FSBL running process, a bit file and an elf file of an address corresponding to Flash are found for loading according to the value of a Multiboot register, and when loading fails due to any abnormity and errors in the process, the Multiboot register is updated through an FsbLfallback function, a chip is reset, BootROM is re-run until a Golden _ Image is found, and therefore starting skip is achieved.

As can be seen from fig. 2, the bootrom header starts searching from the base address (each time the value of the Multiboot register is increased by 32KB, the value is also increased by 1) until a valid bootrom header is found (the bootrom header search range has a certain limit, wherein Nor Flash can only reach 32 MB). When the BootROM finds a valid header, then jumping to the FSBL, detecting the validity of the FSBL, judging the value of the Multiboot register, if the value is not the Multiboot, continuing to run the corresponding application program, otherwise, appointing a new Multiboot starting address, and triggering software reset. After the software is reset, the BOOTROM will use the address in the Multiboot register to read the BOOTROM header, and then jump to the real application.

When a system is upgraded and updated with system firmware, an operation error of writing in Flash may occur, or data in a part of addresses in Flash may be in error, which may result in an error in data that cannot be written correctly or stored, and thus may result in an inability to load an FPGA successfully. Multiboot recovers it from an error. FSBL updates the value of the Multiboot register and generates a software reset to cause the BootROM load to run another available image. That is, if the system is successfully updated or configured, the M image is executed; if the run fails, the G image is loaded.

In Multiboot, only the M-image is updated when the system is updated, and the M-image is directly used after the update. And when the update of the M image has errors, starting the G image. And updating the data of the M image part in the Flash through the design in the G image. Because the G image is read-only, the system can load the G image file normally. Therefore, even if the M image has errors, the current running function of the system can be completed through the G image, and the reliability of the system is ensured.

FIG. 3 is a schematic diagram of Flash interval division of a generalized test platform. First, a structure of a different-function image block boot. bin file generated by the SDK is as follows, corresponding addresses from top to bottom are from low to high. The system is divided into 4 parts:

user controls the first-level boot

The multi-boot image is composed of 3 blocks including FSBL, bit and multi-boot

Golden _ image is composed of 3 blocks of FSBL, bit and Golden

Fixed Parameter area

MD5 checking of bit files and elf files is enabled when generating bin files (fsbl. elf cannot use MD5 checking function). Both MD5 checksums will be added at the end of the bin file. The structure of the BOOT. BIN file at this time is: MD5 checksum allows FSBL to check the correctness of bit files and elf files. This has a very important role for image upgrade.

And burning a USB Flash through a JTAG (joint test action group) by using a Userboot _ image Multiboot _ image Golden _ image file generated by the SDK.

As can be seen from fig. 3, the Multiboot scheme of the Xilinx 7-series FPGA stores UserBoot _ Image from the base address (and subsequently stores Multiboot1_ Image, Multiboot2_ Image, and Golden _ Image). In the loading process, UserBoot _ Image is loaded firstly, and mapping files, namely Multiboot _ Image and Golden _ Image, are stored in Flash. The Image upgrade process only updates the Multiboot _ Image, while Golden _ Image is read-only as a backup and is not updated. The purpose of this is to switch to the backup Golden _ Image to start when the Multiboot _ Image is abnormal or fails to update the Multiboot _ Image, so as to avoid the device program being executed in the abnormal starting part all the time.

Fig. 4 is a general software flowchart, and in general, after a chip is powered on, BootROM starts up first, a program start-up mode is detected, and FSBL is loaded from Flash. And the FSBL reads Bitstream from the Flash in sequence, configures the Bitstream to a PL (provider line) end, reads an elf file and loads the elf file to the DDR. And finally, the FSBL finishes running, and the PS jumps to the program corresponding to the elf file to continue executing. Partition Header in the bin file is an important parameter for FSBL to load bit file and elf file.

Under a Vivado development environment, manufacturing a BLOCK part design based on ZYNQ according to Platform hardware, and importing a bit stream and a Platform file into an SDK; after the Flash storage format and address allocation of fig. 3 are completed, the Userboot _ image at the starting position 1 is loaded through the BootROM, the correctness of the Userboot _ image is verified through checking the Partition Header through the Header checksum, and the correctness of the bit and elf files is verified through the MD5 checksum. If the image is incomplete or an error occurs in a portion other than the FSBL, it is detected by BootROM or FSBL. BootROM Header verifies correctness through Header check and is checked by BootROM. An incorrect Header check will cause the FSBL to effect a chip jump into Golden _ Image launch via FsblFallback. Sequentially executing the FSBL, the loading bit and the Golden application program from the Golden _ Image address; if the correctness of the Image is verified through checking the Partition Header through the Header check, jumping to the position of the Multiboot _ Image, starting to execute a Multiboot program, sequentially executing the FSBL, loading the bit and finally starting the Multiboot application program.

If an error or an abnormality occurs in the process of updating the multibot _ image, so that the multibot _ image cannot be completely updated, the chip cannot be started from the multibot _ image, and the function of the multibot program fails, because the BootROM does not check the FSBL part in the BOOT.bin. If BootROM loads and runs incomplete FSBL or FSBL with errors, abnormal FSBL cannot normally load bit files and elf files, and cannot realize Multiboot through an FsbLfallback function. At this time, the Golden _ Image area is immediately jumped to, and the Golden _ Image area-dependent FSBL, the bit stream and the application program are executed. And if the Multiboot needs to be updated again, the system jumps to the Uerboot _ image to be executed again, and the re-upgrading work of the corresponding area is completed according to the upgrading option.

Fig. 5 is a flow chart of the user boot software, where the user boot part is a key component of the Multiboot technology and is also a first image file that needs to be loaded when the boot rom is started by the whole system, and the steps of the flow chart of the user boot software are described as follows in combination with fig. 5:

a. initial state

Before the UserBoot software is realized and executed, the FSBL and the Userboot _ image Multiboot _ image Golden _ image need to be sequentially downloaded to Flash formulated addresses through the JTAG;

b. system start-up

The system is powered on, firstly, the sending of an upgrading instruction is waited, whether the system interrupt enters into the Multiboot _ image or enters into the Multiboot _ image updating is judged by detecting the update identifier, and if the system does not receive the update identifier, the system directly enters into the Multiboot _ image to be started.

c. Upgrade file

And if the system receives the update identification request, the upper computer sends an update file Multiboot _ image through the network, and after the update file is received, the file is written into a corresponding memory address. After the image is updated, skipping, namely running one or more Multiboot _ images in the image or entering the image abnormally can be realized.

Fig. 6 shows how to update the upgrade prompt information, if an update identifier request is received during the starting process, the upper computer may send the data to be upgraded to the platform through the platform port, and after the platform checks to ensure the integrity and correctness of the sent data, the upper computer automatically updates the received multi _ image to the designated multi region to complete the update and upgrade. If the multi _ image cannot be completely updated or even the wrong data is updated due to some reasons, such as sudden power off, during the updating of the multi _ image, the chip cannot be started from the multi _ image, and the function of the multi program fails. In this case, the PS will run away in the wrong FSBL, causing system deadlock, and the chip cannot be started normally, and if there is no Multiboot function, Flash can be re-burned only through JTAG by the conventional method. This is a fatal consequence for the product.

By the method, the device can be freely jumped and upgraded among a plurality of Multiboot _ images according to different requirements and states, and the flexibility of loading parameters of the device can be dynamically modified. The equipment can be ensured to intelligently respond to various requirements and use conditions, and the upgrading reliability and stability of the application program of the equipment are ensured.

By comprehensively comparing the conventional equipment upgrading method with the multi-boot update upgrading method and taking a boot.bin (about 2.75M) file as an example for testing, as shown in table 1, it can be seen that the multi-boot method is adopted, compared with the conventional method, the method is simple to use and high in reliability, and the upgrading time is improved by 9 times compared with the conventional method, and the two methods are comprehensively compared as shown in the following table.

It should be understood that the above examples are only for clarity of illustration and are not intended to limit the embodiments. Other variations and modifications will be apparent to persons skilled in the art in light of the above description. And are neither required nor exhaustive of all embodiments. And obvious variations or modifications of the invention may be made without departing from the spirit or scope of the invention.

Claims

1. Based on a Multiboot device firmware upgrading and exception handling method, the reliable processing method for upgrading and loading exception device images and the dynamic update of device firmware configuration parameters, which can be used for device firmware application programs, are realized by using a Multiboot technology, and the method is characterized by comprising the following steps:

2. The Multiboot-based device firmware upgrade and exception handling method according to claim 1, wherein: the abnormality processing method is based on the fact that hardware adopts an acquisition control board with an SOC + FPGA architecture, a control chip adopts ZYNQ, the FPGA adopts K7, and the ZYNQ chip integrates dual-core ARM and FPGA and supports serial ports and gigabit network ports.

3. The Multiboot-based device firmware upgrade and exception handling method according to claim 1, wherein: in step S1, the user book Image and the Golden Image multi-boot Image are generated based on the same BLOCK design and Platform file.

4. The Multiboot-based device firmware upgrade and exception handling method according to claim 1, wherein: the Flash partition in step S2 is a work that needs to be done for a new device used for the first time, or a device that has not used the Multiboot technology before.

5. The Multiboot-based device firmware upgrade and exception handling method according to claim 1, wherein: in step S3, after the ZYNQ Flash program is updated, it is ensured that the software of the upper computer required for upgrading is opened before power-on, and the serial port and the network port connected to the terminal for upgrading or parameter modification are connected to the device, otherwise, the execution of the subsequent steps will be affected.

6. The Multiboot-based device firmware upgrade and exception handling method according to claim 1, wherein: in the step S4, if the upgrade and the related parameter change requirements are met, an upgrade instruction needs to be issued by the upper computer before the wait countdown in the user boot Image stage is finished, so as to complete the update of the test platform specified multi boot Image, otherwise, the test platform needs to jump to the step S3 again to start execution.

7. The Multiboot device based firmware upgrade and exception handling method according to claim 1, wherein: in step S5, the checking of the integrity and correctness of the multi boot Image is mainly completed by using the MD5 check algorithm, the MD5 check is added when the Image file is generated, and the result of the MD5 check algorithm is read when the Image file is started, so as to determine the correctness of the multi boot Image and the decision of whether to jump to the Golden Image.