Network node batch online upgrading device and method

Abstract

The invention discloses a network node batch on-line upgrading device and method, the device is composed of an upgrading end and an upgraded end, the upgrading end runs on an operating system with an Ethernet network function, and a self-defined communication protocol is used for sending an FPGA on-line upgrading file and an FPGA on-line upgrading command to the upgraded end to complete the whole upgrading process; the upgraded end is embedded in an FPGA (Field Programmable Gate Array) with a network function to run, and is used for executing an instruction issued by the upgrading end to operate the FLASH to complete the whole upgrading process; the upgraded end comprises a link layer, original logic and upgrading logic, and the upgrading logic comprises a datarx module, a datatx module, a command processing module and a FLASH read-write module. According to the method, the inherent network hardware interface serving as the network node FPGA is used on hardware, online upgrading can be carried out in any scene, the complexity is low, and the efficiency is high.

Description

Technical Field

[0001] The present invention belongs to the field of computer networks, and relates to a method for realizing batch online upgrade of FPGAs serving as network nodes, specifically a device and method for batch online upgrade of network nodes. Background Art

[0002] Since the world's first FPGA was introduced in 1984, due to its high flexibility, low cost, fast operating speed, good reusability, low latency and high throughput, it has been widely used in fields such as artificial intelligence, real-time data processing, industrial control and aerospace. The FPGA adopts the concept of Logic Cell Array (LCA), and internally includes three parts: Configurable Logic Block (CLB), Input Output Block (IOB) and Interconnect. In practical applications, the required logic code is written using a hardware description language (HDL), and then the logic code is converted into a programming file through EDA software. The programming file contains different connection methods of CLBs and IOBs, and different connection methods form different logical relationships to achieve different logical functions.

[0003] The programming file can be directly programmed into the FPGA using the JTAG interface to implement its logic. However, the logic will disappear after the FPGA is powered off, and it needs to be reprogrammed every time it is powered on. Therefore, the programming file is generally stored in a FLASH device, and the programming file stored in the FLASH is read out and automatically programmed into the FPGA every time it is powered on to implement the desired logic. When it is necessary to update and iterate the existing FPGA logic, as long as the programming file stored in the FLASH is changed, the version update and iteration can be achieved. This update and iteration process is called the online upgrade of the FPGA.

[0004] There are various ways to implement the online upgrade of the FPGA. The simplest way is to use the tool suite provided by the FPGA manufacturer to write the programming file into the FLASH through the JTAG interface. In addition to using the tool suite provided by the manufacturer and the JTAG interface, there are also ways to implement online upgrade through the serial port and the PCIE interface. In both implementation methods, the programming file is sent to the FPGA through the serial port or the PCIE interface, and then the programming file sent through the serial port or the PCIE interface is further written into the FLASH through the interface conversion logic written by oneself on the FPGA.

[0005] Although the above online upgrade methods can all complete the task of FPGA online upgrade, in the usage scenario of FPGAs serving as network nodes, their existing problems are easily revealed:

[0006] Problem 1: The JTAG interface is generally used as the debugging interface of the FPGA during the early-stage debugging function. Once the basic functions of the FPGA are normal, it will be installed and tested in conjunction with other devices. The JTAG interface will be hidden inside the hardware product and cannot be connected. This is especially true for the FPGA serving as a network node. Therefore, after installation, to perform online upgrade through JTAG using the tool suite provided by the FPGA manufacturer, it is necessary to disassemble the machine and connect the wires, which is very inconvenient. In some cases where disassembly is not allowed, online upgrade cannot even be completed.

[0007] Problem 2: For serial port online upgrade, it does not depend on the tools of the FPGA manufacturer. The serial port can be used to transmit the programming file in combination with the uart protocol, and then combined with the interface conversion logic implemented in the FPGA for online upgrade. However, due to the limitations of the hardware attributes of the low-speed interface itself, its transmission rate is slow, and the efficiency is low when upgrading multiple devices at a time.

[0008] Problem 3: For PCIE interface online upgrade, the upgrade speed depends on the hardware attributes of the high-speed interface and is very fast. However, to implement PCIE interface online upgrade, the FPGA design must have an external PCIE hardware interface and an internal PCIE bus logic. For the FPGA serving as a network node, the complexity of the online upgrade design based on this increases, and more FPGA on-chip resources will be consumed. Summary of the Invention

[0009] The purpose of the present invention is to propose a method and device for batch online upgrade of network nodes on the FPGA serving as a network node, so as to solve the problems of the existing online upgrade technology relying on third-party tools, slow upgrade speed, and high design complexity for the FPGA serving as a network node.

[0010] To achieve the above task, the present invention adopts the following technical solutions to solve:

[0011] On the one hand, the present invention provides a network node batch online upgrade device, which consists of an upgrade end and an end to be upgraded. The upgrade end runs on an operating system with Ethernet network function, and uses a custom communication protocol to send the FPGA online upgrade file and the FPGA online upgrade command to the end to be upgraded to complete the entire upgrade process. The end to be upgraded is embedded in an FPGA with network function and runs to execute the instructions sent by the upgrade end to operate the FLASH to complete the entire upgrade process. The end to be upgraded includes a link layer, original logic, and upgrade logic. The upgrade logic includes a data_rx module, a data_tx module, a command processing module, and a FLASH read / write module. The original logic is the logic function that the FPGA itself has before adding the online upgrade function. The link layer is used to process the Ethernet frames received and sent on the link between the upgrade end and the end to be upgraded, and realize the communication between the upgrade end and the end to be upgraded. The data_rx module is used to perform CRC and length checks on the received Ethernet frames to ensure the correctness of link transmission. The data_tx module is used to add CRC to the sent Ethernet frames. The command processing module is used to parse the received Ethernet frames and parse the command types therein. The FLASH read / write module is used to perform read and write operations on the FLASH.

