Firmware recovery method and device in switching equipment interconnection scene, product and medium

Abstract

The invention discloses a firmware recovery method and device in a switching equipment interconnection scene, a product and a medium, and relates to the technical field of switching equipment. The firmware recovery method in the switching equipment interconnection scene aims at solving the problem that when firmware of switching equipment without an uplink port is damaged, it is difficult to implement firmware recovery through a programmer depending on manual work. The method comprises the following steps: selecting a switching device which has available communication connection with a host as a target switching device from all switching devices connected with a current switching device; and assigning an interconnection port, connected with the target switching equipment, of the current switching equipment as a loading port for recovering firmware. Namely, the host accurately sends the recovery firmware to the target switching equipment through the available communication connection, and then the target switching equipment sends the recovery firmware to the current switching equipment through the specified port, so that the purpose that the recovery firmware accurately reaches the current switching equipment is achieved, and then firmware recovery of the switching equipment is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of switching devices, and in particular to a firmware recovery method, device, program product, and medium in a switching device interconnection scenario. Background Art

[0002] New switching chip networking technology bypasses the tree-like hierarchical structure of the high-speed Peripheral Component Interconnect Express (PCIe) bus standard. Instead, it defines a specialized "interconnect port." The connections between interconnect ports differ from the traditional upstream-downstream relationship, instead using a peer-to-peer interconnection between chips to transmit information. Therefore, each connection is not bound to a hierarchy or host domain and can transmit information from any host or device. In theory, multiple chips can be interconnected in any topology without regard to the binding relationship between hosts and devices, enabling more flexible networking. For example, if switching chips are independently networked, changes in the host-device connection relationship do not require adjustments to the inter-chip interconnection.

[0003] However, this connection solution also presents certain issues: while switching devices support firmware updates, firmware corruption may occur during these updates. Switching devices connected via interconnected ports lack a hierarchical structure and fixed routing relationships; routing relationships are instead specified through configured routing tables. When the firmware becomes corrupted, the pre-configured routing table is likely lost. In this case, a switching device with corrupted firmware cannot guarantee normal transmission with other switching devices or hosts. Therefore, it cannot receive new firmware and perform firmware recovery through other interconnected switching devices or hosts, requiring manual reprogramming using a programmer. Manual reprogramming using a programmer is cumbersome and cannot be automated, making it difficult to implement in scenarios where multiple switching devices are interconnected.

[0004] Therefore, technicians in this field are in urgent need of a firmware recovery method in a switching device interconnection scenario to solve the problem that the solution of relying on programmer reprogramming to achieve firmware recovery is difficult to implement in the current scenario of multiple switching devices interconnected based on interconnection ports. Summary of the Invention

[0005] The purpose of the present invention is to provide a firmware recovery method, device, program product and medium in a switching device interconnection scenario, which is used to solve the problem that when the firmware of a switching device without an uplink port is damaged, it is difficult to rely on manual recovery of the firmware through a programmer.

[0006] To solve the above technical problems, the present invention provides a firmware recovery method in a switching device interconnection scenario, comprising: Determine whether the switching device to be restored currently has an uplink port connected to a host; wherein the host stores restoration firmware.

[0007] If not, then designate an interconnection port of the switching device as the loading port for the recovery firmware; wherein, there is an available communication connection between the target switching device connected to the designated interconnection port and the host.

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

[0009] In an optional embodiment, after determining whether the switching device to be restored currently has an uplink port connected to the host, the method further includes: If so, designate an uplink port of the switching device as a loading port for the recovery firmware.

[0010] Communicate with the host through the loading port, obtain the recovery firmware, and perform firmware recovery.

[0011] In an optional embodiment, the step of designating an interconnection port of the switching device as a loading port for the recovery firmware includes: If none of the switching devices interconnected with the current switching device through ports satisfies the condition of having an available communication connection with the host, any switching device located one level above the current switching device in the switching device network is designated as the target switching device.

[0012] The interconnection port connected to the target switching device in the current switching device is designated as the loading port.

[0013] Among them, the level of the switching device network is determined by the distance between the connection position relationship between the switching device and the host; the switching device directly connected to the host is a first-level switching device, and the switching device indirectly connected to the host through the N-1th level switching device is an N-level switching device, where N is any positive integer greater than 1.

[0014] In an optional embodiment, after designating an interconnection port of the switching device as a 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.

[0015] 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.

[0016] If so, the received routing table is saved locally.

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

[0018] In an optional embodiment, sending the target domain code carried in the routing table to the next-level switching device via a message packet includes: The target domain code is carried by a transaction layer packet prefix in the message packet.

[0019] In an optional embodiment, sending the target domain code 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 switching device at the next level.

[0020] In an optional embodiment, communicating with the host through the loading port to obtain the recovery firmware includes: Communicate with the host through the loading port to obtain the address where the recovery firmware is stored in the host.

[0021] A direct memory access operation is initiated to the host according to the address, and the recovery firmware is directly read from the host memory.

[0022] In an optional embodiment, the switching device includes a first configuration pin; wherein the first configuration pin is used to configure the recovery firmware to be loaded from the uplink port or the interconnection port.

[0023] Determining whether the switching device to be restored currently has an uplink port connected to the host includes: If the first configuration pin is configured to load the 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.

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

[0025] 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 loading port.

[0026] Designating one of the interconnection ports / the uplink port of the switching device as a loading port for the recovery firmware includes: According to the port number configured by the second configuration pin, the corresponding port is used as the loading port.

[0027] The load port is initialized as the interconnect port / the upstream port according to the configuration of the first configuration pin.

[0028] In an optional 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 the startup firmware.

[0029] The first storage medium is a storage medium in the switching device for storing firmware.

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

[0031] When executed, the default firmware is used to achieve: determining whether the switching device to be restored currently has an uplink port connected to the host; wherein the host stores the recovery firmware; if not, designating an interconnection port of the switching device as a loading port for the recovery firmware; wherein an available communication connection exists between the target switching device connected to the designated interconnection port and the host; receiving the recovery firmware forwarded by the target switching device through the loading port, and performing firmware recovery.

[0032] In an optional embodiment, the default firmware is stored in a target area in the first storage medium.

[0033] The modification authority of the target area in the first storage medium is limited to allowing only a programmer to modify it.

