A firmware recovery method and device in a scenario where exchange equipment is interconnected, a product and a medium

Abstract

The application discloses a firmware recovery method and device in a switching device interconnection scene, a product and a medium, and relates to the technical field of switching devices. In view of the problem that it is difficult to implement recovery of firmware by means of an artificial programmer when firmware of a switching device without an uplink port is damaged, a firmware recovery method in a switching device interconnection scene is provided. In all switching devices connected to the current switching device, a switching device with an available communication connection with a host computer is selected as a target switching device. An interconnection port through which the current switching device is connected to the target switching device is specified as a loading port for recovery of the firmware. That is, the host computer accurately sends the recovery firmware to the target switching device through the available communication connection, and then the target switching device sends the recovery firmware to the current switching device through the specified port, so that the recovery firmware accurately reaches the current switching device, and the firmware of the switching device is recovered.

Description

Technical Field

[0001] This invention relates to the field of switching equipment technology, and in particular to a firmware recovery method, apparatus, program product, and medium for interconnecting switching equipment. Background Technology

[0002] The new switching chip networking technology does not use the tree-like hierarchical structure of the high-speed serial computer extended bus standard (Peripheral Component Interconnect Express, PCIe). Instead, it defines a special "interconnect port." The connection between these interconnect ports differs from the upstream / downstream relationship in traditional methods; instead, information is transmitted through a peer-to-peer interconnection between chips. Therefore, each connection is not bound to a hierarchical relationship or host domain, and can transmit information sent by any host or device. Theoretically, multiple chips can be interconnected in any topology without considering the binding relationship between hosts and devices, enabling more flexible networking. For example, in an independent switching chip network, when the connection relationship between hosts and devices changes, there is no need to adjust the interconnection between chips.

[0003] However, this connection scheme also has certain problems: the switching devices support firmware updates, but firmware corruption may occur during updates. Switches connected via interconnect ports lack a hierarchical structure and fixed routing relationships; routing is specified through configured routing tables. When firmware corruption occurs, the pre-configured routing tables are likely lost. In this case, normal transmission between the corrupted switch and other switches or hosts cannot be guaranteed. Therefore, it cannot receive new firmware and restore it through other interconnected switches or hosts; firmware restoration can only be achieved manually by reprogramming it with a programmer. Manual reprogramming is cumbersome, cannot be automated, and is difficult to implement in scenarios with multiple interconnected switches.

[0004] Therefore, those skilled in the art urgently need a firmware recovery method for interconnected switching devices to solve the problem that current solutions relying on programmers to reprogram firmware for recovery are difficult to implement in interconnected scenarios of multiple switching devices based on interconnection ports. Summary of the Invention

[0005] The purpose of this invention is to provide a firmware recovery method, apparatus, program product, and medium for interconnected switching devices, to solve the problem that it is difficult to manually recover firmware using a programmer when firmware corruption occurs in switching devices without uplink ports.

[0006] To address the aforementioned technical problems, this invention provides a firmware recovery method for interconnected switching devices, comprising:

[0007] Determine whether the switching device to be restored has an uplink port connected to the host; wherein the host stores the recovery firmware.

[0008] If not, then an interconnect port of the switching device is designated as the loading port for the recovery firmware; wherein the target switching device connected to the designated interconnect port has a usable communication connection with the host.

[0009] The recovery firmware, forwarded by the target switching device, is received through the loading port, and firmware recovery is performed.

[0010] In an optional embodiment, after determining whether the switching device currently to be restored has an uplink port connected to the host, the method further includes:

[0011] If so, then designate one of the uplink ports of the switching device as the loading port for the recovery firmware.

[0012] The system communicates with the host through the loading port to obtain the recovery firmware and performs firmware recovery.

[0013] In an optional embodiment, designating an interconnect port of the switching device as the loading port for the recovery firmware includes:

[0014] If none of the switching devices connected to the current switching device via the interconnect port meet the condition of having a usable communication connection with the host, then any one of the switching devices located one level above the current switching device in the switching device network is designated as the target switching device.

[0015] The interconnect port in the current switching device that is connected to the target switching device is designated as the loading port.

[0016] The switching network is categorized into levels based on the proximity of the connection between the switching devices and the host. Switching devices directly connected to the host are classified as first-level switching devices, and switching devices indirectly connected to the host through (N-1)th-level switching devices are classified as Nth-level switching devices, where N is any positive integer greater than 1.

[0017] In an optional embodiment, after designating an interconnect port of the switching device as the loading port for the recovery firmware, the method further includes:

[0018] The target domain code carried in the first message packet received through the loading port is used as the target domain code of the current switching device; wherein, the target domain code is a globally unique code in the switching device network.

[0019] When a routing table is received through the loading port, it is determined whether the target domain code carried in the routing table is the same as the target domain code corresponding to the current switching device.

[0020] If so, the received routing table will be saved locally.

[0021] If not, after the interconnection link with the next-level switching device is established, the target domain code carried in the routing table is sent to the next-level switching device via a message packet.

[0022] In an optional embodiment, sending the target domain encoding carried in the routing table to the next-level switching device via a message packet includes:

[0023] The target field encoding is carried by the transaction layer packet prefix in the message packet.

[0024] In an optional embodiment, sending the target domain encoding carried in the routing table to the next-level switching device via a message packet includes:

[0025] The transaction layer packet containing the target domain code is sent to the next-level switching device.

[0026] In one optional embodiment, communicating with the host via the loading port to obtain the recovery firmware includes:

[0027] The system communicates with the host through the loading port to obtain the address where the recovery firmware is stored in the host.

[0028] Initiate a direct memory access operation to the host based on the address, and directly read the recovery firmware from the host memory.

[0029] In one alternative embodiment, the switching device includes a first configuration pin; wherein the first configuration pin is configured to load recovery firmware from an uplink port or an interconnect port.

[0030] Determining whether the switching device currently to be restored has an uplink port connected to the host includes:

[0031] If the first configuration pin is configured to load recovery firmware from the uplink port, it is determined that the switching device to be recovered currently has an uplink port connected to the host.

[0032] If the first configuration pin is configured to load recovery firmware from the interconnect port, it is determined that the switching device to be recovered does not have an uplink port connected to the host.

[0033] In an optional embodiment, the switching device further includes a second configuration pin; wherein the second configuration pin is used to configure the port number of the load port.

[0034] Designating one of the interconnect ports / uplink ports of the switching device as the loading port for the recovery firmware includes:

[0035] Based on the port number configured by the second configuration pin, the corresponding port is used as the loading port.

[0036] The load port is initialized to the interconnect port / uplink port according to the configuration of the first configuration pin.

[0037] In one alternative embodiment, the switching device includes a third configuration pin; the third configuration pin is used to configure a firmware stored in the first storage medium as boot firmware.

[0038] The first storage medium is the storage medium used to store firmware in the switching device.

[0039] The first storage medium includes: default firmware and user firmware.

[0040] When the default firmware is executed, it is used to: determine whether the switching device to be restored has an uplink port connected to the host; wherein the host stores the restoration firmware; if not, designate an interconnect port of the switching device as the loading port of the restoration firmware; wherein the target switching device connected to the designated interconnect port has a usable communication connection with the host; receive the restoration firmware forwarded by the target switching device through the loading port, and perform firmware restoration.

[0041] In one alternative embodiment, the default firmware is stored in a target area of ​​the first storage medium.

[0042] The modification permission for the target area in the first storage medium is restricted to allow only the programmer to modify it.