[0012] Further, the working process of the network node batch online upgrade device is as follows: The link layer receives the Ethernet frame sent by the upgrade end on the link and further passes it to the data_rx module. After receiving the Ethernet frame from the link layer, the data_rx module performs CRC and length checks on it, discards the Ethernet frames with CRC errors and length errors, and at the same time passes the Ethernet frames with correct checks to the command processing module. After receiving the Ethernet frame from the data_rx module, the command processing module parses the command carried in the frame content and passes the command to the FLASH read / write module. After receiving the command from the command processing module, the FLASH read / write module performs different read and write operations on the FLASH according to different commands. After the command execution is completed, it notifies the command processing module that the command execution is completed. Subsequently, the command processing module constructs a command response Ethernet frame and passes it to the data_tx module. After receiving the Ethernet frame from the command processing module, the data_tx module adds a CRC check field to the frame and further passes the frame to the link layer. After receiving the Ethernet frame from the data_tx module, the link layer sends the frame to the upgrade end through the link.

[0013] Further, the protocol of the upgrade end and the end to be upgraded stipulates the expressions of each field of the frame as follows:

[0014] DMAC: The protocol stipulates that when the frame is a request frame, it is fixed as 5A_4C_59_57_00_01, and when the frame is a response frame, it is fixed as the physical MAC address of the upgrade end.

[0015] SMAC: The protocol stipulates that when the frame is a request frame, it is fixed as the physical MAC address of the upgrading end. When the frame is a response frame, it is fixed as 5A_4C_59_57_00_01;

[0016] TYPE / LEN: The protocol stipulates that this field is fixed as 0xFAFB;

[0017] CmdType: The protocol stipulates that this field is used to identify whether the current frame is a request frame or a response frame. When it is 0x0001, it represents a request frame. When it is 0x0002, it represents a response frame;

[0018] CmdWord: The protocol stipulates that this field is used to identify the command word of the current frame. There are four commands in total: getInfo, eraseFlash, writeFlash, and readFlash;

[0019] ParameterNum: The protocol stipulates that frames with different command words may carry different numbers of parameters. This field is used to identify the number of parameters;

[0020] Parameter: This field is the specific parameter value. When ParameterNum is 0, this field does not exist;

[0021] Payload: This field is the data written to or read from the FLASH. It only exists when the command word is writeFlash or readFlash;

[0022] CRC: The checksum field of Ethernet;

[0023] The formats of all frames defined by the protocol are as follows:

[0024] getInfo request frame: It carries the command to obtain the FLASH erase status, and is sent by the upgrading end to the upgraded end for the upgrading end to query the erase status of the upgraded end;

[0025] getInfo response frame: It carries the FLASH erase status, and is sent by the upgraded end to the upgrading end for the upgraded end to inform the upgrading end of its own erase status; The erase status is located in the Parameter field, with a total length of 4 bytes. 0x0000_0000 indicates that the FLASH has not started erasing, 0x0000_0001 indicates that the FLASH is being erased, and 0x0000_0002 indicates that the FLASH erase has ended;

[0026] eraseFlash request frame: It carries the command to erase the FLASH, and is sent by the upgrading end to the upgraded end for the upgrading end to instruct the upgraded end to perform an erase operation on the FLASH;

[0027] eraseFlash response frame: It does not carry any parameters and is sent from the device to be upgraded to the upgrader, used for the device to be upgraded to inform the upgrader that it has received the erase command and executed it;

[0028] writeFlash request frame: It carries the write FLASH command, the data to be written to the FLASH, the block number of the data to be written to the FLASH, and the length of the data to be written to the FLASH. It is sent from the upgrader to the device to be upgraded, used for the upgrader to instruct the device to be upgraded to perform a write operation on the FLASH; the block number and length of the data to be written to the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes represent the block number, and the last 4 bytes represent the length; the data to be written to the FLASH is located in the Payload field, and the number of bytes occupied is identified by the length in the Parameter field;

[0029] writeFlash response frame: It carries the block number of the data written to the FLASH and the write result of the data written to the FLASH. It is sent from the device to be upgraded to the upgrader, used for the device to be upgraded to inform the upgrader of the write status of the data corresponding to the block number; the block number of the data written to the FLASH and the write result of the data written to the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes are the block number, and the last 4 bytes are the write status. 0x0000_0000 indicates successful writing, and 0x0000_0001 indicates writing failure;

[0030] readFlash request frame: It carries the read FLASH command and the block number of the data to be read from the FLASH. It is sent from the upgrader to the device to be upgraded, used for the upgrader to instruct the device to be upgraded to perform a read operation on the FLASH; the block number of the data to be read from the FLASH is located in the Parameter field, occupying a total of 4 bytes;

[0031] readFlash response frame: It carries the data read from the FLASH, the block number of the data read from the FLASH, and the length of the data read from the FLASH. It is sent from the device to be upgraded to the upgrader, used for the device to be upgraded to feedback the data of the FLASH that the upgrader wants to read to the upgrader; the block number of the data read from the FLASH and the length of the data read from the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes are the block number, and the last 4 bytes are the length. The data read from the FLASH is located in the Payload field, and the number of bytes occupied is identified by the length in the Parameter field.