[0034] To solve the above technical problems, the present invention further provides a firmware recovery device in a multi-switch device interconnection scenario, comprising: The type determination module is used to determine whether the switching device to be restored currently has an uplink port connected to the host; if not, the port determination module is triggered; wherein the host stores the recovery firmware.

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

[0036] 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.

[0037] To solve the above technical problems, the present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the firmware recovery method in the switching device interconnection scenario described above.

[0038] To solve the above technical problems, the present invention further provides a firmware recovery device in a multi-switch device interconnection scenario, comprising: Memory for storing computer programs.

[0039] The processor is configured to implement the steps of the firmware recovery method in the switching device interconnection scenario described above when executing the computer program.

[0040] To solve the above technical problems, the present invention also provides a non-volatile storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the firmware recovery method in the switching device interconnection scenario described above are implemented.

[0041] The present invention provides a firmware recovery method for interconnected switching devices, providing a firmware recovery solution for switching devices connected to other switching devices only via interconnected ports. This method randomly selects a switching device with an available communication connection (direct or indirect) with a host as the target switching device from among all other switching devices connected to the current switching device for firmware recovery. The interconnected 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. Specifically, the host first accurately sends the recovery firmware to the target switching device directly connected to the current switching device via an available communication connection. The target switching device then sends the recovery firmware to the current switching device via a designated port (i.e., the loading port), ensuring that the recovery firmware accurately reaches the current switching device. Furthermore, the current switching device can use the recovery firmware to restore its own firmware, resolving the issue of firmware corruption.

[0042] This method does not require the switch device with corrupted firmware to have an uplink port. It is also applicable to switches with damaged routing tables that are networked only with other switches via interconnected ports. Furthermore, this method can automatically restore firmware to the switch device via the host, eliminating the need for manual programming. This makes it an automated solution for restoring firmware after corrupted switch device firmware, and is particularly suitable for resolving firmware issues in scenarios where large-scale switches are networked via interconnected ports.

[0043] The firmware recovery device, program product, and non-volatile storage medium in a switching device interconnection scenario provided by the present invention correspond to the above method and have the same effects as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0045] Figure 1 A structural diagram of a switching chipset network with a traditional hierarchical topology provided by an embodiment of the present invention.

[0046] Figure 2 A structural diagram of a switching chip networking based on interconnected ports provided by an embodiment of the present invention.

[0047] Figure 3 The present invention provides a flowchart of a firmware recovery method in a switching device interconnection scenario.

[0048] Figure 4 A schematic diagram of implementing switch device firmware recovery through an interconnection port provided by an embodiment of the present invention.

[0049] Figure 5 A schematic diagram of implementing switch device firmware recovery through an uplink port provided by an embodiment of the present invention.

[0050] Figure 6 A schematic diagram of layer-by-layer firmware recovery of a switching device network provided by an embodiment of the present invention.

[0051] Figure 7 A schematic diagram of the structure of a switching device provided in an embodiment of the present invention.

[0052] 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.

[0053] Figure 9 This is a structural diagram of another firmware recovery device in a switching device interconnection scenario provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0055] The core of the present invention is to provide a firmware recovery method, device, program product and medium in a switching device interconnection scenario.

[0056] In order 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 implementation methods.

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

[0058] However, Figure 1 The networking scheme shown here has a significant drawback: it only supports the tree-like hierarchical structure supported by the PCIe protocol. Each interconnected data path can only transmit information within that hierarchy. Therefore, changes in the host and device interconnections may also require changes to the hierarchy, necessitating adjustments to the interconnections between chips. This makes this networking scheme unsuitable for scenarios such as combining multiple switching chips into a switching network independent of the host, or for large-scale dynamic allocation of computing resources.

[0059] Currently, if Figure 2 As shown in the figure, a new switching chip networking technology is proposed. It does not use the tree-like hierarchical structure of the PCIe standard, but instead defines a special "interconnection port." The connection between the interconnection ports is different from the upstream and downstream relationship in the traditional method. Instead, information is transmitted in 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. In theory, multiple chips can be interconnected in any topology without considering the binding relationship between hosts and devices, which can achieve more flexible networking. For example, when switching chips are independently networked, when the connection relationship between hosts and devices changes, there is no need to adjust the interconnection between chips.

[0060] On the other hand, when multiple switching devices are interconnected, each has its own firmware (user firmware), which is typically stored internally on the chip or on external non-volatile storage media (such as flash memory). When the chip is powered on and booted, the program and necessary parameters are loaded from this media. To enable continuous iterative updates and vulnerability fixes, switching devices generally support firmware updates. For example, a programmer can write new firmware to the non-volatile storage media through a special interface on the switching device, or a host can update the firmware to the switching device through its uplink interface. The switching device then updates the firmware to the non-volatile storage media.

[0061] During a firmware update, if a power outage causes firmware corruption, or if the wrong firmware is updated, the switch device will load an inexecutable firmware the next time it powers on. This corrupted firmware can cause the switch device to malfunction. Manually reprogramming the switch device using a programmer is a common solution, but this approach is cumbersome and difficult to implement for a large number of devices.

[0062] Currently, for traditional hierarchical switching device networks, automated firmware recovery can be achieved by having the host distribute firmware to the switching device. However, this solution cannot be applied to switching device networks based on interconnected ports. The specific issues are as follows: 1. The above solution relies on the switch device to interact directly with the host through the uplink port. The switch device can know that the firmware received by the uplink port is the recovery firmware issued by the host, and then update the recovery firmware received by the uplink port to the Flash.

[0063] However, in a switching device network based on interconnected ports, not all switching devices have uplink ports; some switching devices only have interconnected ports. In extreme cases, only one switching device in the entire switching device network may have an uplink port. In this case, a switching device with damaged firmware would not know which port to receive the recovery firmware from.

[0064] 2. The switching devices based on the hierarchical structure have a fixed routing relationship, which can ensure that the firmware issued by the host accurately reaches any switching device in the switching device network.

[0065] However, interconnected devices based on interconnected ports are not directly specified by the topology and do not have fixed routing relationships. Instead, their routing relationships are generally determined by a user-programmed routing table. This routing table is also typically stored in Flash memory, so if the firmware is corrupted, the routing table is also considered corrupted. Therefore, the host cannot guarantee that the firmware will be accurately transferred to the designated switching device with corrupted firmware.

[0066] In order to solve the above problems, a more automated firmware recovery solution is implemented. The present invention provides a firmware recovery method in a switching device interconnection scenario, such as Figure 3 Shown, including: S1: Determine whether the switching device to be restored currently has an uplink port connected to the host; if not, go to step S21.