[0043] To address the aforementioned technical problems, the present invention also provides a firmware recovery device for a multi-switch device interconnection scenario, comprising:

[0044] The type determination module is used to determine whether the switching device to be restored has an uplink port connected to the host; if not, the port determination module is triggered; wherein, the host stores the recovery firmware.

[0045] The port determination module is used to designate an interconnect port of the switching device as the loading port of the recovery firmware; wherein the target switching device connected to the designated interconnect port has a usable communication connection with the host.

[0046] The firmware recovery module is used to receive the recovery firmware forwarded by the target switching device through the loading port and perform firmware recovery.

[0047] To address the aforementioned technical problems, the present invention also provides a computer program product, comprising a computer program / instructions, wherein the computer program / instructions, when executed by a processor, implement the steps of the firmware recovery method in the interconnection scenario of switching devices as described above.

[0048] To address the aforementioned technical problems, the present invention also provides a firmware recovery device for a multi-switch device interconnection scenario, comprising:

[0049] Memory is used to store computer programs.

[0050] A processor is configured to execute the computer program to implement the firmware recovery method described above in a switching device interconnection scenario.

[0051] To address the aforementioned technical problems, the present invention also provides a non-volatile storage medium storing a computer program, which, when executed by a processor, implements the steps of the firmware recovery method in the interconnection scenario of switching devices as described above.

[0052] This invention provides a firmware recovery method in a switching device interconnection scenario, offering a firmware recovery solution for switching devices connected to other switching devices only via an interconnect port. In this method, from all other switching devices connected to the current switching device undergoing firmware recovery, one switching device with a usable communication connection (direct or indirect) to the host is arbitrarily selected as the target switching device. The interconnect port connecting the current switching device and the target switching device is designated as the loading port for the recovery firmware, allowing the host to forward the recovery firmware to the loading port of the current switching device via the target switching device. That is, the host first accurately sends the recovery firmware to the target switching device directly connected to the current switching device via the usable communication connection, and then the target switching device sends the recovery firmware back to the current switching device via the designated port (i.e., the loading port), achieving the goal of the recovery firmware accurately reaching the current switching device. Furthermore, the current switching device can recover its own firmware using the recovery firmware, resolving the firmware corruption problem.

[0053] This method does not require the corrupted switch to have an uplink port. It is also applicable to switches with corrupted routing tables that are networked with other switches only through interconnect ports. Furthermore, this method allows the host to send recovery firmware to the switch, eliminating the need for manual programming. It provides an automated solution for recovering corrupted switch firmware, making it particularly suitable for resolving firmware recovery issues in scenarios where large-scale switches are networked through interconnect ports.

[0054] The firmware recovery device, program product, and non-volatile storage medium provided by this invention for the interconnection of switching devices correspond to the above-mentioned methods and have the same effect. Attached Figure Description

[0055] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is a structural diagram of a traditional hierarchical topology switching chip network provided in an embodiment of the present invention.

[0057] Figure 2 This is a structural diagram of a switching chip network based on interconnection ports, provided as an embodiment of the present invention.

[0058] Figure 3 This is a flowchart of a firmware recovery method in a switching device interconnection scenario provided by an embodiment of the present invention.

[0059] Figure 4 This is a schematic diagram illustrating firmware recovery of a switching device via an interconnect port, as provided in an embodiment of the present invention.

[0060] Figure 5 This is a schematic diagram illustrating a method for restoring switching device firmware via an uplink port, as provided in an embodiment of the present invention.

[0061] Figure 6 This is a schematic diagram illustrating firmware recovery layer by layer in a switching equipment network, as provided in an embodiment of the present invention.

[0062] Figure 7 This is a schematic diagram of the structure of a switching device provided in an embodiment of the present invention.

[0063] Figure 8 This is a structural diagram of a firmware recovery device in a switching device interconnection scenario provided by an embodiment of the present invention.

[0064] Figure 9This is a structural diagram of a firmware recovery device in another scenario of interconnected switching devices provided by an embodiment of the present invention. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0066] The core of this invention is to provide a firmware recovery method, apparatus, program product, and medium for interconnected switching devices.

[0067] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0068] In related technologies, such as Figure 1 As shown, traditional high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe) switching chip networking expands by cascading according to the hierarchical structure defined by the PCIe protocol. Here, the switching chip is a switching device packaged in chip form.

[0069] However, Figure 1 The networking scheme shown has a significant drawback: it can only be networked according to the tree-like hierarchical structure supported by the PCIe protocol, and each interconnected data path can only transmit information within that hierarchy. Therefore, when the interconnection relationship between the host and devices changes, it may mean a change in the hierarchical structure, necessitating adjustments to the interconnection relationships between chips. Based on these characteristics, this networking scheme is unsuitable for applications requiring multiple switching chips to form a host-independent switching network, or for large-scale applications with dynamically allocated computing resources.

[0070] Currently, such as Figure 2 As shown, a novel switching chip networking technology is proposed. Instead of using the tree-like hierarchical structure of the PCIe standard, it defines a special "interconnect port." The connections between these interconnect ports differ from the upstream / downstream relationships in traditional methods; instead, information is transmitted through peer-to-peer interconnection between chips. Therefore, each connection is not bound to hierarchical relationships or host domains, and can transmit information sent by any host or device. Theoretically, multiple chips can be interconnected in any topology without considering the binding relationships between hosts and devices, enabling more flexible networking. For example, in an independent switching chip network, when the connection relationships between hosts and devices change, there is no need to adjust the interconnections between chips.

[0071] On the other hand, in scenarios where multiple switching devices are interconnected, each switching device has its own firmware (user firmware), which is generally stored on non-volatile storage media (such as flash memory) inside the chip or externally. When the chip powers on, the program and necessary parameters need to be loaded from this media. To enable continuous iterative updates and bug fixes, switching devices generally support firmware updates. For example, new firmware can be written to the non-volatile storage media via a programmer through a special interface of the switching device, or the host can update the firmware of the switching device through an uplink interface connected to the switching device, and then the switching device updates the firmware to the non-volatile storage media.

[0072] During firmware updates, if an unexpected power outage causes firmware corruption, or if an incorrect firmware is updated, the switching device may load unexecutable firmware upon the next power-on. This firmware corruption will prevent the switching device from functioning properly. Manually reprogramming the switching device using a programmer is a common recovery method, but this approach is cumbersome and difficult to implement when dealing with a large number of switching devices.

[0073] Currently, for traditional hierarchical switching networks, automated firmware recovery can be achieved by the host sending firmware to the switching device. However, this solution cannot be applied to switching networks based on interconnect ports, for the following specific reasons:

[0074] 1. The above solution relies on the switching device to interact directly with the host through the uplink port. The switching device can know that what is received by the uplink port is the recovery firmware sent by the host, and then update the recovery firmware received by the uplink port to the Flash.

[0075] However, in switching networks based on interconnect ports, not all switches have uplink ports; some switches only have interconnect ports. In extreme cases, the entire switching network may have only one switch with an uplink port. In this situation, a switch with corrupted firmware cannot know from which port to receive recovery firmware.

[0076] 2. Hierarchical switching devices have fixed routing relationships, which can ensure that the firmware sent by the host accurately reaches any switching device in the switching device network.

[0077] However, interconnected devices based on interconnect ports are not directly designated by the topology and do not have fixed routing relationships. Their routing relationships are generally determined by user-programmed routing tables. These routing tables are usually also stored in Flash memory, so when the firmware is corrupted, the routing table should be considered corrupted as well. Therefore, in this case, the host cannot guarantee that the firmware will be accurately transmitted to the specified switching device with corrupted firmware.