[0032] On the other hand, the present invention provides a method for batch online upgrading of network nodes. Based on the network node batch online upgrading device described in claim 3, it is characterized by including the following steps:

[0033] Step 1: Query the erasure status of the current device to be upgraded. Specifically, the upgrading device sends a getInfo request frame to the device to be upgraded. After receiving the getInfo request frame, the device to be upgraded carries its erasure status in the getInfo response frame and sends it to the upgrading device. After receiving the getInfo response frame, the upgrading device determines whether the erasure status in it is "not started erasing". If so, proceed to Step 2; if not, continue to execute Step 1 until the erasure status is "not started erasing".

[0034] Step 2: Erase the FLASH, including the following sub-steps:

[0035] Step 2-1: The upgrading device sends an eraseFlash request frame to the device to be upgraded, instructing the device to be upgraded to perform the operation of erasing the FLASH.

[0036] Step 2-2: After receiving the eraseFlash request frame, the device to be upgraded first responds to the upgrading device with an eraseFlash response frame, indicating that the erasure request has been received and the erasing operation of the FLASH will start soon. Subsequently, it generates a control signal to perform the erasing operation on the FLASH.

[0037] Step 2-3: After receiving the eraseFlash response frame, the upgrading device continuously sends getInfo request frames to the device to be upgraded to query the current erasure status until the erasure status in the getInfo response frame obtained by the upgrading device changes to "erasure completed", and then proceed to Step 3.

[0038] Step 3: Write to the FLASH, including the following sub-steps:

[0039] Step 3-1: The upgrading device divides the upgrade file into multiple block data with a unit of 1024 Byte. The length of the last block can be less than 1024 Byte, and all blocks are numbered incrementally starting from 0, which is called the block number.

[0040] Step 3-2: In the order of the block numbers, form a writeFlash request frame for the data corresponding to each block number and send it to the device to be upgraded. Except for the writeFlash request frame with block number 0 that can be sent directly, the sending of the writeFlash request frames with other block numbers must wait for the writeFlash response frame from the device to be upgraded.

[0041] Step 3-3: After receiving the writeFlash request frame, the device to be upgraded checks whether the frame format complies with the protocol regulations. If it complies, proceed to Step 3-4 for subsequent processing; otherwise, discard it and continue to wait for the next writeFlash request frame.

[0042] Step 3-4, the device to be upgraded parses the block number, length, and data payload of the writeFlash request frame that has passed the verification, calculates the address segment in the FLASH where the data payload should be stored according to the block number and length. The starting address is block number * 1024, and the ending address is block number * 1024 + length. After the calculation, a control signal is output to write the data payload into the calculated address segment of the FLASH;

[0043] Step 3-5, after the FLASH writing is completed, the device to be upgraded uses the same block number and writing status as the current writeFlash request frame to form a writeFlash response frame and sends it to the upgrader to feedback whether the current writing is completed;

[0044] Step 3-6, repeat Step 3-4 and Step 3-5. After all the data of all block numbers are successfully transmitted and written into the FLASH, execute Step 4;

[0045] Step 4, read back the FLASH, including the following sub-steps:

[0046] Step 4-1, the upgrader uses the block numbers described in Step 3-1 to form readFlash request frames and sends them to the device to be upgraded in sequence according to the block number order. Except for the readFlash request frame with block number 0 that can be sent directly, the sending of the readFlash request frames with other block numbers must wait for the readFlash response frame from the device to be upgraded;

[0047] Step 4-2, after receiving the readFlash request frame, the device to be upgraded checks whether the frame format conforms to the protocol regulations. If it conforms, it proceeds to Step 4-3 for subsequent processing. Otherwise, it discards the frame and continues to wait for the next readFlash request frame to arrive;

[0048] Step 4-3, the device to be upgraded parses the block number of the readFlash request frame that has passed the verification, calculates the address of the FLASH to be read according to the block number, then outputs a control signal to read 1024 Byte of data from the calculated address, and uses the block number and the data to form a readFlash response frame and returns it to the upgrader;

[0049] Step 4-4, the upgrader sorts the data payloads carried in the received readFlash response frames according to the block number and reorganizes them into a new upgrade file, named the read-back upgrade file;

[0050] Step 4-5, the upgrader performs a full-word comparison between the read-back upgrade file and the original upgrade file. If the data contents of the two are exactly the same, it indicates that the upgrade is successful; otherwise, it indicates that the upgrade fails.

[0051] Further, during the continuous query process in step 2-3, timeout protection is set. If the erasure status queried continuously for one minute is "not started to erase", step 2 is re-executed; if the erasure status queried continuously for one minute is "erasing", it is considered that the device to be upgraded has a fault and this online upgrade fails. At this time, the device is powered off and the online upgrade process is restarted from step 1.

[0052] Further, during the entire writing process of step 3, a timeout protection mechanism is provided. When the writeFlash request frame of a block number is sent and the writeFlash response frame corresponding to its block number is not received within one minute, it is considered a timeout, and the data of this block number will be re-transmitted. If the response is not received after repeating the transmission 10 times or the received response status is "write failure", it is considered that the device to be upgraded has a fault and this online upgrade fails. At this time, the device is powered off and the online upgrade process is restarted from step 1.