[0067] The host computer stores recovery firmware.

[0068] S21: Designate an interconnection port of the switching device as the loading port for the recovery firmware.

[0069] The target switching device connected to the designated interconnection port has an available communication connection with the host.

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

[0071] Among them, step S1 is to determine whether the switching device currently requiring firmware recovery is a switching device with only interconnection ports in the above-mentioned related technical description. This application provides a method for this switching device, which is used to replace manual reprogramming through a programmer to achieve a more automated firmware recovery solution.

[0072] For step S21, the firmware recovery process for the switching device with only interconnected ports is officially entered. As can be seen from the above, step S21 involves the current switching device (that is, the switching device with only interconnected ports and firmware damage), the target switching device and the host. Among them, the target switching device refers to other switching devices in the switching device network that are directly connected to the current switching device through the interconnected port and have an available communication connection with the host. It should be noted that this embodiment is not limited to whether the available communication connection between the target switching device and the host is achieved by direct connection through the uplink port or by indirect connection through other switching devices. For example, Figure 4 As shown, switching device 1 is the current switching device, and switching device 0 is the target switching device. At this time, the interconnection port 9 in switching device 1 connected to switching device 0 can be designated as the loading port.

[0073] Because a communication connection exists between the target switch and the host, the host can accurately send data (including recovery firmware) to the target switch. For a network of switches implemented via interconnected ports, the target switch can be either a switch directly connected to the host via an uplink port, or a switch indirectly connected to the host but with no firmware corruption, meaning the routing table in Flash memory is available, ensuring that data sent by the host accurately reaches its own switch. In short, the target switch is any switch in the network that is directly connected to the current switch and can accurately ensure that the recovery firmware sent by the host reaches it.