[0078] To address the aforementioned problems and achieve a more automated firmware recovery solution, this invention provides a firmware recovery method for interconnected switching devices, such as... Figure 3 As shown, it includes:

[0079] S1: Determine whether the switching device to be restored has an uplink port connected to the host; if not, proceed to step S21.

[0080] The host computer stores the recovery firmware.

[0081] S21: Specifies an interconnect port of the switching device as the port for loading the recovery firmware.

[0082] The target switching device connected to the designated interconnect port has a usable communication connection with the host.

[0083] S22: Receive the recovery firmware forwarded by the target switching device through the load port and perform firmware recovery.

[0084] In step S1, it is determined whether the switching device requiring firmware recovery is a switching device with only interconnect ports as described in the relevant technical specifications above. This application provides a method for this switching device to replace manual reprogramming via a programmer, achieving a more automated firmware recovery solution.

[0085] Step S21 formally initiates the firmware recovery process for the switch device with only an interconnect port. As described above, step S21 involves the current switch device (i.e., the switch device with only an interconnect port and corrupted firmware), the target switch device, and the host. The target switch device refers to another switch device in the switch device network that is directly connected to the current switch device via an interconnect port and has a usable communication connection with the host. It should be noted that this embodiment is not limited to whether the usable communication connection between the target switch device and the host is achieved through a direct connection via an uplink port or indirectly through other switch devices. For example, as shown... Figure 4 As shown, switching device 1 is the current switching device described above, and switching device 0 is the target switching device described above. At this time, the interconnection port 9 in switching device 1 that is connected to switching device 0 can be designated as the loading port.

[0086] Because a usable communication connection exists between the target switch and the host, the host can accurately send data (including recovery firmware) to the target switch. In a network of switches connected via interconnect ports, the target switch can be a switch directly connected to the host via an uplink port; or it can be an indirectly connected switch with only an interconnect port, provided its firmware is not corrupted (i.e., its routing table in Flash is usable), ensuring that data sent by the host accurately reaches it. In short, the target switch is any switch in the network that is directly connected to the current switch and guarantees that the recovery firmware sent by the host accurately reaches it.

[0087] Furthermore, step S22 forwards the recovery firmware through a target switching device directly connected to the current switching device. As explained above regarding the target switching device, the host can accurately send the recovery firmware to the target switching device. Figure 4 The scenario shown illustrates that the host sends the recovery firmware to switch device 0 via uplink port 2. Subsequently, since the target switch device is directly connected to the current switch device, and the connection port is the interconnect port (e.g.,...),... Figure 4 The path from the target switch to the current switch is fixed and unique (switch 0 — port 4 — port 9 — switch 1), ensuring that the recovery firmware is accurately delivered to the current switch.

[0088] Based on steps S21 and S22 above, this method solves two major problems in related technologies that prevent switching devices with only interconnect ports from achieving firmware recovery via firmware distribution from the host: First, step S21 specifies the interconnect port in the current switching device that corresponds to the target switching device as the loading port, solving the problem that the current switching device does not know from which port to receive the recovery firmware. Second, step S22 uses the target switching device, which has a usable communication connection with the host, as a relay to forward the recovery firmware, decomposing the data transmission from "host to current switching device" into two data transmissions: "host to target switching device" and "target switching device to current switching device." Based on the definition of the target switching device, the path from "host to target switching device" is known, enabling accurate distribution of the host recovery firmware. Furthermore, since the target switching device is another switching device directly connected to the current switching device, and the interconnect port is known, the path from "target switching device to current switching device" is unique and known, ensuring that the recovery firmware forwarded by the target switching device accurately reaches the current switching device. Therefore, the current switching device can complete its own firmware recovery based on the received recovery firmware.

[0089] As described above, the firmware recovery method for interconnected switching devices provided by this invention overcomes two major problems encountered when sending recovery firmware from a host to the switching device to be recovered: port uncertainty and routing table corruption preventing the recovery firmware from accurately reaching the current switching device. Therefore, the application of this method enables a more automated firmware recovery scheme for switching devices via host-sent recovery firmware. It is applicable to firmware recovery of switching devices with only interconnection ports and offers significant advantages in scenarios involving multiple interconnected switching devices, including high recovery efficiency and low implementation difficulty.

[0090] On the other hand, in a network of switching devices based on interconnect ports, besides the switching devices with only interconnect ports mentioned above, there are also switching devices that include uplink ports, which correspond to the "yes" branch in step S1. Therefore, this embodiment also provides an optional embodiment for how to recover these switching devices that include uplink ports after firmware corruption.

[0091] like Figure 3 As shown, after the judgment in step S1, the above method, corresponding to the "yes" branch, further includes:

[0092] S31: Specifies an uplink port of the switching device as the port for loading recovery firmware.

[0093] S32: Communicates with the host via the load port to obtain the recovery firmware and perform firmware recovery.

[0094] Step S31 is similar in principle to step S21 above, designating one port of the switching device as the loading port for receiving the recovery firmware, so that the switching device with firmware failure knows which port to receive the recovery firmware from. However, unlike the above-mentioned switching devices with only interconnect ports, the switching device with an uplink port connects directly to the host through the uplink port, so the transmission path between it and the host is unique and definite. Therefore, in step S32, the switching device can communicate directly with the host through the loading port (i.e., the uplink port) to obtain the recovery firmware stored in the host for its own firmware recovery.

[0095] Based on the optional solutions provided in this embodiment, in a switching device network that uses interconnection ports for networking, both types of switching devices (whether or not they have uplink ports) have corresponding firmware recovery solutions implemented via a host. Furthermore, neither of these firmware recovery solutions requires manual reprogramming using a programmer, enabling more automated firmware recovery for the entire switching device network.

[0096] Furthermore, for firmware recovery of switching devices with uplink ports, unlike switching devices with only interconnect ports, since they are directly connected to the host via the uplink port, the transmission path between them and the host is unique and known. Therefore, for recovery firmware containing uplink ports, no active distribution from the host is required. This embodiment also provides another optional implementation scheme:

[0097] The above step S32 specifically includes:

[0098] S321: Communicates with the host via the load port to obtain the address where the recovery firmware is stored in the host.

[0099] S322: Initiates a direct memory access operation to the host based on the address, and directly reads the recovery firmware from the host memory.

[0100] In practical applications, the host used to restore the firmware of a switching device typically stores the corresponding recovery firmware in memory for easy access later. Therefore, in this embodiment, the switching device with an uplink port can obtain the address (memory address) where the recovery firmware is stored in the host through communication with the host, and then initiate a Direct Memory Access (DMA) operation to retrieve the corresponding recovery firmware stored in the host itself, without the host actively sending it, thus reducing the host's load.

[0101] It should also be noted that the reason this embodiment communicates with the host in step S321 to obtain the firmware address is that in practical applications, the host may store different recovery firmware for different switching devices. These different recovery firmwares are stored at different addresses in the host memory, so it is necessary to obtain the firmware address first in order to accurately obtain the correct recovery firmware. If all switching devices share the same recovery firmware, it is not necessary to communicate to obtain the address first; the storage address of this unique recovery firmware can be pre-configured in the switching device, and it can be directly obtained from the host memory based on this address during subsequent recovery. However, in practical applications, the scenario where different switching devices use different recovery firmware is more common, and firmware recovery in this scenario is also more flexible, as different switching devices can use different firmware.