[0053] Further, during the entire reading process of step 4, a timeout mechanism is provided. If a readFlash request frame is not responded within one minute, it is considered a timeout, and the readFlash request frame with the same block number will be re-sent. If all 10 readFlash request frames time out, it is considered that the device to be upgraded has a fault and this online upgrade fails. At this time, the device is powered off and the online upgrade process is restarted from step 1.

[0054] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0055] 1. In the present invention, the inherent network hardware interface of the FPGA as a network node is used in hardware, and online upgrade can be performed in any scenario.

[0056] 2. The present invention shares the logical design of the network interface with the FPGA as a network node, saving FPGA on-chip resources and reducing design complexity.

[0057] 3. The present invention relies on the property that the network interface is a high-speed interface and can complete the upgrade process quickly.

[0058] 4. The present invention is functionally independent, can be quickly configured onto any FPGA serving as a network node, and the upgrade process runs autonomously without affecting any functions of the original design of the FPGA.

[0059] 5. The present invention uses a custom interaction protocol, and the process of burning file transmission is simple and controllable. At the same time, the network can be accessed during the upgrade process, and batch upgrade of multiple network node FPGAs can be easily achieved with high efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 is a schematic diagram of the overall upgrade architecture of the device of the present invention;

[0061] Figure 2 It is a custom protocol frame format;

[0062] Figure 3 It is a frame example defined by the custom protocol;

[0063] Figure 4 It is the online upgrade flowchart of the present invention.

[0064] The present invention will be further explained and illustrated below in conjunction with the accompanying drawings and specific embodiments. Specific Embodiment

[0065] The design block diagram of the method in this embodiment is as shown in Figure 1 and Figure 2 This embodiment provides a method and device for batch online upgrade of network nodes.

[0066] Figure 1 The block diagram shown is the overall architecture of this embodiment, which consists of an upgrade end and an end to be upgraded. The upgrade end is implemented by software design and can run on any operating system with Ethernet network function. Its main task is to send the FPGA online upgrade file and FPGA online upgrade command to the end to be upgraded using a custom communication protocol to complete the entire upgrade process. The end to be upgraded is implemented by FPGA using logic design and can be embedded in any FPGA with network function to run. Its main task is to execute the instructions sent by the upgrade end according to the custom communication protocol to operate the FLASH to complete the entire upgrade process.

[0067] Figure 1 The block diagram shown on the right is the internal implementation method of the end to be upgraded. Among them, the original logic is the logic function that the FPGA itself has before adding the online upgrade function, which can be any logic with Ethernet function; the link layer is used to process the Ethernet frames received and sent on the link between the upgrade end and the end to be upgraded to realize the communication between the upgrade end and the end to be upgraded; the data_rx module is used to perform CRC and length verification on the received Ethernet frames to ensure the correctness of link transmission, and the data_tx module is used to add CRC to the sent Ethernet frames; the command processing module is used to parse the received Ethernet frames and parse the command types therein; the FLASH read / write module is used to perform read / write operations on the FLASH.

[0068] The working process of the above-mentioned upgraded segment is as follows: The link layer receives the Ethernet frame sent by the upgrade end on the link and further passes it to the data_rx module; after receiving the Ethernet frame from the link layer, the data_rx module performs CRC and length checks on it, discards the Ethernet frames with CRC errors and length errors, and at the same time passes the Ethernet frames with correct checks to the command processing module. After receiving the Ethernet frame from the data_rx module, the command processing module parses the command carried in the frame content and passes the command to the FLASH read / write module. After receiving the command from the command processing module, the FLASH read / write module performs different read / write operations on the FLASH according to different commands. After the command execution is completed, it notifies the command processing module that the command execution is completed. Subsequently, the command processing module constructs a command response Ethernet frame and passes it to the data_tx module; after receiving the Ethernet frame from the command processing module, the data_tx module adds a CRC check field to the frame and further passes the frame to the link layer. After receiving the Ethernet frame from the data_tx module, the link layer sends the frame to the upgrade end through the link.

[0069] The custom communication protocol between the upgrade end and the upgraded end is based on Ethernet and adopts a one-way "one request, one response" method. The upgraded end will not actively send a request to the upgrade end, that is, one communication starts with the request from the upgrade end and ends with the response from the upgraded end. The Ethernet frame format during the communication process is as Figure 2 shown. The protocol stipulates that the descriptions of each field of the frame are as follows:

[0070] DMAC Ethernet destination MAC address. SMAC Ethernet source MAC address. TYPE / LEN Ethernet type / length field. CmdType Command type field of the custom protocol header. CmdWord Command word field of the custom protocol header. ParameterNum Parameter number field of the custom protocol header. Parameter Parameter field of the custom protocol header. Payload Data payload of the custom protocol. CRC Ethernet checksum field.

[0071] During the communication process, the protocol further stipulates different values for different fields, which are described as follows.

[0072] DMAC: The protocol stipulates that when the frame is a request frame, it is fixed as 5A_4C_59_57_00_01, and when the frame is a response frame, it is fixed as the physical MAC address of the upgrade end.

[0073] SMAC: The protocol stipulates that when the frame is a request frame, it is fixed as the physical MAC address of the upgrade end, and when the frame is a response frame, it is fixed as 5A_4C_59_57_00_01.

[0074] TYPE / LEN: The protocol stipulates that this field is fixed as 0xFAFB.

[0075] CmdType: The protocol stipulates that this field is used to identify whether the current frame is a request frame or a response frame. When it is 0x0001, it indicates a request frame, and when it is 0x0002, it identifies a response frame.