[0074] Then, step S22 forwards the recovery firmware via the target switching device directly connected to the current switching device. As can be seen from the above description of the target switching device, the host can accurately send the recovery firmware to the target switching device. Figure 4In the scenario shown, the host sends the recovery firmware to switch device 0 through uplink port 2. Afterwards, since the target switch device is directly connected to the current switch device, and the connection port is the interconnection port (such as Figure 4 Therefore, the path for the target switch to forward the recovery firmware to the current switch is fixed and unique (switch device 0 - port 4 - port 9 - switch device 1), ensuring that the recovery firmware is accurately delivered to the current switch.

[0075] Based on the above steps S21 and S22, it can be seen that this method solves two major problems in the related art that hinder switch devices with only interconnected ports from implementing firmware recovery via host firmware distribution. First, in step S21, the interconnected port corresponding to the target switch device on the current switch device is specified as the loading port, resolving the problem of the current switch device not knowing which port the recovery firmware is received from. Second, in step S22, the target switch device, which has an available communication connection with the host, acts as a relay to forward the recovery firmware, splitting the "host-to-current switch device" data transmission into two data transmissions: "host-to-target switch device" and "target switch device-to-current switch device." Given the definition of the target switch device, the "host-to-target switch device" path is known, enabling accurate distribution of the host recovery firmware. Furthermore, since the target switch device is directly connected to the current switch device and its interconnected port is known, the "target switch device-to-current switch device" path is unique and known, allowing the recovery firmware forwarded by the target switch device to accurately reach the current switch device. Consequently, the current switch device can complete its own firmware recovery based on the received recovery firmware.

[0076] As can be seen from the above, the firmware recovery method provided by the present invention in a switching device interconnection scenario can overcome the two major problems encountered when the host sends the recovery firmware to the switching device to be restored: port uncertainty and routing table damage, which make it impossible to ensure that the recovery firmware sent by the host can accurately reach the current switching device. Therefore, the application of this method can achieve a more automated switching device firmware recovery solution by sending the recovery firmware from the host. It is also suitable for firmware recovery of switching devices with only interconnected ports. In the scenario of multiple switching devices being interconnected, it has significant advantages in terms of high recovery efficiency and low implementation difficulty.

[0077] On the other hand, in a network of switching devices based on interconnected ports, in addition to the aforementioned switching devices that only have interconnected ports, there are also switching devices that include uplink ports, corresponding to the "Yes" branch of step S1. Therefore, this embodiment also provides an optional implementation for recovering these switching devices that include uplink ports after firmware corruption occurs.

[0078] like Figure 3 As shown, after the determination in step S1, the above method corresponds to the "yes" branch and further includes: S31: Designate an uplink port of the switching device as the port for loading recovery firmware.

[0079] S32: Communicate with the host through the loading port, obtain recovery firmware, and perform firmware recovery.

[0080] Step S31 follows the same principle as step S21 above. It also designates a port on the switching device as the loading port for receiving the recovery firmware, ensuring that the switching device with the firmware failure knows which port to use to receive the recovery firmware. However, unlike the aforementioned devices with only interconnect ports, switching devices with uplink ports connect directly to the host via the uplink port, resulting in a unique and deterministic transmission path between them. Therefore, in step S32, the switching device can communicate directly with the host via the loading port (i.e., the uplink port) to obtain the recovery firmware stored in the host for its own firmware recovery.

[0081] Based on the optional solutions provided in this embodiment, both types of switching devices (with or without uplink ports) in a network of interconnected switching devices have corresponding host-based firmware recovery solutions. Both of these firmware recovery solutions do not require manual reprogramming with a programmer, enabling a more automated firmware recovery for the entire switching device network.

[0082] Furthermore, regarding firmware recovery for a switch device with an uplink port, unlike a switch device with only interconnect ports, since it is directly connected to the host via the uplink port, the transmission path between it and the host is unique and known. Therefore, for recovery firmware containing an uplink port, the host does not need to actively send it. This embodiment also provides another optional implementation scheme: The above step S32 specifically includes: S321: Communicate with the host through the loading port to obtain the address where the recovery firmware is stored in the host.

[0083] S322: Initiate a direct memory access operation to the host according to the address, and directly read the recovery firmware from the host memory.

[0084] In actual applications, the host used to restore the switch device firmware typically stores the corresponding recovery firmware in memory for easy access later. Therefore, in this embodiment, the switch device with an uplink port can obtain the host's address (memory address) where the recovery firmware is stored through communication with the host. It can then initiate a Direct Memory Access (DMA) operation to the host, thereby automatically retrieving the corresponding recovery firmware stored in the host. This eliminates the need for the host to actively send the firmware, thus reducing the host's load.

[0085] It should also be noted that the reason why this embodiment communicates with the host to obtain the firmware address through step S321 is that in actual applications, the host may store different recovery firmware for different switching devices. These different recovery firmware will be 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, there is no need to communicate to obtain the address first. The storage address of this unique recovery firmware can be pre-configured in the switching device, and in subsequent recovery, it can be directly obtained from the host memory based on this address. However, in actual applications, it is more common to have different recovery firmware corresponding to different switching devices, and firmware recovery in this scenario is also more flexible, and different switching devices can use different firmware.

[0086] On the other hand, as can be seen from the above embodiments, firmware recovery for a switch device with only interconnected ports requires that the switch device have a target switch device that is directly connected to it and has a usable communication connection with the host. This places additional requirements on firmware recovery. In actual applications, not all switches with damaged firmware will have a target switch device that meets the above conditions.

[0087] To solve the above problem, this embodiment further provides an optional implementation scheme, which further includes the following steps for the above step S21: S211: If none of the switching devices interconnected with the current switching device through ports satisfies the condition of having an available communication connection with the host, any switching device located one level above the current switching device in the switching device network is designated as the target switching device.

[0088] S212: Designate the interconnection port connected to the target switching device in the current switching device as the loading port.

[0089] The switching device network determines its level by the distance between the switching device and the host. A switching device directly connected to the host is a first-level switching device, and a switching device indirectly connected to the host via an N-1th-level switching device is an Nth-level switching device, where N is any positive integer greater than 1. It should also be noted that the aforementioned levels are determined by the number of other switching devices included in the transmission path between the switching device and the host. Although this embodiment does not restrict the selection of a specific transmission path, in actual applications, to improve efficiency, the shortest transmission path to the host is preferably selected as the transmission path for determining the switching device level.

[0090] For example, Figure 6 Taking the switching device network shown as an example, assume that the firmware of switching devices 0-3 in the switching device network is damaged and needs to be restored. Based on the division of step S1 above, it can be seen that switching device 0 is a switching device with an uplink port, corresponding to the firmware recovery of steps S31-S32 above; switching devices 1-3 are switching devices with only interconnection ports, corresponding to the firmware recovery of steps S21-S22 above. Since the firmware of switching device 0 is also damaged, switching devices 1 and 2 do not have a target switching device that meets the conditions of step S21 above. Similarly, since switching devices 1 and 2 are damaged, switching device 3 does not have a target switching device that meets the conditions of step S21 above.

[0091] However, based on the solution provided in this embodiment, it can be determined as follows Figure 6 In the switching device network shown, switching device 0, which is directly connected to the host, is the first-level switching device defined above; switching devices 1 and 2, which are indirectly connected to the host through switching device 0, are the second-level switching devices 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 defined above.

[0092] Therefore, for the second-level switching devices 1 and 2, the first-level switching device 0 can be designated as the target switching device. At this time, since the switching device 0 is a switching device directly connected to the host through the uplink port, it can achieve firmware recovery through steps S31~S32. After the firmware of the switching device 0 is restored, the switching device 0 can be used as the target switching device that meets the conditions of the above-mentioned step S21, and the second-level switching devices 1 and 2 can achieve firmware recovery through steps S21~S22. Similarly, after the second-level switching devices 1 and 2 complete the firmware recovery, they can also be used as the target switching device that meets the conditions of the above-mentioned step S21, and at this time the third-level switching device 3 can also achieve firmware recovery through steps S21~S22. That is, for Figure 6 In the switching device network shown, the firmware recovery order of each switching device is: switching device 0 - switching devices 1 and 2 - switching device 3.

[0093] Thus, based on the hierarchical firmware recovery solution provided by this embodiment, regardless of the topology of the switching device network or the switching device failures within the switching device network, all switching devices with damaged firmware can be restored using the firmware recovery method provided by the present invention in a switching device interconnection scenario. Specifically, based on the proximity of each switching device to the host, the devices are restored in order from nearest to farthest. After the upper-level switching device completes firmware recovery, it can serve as the target switching device for the lower-level switching device, helping the lower-level switching device to achieve firmware recovery, thereby achieving firmware recovery for the entire switching device network.

[0094] Furthermore, it can be seen from the description of the relevant technical part that for switching devices that are networked through interconnected ports, they do not have fixed routing relationships like hierarchical networking. Therefore, it is necessary to store the routing table programmed by the user in the switching device. And in general application scenarios, the routing table and firmware are both stored in the non-volatile storage medium Flash of the switching device, so when the firmware is damaged, it can be regarded as equivalent to the routing table being damaged. Through the method provided in the above embodiment, the firmware can be restored, but as for how to restore the damaged routing table, the simplest way is to send another routing table based on the transmission path of the restored firmware. However, since the switching devices at the second level and later levels in the switching device network need to be forwarded by the previous level switching device to complete the firmware recovery, this routing table will pass through other switching devices. In particular, when other switching devices also implement firmware recovery based on the above method and also have the problem of routing table damage, how to distinguish whether the transmitted routing table is for themselves becomes a key issue in routing table recovery.

[0095] In view of this, this embodiment provides an optional implementation scheme. After step S21, the above method further includes: S23: Using the target domain code carried in the first message packet received through the loading port as the target domain code of the current switching device.

[0096] The target domain code is a globally unique code in the switching device network.

[0097] S24: When the routing table is received through the loading port, determine 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, go to step S25; if not, go to step S26.

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

[0099] S26: 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.

[0100] It should be noted that the target domain code is a newly defined parameter in this embodiment. As a globally unique code within the switching device network, it can be used to distinguish different switching devices within the switching device network. Therefore, when transmitting a routing table, the server can determine whether the routing table is the one it needs to update based on whether the target domain code carried in the routing table matches its own target domain code. Furthermore, the target domain code setting can also be used to determine routing. Specifically, if a routing table is determined not to be its own, the server can determine to which next-level switching device the routing table should be sent.

[0101] For example, Figure 6 Taking the switching device network shown in the figure as an example, assume that the target domain codes (domain IDs) corresponding to switching devices 0 through 3 are also 0 through 3. Suppose the current host sends a routing table with domain ID 1, indicating that this routing table is for switching device 1.

[0102] The routing table sent by the host first passes through switch 0. Switch 0 compares the domain ID and finds that the routing table is not its new routing table. At this point, there are two possible solutions: First, assume that Switch 0 already has a routing table, meaning that its routing table also uses a hierarchical recovery scheme. In this case, Switch 0 can determine, based on the domain ID 1 in its routing table and its own routing table, that this routing table corresponds to Switch 1. Therefore, Switch 0 routes this routing table to Switch 1.

[0103] Second, assume that switching device 0 does not have a routing table. In this case, switching device 0 can directly forward the routing table to the next-level switching device. The next-level switching device then determines whether the routing table is its own based on its domain ID. If so, it restores the routing table and forwards it to the next level. If not, it forwards it to the next level. This layer-by-layer forwarding process ensures that the routing table reaches the corresponding switching device, completing the setup and restoration of its routing table.

[0104] However, it should be noted that both of the above options require each switch to know its own target domain code, which also limits the implementation of batch recovery of switches in a multi-switch interconnection scenario. Therefore, this embodiment also provides a targeted solution for setting and restoring the target domain code, namely steps S23 and S26.

[0105] Based on the aforementioned role of the target domain code, it can be seen that the target domain code also needs to be persistently stored locally on the switching device, specifically in the non-volatile storage medium Flash within the switching device. Furthermore, since the present invention addresses the recovery of switching device firmware after firmware damage, firmware damage is equivalent to the loss of the target domain code, also stored in Flash. Therefore, the issue of how to specify the target domain code after firmware recovery is addressed in step S26 of this embodiment.

[0106] 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, and then sends the target domain code carried in the 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 and completes the setting or restoration of the target domain code 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 downward, continuing to trigger the recovery of the routing table and the setting of the target domain code of the next level.

[0107] It should be noted that if there are multiple lower-level switching devices during the execution of step S26, to ensure the uniqueness of the target domain code, one of them may be selected to send the target domain code. This selection may be random or based on arbitrary selection rules, and this embodiment does not impose any restrictions on this. Based on the host continuously sending routing tables with different target domain codes, after the above steps of this embodiment are continuously repeated in different levels of switching devices, all switching devices in the switching device network will eventually complete the setting or restoration of the target domain code and routing table.

[0108] Furthermore, regarding the target domain code in the above embodiment, since it is a new parameter defined in the above embodiment, it is not a parameter defined in the PCIe protocol and is not included in the standard transaction layer packet (TLP). Therefore, how to implement the sending of the target domain code through a message packet in step S26 is unknown. This embodiment provides an optional implementation scheme: The above step S26 is specifically as follows: S26-A: The target domain code is carried through the transaction layer packet prefix in the message packet.

[0109] That is, in this embodiment, the destination domain code is carried by a transaction layer packet prefix (Prefix) in the PCIe protocol. Specifically, the message packet may be a message packet for sending a routing table or other request packet.

[0110] In addition, this embodiment also provides another optional implementation scheme: The above step S26 is specifically as follows: S26-B: Send the transaction layer packet containing the target domain code to the next-level switching device.

[0111] That is, this embodiment sends a TLP packet with the target domain code as the data to be transmitted before transmitting the routing table message packet or other request packet to the next-level switching device. This ensures that the target domain code is set before the routing table arrives, avoiding the problem that the switching device cannot determine whether the routing table corresponds to itself due to the lack of the target domain code, and thus does not know how to proceed.

[0112] It should be noted that the two target domain code transmission methods provided in the above embodiments both enable the transmission of the target domain code as a newly defined parameter between switching devices. Alternatively, other existing data transmission methods can be used to transmit the target domain code within the switching device, which will not be detailed in this embodiment. In actual applications, the appropriate implementation method can be freely selected based on specific needs, and this embodiment does not impose any restrictions thereon.

[0113] On the other hand, based on the above embodiments, it can be seen that the firmware recovery method provided by the present invention in a switching device interconnection scenario can achieve firmware recovery for all switching devices in a switching device network based on interconnected port networking. Moreover, this recovery can be achieved by sending recovery firmware from a host, which greatly improves the degree of automation compared to manually reprogramming switching devices with damaged firmware one by one using a programmer. However, the automated implementation of the above method requires some "configuration", such as the designation of 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 damaged firmware, this information cannot be pre-stored or obtained through communication with external devices, and must be determined through configuration information.

[0114] In the current structure of switching devices, there are configuration pins for implementing startup configuration of the switching device. This embodiment expands the configuration pins and provides an optional implementation scheme: The switching device includes a first configuration pin, wherein the first configuration pin is used to configure the loading of recovery firmware from an uplink port or an interconnection port.

[0115] Then the above step S1 specifically includes: S11: If the first configuration pin is configured to load the 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.

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

[0117] Specifically, this embodiment extends the configuration pins in the switching device, using a first configuration pin to specify whether to load the recovery firmware from the uplink port or the interconnection port (which is equivalent to specifying the port type of the loading port, or specifying whether the current switching device is a switching device with only interconnection ports). This allows the determination in step S1 to be performed even when the switching device firmware is damaged. Furthermore, this embodiment implements the aforementioned "designation" based on a configuration method, pre-positioning any additional work required before the actual firmware recovery. This provides more margin for firmware recovery, improves firmware recovery efficiency, and reduces the difficulty of implementing the firmware recovery solution.

[0118] Similarly, from the above embodiment, it can be seen that in order to implement firmware recovery, it is necessary to clearly specify the port for loading the recovery firmware. In addition to specifying the type of loading port based on the configuration method 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: The switching device further includes a second configuration pin, wherein the second configuration pin is used to configure the port number of the loading port.

[0119] Accordingly, when an interconnection port / uplink port of the switching device is designated as a loading port for the recovery firmware in step S21 and step S31, the steps specifically include: According to the port number configured by the second configuration pin, the corresponding port is used as the loading port; according to the configuration of the first configuration pin, the loading port is initialized as the interconnection port / uplink port.

[0120] It should be noted that, since the firmware of the current switching device is damaged, it does not know which ports are interconnection ports and which ports are uplink ports. In this embodiment, the implementation of firmware recovery only focuses on the loading port that loads the recovery firmware. For other ports, their port types can be known after the firmware is restored, so this embodiment will not discuss them. Based on the first configuration pin of the previous embodiment, the type of the loading port can be determined. However, which port in the switching device is the loading port still needs to be specified. In this embodiment, the port number of the loading port is specified by the second configuration pin, that is, a unique port is determined 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, so that the loading port can perform its function normally and receive the recovery firmware to achieve firmware recovery.

[0121] Similar to the previous embodiment, this embodiment also converts the designation of the loading port into a pre-configuration step by expanding existing configuration pins. This ensures that a switch device with damaged firmware can clearly identify which internal port is the loading port. Furthermore, this step, which is difficult to automatically implement, is moved to the preparatory stage before the actual firmware recovery process, improving firmware recovery efficiency and reducing the difficulty of implementing the firmware recovery solution.

[0122] It should also be noted that the first configuration pin and the second configuration pin do not necessarily include only one pin, but may also be a group of pins set to implement complex functions that cannot be implemented by a single pin. In an alternative embodiment, the first configuration pin and the second configuration pin may be integrated into the configuration function of the load port and implemented through a configuration pin group. Figure 4 and Figure 5 As shown, configuring the loading port at least requires configuring the type and port number of the loading port, so that the loading port is uniquely determined and can receive the recovery firmware.

[0123] Furthermore, in addition to the configuration work of the above two embodiments, the other steps of this embodiment can be automated by writing scripts or programs. Specifically, this embodiment provides an optional implementation scheme for how to achieve this: The above-mentioned switching device includes a third configuration pin; the third configuration pin is used to configure a firmware stored in the first storage medium as the startup firmware.

[0124] The first storage medium is a storage medium in the switching device for storing firmware.

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

[0126] When the default firmware is executed, it is used to achieve the following: determine whether the switching device to be restored currently has an uplink port connected to the host; wherein the host stores the recovery firmware; if not, designate an interconnection port of the switching device as a loading port for the recovery firmware; wherein the target switching device connected to the designated interconnection port has an available communication connection with the host; receive the recovery firmware forwarded by the target switching device through the loading port, and perform firmware recovery.

[0127] It should be noted that the third configuration pin in this embodiment is not necessarily a new pin. Existing switching devices may store multiple different firmware programs (i.e., multiple user firmware programs) in their Flash memory. In this case, the configuration pin is currently used to select which user firmware program is loaded into the random access memory (RAM) during startup for execution by the central processing unit (CPU).

[0128] Therefore, the third configuration pin in this embodiment can be obtained by expanding the configuration pin for selecting the boot firmware described above. Specifically, the expansion selects one of all user firmwares as the boot firmware, expanding it to select one of all user firmwares and the default firmware as the boot firmware. When the default firmware is selected as the boot firmware, it indicates that the switching device has experienced firmware corruption and requires firmware recovery using the above-mentioned method. It is easy to understand that if the switching device does not have firmware corruption, the third configuration pin can be configured to select a specific user firmware for boot, thereby specifically recovering the firmware of switching devices in the switching device network that have experienced firmware corruption.

[0129] Furthermore, the default firmware in this embodiment is used to implement all the method steps implemented on the switching device side in the above-described embodiments, excluding the configuration of the first, second, and third configuration pins. This includes at least the aforementioned steps S11, S12, S22-S26, S32, and their further derived specific embodiments. Furthermore, all other parts of steps S1, S21, and S31, excluding the manual configuration of the pins, such as how to identify the status of the configuration pins and determine their configuration, are also implemented when the default firmware is executed. Furthermore, the default firmware is also used to implement steps not described in the above-described embodiments but necessary for normal switching device startup.

[0130] Furthermore, since the default firmware must be selected as the startup firmware to execute after the switch is powered on, automating the above method, the default firmware must be stored in the switch's internal flash memory along with other firmware (i.e., user firmware). Therefore, firmware corruption also means that the default firmware may also be corrupted.

[0131] Although the default firmware only occupies a portion of the Flash memory, it is only probabilistic that the default firmware will also be damaged when the firmware is damaged. However, if this event occurs, it is impossible to achieve a more automated firmware recovery using this method, so it should be avoided as much as possible. Based on this, this embodiment further provides an optional implementation scheme: The default firmware is stored in a target area in the first storage medium, wherein the modification authority of the target area in the first storage medium is limited to allowing only a programmer to modify it.

[0132] As can be seen from the above related technical description, the main cause of current switching device damage is interrupted or incorrectly updated firmware due to abnormalities during the update. The probability of physical damage to the Flash memory causing damage to the stored firmware is low, and this situation is considered force majeure. Once the Flash memory, which carries the firmware program, is damaged, the firmware cannot be restored until it is replaced with a new Flash memory. Therefore, this embodiment does not consider this situation and only discusses the firmware damage scenario caused by incorrect firmware updates.

[0133] Because the default firmware in this method is the firmware program used to implement the aforementioned firmware recovery method, its functionality is fixed and its stability is strong. That is, the default firmware used by all switching devices can be identical, and changes in the default firmware program or code due to version updates or other operations that change with user needs are not expected. Based on this characteristic, this embodiment employs a segmented design for the first storage medium (i.e., Flash memory), dividing it into a storage area that allows free user editing and a target area that restricts user editing and only allows modification by a programmer. The user firmware is stored in the storage area to meet user firmware update needs. The default firmware is stored in the target area, which restricts user modification, thereby preventing default firmware corruption due to erroneous firmware updates. In other words, when the default firmware is stored in the target area, which restricts user editing, even if firmware corruption occurs, it can be reasonably assumed that only the user firmware is corrupted, while the default firmware is intact. The aforementioned method can still be automated, further improving the reliability of the method.

[0134] On the other hand, based on the above embodiment, in order to better illustrate the specific implementation of this method. This embodiment also provides an optional internal implementation structure of the switching device, such as Figure 7 As shown (taking a switching device including an uplink port as an example, a switching device having only interconnection ports has the same structure after removing the uplink port), a switching device includes: Read-Only Memory (ROM): This is used to store the most basic boot program. This program needs to include the program that reads the configuration through the configuration pins and the program that controls the Flash controller to load the firmware from the Flash media into Random Access Memory (RAM) and run it.

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

[0136] Flash: The non-volatile storage medium inside the switching device, used to store firmware programs, including user-defined user firmware and default firmware. It should be noted that the default firmware is the firmware program newly added to the Flash in this embodiment. The specific function and implementation scheme will be described later.

[0137] Configuration pins: These pins are used to configure the switching device's startup state by changing the pin's high or low level. For example, they can be used to select which user firmware stored in Flash memory the switching device boots from. Based on the above embodiments, the present invention requires configuration pins, in addition to the pins that implement the existing configuration functions, to include at least the first, second, and third configuration pins described in the above embodiments (this can be achieved by expanding the existing startup firmware selection configuration pins).

[0138] It should be noted that Figure 7 The illustrated switching device structure is a common internal structure for switching devices. The ROM, RAM, CPU, Flash, and Flash controller are all common internal components of switching devices. This embodiment does not modify these components, so a detailed description is omitted. The key point is that this embodiment adds a new firmware program to the Flash memory: the default firmware. Furthermore, this embodiment expands the functionality of the configuration pins used to select the boot firmware, now including the default firmware. Furthermore, the first and second configuration pins, as expanded in the above-mentioned embodiments, are also included.

[0139] based on Figure 7 The present embodiment further describes the above-mentioned several different switching device firmware recovery processes. 1. First-level switching equipment (or switching equipment that includes uplink ports, switching equipment that is directly connected to the host through uplink ports, etc.).

[0140] This switching device corresponds to Figure 5 Specifically, a complete process from initialization to power on the switching device and then to firmware recovery is as follows: Figure 5 As shown, it includes the following two stages.

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

[0142] Firmware recovery phase: ① The CPU inside the switch executes the program in the ROM, which reads the firmware selection configuration in the configuration pins.

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

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

[0145] ④ The default firmware initializes port 2 as an upstream port based on the configuration pins and establishes a PCIe link with the host. The CPU then interacts with the host to obtain the address where the host stores the firmware to be restored. After obtaining the address, the CPU initiates a DMA operation to the host according to the above address, obtains the firmware to be restored from the host memory and places it in RAM.

[0146] In addition, as an alternative to this solution, the CPU can also declare that the switching device has an accessible space when initializing the link, and point the accessible space to RAM by configuring the decoder. The host then actively writes the firmware to be recovered into this space (that is, it is actually written to RAM).

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

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

[0149] 2. N-1th level switching device (in this embodiment, the N-1th level switching device is defined as a switching device having only interconnection ports, but it already has a target switching device that meets the conditions of step S21).

[0150] This switching device corresponds to Figure 4 The switching device 1 in the embodiment (switching device 0 is the target switching device of switching device 1), and steps S21 to S22 provided in the above embodiment. Specifically, a complete process from initialization to powering on the switching device and then restoring the firmware is as follows: Figure 4 As shown, it includes the following two stages.

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

[0152] Firmware recovery phase: ① The CPUs of swap devices 0 and 1 first execute a program from ROM, which reads the firmware selection from the configuration pins.

[0153] ②Switch device 0 and switch device 1 read the user firmware and default firmware from Flash to RAM respectively.

[0154] ③ Switch 0 executes the user firmware, which initializes port 2 as an uplink port and port 4 as an interconnect port. Switch 0 waits for a PCIe connection to be established with the host and adjacent chips. Switch 1 executes the default firmware, which initializes port 9 as an interconnect port based on the configuration pins and then waits for a connection to be established with Switch 0. This link requires a crosslink as defined in the PCIe protocol.

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

[0156] ⑤ 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 to be restored for switch device 1.

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

[0158] It can be seen from the above embodiment that when the switching device uses the default firmware, the domain ID of this device should be considered to be an uninitialized value in the initial state. In this state, when the switching device receives the first message packet from the interconnection port specified by the configuration pin, it should be considered that the message packet is received by itself, and its own domain ID is set as the target ID of the message packet. Subsequent packets with a target ID of the domain ID are processed by the device without the need to look up the routing table and route them outward. The message packet sent by switching device 0 needs to be informed to switching device 1, and the user firmware and basic information such as the length of the firmware will be sent later. After receiving the message packet, switching device 1 will prepare RAM space for receiving the firmware.

[0159] ⑦ The CPU of switch device 0 initiates a DMA operation to the host at the address provided by the host in step ⑤, retrieves the firmware to be restored from the host memory, and forms a series of message packets that are sent out through port 4. These message packets eventually reach 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.

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

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

[0162] 3. Nth-level switching device (in this embodiment, the Nth-level switching device is defined as a switching device having only interconnection ports and no target switching device meeting the conditions of step S21, that is, a switching device requiring hierarchical recovery).

[0163] This switching device corresponds to Figure 6 Switching device 3 in the example (switching device 0 is the first level; switching devices 1 and 2 are the second level; switching device 3 is the third level), and steps S211, S212, and S22 provided in the above embodiment. Specifically, a complete process from initialization to powering on the switching device and then restoring the firmware is as follows: Figure 6 As shown, it includes the following two stages.

[0164] Initialization (configuration) phase: By configuring the configuration pins of switch device 3, choose to load the default firmware in the Flash; choose to load the firmware to be restored from the interconnection port; and configure the port number of the interconnection port (which can be the port number of any port connected to switch device 1 or 2).

[0165] ① Complete the firmware recovery of switch device 0 through the aforementioned firmware recovery process 1.

[0166] ② The host configures a complete routing table for switch device 0 after the firmware is restored, that is, the egress port numbers of all target domain IDs in the network.

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

[0168] The steps of setting the domain ID and the routing table correspond to steps S23 to S26 in the above embodiment.

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

[0170] ⑤Same as step ③, but restore the firmware and set the domain ID for switching device 2.

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

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

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

[0174] Among them, switching device 1 does not need to forward the data packet by the CPU like switching device 0. Instead, after receiving the data packet with the target domain ID as 3, it knows that the final target is not itself, and then searches the routing table to obtain the egress port of the target domain ID, and then sends the message packet out from the egress port and finally reaches switching device 3.

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

[0176] Among them, the switching device 1 is the same as step ⑦, and only needs to play the role of routing. It should be noted that Figure 6 Step ⑧ uses a different path from step ⑦. The purpose is only to illustrate the difference between steps ⑦ and ⑧. Figure 6 In the scenario shown, there are two different paths (i.e., through switch 1 or 2) to reach switch 3, depending on how the routing table in switch 0 is configured. However, in general, the path used in steps 7 and 8 needs to be the same.

[0177] In addition to the embodiments of the firmware recovery method for interconnected switching devices provided in the above embodiments, the present invention also provides corresponding embodiments of a computer program product. The computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the firmware recovery method for interconnected switching devices described in any of the above embodiments.

[0178] Since the embodiments of the computer program product part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the computer program product part, and will not be repeated here.

[0179] The above embodiments describe in detail a firmware recovery method for interconnected switching devices. The present invention also provides a corresponding embodiment of a firmware recovery apparatus for interconnected switching devices. It should be noted that the present invention describes the apparatus embodiments from two perspectives: one based on functional modules and the other based on hardware.

[0180] Based on the perspective of functional modules, this embodiment provides a firmware recovery device in a switching device interconnection scenario, such as Figure 8 Shown, including: The type determination module 11 is used to determine whether the switching device to be restored currently has an uplink port connected to the host; if not, the port determination module is triggered; wherein the host stores the restoration firmware.

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

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

[0183] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, and they will not be repeated here.

[0184] 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 as follows: Figure 9 As shown, a firmware recovery device in a switching device interconnection scenario includes: a memory 20 for storing computer programs.

[0185] The processor 21 is configured to implement the steps of the firmware recovery method in a switching device interconnection scenario in the above embodiment when executing a computer program.

[0186] The firmware recovery device in the switching device interconnection scenario provided in this embodiment mainly refers to the switching device, and may also refer to a control device in the switching device, or other devices or components additionally deployed in the switching device with a control function.

[0187] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0188] 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, flash memory storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201, wherein, after the computer program is loaded and executed by the processor 21, it can implement the relevant steps of a firmware recovery method in a switching device interconnection scenario disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, 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, etc.

