Online updating method for ZYNQ master-slave system based on BS architecture

Abstract

The invention discloses an online updating method for a ZYNQ master-slave system based on a BS (Browser / Server) architecture, which comprises the following steps: firstly, a data transmission link between a browser client and an HTTP (Hyper Text Transport Protocol) server is carried out, the browser client is connected to the HTTP server running on a mainboard, and binary files are subpackaged and sent to the server; in the data transmission link between the main board and the slave board, the main board runs a functional program, and the slave board develops an application program based on a bare core. When the mainboard is upgraded, the mainboard is restarted, and the binary programming file is replaced and operated. When the slave board is upgraded, the binary programming file is sent to the slave board subpackage through a UDP protocol, after sending is completed, the slave board replies the check sum of the received binary programming file, after the check sum is compared by the functional program to be consistent, a programming instruction is sent to the slave board, and the slave board erases and programs the corresponding QSPI FLASH sector according to the length of the binary programming file. And the server and the function program interact through the state file, and the progress of each link is displayed on a webpage, so that the ZYNQ master-slave system is quickly and conveniently upgraded based on the BS architecture.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology, and in particular relates to a ZYNQ master-slave system online update method based on BS architecture. Background Art

[0002] ZYNQ is a new generation of fully programmable system-on-chip launched by Xilinx. It combines a processing system (PS) with a dual-core ARMCortex-A9 processor and a field-programmable gate array logic unit (PL), providing unparalleled system performance, flexibility and scalability, and has been widely used in the fields of communications, aerospace, etc. However, in complex ZYNQ systems, when the equipment needs to run in a Linux operating system and work with a naked ZYNQ master-slave system, the existing upgrade method cannot simultaneously meet the requirements of upgrading the ZYNQ master and slave boards. Developing a convenient and fast upgrade method for complex ZYNQ systems has become the key to the flexible application of ZYNQ chips.

[0003] The existing ZYNQ multi-board software upgrade methods mainly include upgrading using JTAG emulators, remote upgrading using BS architecture, and online upgrading that relies on different transmission methods of the host computer. When there are multiple ZYNQ boards in the system, the traditional JTAG upgrade can upgrade the naked ZYNQ, but it requires plugging and unplugging connectors one by one, which is time-consuming and labor-intensive; the existing BS architecture remote upgrade requires each ZYNQ board to run an operating system, and cannot upgrade the naked ZYNQ board without an operating system, which limits the use scenario of ZYNQ multi-board cards that are all deployed with an operating system; online upgrading that relies on different transmission methods of the host computer requires carrying special host computer software and upgrading through different transmission methods, such as serial ports, CAN interfaces, etc. This process is heavily dependent on the host computer and requires the host computer to establish a direct connection with the slave board, which is not conducive to system expansion. Therefore, it has become a difficult problem to achieve fast and convenient upgrades of complex ZYNQ multi-boards. Summary of the invention

[0004] In view of the problem that the existing upgrade method cannot simultaneously meet the needs of upgrading the ZYNQ master and slave boards when the equipment needs to operate in a Linux operating system and a naked ZYNQ master-slave system in a complex system, the present invention provides a method for online updating of the ZYNQ master-slave system based on the BS architecture, designs a strategy for collaborative upgrading of "main board (operating system ZYNQ) and slave board (naked ZYNQ)", and the upgrade process is convenient and intuitive, which can cope with the ZYNQ multi-board software upgrade scenario in a complex system.

[0005] The technical solution to realize the present invention is: a ZYNQ master-slave system online update method based on BS architecture, the steps are as follows:

[0006] Step 1: The PC interacts with the mainboard through the external network port, and the mainboard interacts with the slave board through the internal network port; the ZYNQ mainboard installs an embedded operating system and runs the HTTP server and functional programs.

[0007] Step 2: The server and the functional program are different processes running on the operating system. They interact by reading and writing the "status file". When the server receives the burning file sent by the web interface, it sets the upgrade status in the "status file" of the board to be upgraded to "1", indicating that the browser has completed sending it to the server.