[0076] CmdWord: This field in the protocol is used to identify the command word of the current frame. There are four commands in total: getInfo(0xAC00), eraseFlash(0xAC00), writeFlash(0xAC00), and readFlash(0xAC00).

[0077] ParameterNum: According to the protocol, frames with different command words may carry different numbers of parameters. This field is used to identify the number of parameters.

[0078] Parameter: This field is the specific parameter value. When ParameterNum is 0, this field does not exist.

[0079] Payload: This field is the data written to or read from the FLASH. It only exists when the command word is writeFlash or readFlash.

[0080] CRC: The checksum field of Ethernet.

[0081] Figure 3 The formats of all frames defined by the protocol are shown below and described as follows.

[0082] getInfo request frame: It carries the command to obtain the FLASH erase status and is sent from the upgrade end to the device to be upgraded for the upgrade end to query the erase status of the device to be upgraded.

[0083] getInfo response frame: It carries the FLASH erase status and is sent from the device to be upgraded to the upgrade end for the device to be upgraded to inform the upgrade end of its own erase status. The erase status is located in the Parameter field and occupies a total of 4 bytes. 0x0000_0000 indicates that the FLASH has not started erasing, 0x0000_0001 indicates that the FLASH is being erased, and 0x0000_0002 indicates that the FLASH erase has ended.

[0084] eraseFlash request frame: It carries the command to erase the FLASH and is sent from the upgrade end to the device to be upgraded for the upgrade end to instruct the device to be upgraded to perform an erase operation on the FLASH.

[0085] eraseFlash response frame: It does not carry any parameters and is sent from the device to be upgraded to the upgrade end for the device to be upgraded to inform the upgrade end that it has received the erase command and executed it.

[0086] writeFlash request frame: It carries the write FLASH command, the data to be written to the FLASH, the block number of the data to be written to the FLASH, and the length of the data to be written to the FLASH. It is sent from the upgrading end to the upgraded end, and is used for the upgrading end to instruct the upgraded end to perform a write operation on the FLASH. The block number and length of the data to be written to the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes represent the block number, and the last 4 bytes represent the length. The data to be written to the FLASH is located in the Payload field, and the number of bytes it occupies is identified by the length in the Parameter field.

[0087] writeFlash response frame: It carries the block number of the data written to the FLASH and the write result of the data written to the FLASH. It is sent from the upgraded end to the upgrading end, and is used for the upgraded end to inform the upgrading end of the write status of the data corresponding to the block number. The block number of the data written to the FLASH and the write result of the data written to the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes are the block number, and the last 4 bytes are the write status. 0x0000_0000 indicates successful writing, and 0x0000_0001 indicates writing failure.

[0088] readFlash request frame: It carries the read FLASH command and the block number of the data to be read from the FLASH. It is sent from the upgrading end to the upgraded end, and is used for the upgrading end to instruct the upgraded end to perform a read operation on the FLASH. The block number of the data to be read from the FLASH is located in the Parameter field, occupying a total of 4 bytes.

[0089] readFlash response frame: It carries the data read from the FLASH, the block number of the data read from the FLASH, and the length of the data read from the FLASH. It is sent from the upgraded end to the upgrading end, and is used for the upgraded end to feedback the data of the FLASH that the upgrading end wants to read to the upgrading end. The block number of the data read from the FLASH and the length of the data read from the FLASH are located in the Parameter field, occupying a total of 8 bytes. The first 4 bytes are the block number, and the last 4 bytes are the length. The data read from the FLASH is located in the Payload field, and the number of bytes it occupies is identified by the length in the Parameter field.

[0090] Figure 4 Shows a complete online batch upgrade process of network nodes based on Ethernet, and its detailed description is as follows:

[0091] Step 1, query the erasure status of the current upgraded end.

[0092] Specifically: The upgrade end sends a getInfo request frame to the device to be upgraded. After receiving the getInfo request frame, the device to be upgraded carries its own erasure status in the getInfo response frame and sends it to the upgrade end. After receiving the getInfo response frame, the upgrade end determines whether the erasure status in it is "not started erasing". If so, it executes step 2; if not, it continues to execute step 1 until the erasure status is "not started erasing".

[0093] Step 2, erase the FLASH. It includes the following sub-steps:

[0094] Step 2-1, the upgrade end sends an eraseFlash request frame to the device to be upgraded, instructing the device to be upgraded to perform the operation of erasing the FLASH;

[0095] Step 2-2, after receiving the eraseFlash request frame, the device to be upgraded first responds to the upgrade end with an eraseFlash response frame, indicating that the erasure request has been received and the FLASH erasure operation will start soon. Subsequently, it generates a control signal to perform the FLASH erasure operation;

[0096] Step 2-3, after receiving the eraseFlash response frame, the upgrade end continuously sends getInfo request frames to the device to be upgraded to query the current erasure status until the erasure status in the getInfo response frame obtained by the upgrade end changes to "erasure completed", and then step 3 is executed. As a preferred embodiment of the present invention, a timeout protection is set during the continuous query process of step 2-3. If the erasure status queried for one minute is "not started erasing", step 2 is re-executed; if the erasure status queried for one minute is "erasing", it is considered that the device to be upgraded has a fault and this online upgrade fails. The device should be powered off and the online upgrade process should be restarted from step 1.

[0097] Step 3, write to the FLASH. It includes the following sub-steps:

[0098] Step 3-1, the upgrade end divides the upgrade file into multiple block data with 1024 Byte as a unit. The length of the last block can be not 1024 Byte, and all blocks are numbered incrementally starting from 0, which is called the block number;

[0099] Step 3-2, in the order of the block numbers, the data corresponding to each block number is formed into a writeFlash request frame and sent to the device to be upgraded. Except that the writeFlash request frame with block number 0 can be directly sent, the sending of the writeFlash request frames with other block numbers must wait for the writeFlash response frame of the device to be upgraded;

[0100] Step 3-3: After receiving the writeFlash request frame, the device to be upgraded checks whether the frame format complies with the protocol. If it complies, it proceeds to Step 3-4 for subsequent processing; otherwise, it discards the frame and continues to wait for the next writeFlash request frame.

[0101] Step 3-4: The device to be upgraded parses the block number, length, and data payload of the writeFlash request frame that has passed the check. It calculates the address segment in the FLASH where the data payload should be stored based on the block number and length. The starting address is block number * 1024, and the ending address is block number * 1024 + length. After calculation, it outputs a control signal to write the data payload into the calculated address segment of the FLASH.

[0102] Step 3-5: After the FLASH write is completed, the device to be upgraded uses the same block number and write status as the current writeFlash request frame to form a writeFlash response frame and sends it to the upgrader to feedback whether the current write is completed.

[0103] Step 3-6: Repeat Step 3-4 and Step 3-5. After all block numbers of data are successfully transmitted and written to the FLASH, execute Step 4. As a preferred embodiment of the present invention, a timeout protection mechanism is provided during the entire write process in Step 3. If a writeFlash response frame corresponding to a block number is not received within one minute after a writeFlash request frame of that block number is sent, it is considered a timeout. The data of this block number will be retransmitted. If the response is not received or the received response status indicates a write failure after repeating the transmission 10 times, it is considered that the device to be upgraded has a fault, and the online upgrade fails. The device should be powered off and the online upgrade process should be restarted from Step 1.

[0104] Step 4: Read back the FLASH. It includes the following sub-steps:

[0105] Step 4-1: The upgrader uses the block numbers described in Step 3-1 to form readFlash request frames and sends them to the device to be upgraded in sequence according to the block number order. Except for the readFlash request frame with block number 0 that can be sent directly, the sending of the readFlash request frames with other block numbers must wait for the readFlash response frame from the device to be upgraded.

[0106] Step 4-2: After receiving the readFlash request frame, the device to be upgraded checks whether the frame format complies with the protocol. If it complies, it proceeds to Step 4-3 for subsequent processing; otherwise, it discards the frame and continues to wait for the next readFlash request frame.

[0107] Step 4-3: The device to be upgraded parses the block number of the readFlash request frame that has passed the verification, calculates the address of the FLASH to be read based on the block number, then outputs a control signal to read 1024 Byte of data from the calculated address, and uses the block number and the data to form a readFlash response frame and return it to the upgrading device;

[0108] Step 4-4: The upgrading device sorts the data payloads carried in the received readFlash response frames according to the block numbers, and reorganizes them into a new upgrade file, named the read-back upgrade file;

[0109] Step 4-5: The upgrading device performs a full-word comparison between the read-back upgrade file and the original upgrade file. If the data contents of the two are exactly the same, it indicates that the upgrade is successful; otherwise, it indicates that the upgrade fails. As a preferred embodiment of the present invention, a timeout mechanism is provided during the entire reading process of Step 4. If a readFlash request frame is not responded within one minute, it is considered timed out, and a readFlash request frame with the same block number will be resent. If 10 readFlash request frames are all timed out, it is considered that there is a fault in the device to be upgraded, and this online upgrade fails. The device should be powered off and the online upgrade process should be restarted from Step 1.

[0110] Application example:

[0111] In actual applications, for the FPGAs of the network-side system and the network switch, they are both hidden deep in the hardware structure. When performing version upgrade and maintenance, the operation of disassembling the machine and burning the program is too cumbersome, and disassembly is not even allowed in special environments, which is extremely inconvenient. When performing online upgrade through a low-speed interface, the speed is very slow, and it is not convenient enough when multiple devices need to be upgraded. When performing online upgrade through a high-speed interface, complex designs will be introduced, increasing the design cost.

[0112] Based on this, the applicant uses the method of the present invention to utilize the network interfaces that originally exist in the FPGAs of the network-side system and the network switch. Combining with the high portability advantage of the FPGA itself, the logic design of the FPGA in the present invention is embedded into different projects, and at the same time, it is used in conjunction with the upgrading device software in the invention. During the entire upgrade process, there is no need to disassemble the machine. Relying on the original network high-speed interface for upgrade, no additional high-speed interface design is required, which improves the upgrade speed and simplifies the design complexity.

Claims

1. A network node batch online upgrade device, characterized in that: It consists of an upgrade end and an upgraded end. The upgrade end runs on an operating system with Ethernet network function and uses a custom communication protocol to send FPGA online upgrade files and FPGA online upgrade commands to the upgraded end to complete the entire upgrade process. The upgraded end is embedded in an FPGA with network functions and runs, and is used to execute the instructions issued by the upgrading end to operate FLASH to complete the entire upgrading process; the upgraded end includes a link layer, original logic and upgrading logic, wherein the upgrading logic includes a data_rx module, a data_tx module, a command processing module and a FLASH reading and writing module; the original logic is the logic function that the FPGA itself has before adding the online upgrading function; the link layer is used to process the Ethernet frames received and sent on the link between the upgrading end and the upgraded end, so as to realize the communication between the upgrading end and the upgraded end; the data_rx module is used to perform CRC and length check on the received Ethernet frames to ensure the correctness of the link transmission; the data_tx module is used to add CRC to the sent Ethernet frames; the command processing module is used to parse the received Ethernet frames and parse the command types therein; the FLASH reading and writing module is used to perform reading and writing operations on the FLASH.