[0189] 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 .

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

[0191] An embodiment of the present invention provides a firmware recovery device in 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 in a switching device interconnection scenario.

[0192] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiment.

[0193] It is understood that if the methods in the above embodiments are implemented in the form of 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, or the portion 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 each embodiment of the present invention. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0194] The above is a detailed introduction to the firmware recovery method, device, program product and medium in a switching device interconnection scenario provided by the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in several ways, and these improvements and modifications also fall within the scope of protection of the present invention.

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

Claims

1. A method for restoring firmware in a switching device interconnection scenario, characterized in that: include: Determining whether the switching device to be restored currently has an uplink port connected to a host; wherein the host stores recovery firmware; If not, designate an interconnection port of the switching device as a loading port for the recovery firmware; wherein a target switching device connected to the designated interconnection port has an available communication connection with the host; 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 device interconnection scenario according to claim 1, characterized in that: After determining whether the switching device to be restored currently has an uplink port connected to the host, the method further includes: If so, designating an uplink port of the switching device as a loading port for the recovery firmware; Communicate with the host through the loading port, obtain the recovery firmware, and perform firmware recovery.

3. The firmware recovery method in a switching device interconnection scenario according to claim 2, characterized in that: The step of designating an interconnection port of the switching device as a loading port for the recovery firmware includes: If none of the switching devices interconnected with the current switching device through ports satisfies the condition of having an available communication connection with the host, then designating any switching device located one level above the current switching device in the switching device network as the target switching device; designating an interconnection port in the current switching device connected to the target switching device as the loading port; Among them, the level of the switching device network is determined by the distance between the connection position relationship between the switching device and the host; the switching device directly connected to the host is a first-level switching device, and the switching device indirectly connected to the host through the N-1th level switching device is an N-level switching device, where N is any positive integer greater than 1.