[0008] Step 3: When upgrading the motherboard, after the server receives the data, it binds the upgrade status data of the corresponding motherboard in the "status file" to "1" and starts the motherboard upgrade process.

[0009] Step 4. The running environment of the ZYNQ slave board is naked running, and it interacts with the main board through the internal network port and performs file transfer based on the UDP protocol. When upgrading the slave board, after the server receives the burning file sent by the web interface, it binds the upgrade status corresponding to the upgraded board in the "status file" to "1", and the main board function program reads the "status file" to obtain the ID and upgrade status of the slave board to be upgraded. When the upgrade status is "1", the main board function program reads the binary burning file from the upgrade folder, accumulates and calculates the binary burning file by byte, and obtains a 1-byte checksum. If the main board function program cannot read the binary burning file, the corresponding upgrade status in the "status file" is bound to "4", indicating that the binary file does not exist, the main board function program cannot read it, and the upgrade fails. At the same time, a read success or failure mark is sent to the client, and the web interface displays the upgrade progress.

[0010] Step 5. The main board and the slave board establish a UDP connection. The main board function program transmits the binary burning file in packets. The message length and packet sequence number are attached to the message and transmitted to the slave board through the UDP protocol. The slave board puts the valid data part of each received message into the buffer area to complete the splicing.

[0011] Step 6. When the slave receives the last packet, the binary burning file in the buffer area is accumulated and calculated by bytes to obtain a 1-byte checksum. The checksum and the binary file length are attached to the reply message and sent to the main board through the UDP protocol; the main board compares the checksum and file length in step 4 with the checksum and file length received from the slave. If they are inconsistent, the corresponding upgrade status in the "status file" is bound to "7", indicating that the data received by the slave is inconsistent with the checksum and file length of the binary file; if they are consistent, the corresponding upgrade status in the "status file" is bound to "2", indicating that the main board has successfully sent the data to the slave, and the slave starts burning; at the same time, the checksum and file length comparison mark are sent to the client, and the web interface displays the upgrade progress.

[0012] Step 7. The slave board erases the memory area of ​​the corresponding QSPI FLASH chip according to the length of the binary message, and then burns the binary burning file. After the file is burned, the QSPI FLASH is read back, and the read-back data is compared with the burned data byte by byte, and the comparison result is sent to the main board.

[0013] Compared with the prior art, the present invention has the following significant advantages:

[0014] (1) In scenarios where the equipment system is complex and requires the Linux operating system and the naked ZYNQ master-slave system to work together, the multi-board upgrade speed is fast.

[0015] (2) Easy operation, can be upgraded using a PC browser, no need to install a host computer program. Under this master-slave architecture, any increase in the number of slave boards can achieve rapid upgrades of multiple boards, with strong scalability.

[0016] (3) The main board acts as a medium for the interaction between the slave board and the web page, which reduces the difficulty of developing a BS architecture suitable for the slave board whose operating environment is naked.

[0017] (4) Data transmission between the master and the slave uses custom messages and adds a UDP receiving handshake mechanism, which has strong reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a connection diagram of the PC, mainboard, and slave board.

[0019] Figure 2 This is a schematic diagram of the interaction between the web page interface and the mainboard.

[0020] Figure 3 Flowchart for sending files to the server for the web interface.

[0021] Figure 4 This is a schematic diagram of the status file data.

[0022] Figure 5 Schematic diagram for upgrading the ZYNQ master and slave boards. DETAILED DESCRIPTION

[0023] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only 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.

[0024] In a complex ZYNQ master-slave system, the ZYNQ mainboard is the control center of each component in the device and the main body of the interaction between devices. Therefore, the ZYNQ mainboard often needs to meet various flexibility requirements and can run a rich set of third-party services based on the operating system, which requires the ZYNQ mainboard to be equipped with an operating system. The ZYNQ slave board needs to complete various functional tasks in the device and also needs to call the drivers of various digital-to-analog conversion chips. It has the characteristics of large amount of calculation, high performance requirements, and easy development of underlying programs. Therefore, the operating environment is mostly naked. At present, the remote upgrade operation for the complex ZYNQ master-slave system is cumbersome, and the BS architecture has the advantages of easy deployment, cross-platform, and easy expansion. It is widely used in the remote upgrade of equipment. However, due to the difficulty of developing the BS architecture under the non-operating system, the ZYNQ slave board developed based on naked running is difficult to adapt to the BS architecture. Therefore, the present invention proposes a ZYNQ mainboard as a server, which acts as a medium for the client to interact with the ZYNQ slave board, so as to realize a method in which the complex ZYNQ master-slave system can be remotely upgraded based on the BS architecture.

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