2. The network node batch online upgrade device according to claim 1, characterized in that: The workflow of the network node batch online upgrade device is as follows: the link layer receives the Ethernet frame sent to the link by the upgrade end, and further passes it to the data_rx module; after receiving the Ethernet frame of the link layer, the data_rx module performs CRC and length checks on it, discards the Ethernet frames with CRC errors and length errors, and passes the Ethernet frames with correct checks to the command processing module. After receiving the Ethernet frame from the data_rx module, the command processing module parses the command carried in the frame content and passes the command to the FLASH read-write module. After receiving the command from the command processing module, the FLASH read-write module performs different read and write operations on the FLASH according to different commands. After the command is executed, the command processing module is notified that the command execution is completed, and then the command processing module constructs a command response Ethernet frame and passes it to the data_tx module; after receiving the Ethernet frame from the command processing module, the data_tx module adds a CRC check field to the frame and further passes the frame to the link layer. After receiving the Ethernet frame from the data_tx module, the link layer sends the frame to the upgrade end through the link.

3. The network node batch online upgrade device according to claim 1, characterized in that: The protocol of the upgrading end and the upgraded end specifies that the fields of the frame are expressed as follows: DMAC: The protocol stipulates that when the frame is used as a request frame, it is fixed to 5A_4C_59_57_00_01, and when the frame is used as a response frame, it is fixed to the physical MAC address of the upgrade end; SMAC: The protocol stipulates that when the frame is used as a request frame, it is fixed to the physical MAC address of the upgrade end; when the frame is used as a response frame, it is fixed to 5A_4C_59_57_00_01; TYPE / LEN: The protocol stipulates that this field is fixed to 0xFAFB; CmdType: The protocol specifies that this field is used to identify whether the current frame is a request frame or a response frame. 0x0001 indicates a request frame, and 0x0002 indicates a response frame. CmdWord: The protocol specifies that this field is used to identify the command word of the current frame. There are four commands: getInfo, eraseFlash, writeFlash, and readFlash. ParameterNum: The protocol stipulates that frames of different command words may carry different numbers of parameters. This field is used to identify the number of parameters. Parameter: This field is the specific parameter value. When ParameterNum is 0, there is no such field. Payload: This field is the data written to or read from FLASH. This field exists only when the command word is writeFlash or readFlash. CRC: Ethernet checksum field; The format of all frames defined by the protocol is as follows: GetInfo request frame: It carries the command to obtain the FLASH erase status and is sent from the upgrade end to the upgraded end. It is used by the upgrade end to query the erase status of the upgraded end. GetInfo response frame: It carries the erasure status of FLASH and is sent from the upgraded end to the upgrading end to inform the upgrading end of its own erasure status. The erasure status is located in the Parameter field, which is 4 bytes in length. 0x0000_0000 indicates that FLASH has not started to be erased, 0x0000_0001 indicates that FLASH is being erased, and 0x0000_0002 indicates that FLASH erasure is completed. EraseFlash request frame: It carries the command to erase FLASH and is sent from the upgrade end to the upgraded end. It is used by the upgrade end to instruct the upgraded end to erase FLASH. EraseFlash response frame: It does not carry any parameters and is sent from the upgraded end to the upgrading end. It is used by the upgraded end to inform the upgrading end that it has received the erase command and executed it. WriteFlash request frame: it carries the write FLASH command, the data to be written to FLASH, the block number of the data to be written to FLASH and the length of the data to be written to FLASH. It is sent by the upgrade end to the upgraded end to instruct the upgraded end to write to FLASH. The block number and length of the data written to FLASH are located in the Parameter field, which occupies 8 bytes in total. The first 4 bytes indicate the block number, and the last 4 bytes indicate the length. The data written to FLASH is located in the Payload field, and the number of bytes occupied is identified by the length in the Parameter field. WriteFlash response frame: it carries the block number of the data written to FLASH and the writing result of the data written to FLASH, and is sent by the upgraded end to the upgrading end to inform the upgrading end of the writing status of the data corresponding to the block number; The block number of the data written to FLASH and the writing result of the data written to FLASH are located in the Parameter field, which occupies 8 bytes in total. The first 4 bytes are the block number, and the last 4 bytes are the writing status. 0x0000_0000 indicates a successful write, and 0x0000_0001 indicates a write failure. ReadFlash request frame: it carries the read FLASH command and the block number of the FLASH data to be read, and is sent from the upgrade end to the upgraded end to instruct the upgraded end to read the FLASH; The block number of the data read from FLASH is located in the Parameter field, which occupies 4 bytes in total; readFlash response frame: it carries the data to be read from FLASH, the block number of the data to be read from FLASH and the length of the data to be read from FLASH. It is sent from the upgraded end to the upgrading end, and is used by the upgraded end to feed back the FLASH data to be read by the upgrading end to the upgrading end. The block number of the data to be read from FLASH and the length of the data to be read from FLASH are located in the Parameter field, occupying a total of 8 bytes, the first 4 bytes are the block number, and the last 4 bytes are the length. The data to be read from FLASH is located in the Payload field, and the number of bytes occupied is identified by the length in the Parameter field.