4. The firmware recovery method in a switching device interconnection scenario according to claim 3, characterized in that: After designating an interconnection port of the switching device as a loading port for the recovery firmware, the method further includes: Using the target domain code carried in the first message packet received through the loading port 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, determining 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 yes, the received routing table is saved locally; If not, after the interconnection link with the switching device at the next level is established, the target domain code carried in the routing table is sent to the switching device at the next level via a message packet.

5. The firmware recovery method in a switching device interconnection scenario according to claim 4, characterized in that: The sending of the target domain code carried in the routing table to the switching device at the next level via a message packet includes: The target domain code is carried by a transaction layer packet prefix in the message packet.

6. The firmware recovery method in a switching device interconnection scenario according to claim 4, characterized in that: The sending of the target domain code carried in the routing table to the switching device at the next level via a message packet includes: The transaction layer packet containing the target domain code is sent to the switching device at the next level.

7. The firmware recovery method in a switching device interconnection scenario according to claim 2, characterized in that: Communicating with the host through the loading port to obtain the recovery firmware includes: Communicate with the host through the loading port to obtain the address of the host where the recovery firmware is stored; A direct memory access operation is initiated to the host according to the address, and the recovery firmware is directly read from the host memory.

8. The firmware recovery method in a switching device 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 the recovery firmware to be loaded from the uplink port or the interconnection port; Determining whether the switching device to be restored currently has an uplink port connected to the host includes: If the first configuration pin is configured to load the recovery firmware from the uplink port, determining 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 the recovery firmware from the interconnection port, it is determined that the switching device to be currently recovered does not have an uplink port connected to the host.

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