[0102] On the other hand, as can be seen from the above embodiments, firmware recovery for a switching device with only an interconnect port requires that the switching device have a target switching device that is directly connected to it and has a usable communication connection with the host. This places additional requirements on firmware recovery. In practical applications, not all switching devices with corrupted firmware have a target switching device that meets the above conditions.

[0103] To address the aforementioned problems, this embodiment further provides an optional implementation scheme, which further includes the following for step S21:

[0104] S211: If none of the switching devices connected to the current switching device via the interconnect port meet the condition of having an available communication connection with the host, then designate any switching device located one level above the current switching device in the switching device network as the target switching device.

[0105] S212: Designate the interconnect port in the current switching device that is connected to the target switching device as the load port.

[0106] In this network, the level of the switching equipment is determined by the proximity of the connection between the switching equipment and the host. Switching equipment directly connected to the host is the first-level switching equipment, and switching equipment indirectly connected to the host through the (N-1)th-level switching equipment is the Nth-level switching equipment, where N is any positive integer greater than 1. It should also be noted that the above levels are determined by the number of other switching equipment included in the transmission path between the switching equipment and the host. Although this embodiment does not restrict the selection of the specific transmission path, in practical applications, to improve efficiency, the shortest transmission path to the host is preferentially selected as the transmission path for determining the switching equipment level.

[0107] For example, with Figure 6 Taking the illustrated switching network as an example, assume that switching devices 0-3 in this network all have corrupted firmware and need to be restored. Based on the division in step S1 above, switching device 0 is a switching device with an uplink port, corresponding to the firmware restoration in steps S31-S32; switching devices 1-3 are switching devices with only interconnect ports, corresponding to the firmware restoration in steps S21-S22. Since switching device 0 also has corrupted firmware, switching devices 1 and 2 do not have a target switching device that meets the conditions of step S21. Similarly, since switching devices 1 and 2 are corrupted, switching device 3 does not have a target switching device that meets the conditions of step S21.

[0108] However, based on the solution provided in this embodiment, it can be determined that... Figure 6 In the network of switching devices shown, switching device 0, which is directly connected to the host, is the first-level switching device as defined above; switching devices 1 and 2, which are indirectly connected to the host through switching device 0, are the second-level switching devices as defined above; and switching device 3, which is connected to the host through switching device 0-switching device 1 or switching device 0-switching device 2, is the third-level switching device as defined above.

[0109] Therefore, for the second-level switching devices 1 and 2, the first-level switching device 0 can be designated as the target switching device. Since switching device 0 is directly connected to the host via its uplink port, firmware recovery can be achieved through steps S31-S32. After switching device 0's firmware is recovered, it can serve as the target switching device satisfying the conditions of step S21, and the second-level switching devices 1 and 2 can then achieve firmware recovery through steps S21-S22. Similarly, after the second-level switching devices 1 and 2 complete their firmware recovery, they can also serve as the target switching device satisfying the conditions of step S21, and the third-level switching device 3 can also achieve firmware recovery through steps S21-S22. That is, for... Figure 6 The firmware recovery sequence for each switching device in the network shown is: Switch 0 — Switch 1, 2 — Switch 3.

[0110] Therefore, based on the hierarchical firmware recovery scheme provided in this embodiment, regardless of the network topology or which switching devices within the network are faulty, the firmware recovery method for interconnected switching devices provided by this invention can restore all firmware-damaged switching devices. Specifically, based on the proximity of each switching device to the host, recovery proceeds sequentially from closest to furthest. Once the firmware recovery of a higher-level switching device is complete, it can serve as the target switching device for the next-level device, assisting the next-level device in achieving firmware recovery, thereby realizing firmware recovery for the entire switching network.

[0111] Furthermore, as explained in the relevant technical section, switching devices networked via interconnect ports do not possess the fixed routing relationships found in hierarchical networks. Therefore, user-programmed routing tables need to be stored in the switching devices. In typical application scenarios, both the routing table and firmware are stored in the non-volatile flash memory of the switching devices; therefore, firmware corruption can be considered equivalent to routing table corruption. The method provided in the above embodiments can restore the firmware. However, the simplest way to restore a corrupted routing table is to resend a routing table based on the transmission path of the restored firmware. However, since firmware restoration by switching devices at the second level and later in the network requires forwarding from the previous level switching device, this routing table will pass through other switching devices. Especially when other switching devices also use the above method for firmware restoration and also suffer from routing table corruption, distinguishing whether the transmitted routing table is for themselves becomes a critical issue in routing table recovery.

[0112] In view of this, this embodiment provides an optional implementation scheme, in which the above method, after step S21, further includes:

[0113] S23: Use the target field code carried in the first message packet received through the loading port as the target field code of the current switching device.

[0114] The target domain code is a globally unique code within the switching equipment network.

[0115] S24: When the routing table is received through the loading port, determine whether the destination domain code carried in the routing table is the same as the destination domain code corresponding to the current switching device; if yes, proceed to step S25; if no, proceed to step S26.

[0116] S25: Save the received routing table locally.

[0117] S26: After the interconnection link with the next-level switching device is established, the target field code carried in the routing table is sent to the next-level switching device via a message packet.

[0118] It should be noted that the destination field code is a newly defined parameter in this embodiment. As a globally unique code within the switching network, it can be used to distinguish different switching devices within the network. Therefore, when transmitting a routing table, it can be determined whether the routing table is the one that needs updating, based on whether the destination field code carried in the routing table is the same as its own corresponding destination field code. Furthermore, the setting of the destination field code can also determine the route. That is, after determining that this routing table is not its own, it determines which switching device at the next lower level to send it to.

[0119] For example, also Figure 6 Taking the network of switching devices shown as an example, assume that the target domain codes (domain IDs) corresponding to switching devices 0 to 3 are also 0 to 3. Assume that the current host issues a routing table, in which the domain ID=1, indicating that this routing table is for switching device 1.

[0120] The routing table issued by the host first passes through switch 0; switch 0, after comparing the domain ID, finds that this routing table is not its own new routing table; at this point, there are two possible implementation schemes:

[0121] First, assuming that switch 0 already has a routing table, meaning the routing table also uses a hierarchical recovery scheme. In this case, switch 0 can determine that this routing table corresponds to switch 1 by using the domain ID=1 carried in its routing table and its own routing table. Therefore, switch 0 will route this routing table to switch 1.

[0122] Secondly, assume that switch 0 does not have a routing table. In this case, switch 0 can directly forward the routing table to the next-level switch. The next-level switch then determines whether this routing table belongs to it based on its own domain ID; if it does, it restores the routing table and forwards it to the next level; if not, it forwards it to the next level again; based on this layer-by-layer forwarding, it will always reach the corresponding switch and complete the setting and restoration of its routing table.

[0123] However, it should be noted that both of the above optional solutions require each switching device to know its own target domain code, which also limits the implementation of batch recovery of switching devices in a multi-switching device interconnection scenario. Therefore, this embodiment also provides a target domain code setting and recovery scheme, namely steps S23 and S26.

[0124] Furthermore, based on the aforementioned function of the target field encoding, it is clear that the target field encoding also needs to be persistently stored locally on the switching device, that is, stored in the non-volatile flash memory within the switching device. Since this invention addresses the scenario of recovery after switching device firmware corruption, firmware corruption is equivalent to the loss of the target field encoding, which is also stored in the flash memory. Therefore, how to specify the target field encoding after firmware recovery is the problem that step S26 of this embodiment needs to solve.