4. A method for batch online upgrading of network nodes, characterized in that: The network node batch online upgrade device according to claim 3 is characterized by comprising the following steps: Step 1, querying the erasure status of the current upgraded end, specifically: the upgrading end sends a getInfo request frame to the upgraded end, and after receiving the getInfo request frame, the upgraded end carries its own erasure status in a getInfo response frame and sends it to the upgrading end; after receiving the getInfo response frame, the upgrading end determines whether the erasure status therein is not started to be erased, if so, execute step 2, if not, continue to execute step 1 until the erasure status is not started to be erased; Step 2, erasing FLASH, includes the following sub-steps: Step 2-1, the upgrade end sends an eraseFlash request frame to the upgraded end, instructing the upgraded end to perform an operation of erasing FLASH; Step 2-2, after receiving the eraseFlash request frame, the upgraded end first responds to the upgrade end with an eraseFlash response frame, indicating that the erase request has been received and the FLASH erase operation is about to begin, and then generates a control signal to perform the FLASH erase operation; Step 2-3: After receiving the eraseFlash response frame, the upgrade end continues to send getInfo request frames to the upgraded end to query the current erasure status until the erasure status in the getInfo response frame obtained by the upgrade end changes to erasure completion, and then executes step 3; Step 3, writing to FLASH, includes the following sub-steps: Step 3-1, the upgrade end divides the upgrade file into multiple blocks of data with 1024 bytes as the unit. The length of the last block may not be 1024 bytes, and all blocks are numbered incrementally starting from 0, which is called block number; Step 3-2, in the order of block numbers, the data corresponding to each block number is combined into a writeFlash request frame and sent to the upgraded end. Except for the writeFlash request frame with block number 0, which can be sent directly, the sending of the writeFlash request frames with other block numbers must wait for the writeFlash response frame from the upgraded end. Step 3-3, after receiving the writeFlash request frame, the upgraded end checks whether the frame format complies with the protocol. If it complies, it proceeds to step 3-4 for subsequent processing. Otherwise, it discards it and continues to wait for the next writeFlash request frame to arrive. Step 3-4, the upgraded end parses the block number, length and data payload of the verified writeFlash request frame, and calculates the address segment where the data payload should be stored in the FLASH according to the block number and length. The starting address is the block number * 1024, and the ending address is the block number * 1024 + length. After the calculation, the control signal is output to write the data payload into the calculated address segment of the FLASH; Step 3-5: After the FLASH writing is completed, the upgraded end uses the same block number and writing status as the current writeFlash request frame to form a writeFlash response frame and sends it to the upgrading end to feedback whether the writing is completed; Step 3-6, repeat steps 3-4 and 3-5, and after all block numbers have been transferred and successfully written into FLASH, proceed to step 4; Step 4, read back FLASH, includes the following sub-steps: Step 4-1, the upgrade end uses the block number described in step 3-1 to form a readFlash request frame, and sends it to the upgraded end in the order of the block numbers. Except for the readFlash request frame with block number 0, which can be sent directly, the sending of the readFlash request frames with other block numbers must wait for the readFlash response frame of the upgraded end; Step 4-2: After receiving the readFlash request frame, the upgraded end checks whether the frame format complies with the protocol. If it complies, it proceeds to step 4-3 for subsequent processing. Otherwise, it discards it and continues to wait for the next readFlash request frame to arrive. Step 4-3, the upgraded end parses the block number of the verified readFlash request frame, calculates the address of the FLASH to be read according to the block number, then outputs a control signal to read 1024Byte data from the calculated address, and uses the block number and data to form a readFlash response frame and returns it to the upgrade end; Step 4-4, the upgrade end sorts the data payload carried in the received readFlash response frame according to the block number, recomposes a new upgrade file, and names it as the read-back upgrade file; Step 4-5, the upgrade end compares the read-back upgrade file with the original upgrade file in full word. If the data contents of the two files are completely consistent, it indicates that the upgrade is successful. If they are inconsistent, it indicates that the upgrade has failed.

5. The method for batch online upgrading of network nodes according to claim 4, characterized in that: A timeout protection is set in the continuous query process of step 2-3. If the erasing status queried for one minute is not started, step 2 is executed again; if the erasing status queried for one minute is erasing, it is considered that the upgraded end is faulty and the online upgrade fails. At this time, the device is powered off and the online upgrade process is re-executed from step 1.

6. The method for batch online upgrading of network nodes according to claim 4, characterized in that: During the entire writing process of step 3, a timeout protection mechanism is provided. When a writeFlash request frame of a block number is sent but no writeFlash response frame corresponding to the block number is received within one minute, it is considered to have timed out and the block number data will be retransmitted. If no response is received after 10 transmissions or the received response status is a write failure, it is considered that the upgraded end is faulty and the online upgrade has failed. In this case, the device is powered off and the online upgrade process is re-executed from step 1.

7. The method for batch online upgrading of network nodes according to claim 4, characterized in that: A timeout mechanism is set during the entire reading process of step 4. If a readFlash request frame is not responded to within one minute, it is considered to have timed out, and the readFlash request frame with the same block number will be resent. If 10 readFlash request frames time out, it is considered that the upgraded end is faulty and the online upgrade has failed. At this time, the device is powered off and the online upgrade process is re-executed from step 1.

Images