10. The firmware recovery method in a switching device interconnection scenario according to any one of claims 1 to 9, 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 a startup firmware; Wherein, the first storage medium is a storage medium in the switching device for storing firmware; The first storage medium includes: default firmware and user firmware; When executed, the default firmware is used to achieve: determining whether the switching device to be restored currently has an uplink port connected to the host; wherein the host stores the recovery firmware; if not, designating an interconnection port of the switching device as a loading port for the recovery firmware; wherein an available communication connection exists between the target switching device connected to the designated interconnection port and the host; receiving the recovery firmware forwarded by the target switching device through the loading port, and performing firmware recovery.

11. The firmware recovery method in a switching device interconnection scenario according to claim 10, characterized in that: The default firmware is stored in a target area in the first storage medium; The modification authority of the target area in the first storage medium is limited to allowing only a programmer to modify it.

12. A firmware recovery device in a multi-switch device interconnection scenario, characterized in that: include: A type determination module is used to determine whether the switching device to be restored currently has an uplink port connected to the host; If not, triggering the port determination module; wherein the host stores recovery firmware; The port determination module is configured to designate an interconnection port of the switching device as a loading port for the recovery firmware; wherein a target switching device connected to the designated interconnection port has an available communication connection with the host; 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.

13. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the firmware recovery method in the switching device interconnection scenario according to any one of claims 1 to 11 are implemented.

14. A firmware recovery device in a multi-switch device interconnection scenario, characterized in that: include: memory for storing computer programs; A processor is configured to implement the steps of the firmware recovery method in a switching device interconnection scenario according to any one of claims 1 to 11 when executing the computer program.

15. 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 a switching device interconnection scenario according to any one of claims 1 to 11.

Images