[0125] Based on step S26, when it is determined in step S24 that the received routing table does not correspond to itself, step S26 waits for the interconnection link with the next-level switching device to be established before sending the target domain code carried in this routing table to the next-level switching device via a message packet. At this time, combined with step S23, if the next-level switching device receives the target domain code for the first time, it uses this target domain code as its own target domain code to complete the target domain code setting or restoration for the next-level switching device. After the target domain code of the next-level switching device is set, it can forward the received routing table downwards to continue triggering the routing table restoration and target domain code setting at the next level.

[0126] It should be noted that if multiple next-level switching devices exist during the execution of step S26, one of them can be selected for sending the target domain code to ensure its uniqueness. The selection can be random or based on arbitrary selection rules; this embodiment does not impose any restrictions on this. Based on the host continuously sending routing tables with different target domain codes, and through the repeated execution of the above steps in different levels of switching devices, all switching devices in the switching network will eventually complete the setting or restoration of the target domain code and routing table.

[0127] Furthermore, regarding the target field encoding in the above embodiments, since it is a new parameter defined in the above embodiments, not a parameter defined in the PCIe protocol, and not in the standard Transaction Layer Packet (TLP), the specific method for sending the target field encoding through a message packet in step S26 is as follows: This embodiment provides an optional implementation scheme:

[0128] The specific steps of S26 above are as follows:

[0129] S26-A: The target field encoding is carried by the transaction layer packet prefix in the message packet.

[0130] In other words, this embodiment carries the target field encoding through the transaction layer packet prefix in the PCIe protocol. Specifically, the message packet can be a message packet for sending a routing table or other request packets.

[0131] In addition, this embodiment also provides another optional implementation scheme:

[0132] The above step S26 specifically includes:

[0133] S26-B: Send the transaction layer packet containing the target field code to the next-level switching device.

[0134] In other words, this embodiment sends a TLP packet containing the target field code as the data to be transmitted before transmitting the routing table message packet or other request packets to the next-level switching device. This ensures that the setting of the target field code precedes the arrival of the routing table, avoiding the problem that the switching device cannot determine whether the routing table corresponds to itself due to the absence of the target field code, and thus does not know how to proceed with the next step.

[0135] It should be noted that both target field encoding transmission methods provided in the above embodiments can achieve the transmission of target field encoding, as a newly defined parameter, between switching devices. In addition, other existing data transmission methods can also be used to transmit target field encoding in switching devices, which will not be elaborated upon in this embodiment. In practical applications, appropriate implementation schemes can be freely selected according to different actual needs, and this embodiment does not impose any restrictions in this regard.

[0136] On the other hand, as can be seen from the above embodiments, the firmware recovery method for a switching device interconnection scenario provided by the present invention can realize firmware recovery for all switching devices in a switching device network based on interconnection ports. Moreover, this recovery can be achieved by the host issuing recovery firmware, which greatly improves the degree of automation compared to manually reprogramming each corrupted switching device one by one using a programmer. However, the automation of the above method relies on some "configuration," such as specifying the loading port and whether to load the recovery firmware from the uplink port or the interconnection port (i.e., specifying the type of loading port). This is because for switching devices with corrupted firmware, this information cannot be pre-stored or obtained through communication with external devices and needs to be determined through configuration information.

[0137] In the current architecture of switching equipment, configuration pins are present for booting and configuring the switching equipment. This embodiment extends the configuration pins to provide an optional implementation scheme:

[0138] The aforementioned switching device includes a first configuration pin. This first configuration pin is used to configure the loading of recovery firmware from an uplink port or an interconnect port.

[0139] The above step S1 specifically includes:

[0140] S11: If the first configuration pin is configured to load recovery firmware from the uplink port, it is determined that the switch to be recovered has an uplink port connected to the host.

[0141] S12: If the first configuration pin is configured to load recovery firmware from the interconnect port, it is determined that the switch to be recovered does not have an uplink port connected to the host.

[0142] In other words, this embodiment extends the configuration pins in the switching device, using a first configuration pin to specify whether the recovery firmware is loaded from the uplink port or the interconnect port (equivalent to specifying the port type of the loading port, or specifying whether the current switching device is a switching device with only interconnect ports). This allows the determination in step S1 to be performed even when the switching device firmware is corrupted. Furthermore, this embodiment implements the above "specification" based on configuration, moving the additional work required before the actual firmware recovery, providing more margin for firmware recovery, improving firmware recovery efficiency, and reducing the difficulty of implementing the firmware recovery scheme.

[0143] Similarly, as can be seen from the above embodiments, to achieve firmware recovery, it is necessary to specify the port on which the recovery firmware is loaded. Besides specifying the type of loading port through the first configuration pin in the previous embodiment, it is also necessary to specify which port in the switching device the loading port is. In this regard, this embodiment also provides an optional implementation scheme:

[0144] The aforementioned switching device also includes a second configuration pin. This second configuration pin is used to configure the port number of the loading port.

[0145] Accordingly, when specifying an interconnect port / uplink port of the designated switching device as the loading port for the recovery firmware in steps S21 and S31, the specific steps include:

[0146] Based on the port number configured by the second configuration pin, the corresponding port is used as the load port; based on the configuration of the first configuration pin, the load port is initialized as an interconnect port / uplink port.

[0147] It should be noted that, due to the current firmware corruption of the switching equipment, it is unaware of which ports are interconnect ports and which are uplink ports. In this embodiment, firmware recovery focuses only on the loading port for receiving the recovery firmware. The port types of other ports will be known after firmware recovery, so they will not be discussed in this embodiment. Based on the first configuration pin of the previous embodiment, the type of the loading port can be determined. However, it is still necessary to specify which port in the switching equipment is the loading port. In this embodiment, the port number of the loading port is specified through the second configuration pin, thus determining a single port as the loading port to receive the recovery firmware. Combined with the port type of the loading port determined in the above embodiment, the initialization of the loading port can be completed, enabling the loading port to perform its functions normally and receive the recovery firmware to achieve firmware recovery.

[0148] Similar to the previous embodiment, this embodiment also expands the existing configuration pins to convert the specification of the load port into a pre-configuration process. On the one hand, this ensures that the switching device with corrupted firmware can clearly identify which internal port is the load port. On the other hand, it moves this step, which is not easily automated, to the preparation stage before the formal firmware recovery process, which is beneficial to improving firmware recovery efficiency and reducing the difficulty of implementing the firmware recovery solution.

[0149] It should also be noted that the aforementioned first configuration pin and second configuration pin may not necessarily consist of only one pin; they may be a group of pins designed to achieve complex functions that cannot be accomplished by a single pin. In one alternative implementation, the aforementioned first configuration pin and second configuration pin may even be integrated into a configuration function for the load port, implemented through a single configuration pin group. For example... Figure 4 and Figure 5 As shown, configuring the load port requires configuring at least the load port type and port number to ensure that the load port is uniquely identified and can receive recovery firmware.

[0150] Furthermore, aside from the configuration steps in the two embodiments described above, the other steps in this embodiment can be automated by writing scripts or programs. Specifically, this embodiment provides an optional implementation scheme:

[0151] The aforementioned switching device includes a third configuration pin; the third configuration pin is used to configure a firmware stored in the first storage medium as boot firmware.

[0152] The first storage medium is the storage medium used to store firmware in the switching device.

[0153] The first storage medium includes: default firmware and user firmware.