[0026] Combination Figure 1 to Figure 5 The present invention discloses a ZYNQ master-slave system online update method based on BS architecture, and the steps are as follows:

[0027] Step 1: Combine Figure 1 , the PC interacts with the motherboard through the external network port, and the motherboard interacts with the slave board through the internal network port. Figure 2 , the ZYNQ motherboard is installed with an embedded operating system, and runs HTTP servers and functional programs. The browser client runs and inputs the specified URL, establishes a connection with the server through the external network port, opens the web page interface, selects the board to be upgraded in the web page interface, and loads the binary burning file. The mainboard burning file is an ELF file, and the slave board burning file is a BIN file; the ID of the burning board is compared with the file name of the burning file. After the comparison is passed, the burning file is sub-packaged and transmitted to the server using the HTTP protocol. The server stores the received data in the upgrade folder specified by the mainboard, and sends a receiving completion mark to the client at the same time. The client displays the current progress on the web page.

[0028] Step 2: Combine Figure 2 , the server and the functional program are different processes running on the operating system, and interact by reading and writing "status files". Figure 4The content of the "status file" is a number of data, each of which corresponds to the upgrade status of a different ZYNQ board. After the server receives the burning file sent by the web interface, it binds the upgrade status in the "status file" of the board to be upgraded to "1", indicating that the browser has completed sending it to the server (hereinafter referred to as "1"). When the function program is initialized, the remote upgrade thread is opened, and the "status file" is read regularly. When the data in the "status file" is bound, the board to be upgraded and the board upgrade status are determined according to the data in the "status file", and the corresponding board upgrade process is executed.

[0029] Step 3: Combine Figure 5 When upgrading the motherboard, after the server receives the data, it sets the upgrade status data of the corresponding motherboard in the "status file" to "1" and starts the motherboard upgrade process. The motherboard function program calls the "system" system function to restart the operating system. When the system restarts, the motherboard self-start script replaces the original function program file with the new function program file, and then starts the upgraded motherboard function program to complete the motherboard upgrade. At the same time, the upgrade completion mark is sent to the client, and the web interface shows that the motherboard upgrade is completed.

[0030] Step 4. The running environment of the ZYNQ slave board is naked running, and it interacts with the main board through the internal network port and transfers files based on the UDP protocol. When upgrading the slave board, after the server receives the burning file sent by the web interface, it binds the upgrade status corresponding to the upgraded board in the "status file" to "1", and the main board function program reads the "status file" to obtain the ID and upgrade status of the slave board to be upgraded. When the upgrade status is "1", the main board function program reads the binary burning file from the upgrade folder, accumulates and calculates the binary burning file by byte, and obtains a 1-byte checksum. If the main board function program cannot read the binary burning file, the corresponding upgrade status in the "status file" is bound to "4", indicating that the binary file does not exist, the main board function program cannot read it (hereinafter referred to as "4"), and the upgrade fails. At the same time, a read success / failure mark is sent to the client, and the web interface displays the upgrade progress.

[0031] Step 5: Combine Figure 5 , the main board and the slave board establish a UDP connection, the main board function program transmits the binary burning file in packets, the message length and packet sequence number are attached to the message, and transmitted to the slave board through the UDP protocol. The slave board puts the valid data part of each received message into the buffer area to complete the splicing. If the binary burning file transmission process takes more than 300 seconds, the timeout mark is pulled high, and the main board function program binds the corresponding upgrade status in the "status file" to "6", indicating that the main board has timed out from sending the binary burning file transmission to the slave board (hereinafter referred to as "6"). At the same time, the data transmission timeout mark is sent to the client, and the web interface displays the upgrade progress.