[0154] When the default firmware is executed, it is used to: determine whether the switch to be restored has an uplink port connected to the host; wherein the host stores the restoration firmware; if not, specify an interconnect port of the switch as the loading port for the restoration firmware; wherein the target switch connected to the specified interconnect port has a usable communication connection with the host; receive the restoration firmware forwarded by the target switch through the loading port, and perform firmware restoration.

[0155] It should be noted that the third configuration pin in this embodiment is not necessarily a newly added pin. For existing switching devices, their Flash memory may store multiple different firmware programs (i.e., multiple user firmware). In this case, the configuration pin is currently used to select which user firmware is loaded into the Random Access Memory (RAM) during startup for execution by the Central Processing Unit (CPU).

[0156] Therefore, the third configuration pin in this embodiment can be an extension of the configuration pin used to select the boot firmware. Specifically, the extension involves selecting one boot firmware from all user firmwares, or selecting one firmware from all user firmwares and the default firmware. When the default firmware is selected as the boot firmware, it indicates that the switching device has firmware corruption and needs to be restored using the method described above. It is easy to understand that if the switching device does not have firmware corruption, the third configuration pin can also be configured to select a specific user firmware for booting, thus specifically restoring firmware for switching devices in the network that have firmware corruption.

[0157] Furthermore, the default firmware in this embodiment is used to implement all the method steps implemented on the switching device side, except for configuring the first configuration pin, the second configuration pin, and the third configuration pin, as described in the above embodiments. This includes at least steps S11, S12, S22-S26, S32, and their further derived embodiments. In addition, other parts of steps S1, S21, and S31 besides manually configuring the pins, such as how to identify the state of the configuration pins to determine their configuration, are also implemented when the default firmware is executed. Furthermore, the default firmware is also used to implement necessary steps not described in the above embodiments but required for the startup of a conventional switching device.

[0158] Furthermore, since the default firmware needs to be selected as the boot firmware to execute after the switching device powers on, thus automating the above method, it needs to be stored in the switching device's internal Flash memory along with other firmware (i.e., user firmware). Therefore, firmware corruption also means that the default firmware may be corrupted.

[0159] Although the default firmware only occupies a portion of the Flash memory, and the default firmware also becoming corrupted when the original firmware is corrupted is only a probabilistic event, once this event occurs, the more automated firmware recovery method cannot be achieved, so it needs to be avoided as much as possible. Based on this, this embodiment further provides an optional implementation scheme:

[0160] The default firmware is stored in the target area of ​​the first storage medium. Modification permissions for the target area in the first storage medium are restricted to the programmer only.

[0161] As explained in the above technical sections, the main reason for damage to switching equipment is that firmware updates are interrupted or incorrectly performed due to abnormal circumstances. The probability of physical damage to the Flash memory leading to firmware corruption is low, and this situation is considered unforeseen. Since the Flash memory, which carries the firmware, cannot be restored until a new Flash memory is installed, this embodiment does not consider this situation and only discusses firmware corruption caused by incorrect firmware updates.

[0162] Furthermore, since the default firmware in this method is the firmware program used to implement the aforementioned firmware recovery method, its function is fixed and its stability is strong. That is, the default firmware used by all switching devices can be completely identical, and will not change due to version updates or other operations that affect user needs. Based on this characteristic, this embodiment divides the first storage medium (i.e., Flash) into a segmented design, dividing it into a storage area that allows users to freely edit and a target area that restricts user editing and allows only programmer modification. The user firmware is stored in the storage area to meet user update needs. The default firmware is stored in the target area, which restricts user modification, thus avoiding the possibility of the default firmware being corrupted due to erroneous firmware updates. In other words, when the default firmware is stored in the target area that restricts user editing using this embodiment, even if firmware corruption occurs, it can be reasonably assumed that only the user firmware is corrupted, while the default firmware remains intact, allowing for the automated implementation of the aforementioned method, further improving the reliability of this method.

[0163] On the other hand, based on the above embodiments, to better illustrate the specific implementation of this method, this embodiment also provides an optional internal implementation structure for the switching device, such as... Figure 7 As shown (taking a switching device including an uplink port as an example; a switching device with only an interconnect port has the same structure after removing the uplink port), a switching device includes:

[0164] Read-Only Memory (ROM): This is used to store the most basic boot program. This program needs to include a program that reads the configuration via configuration pins, and a program that controls the Flash controller to load the firmware from the Flash medium into Random Access Memory (RAM) and run it.

[0165] RAM: Used to store firmware programs to be executed. Programs need to be read from Flash and placed into RAM before they can be executed by the Central Processing Unit (CPU).

[0166] Flash memory: A non-volatile storage medium inside the switching device used to store firmware programs, including user-defined firmware and default firmware. It should be noted that the default firmware is a firmware program newly added to the Flash memory in this embodiment; its specific functions and implementation will be described later.

[0167] Configuration pins: These are used to configure the startup of the switching device by changing the pin's high or low levels. For example, the configuration pins can be used to select which user firmware stored in Flash the switching device will boot from. Based on the above embodiments, the configuration pins of this invention, in addition to implementing the original configuration functions, should at least include the first configuration pin, second configuration pin, and third configuration pin (which can be implemented by extending the original boot firmware to select the configuration pins) described in the above embodiments.

[0168] It should be noted that, Figure 7 The switching device structure shown is a common internal structure of a switching device. ROM, RAM, CPU, Flash, Flash controller, etc., are all common internal configurations of switching devices, and this embodiment does not modify them, so they will not be described in detail. The key point to note is that this embodiment adds a new firmware program to the Flash, namely the default firmware; and this embodiment also extends the functionality of the original configuration pins used to select the boot firmware, enabling the selection of the default firmware as the boot firmware. In addition, it also includes the first and second configuration pins extended in the above embodiment.

[0169] based on Figure 7 The embodiment further explains the firmware recovery process for the different switching devices shown above:

[0170] 1. Level 1 switching equipment (or switching equipment containing uplink ports, switching equipment directly connected to the host via uplink ports, etc.).

[0171] This switching device corresponds to Figure 5 The switching device in the above embodiment, and steps S31-S32 provided above. Specifically, a complete process from self-initialization to powering on the switching device and then to firmware recovery completion is as follows: Figure 5 As shown, it includes the following two stages.

[0172] Initialization (configuration) phase: By configuring the configuration pins, select to load the default firmware in Flash; select to load the firmware to be restored from the uplink port; configure the port number of the uplink port to 2.

[0173] Firmware recovery phase:

[0174] ① The CPU inside the switching device executes the program in the ROM, which reads the firmware selection configuration from the configuration pin.

[0175] ② Load the Flash controller driver, read the default firmware from the Flash, and write it into RAM.

[0176] ③ The program in ROM controls the CPU to jump to RAM to execute the default firmware.

[0177] ④ The default firmware initializes port 2 as an uplink port according to the configured pins and establishes a PCIe link with the host; then the CPU interacts with the host to obtain the address used by the host to store the firmware to be restored; after obtaining the address, the CPU initiates a DMA operation to the host according to the above address, retrieves the firmware to be restored from the host memory and puts it into RAM.

[0178] Alternatively, as an alternative to this approach, the CPU can declare that the switching device has an accessible space when initializing the link, and configure the decoder to point the accessible space to RAM. Then, the host can actively write the firmware to be restored into this space (i.e., it is actually written into RAM).

[0179] ⑤ The default firmware controls the CPU to jump to the available firmware for execution.

[0180] ⑥ The firmware can be used to control the CPU to read the firmware from RAM and write it to a specified area of ​​Flash.

[0181] 2. Level N-1 switching device (In this embodiment, the Level N-1 switching device is defined as a switching device that only has interconnect ports, but it already meets the target switching device conditions of step S21).

[0182] This switching device corresponds to Figure 4 The switching device 1 (switching device 0 is the target switching device of switching device 1), and steps S21-S22 provided in the above embodiments. Specifically, a complete process from self-initialization to switching device power-on and firmware recovery completion is as follows: Figure 4 As shown, it includes the following two stages.

[0183] Initialization (configuration) phase: By configuring the configuration pins of switch device 1, select to load the default firmware in Flash (target switch device 0 does not require firmware recovery, load user firmware); select to load the firmware to be recovered from the interconnect port; configure the port number of the interconnect port to 9.

[0184] Firmware recovery phase:

[0185] ① The CPUs of switching devices 0 and 1 first execute a program from the ROM, which reads the firmware selection from the configuration pin.

[0186] ② Switching device 0 and switching device 1 read the user firmware and default firmware from Flash into RAM, respectively.

[0187] ③ Switch 0 executes the user firmware, which initializes port 2 as an uplink port and port 4 as an interconnect port. Switch 0 waits to establish PCIe connections with the host and adjacent chips. Switch 1 executes the default firmware, which initializes port 9 as an interconnect port according to the configured pins, and then waits to establish a connection with switch 0. This link requires a crosslink as defined by the PCIe protocol.

[0188] ④ The host writes a routing table to switch device 0, which configures the egress port of the request packet with target domain ID 1 as port 4 (i.e., the interconnection port of switch device 0).

[0189] ⑤ The host sends a request to switch device 0 to update the firmware of switch device 1. The request includes the location where the host stores the firmware of switch device 1 to be restored.

[0190] ⑥ Switching device 0 waits for the interconnection link to be established, and then sends a message packet with a "target domain ID" of 1 through the link.

[0191] As can be seen from the above embodiments, when the switching device uses the default firmware, its domain ID should be considered uninitialized in the initial state. In this state, when the switching device receives the first message packet from the interconnect port specified by the configuration pin, it should assume that the message packet is received by itself and set its own domain ID to the destination ID of the message packet. Subsequent packets with the destination ID of this domain ID will be processed by the device without needing to look up the routing table for outward routing. Message packets sent by switching device 0 need to inform switching device 1 that user firmware will be sent subsequently, along with basic information such as the firmware length. After receiving the message packet, switching device 1 will prepare RAM space for receiving the firmware.

[0192] ⑦ The CPU of switch device 0 initiates a DMA operation to the host according to the address given by the host in step ⑤, retrieves the firmware to be restored from the host memory, and sends it out as a series of message packets from port 4. These message packets eventually arrive at switch device 1, where the CPU of switch device 1 extracts the firmware code from the message packets and stores it in the available firmware area of ​​RAM.

[0193] ⑧ The default firmware control program of switching device 1 jumps to the available firmware for execution.

[0194] ⑨ The firmware can be used to control the CPU to read the firmware from RAM and write it to a specified area of ​​Flash.

[0195] 3. Level N switching device (In this embodiment, the Level N switching device is defined as a switching device that only has interconnect ports and does not have a target switching device that meets the conditions of step S21, that is, a switching device that needs to be restored at the level).

[0196] This switching device corresponds to Figure 6 The switching device 3 (switching device 0 is the first level; switching devices 1 and 2 are the second level; switching device 3 is the third level), and the steps S211, S212, and S22 provided in the above embodiments. Specifically, a complete process from self-initialization to power-on of the switching device and then to firmware recovery completion is as follows: Figure 6 As shown, it includes the following two stages.

[0197] Initialization (configuration) phase: By configuring the configuration pins of switching device 3, select to load the default firmware in Flash; select to load the firmware to be restored from the interconnect port; configure the port number of the interconnect port (which can be the port number of any connection port in switching device 1 or 2).

[0198] ① The firmware recovery of the switching device 0 is completed through the aforementioned firmware recovery process 1.

[0199] ② The host configures a complete routing table for the restored switch device 0, which includes the exit port numbers for all target domain IDs within the network.

[0200] ③ The host sends the recovery firmware to the switch device 1 through the switch device 0, and completes the firmware recovery of the switch device 1 according to the aforementioned firmware recovery process 2, and sets the domain ID of the switch device 1.

[0201] The steps for setting the domain ID and routing table correspond to steps S23~S26 in the above embodiments.

[0202] ④ The host sets up a complete routing table for switching device 1 through switching device 0 to ensure that subsequent data packets can reach the switching device adjacent to switching device 1.

[0203] ⑤ Same as step ③, but perform firmware recovery and domain ID setting for switch device 2.

[0204] ⑥ Same as step ④, but configure the routing table for switching device 2.

[0205] It should be noted that there is no order restriction between steps ③ and ④ and steps ⑤ and ⑥, and they can be executed in parallel.

[0206] ⑦ The host sends firmware to the switching device 3 through switching device 0 and switching device 1 (or switching device 2).

[0207] Unlike switch 0, switch 1 does not need to forward data packets via CPU. Instead, after receiving a data packet with target domain ID 3, it learns that the final destination is not itself, then looks up the routing table to obtain the exit port of the target domain ID, and sends the message packet out from that exit port, which eventually reaches switch 3.

[0208] ⑧ The host configures a complete routing table to switch device 3 through switch device 0.

[0209] In this case, switching device 1 functions similarly to step ⑦, only needing to perform the routing function. It should be noted that... Figure 6 Step ⑧ uses a different path than step ⑦, and its purpose is only to illustrate the difference between steps ⑦ and ⑧. Figure 6 The scenario shown has two different paths (i.e., through switching device 1 or 2) to reach switching device 3, depending on how the routing table in switching device 0 is configured. However, generally, the paths used in steps ⑦ and ⑧ need to be the same.

[0210] In addition to the firmware recovery method embodiment provided above for a switching equipment interconnection scenario, this invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instructions, which, when executed by a processor, can implement the steps of the firmware recovery method for a switching equipment interconnection scenario as described in any of the above embodiments.

[0211] Since the embodiments of the computer program product portion correspond to the embodiments of the method portion, please refer to the description of the embodiments of the method portion for the embodiments of the computer program product portion, which will not be repeated here.

[0212] In the above embodiments, a firmware recovery method for a switching equipment interconnection scenario has been described in detail. The present invention also provides an embodiment of a firmware recovery device for a switching equipment interconnection scenario. It should be noted that the present invention describes the device embodiment from two perspectives: one based on functional modules and the other based on hardware.

[0213] From the perspective of functional modules, this embodiment provides a firmware recovery device for a switching device interconnection scenario, such as... Figure 8 As shown, it includes:

[0214] The type determination module 11 is used to determine whether the switching device to be restored has an uplink port connected to the host; if not, the port determination module is triggered; wherein, the host stores the recovery firmware.

[0215] The port determination module 12 is used to designate an interconnect port of the switching device as the loading port for the recovery firmware; wherein the target switching device connected to the designated interconnect port has an available communication connection with the host.

[0216] Firmware recovery module 13 is used to receive recovery firmware forwarded by the target switching device through the loading port and perform firmware recovery.

[0217] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0218] Figure 9 A structural diagram of a firmware recovery device in a switching device interconnection scenario provided by another embodiment of the present invention is shown below. Figure 9 As shown, a firmware recovery device in a switching device interconnection scenario includes: a memory 20 for storing computer programs.