[0032] Step 6: When the slave receives the last packet, the binary burning file in the buffer is accumulated and calculated by bytes to obtain a 1-byte checksum. The checksum and the length of the binary file are attached to the reply message and sent to the main board via the UDP protocol. The main board compares the checksum and file length in step 4 with the checksum and file length received from the slave. If they are inconsistent, the corresponding upgrade status in the "status file" is bound to "7", indicating that the data received by the slave is inconsistent with the checksum and file length of the binary file (hereinafter referred to as "7"); if they are consistent, the corresponding upgrade status in the "status file" is bound to "2", indicating that the main board has successfully sent the data to the slave and the slave starts burning (hereinafter referred to as "2"). At the same time, the checksum and file length comparison mark are sent to the client, and the web interface displays the upgrade progress.

[0033] Step 7: Combine Figure 5 , the slave board erases the corresponding memory area of ​​the QSPIFLASH chip according to the binary message length (BIN file size), and then burns the binary burning file; after the file is burned, read back the QSPI FLASH, compare the read-back data with the burned data byte by byte, and send the comparison result to the main board.

[0034] If the comparison fails, the mainboard will bind the corresponding upgrade status in the "status file" to "5", indicating that the comparison between the slave board's burning data and the read-back data fails (hereinafter referred to as "5"), and the upgrade fails; if the comparison passes, the mainboard will bind the corresponding upgrade status in the "status file" to "3", indicating that the slave board is burned and the upgrade is successful (hereinafter referred to as "3"). At the same time, the upgrade success / failure mark is sent to the client, and the web interface displays the upgrade progress.

Claims

1. A ZYNQ master-slave system online update method based on BS architecture, characterized in that: Here are the steps: Step 1: The PC interacts with the mainboard through the external network port, and the mainboard interacts with the slave board through the internal network port; the ZYNQ mainboard installs an embedded operating system and runs the HTTP server and functional programs; Step 2: The server and the functional program are different processes running on the operating system. They interact by reading and writing the "status file". When the server receives the burning file sent by the web interface, it sets the upgrade status in the "status file" of the board to be upgraded to "1", indicating that the browser has completed sending it to the server. Step 3: When upgrading the motherboard, after the server receives the data, it sets the upgrade status data of the corresponding motherboard in the "status file" to "1" and starts the motherboard upgrade process; Step 4. The running environment of the ZYNQ slave board is naked running, and it interacts with the main board through the internal network port and performs file transfer based on the UDP protocol. When upgrading the slave board, after the server receives the burning file sent by the web interface, it binds the upgrade status corresponding to the upgraded board in the "status file" to "1", and the main board function program reads the "status file" to obtain the ID and upgrade status of the slave board to be upgraded. When the upgrade status is "1", the main board function program reads the binary burning file from the upgrade folder, accumulates and calculates the binary burning file by byte, and obtains a 1-byte checksum. If the main board function program cannot read the binary burning file, the corresponding upgrade status in the "status file" is bound to "4", indicating that the binary file does not exist, the main board function program cannot read it, and the upgrade fails. At the same time, a read success or failure mark is sent to the client, and the web interface displays the upgrade progress. Step 5. The main board and the slave board establish a UDP connection. The main board function program transmits the binary burning file in packets. The message length and packet sequence number are attached to the message and transmitted to the slave board through the UDP protocol. The slave board puts the valid data part of each received message into the buffer area to complete the splicing. Step 6. When the slave receives the last packet, the binary burning file in the buffer area is accumulated and calculated by bytes to obtain a 1-byte checksum. The checksum and the binary file length are attached to the reply message and sent to the main board through the UDP protocol; the main board compares the checksum and file length in step 4 with the checksum and file length received from the slave. If they are inconsistent, the corresponding upgrade status in the "status file" is bound to "7", indicating that the data received by the slave is inconsistent with the checksum and file length of the binary file; if they are consistent, the corresponding upgrade status in the "status file" is bound to "2", indicating that the main board has successfully sent the data to the slave, and the slave starts burning; at the same time, the checksum and file length comparison mark are sent to the client, and the web interface displays the upgrade progress; Step 7, the slave board erases the memory area of ​​the corresponding QSPIFLASH chip according to the binary message length, and then burns the binary burning file; After the file is burned, the QSPIFLASH is read back, and the read-back data is compared with the burned data byte by byte, and the comparison result is sent to the mainboard.

2. According to the BS architecture-based ZYNQ master-slave system online update method of claim 1, it is characterized in that: In step 1, the PC interacts with the mainboard through the external network port, and the mainboard interacts with the slave board through the internal network port; the ZYNQ mainboard installs an embedded operating system and runs the HTTP server and functional programs, as follows: The browser client runs and inputs the specified URL, establishes a connection with the server through the external network port, opens the web page interface, selects the board to be upgraded in the web page interface, and loads the binary burning file. The mainboard burning file is an ELF file, and the slave board burning file is a BIN file. The ID of the burning board is compared with the file name of the burning file. After the comparison is passed, the burning file is packaged and transmitted to the server using the HTTP protocol. The server stores the received data in the upgrade folder specified by the mainboard, and sends a receiving completion mark to the client at the same time. The client displays the current progress on the web page.

3. According to the BS architecture-based ZYNQ master-slave system online update method of claim 1, it is characterized in that: In step 2, the content of the "status file" is a number of data, each of which corresponds to the upgrade status of a different ZYNQ board.

4. According to the BS architecture-based ZYNQ master-slave system online update method of claim 1, it is characterized in that: In step 2, the server and the functional program are different processes running on the operating system, and interact by reading and writing the "status file". When the server receives the burning file sent by the web interface, it sets the upgrade status in the "status file" of the board to be upgraded to "1", indicating that the browser has completed sending it to the server; the details are as follows: When the function program is initialized, the remote upgrade thread is started and the "status file" is read regularly. When the data in the "status file" is bound, the board to be upgraded and the board upgrade status are determined according to the data in the "status file", and the corresponding board upgrade process is executed.

5. The online update method of ZYNQ master-slave system based on BS architecture according to claim 1 is characterized in that: In step 3, when upgrading the motherboard, after the server receives the data, it sets the upgrade status data of the corresponding motherboard in the "status file" to "1" and starts the motherboard upgrade process, as follows: The motherboard function program calls the "system" system function to restart the operating system; when the system restarts, the motherboard self-startup script replaces the original function program file with the new function program file, and then starts the upgraded motherboard function program to complete the motherboard upgrade; at the same time, an upgrade completion mark is sent to the client, and the web interface shows that the motherboard upgrade is complete.

6. The online update method of ZYNQ master-slave system based on BS architecture according to claim 1 is characterized in that: In step 5, the main board and the slave board establish a UDP connection. The main board function program transmits the binary burning file in packets. The message length and packet sequence number are attached to the message and transmitted to the slave board through the UDP protocol. The slave board puts the valid data part of each received message into the buffer area to complete the splicing, as follows: If the binary burning file transmission process takes more than 300 seconds, the timeout mark is pulled high, and the mainboard function program sets the corresponding upgrade status in the "status file" to "6", indicating that the mainboard has timed out in sending the binary burning file transmission to the slave board; at the same time, it sends a data transmission timeout mark to the client, and the web interface displays the upgrade progress.

7. The online update method of ZYNQ master-slave system based on BS architecture according to claim 1 is characterized in that: In step 7, the slave board erases the memory area of ​​the corresponding QSPIFLASH chip according to the length of the binary message, and then burns the binary burning file; after the file is burned, the QSPIFLASH is read back, and the read-back data is compared with the burning data byte by byte, and the comparison result is sent to the main board, as follows: If the comparison fails, the motherboard will bind the corresponding upgrade status in the "status file" to "5", indicating that the comparison between the slave board's burned data and the read-back data fails and the upgrade fails; if the comparison passes, the motherboard will bind the corresponding upgrade status in the "status file" to "3", indicating that the slave board's burned data is complete and the upgrade is successful; at the same time, the upgrade success / failure mark is sent to the client, and the web interface displays the upgrade progress.

Images