[0219] The processor 21 is used to execute a computer program to implement the steps of a firmware recovery method in a switching device interconnection scenario as described in the above embodiment.

[0220] The firmware recovery device provided in this embodiment for a switching device interconnection scenario mainly refers to the switching device, or it can refer to the control device in the switching device, or other devices or components that are additionally deployed in the switching device and have a control function.

[0221] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0222] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of a firmware recovery method in a switching device interconnection scenario disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, a firmware recovery method in a switching device interconnection scenario.

[0223] In some embodiments, a firmware recovery device in a switching device interconnection scenario may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0224] Those skilled in the art will understand that Figure 9 The structure shown does not constitute a limitation on a firmware recovery device in a switching device interconnection scenario, and may include more or fewer components than shown.

[0225] The present invention provides a firmware recovery device for a switching device interconnection scenario, comprising a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a firmware recovery method for a switching device interconnection scenario.

[0226] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. A computer program is stored on the non-volatile storage medium, and when executed by a processor, the computer program implements the steps described in the above method embodiments.

[0227] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0228] The firmware recovery method, apparatus, program product, and medium for a switching device interconnection scenario provided by the present invention have been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to the present invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the present invention.

[0229] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A firmware recovery method in a switching device interconnection scenario, characterized in that, include: Determine whether the switching device to be restored has an uplink port connected to the host; wherein the host stores the recovery firmware; If not, then an interconnect port of the switching device is designated as the loading port of the recovery firmware; wherein the target switching device connected to the designated interconnect port has a usable communication connection with the host; the corresponding port is designated as the loading port according to the port number configured by the configuration pin; If none of the switching devices connected to the current switching device via an interconnect port meet the condition of having a usable communication connection with the host, then any switching device located one level above the current switching device in the switching device network is designated as the target switching device; the interconnect port of the current switching device connected to the target switching device is designated as the loading port; wherein, the switching device network determines the level based on the proximity of the connection position between the switching device and the host; the switching device directly connected to the host is the first-level switching device, and the switching device indirectly connected to the host through the (N-1)th-level switching device is the Nth-level switching device, where N is any positive integer greater than 1; The recovery firmware, forwarded by the target switching device, is received through the loading port, and firmware recovery is performed.

2. The firmware recovery method in a switching equipment interconnection scenario according to claim 1, characterized in that, After determining whether the switching device currently to be restored has an uplink port connected to the host, the process further includes: If so, then designate one of the uplink ports of the switching device as the loading port for the recovery firmware; The system communicates with the host through the loading port to obtain the recovery firmware and performs firmware recovery.

3. The firmware recovery method in the scenario of interconnected switching devices according to claim 2, characterized in that, After designating an interconnect port of the switching device as the loading port for the recovery firmware, the method further includes: The target domain code carried in the first message packet received through the loading port is used as the target domain code of the current switching device; wherein, the target domain code is a globally unique code in the switching device network; When a routing table is received through the loading port, it is determined whether the target domain code carried in the routing table is the same as the target domain code corresponding to the current switching device. If so, the received routing table will be saved locally; If not, after the interconnection link with the next-level switching device is established, the target domain code carried in the routing table is sent to the next-level switching device via a message packet.

4. The firmware recovery method in the scenario of interconnected switching devices according to claim 3, characterized in that, The step of sending the target domain encoding carried in the routing table to the next-level switching device via a message packet includes: The target field encoding is carried by the transaction layer packet prefix in the message packet.

5. The firmware recovery method in the scenario of interconnected switching devices according to claim 3, characterized in that, The step of sending the target domain encoding carried in the routing table to the next-level switching device via a message packet includes: The transaction layer packet containing the target domain code is sent to the next-level switching device.

6. The firmware recovery method in a switching equipment interconnection scenario according to claim 2, characterized in that, Communicating with the host through the loading port to obtain the recovery firmware includes: The host is communicated through the loading port to obtain the address where the recovery firmware is stored in the host. Initiate a direct memory access operation to the host based on the address, and directly read the recovery firmware from the host memory.

7. The firmware recovery method in a switching equipment interconnection scenario according to claim 2, characterized in that, The switching device includes a first configuration pin; wherein the first configuration pin is used to configure loading recovery firmware from an uplink port or an interconnect port; Determining whether the switching device currently to be restored has an uplink port connected to the host includes: If the first configuration pin is configured to load recovery firmware from the uplink port, it is determined that the switching device to be recovered currently has an uplink port connected to the host. If the first configuration pin is configured to load recovery firmware from the interconnect port, it is determined that the switching device to be recovered does not have an uplink port connected to the host.

8. The firmware recovery method in a switching equipment interconnection scenario according to claim 7, characterized in that, The switching device further includes a second configuration pin; wherein the second configuration pin is used to configure the port number of the load port; Designating one of the interconnect ports / uplink ports of the switching device as the loading port for the recovery firmware includes: Based on the port number configured by the second configuration pin, the corresponding port is used as the loading port; The load port is initialized to the interconnect port / uplink port according to the configuration of the first configuration pin.

9. The firmware recovery method in a switching equipment interconnection scenario according to any one of claims 1 to 8, characterized in that, The switching device includes a third configuration pin; the third configuration pin is used to configure a firmware stored in the first storage medium as boot firmware; Wherein, the first storage medium is the storage medium used to store firmware in the switching device; The first storage medium includes: default firmware and user firmware; When the default firmware is executed, it is used to: determine whether the switching device to be restored has an uplink port connected to the host; wherein the host stores the restoration firmware; if not, designate an interconnect port of the switching device as the loading port of the restoration firmware; wherein the target switching device connected to the designated interconnect port has a usable communication connection with the host; receive the restoration firmware forwarded by the target switching device through the loading port, and perform firmware restoration.

10. The firmware recovery method in a switching equipment interconnection scenario according to claim 9, characterized in that, The default firmware is stored in the target area of ​​the first storage medium; The modification permission for the target area in the first storage medium is restricted to allow only the programmer to modify it.

11. A firmware recovery device for a multi-switch device interconnection scenario, characterized in that, include: The type determination module is used to determine whether the switching device currently to be restored has an uplink port connected to the host; If not, the port determination module is triggered; wherein, the host stores recovery firmware; The port determination module is used to designate an interconnect port of the switching device as the loading port of the recovery firmware; wherein, the target switching device connected to the designated interconnect port has a usable communication connection with the host; the port number configured by the configuration pin is used to designate the corresponding port as the loading port; if none of the switching devices connected to the current switching device through the interconnect port meet the condition of having a usable communication connection with the host, then any switching device located one level above the current switching device in the switching device network is designated as the target switching device; the interconnect port of the current switching device connected to the target switching device is designated as the loading port; wherein, the switching device network determines the level based on the proximity of the connection position between the switching device and the host; the switching device directly connected to the host is the first-level switching device, and the switching device indirectly connected to the host through the (N-1)th-level switching device is the Nth-level switching device, where N is any positive integer greater than 1; The firmware recovery module is used to receive the recovery firmware forwarded by the target switching device through the loading port and perform firmware recovery.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the firmware recovery method in the interconnection scenario of switching devices as described in any one of claims 1 to 10.

13. A firmware recovery device for a multi-switch device interconnection scenario, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the firmware recovery method in a switching device interconnection scenario as described in any one of claims 1 to 10.

14. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the firmware recovery method in the interconnection scenario of switching devices as described in any one of claims 1 to 10.

Images