A network card firmware hot patch method, a storage medium and an electronic device

Abstract

This invention relates to the field of network interface card (NIC) firmware repair and upgrade, and particularly to a method for hot-patching NIC firmware, a storage medium, and an electronic device. The method receives a patch file and loads it into the reserved area of ​​the NIC's SRAM, executes address acquisition logic to generate a patch symbol table, matches the function jump table to determine the function to be updated, and updates the address pointing information to point to the target function code in the SRAM, thus achieving indirect calling based on the jump table. This invention solves the problem of wasted memory resources through function-granular updates, ensures accurate addresses through dynamic symbol table matching, and achieves seamless service switching through the indirect calling mechanism without requiring device restarts, thereby improving the continuity and reliability of network services.

Description

Technical Field

[0001] This invention relates to the field of network card firmware repair and upgrade, and in particular to a network card firmware hot patching method, storage medium, and electronic device. Background Technology

[0002] With the rapid development of cloud computing and data center technologies, the stability and flexibility of the firmware of SmartNICs, as core components of server network interaction, are crucial. In practical applications, NIC firmware often needs to be extended to meet specific business requirements or to fix logical defects discovered during operation (bugfix). To ensure high availability of upper-layer services, firmware upgrades are typically required to be completed without interrupting network connections or restarting the server, i.e., achieving "hot patch" updates. Therefore, how to achieve efficient and accurate online firmware updates in memory-constrained embedded environments has become a key problem that urgently needs to be solved in this field.

[0003] Existing network interface card (NIC) firmware update technologies typically employ either full replacement or module-level replacement. In traditional methods, even fixing a minor function logic error often requires recompiling and loading all functions corresponding to the entire source code file (.c file) into memory. This necessitates reserving jump addresses or backup space in memory for all functions of the entire module, even if most of these functions remain unchanged.

[0004] However, the aforementioned existing technology has significant technical drawbacks. The coarse-grained update method results in a large amount of unmodified function code or jump table entries occupying the valuable, limited on-chip static random access memory (SRAM) resources, causing serious memory waste, which is unacceptable for network card firmware with extremely small memory capacity. Summary of the Invention

[0005] To address one of the aforementioned technical problems, the present invention adopts the following technical solution:

[0006] According to one aspect of the present invention, a method for hot-patching network interface card firmware is provided, comprising the following steps:

[0007] It receives patch files for modules to be updated in the network interface card's (NIC) basic firmware and parses and loads these patch files into the reserved area of ​​the NIC's SRAM. The patch files contain the updated target function code and preset address acquisition logic.

[0008] While the patch file is being loaded, a pre-defined address retrieval logic is executed to obtain the names of all functions contained in the module to be updated and their current execution addresses in SRAM, generating a patch symbol table. The patch symbol table records the correspondence between module names, function names, and execution addresses.

[0009] The patch symbol table is matched with the function jump table to determine the names of the functions that need to be updated in the function jump table. The function jump table stores the correspondence between the function names and addresses of certain functions in the base firmware, some of which are functions marked as supporting hot patching in the source code.

[0010] In the initial state, the address information corresponding to each function name in the function jump table is set to the storage address of the original function in the basic firmware.

[0011] Based on the name of the function to be updated, update the address pointing information in the function jump table so that it points to the storage address of the updated target function code in SRAM.

[0012] In response to a call request to the target function, the system jumps to SRAM based on the updated function jump table to execute the corresponding code.

[0013] According to a second aspect of the present invention, a non-transitory computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the above-described network interface card firmware hot patching method.

[0014] According to a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method for hot-patching network interface card firmware.

[0015] This invention has at least one of the following beneficial effects:

[0016] First, this invention effectively solves the memory resource waste problem caused by coarse-grained module replacement in existing technologies by constructing a function jump table containing only a subset of specific functions and updating address pointer information at the function granularity level based on this table. In traditional technical solutions, to support hot patching, it is often necessary to mark all functions in the entire source code file as replaceable or reserve redundant jump space in memory for the entire module, even if only a small function logic needs to be repaired. In contrast, this invention identifies specific functions marked as supporting hot patching during the basic firmware compilation stage and stores the correspondence between the function names and address pointer information of these specific functions only in the function jump table. When updating the firmware, the system only needs to modify the address pointer information corresponding to the specific function in the jump table to point to the updated target function code in SRAM, without touching other unchanged functions within the same module. This fine-grained control mechanism eliminates the need to store a large number of jump table entries or backup code for irrelevant functions in memory, significantly reducing the occupation of valuable SRAM resources of the network card firmware by the hot patching mechanism, making flexible hot updates possible on embedded devices with extremely limited memory.

[0017] Secondly, in this invention, while the patch file is loaded into the SRAM reserved area, the built-in address acquisition logic is automatically executed to scan the modules to be updated in real time, extract the current running addresses of all functions, and generate a patch symbol table. Subsequently, the system uses the module name and function name in this table as key indexes to perform precise matching with the function jump table in the basic firmware. This mechanism of dual matching (module name + function name) based on a dynamically generated symbol table at runtime ensures that the name of the function to be updated in the function jump table can be accurately located and the correct target address can be obtained. This achieves precise and fast redirection from the original function to the patch function, avoiding system crashes or functional abnormalities caused by address resolution errors.

[0018] Furthermore, this invention achieves seamless switching of business logic through an indirect call mechanism based on a function jump table, solving the problem of needing to restart the device or interrupt business flow during traditional firmware updates. In existing technologies, network card firmware updates often require updating a complete firmware, and the entire firmware needs to be restarted to take effect. This breaks the original call chain, leading to business interruptions such as data loss, requiring a system restart to re-establish the connection. In contrast, this invention initially sets the address pointers of the function jump table to point to the original function in the base firmware. During system operation, in response to a call request to the target function, indirect jumps are always performed based on the function jump table. When an update is needed, only the address pointer information in the jump table needs to be updated in the background, changing it from the original address to the updated target function code address in SRAM. Since the caller always relies on the jump table rather than absolute addresses, this pointer modification operation is transparent to upper-layer business operations, allowing for instant switching between old and new code without restarting the network card or interrupting the flow of processing data packets. This mechanism not only ensures the real-time performance of single-function firmware extensions or defect repairs but also greatly improves the continuity and reliability of data center network services. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0020] Figure 1 A schematic diagram illustrating a network card firmware hot patching method provided in an embodiment of the present invention;

[0021] Figure 2 This is a schematic diagram illustrating the automated generation of the basic symbol table provided in an embodiment of the present invention;

[0022] Figure 3 A swimlane diagram illustrating a PCIe-based network card firmware hot reboot method provided in an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of the system architecture of a PCIe-based network card firmware hot reboot method provided in an embodiment of the present invention. Detailed Implementation

[0024] 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 skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] As one possible embodiment of the present invention, such as Figure 1 As shown, a method for hot-patching network card firmware is provided. This method can be applied to embedded network devices such as smart network cards, and aims to solve the problem of excessive memory usage caused by traditional firmware upgrades requiring device restarts or full replacements.

[0026] This solution involves three main logical storage areas: the basic firmware runtime area (corresponding to mem1 in the diagram), the patch file persistent storage area (corresponding to Flash memory in the diagram), and the patch code dynamic loading and execution area (corresponding to mem3 as a temporary parsing buffer and mem2 as the final code execution area in the diagram). The basic firmware and its core scheduling logic reside permanently in mem1; patch files are initially uploaded and stored in the Flash area via a host-side command-line tool (such as yuncli update) to ensure persistence and prevent data loss; when executing update commands (such as yuncli switch), the firmware kernel reads the patch from Flash to mem3 for parsing and relocation, and finally loads it into the specific execution slot in mem2 for execution. mem1, mem2, and mem3 are all memory partitions on SRAM.

[0027] Specifically, this embodiment includes the following steps:

[0028] S1: Receives the patch file for the module to be updated in the network card's basic firmware and parses and loads the patch file into the reserved area of ​​the network card's SRAM. The patch file contains the updated target function code and the preset address acquisition logic.

[0029] In this step, the user uses a command-line management tool on the host (e.g., Figure 1 The `yuncli update` command (as shown) distributes the compiled patch file to the network card. This patch file is first written to the network card's Flash memory for persistent storage. Upon receiving an activation command (such as `yuncli switch`), the network card firmware kernel reads the patch file from the Flash and loads it into the temporary parsing area of ​​SRAM (i.e., the mem3 area in the diagram) for preprocessing.

[0030] Specifically, the patch file is a relocatable executable linker (ELF) file. Since the patch file is compiled independently of the base firmware, the addresses of the base firmware functions it calls (such as hardware register operations and memory allocation interfaces) are unknown at compile time, resulting in "undefined symbols." Therefore, before the step in S1 where the patch file is parsed and loaded into the reserved area of ​​the network card's SRAM, the method also includes an automatic repair process for patch dependencies to ensure that the patch can be correctly "hooked" to the base firmware. The specific steps are as follows:

[0031] Before the step of parsing and loading the patch file in the reserved area of ​​the network card's SRAM in S1, the method also includes:

[0032] S1.1: Read undefined symbols from the patch file.

[0033] The firmware loader parses the ELF file header and extracts all symbol names marked as undefined. These symbols represent external functions or variables that the patch depends on.

[0034] S1.2: Query the basic symbol table to obtain the actual memory address corresponding to the undefined symbol.

[0035] The basic symbol table referenced here is a global address mapping table pre-generated during the basic firmware compilation phase. The loader searches this table for the names of undefined symbols and finds their actual physical addresses in the basic firmware runtime area (mem1).

[0036] S1.3: Based on the obtained actual memory address, relocate the undefined symbols in the patch file to correct the call addresses inside the patch file.

[0037] The loader fills the found real address into the instruction segment of the patch file, completing the relocation. After this step, the patch file is transformed from a "static code package" into "binary code that can be directly executed in SRAM" and has the ability to call basic firmware functions.

[0038] S2: While the patch file is being loaded, a preset address acquisition logic is executed to obtain all function names and their current running addresses in SRAM contained in the module to be updated, and to generate a patch symbol table.

[0039] The patch symbol table records the correspondence between module names, function names, and runtime addresses.

[0040] In this step, to support the basic firmware in reverse calling of newly added functions in the patch, or to accurately locate function entry points within the patch, a self-parsing code (i.e., the preset address acquisition logic) is pre-embedded within the patch file. This logic is simultaneously parsed and automatically executed as the patch code is parsed and loaded into the SRAM runtime area (i.e., the mem2 area in the diagram). The preset address acquisition logic traverses all content in the current module's SRAM, extracts the entry address of each function, and dynamically generates a "patch symbol table" by combining it with the module ID. Since the preset address acquisition logic parses not only code segments but also data segments, the table contains both functions and data. For example, this table may contain not only the addresses of the fixed functions but also new functions exported by the patch (Patch Export Symbol), as well as some variable names and their corresponding addresses, thus enabling bidirectional communication between the basic firmware and the patch.

[0041] S3: Based on the matching of the patch symbol table and the function jump table, determine the name of the function to be updated in the function jump table.

[0042] The function jump table stores the mapping between function names and address pointers for certain functions in the base firmware. These specific functions are those marked as supporting hot-patching in the source code. Initially, the address pointers for each function name in the function jump table are set to the storage addresses of the original functions in the base firmware.

[0043] This step is the core of implementing "function-level" updates. The function table, located in the base firmware runtime area (mem1), acts as the "traffic control center" for all hot-patched functions. Unlike traditional solutions that manage all functions, the function table in this embodiment only contains specific functions that are explicitly marked by the developer at compile time (e.g., via the #define FUNC_NAME macro).

[0044] In S3, matching based on the patch symbol table and function jump table includes:

[0045] S3.1: Traverse the records in the patch symbol table and extract the module name and function name.

[0046] S3.2: Search the function jump table for entries that match both the module name and the function name. Use the dual key of "module name + function name" for precise searching to ensure that functions with the same name in other modules are not mistakenly modified.

[0047] S3.3: If a matching entry is found, it is identified as the name of the function to be updated, and the corresponding runtime address in the patch symbol table is obtained.

[0048] Specifically, the steps for generating a function jump table include:

[0049] S3.1a: During the compilation phase of the basic firmware, identify specific functions in the source code that are marked as supporting hot patching.

[0050] When the compiler scans the source code of the base firmware, it automatically captures function declarations marked with specific hot patch flags. These flags are a direct expression of the developer's intent, indicating that the function may need to be replaced independently in the future.

[0051] S3.2a: Extract the function name of a specific function, the storage address of the specific function in the basic firmware, and the module name of the module to which the specific function belongs.

[0052] Once the target function is identified, the build system immediately retrieves its triplet information: {function name, original address, module name}. The module name is included for subsequent double verification with the patch symbol table, ensuring accurate location in an environment with multiple modules and preventing false matches caused by functions with the same name existing in different modules.

[0053] S3.3a: Based on the extracted function names, storage addresses, and module names, establish a correspondence, generate a function jump table, and link the generated function jump table to the final compiled base firmware.

[0054] This process is fully embedded in the automated compilation process, eliminating the need for developers to manually write and maintain jump tables, thus fundamentally avoiding address errors or omissions that may result from manual configuration.

[0055] In addition, such as Figure 2 As shown, the steps for generating the basic symbol table supporting step S1 include:

[0056] S3.1b: During the compilation phase of the basic firmware, the source code of each functional module is compiled and packaged to generate a corresponding static library file (i.e., mod.a file). The static library file contains the full code data and symbol information of the module.

[0057] The base firmware is divided into multiple independent modules (mod_1, mod_2, ...). The source files (.c) of each module are first compiled into object files (.o), and then packaged into a static library file (mod.a). The .a file is a crucial data container, which fully preserves all symbol definitions within the module. This modular division is a prerequisite for saving memory later on.

[0058] S3.2b: Identify specific functions in the source code that are marked as supporting hot patching, and determine other functions and / or variables that the specific functions depend on as target dependency symbols.

[0059] S3.3b: If the extracted target dependency symbol does not exist in the current base symbol table, then update and add the name of the target dependency symbol and its corresponding address to the current base symbol table.

[0060] In this step, a symbol is only written to the basic symbol table if both conditions are met: it is a dependent symbol and it does not exist in the table. This mechanism achieves "accumulation on demand." It avoids the tedious process of developers manually exporting symbols (prone to errors and omissions) in traditional solutions, and also avoids the waste caused by loading all symbols from all modules into memory indiscriminately. By checking for existence, the compactness and uniqueness of the symbol table are ensured.

[0061] S3.4b: Repeat the above extraction and update process until all relevant module static library files have been traversed, ultimately forming a complete basic symbol table used to resolve undefined symbols when loading patch files.

[0062] As each mod.a file is processed, the basic symbol table grows dynamically, eventually forming a complete lookup table containing all necessary dependency mappings. Since each module is processed independently, if a module is not involved in the current hot patch scenario, its symbols will not be loaded into memory, thus avoiding the waste of precious and scarce memory by storing irrelevant symbols (functions and variables) in memory.

[0063] S4: Based on the name of the function to be updated, update the address pointing information in the function jump table so that it points to the storage address of the updated target function code in SRAM.

[0064] This step performs an "atomic switch." Once a match is successful, the firmware only needs to modify the pointer value of the corresponding entry in the function jump table, updating it from pointing to the original function address in mem1 to pointing to the address of the patch function in mem2. Since the function jump table resides in high-speed SRAM and the modification operation is only a memory write operation, this process can be completed in microseconds. At this point, the system's execution flow instantly switches from the old code to the new code without restarting the device or interrupting the data packets being processed.

[0065] S5: In response to a call request to the target function, jump to SRAM based on the updated function jump table to execute the corresponding code.

[0066] In this state, all calls to the target function within the business logic will first access the function jump table, and after looking up the table, will directly jump to the patch code in SRAM for execution. For ordinary functions that are not marked, the system will still directly call the original code in the base firmware, thus achieving seamless firmware hot upgrades in the hybrid operation mode.

[0067] As another possible embodiment of the present invention, this embodiment further introduces a double-buffering mechanism based on the first embodiment. This embodiment aims to address the risk of service interruption that may be caused by single-slot updates. In this embodiment, the system configures an independent patch file for each functional module in the basic firmware. Simultaneously, in the running area of ​​the network card SRAM (corresponding to...) Figure 1 Within the mem2 area, two physically isolated independent spaces are allocated for each functional module, defined as the first running slot (corresponding to...). Figure 1 Slot A in the middle) and the second running slot (corresponding to Figure 1 (Slot B in the middle). These two slots serve as backups for each other, ensuring that at least one slot is in a stable operating state at any time, thus supporting seamless switching.

[0068] In S1, the patch file is parsed and loaded in the reserved area of ​​the network card's SRAM, including:

[0069] S1.1: If the first running slot is in a running state, the parsed new patch code will be loaded into the second running slot.

[0070] In the step of parsing and loading the patch file into the reserved area of ​​the network card's SRAM, the system first performs a status check: If the first running slot (Slot A) is currently carrying traffic and executing the old version of the code, the system reads the new patch file from Flash, performs relocation parsing, and directly writes it to the free second running slot (Slot B). During this process, the old and new code are completely isolated in physical memory and do not interfere with each other. Traffic continues to be processed by Slot A, achieving a background loading effect with no foreground interference. Conversely, if Slot B is currently running, the new code is loaded into Slot A.

[0071] The corresponding S4 includes:

[0072] S4.1 (Successful Switch): If the new patch code is successfully parsed and loaded in the second run slot, the address pointing information corresponding to the function name to be updated in the function jump table is replaced with the address pointing information corresponding to the function name to be updated in the patch symbol table, so that it points to the code address in the second run slot.

[0073] Once the verification passes, the system only needs to modify the pointer value in the function jump table, instantly changing it from pointing to the address of Slot A to pointing to the address of Slot B. Since CPU execution flow is based on table lookup jumps, this modification takes effect immediately, and all subsequent calls to the function will automatically flow to the new code in Slot B. The switching process is extremely fast and will not cause packet loss or connection interruption.

[0074] S4.2 (Failure Rollback): If a parsing error or verification failure is detected during the process of loading the parsed new patch code into the second run slot, the status of the second run slot is marked as a failure, and the code in the first run slot continues to run, skipping the step of updating the corresponding address pointer information in the function jump table.

[0075] At this point, the system skips the step of updating the function jump table. The pointer in the function jump table still points to the first running slot (Slot A). Therefore, business traffic continues to be handled by the old version of the code, and the system automatically implements "failure rollback," ensuring zero service interruption and high availability. No manual intervention is required from the user; the system has automatically protected the runtime environment.

[0076] Following S4.1, the method also includes:

[0077] S4.2 Release the first running slot and mark the status of the first running slot as idle.

[0078] After a successful switchover, the old code in the original first running slot (Slot A) is no longer used. The system releases the SRAM space it occupied and updates its status to "free". This makes Slot A a backup slot for the next update, achieving the recycling of memory resources.

[0079] As another embodiment of the present invention, in order to facilitate maintenance personnel to perceive the patch status in real time, a debugging and status query mechanism based on command-line tools is also provided.

[0080] Patch ID binding and version verification: Each patch file has a unique Patch ID, which is strongly bound to the base firmware version number. Before loading, the firmware automatically verifies version compatibility to prevent incompatible patches from being loaded incorrectly.

[0081] State Enumeration and Visual Query: The system kernel maintains the real-time state machine of each module and displays detailed list information to the user via commands. Specifically, states can include the following four types:

[0082] flash: This indicates that the patch file has been safely stored in the Flash area, but has not yet been loaded into SRAM for execution. This corresponds to the intermediate state where the user has uploaded the patch but has not yet executed the switch command.

[0083] "Active" indicates that the patch has been successfully loaded into a running slot (Slot A or B), and the function jump table has been switched to point to that slot, currently processing business traffic. This is a normal operating state.

[0084] "Fail" indicates that the most recent attempt to load the patch for this module failed (e.g., a verification error or parsing exception). In this case, the system automatically retains the previous version, and this status prompts operations personnel to check the integrity and compatibility of the patch package.

[0085] fw (Firmware): This indicates that the module is currently running the raw code in the base firmware without any patches applied. This typically occurs when a new module is deployed for the first time or in scenarios where a hot update has not been performed.

[0086] This refined status management mechanism enables operations and maintenance personnel to clearly understand the health status of each functional module, quickly locate problematic modules, reduce the difficulty of on-site troubleshooting, and improve the maintainability and transparency of the system.

[0087] It should be noted that the aforementioned network card firmware hot patching method achieves seamless replacement of specified functions through function-level jump tables and on-chip SRAM dynamic loading mechanism. It can complete security vulnerability repair, logic error correction or lightweight function injection without interrupting business, and is particularly suitable for scenarios with extremely high service continuity requirements such as high-frequency trading and real-time audio and video transmission.

[0088] However, this method also has certain limitations: on the one hand, its update scope is limited to the retargetable function region and cannot cover key modules that cannot be hot-replaced, such as firmware initialization code, interrupt vector table, and driver framework core; on the other hand, the patch code needs to reside in the limited on-chip SRAM, which makes it difficult to support large-scale logic changes or full functional evolution.

[0089] Therefore, for scenarios involving architecture reconstruction, protocol stack upgrades, complete replacement of underlying drivers, or restoration to a clean operating baseline, an update mechanism capable of fully refreshing the firmware image and resetting the entire chip state is still needed. Specifically, as a possible embodiment of the invention, Figure 3As shown, a PCIe-based network card firmware hot-reboot method is provided. The core of this method lies in utilizing the endpoint hot reset (EP Hot Reset) signal of the PCIe (Peripheral Component Interconnect Express) protocol standard, combined with a custom status flag mechanism within the network card, to trigger a chip reset at the network card chip level. This allows for firmware, configuration items, or FPGA logic updates and activation without disconnecting the server's power supply or restarting the operating system. Specifically, the method includes:

[0090] S100: In response to the firmware upgrade command sent by the host, the network card writes the firmware upgrade package information to be updated into the non-volatile flash memory.

[0091] like Figure 3 and Figure 4 As shown, the specific implementation of step S100 is as follows:

[0092] Command Triggering and Transmission: When a user performs a firmware upgrade operation on the host machine (e.g., loads and runs an MCR release package containing new firmware), the host machine driver automatically sends the data stream of the firmware upgrade package to the network card via the PCIe bus channel. The start of this data transmission constitutes the de facto "firmware upgrade command".

[0093] Listening and Response Mechanism: The network card has a dedicated firmware write listener task running pre-installed. This task continuously monitors data write requests and address ranges on the PCIe bus.

[0094] Once the monitoring task detects that the host is writing data to a specific firmware storage area of ​​the network card (i.e., it detects the transmission of MCR release packets), it immediately determines that a firmware upgrade command has been received.

[0095] Subsequently, the network interface card (NIC) controller logic responds to this instruction, takes over the data flow, and writes the received firmware upgrade package information completely and accurately into the NIC's internal non-volatile flash memory. Flash memory is a storage medium that does not lose data after power failure, ensuring that the new firmware can be permanently saved even if an unexpected power failure occurs after it is written, providing a reliable data source for subsequent reset loading.

[0096] In step S100, when the network card receives the firmware upgrade command and the firmware upgrade package to be updated from the host machine, it does not immediately perform the write operation. Instead, it first initiates a strict security access mechanism to verify the integrity and security of the firmware upgrade package. Specifically, the network card firmware uses its built-in encryption algorithm module to calculate the hash value (such as SHA-256) of the received firmware package and compares it with the pre-stored hash value attached to the firmware package to perform hash integrity verification, ensuring that no bit flips, packet loss, or tampering occurs during data transmission. At the same time, the network card calls a pre-set public key certificate to decrypt and verify the digital signature carried in the firmware package, performing digital signature verification to confirm that the firmware package indeed originates from a trusted official publisher and has not been illegally forged. Only when both of the above verifications pass will the network card allow the firmware upgrade package information to be written to the non-volatile flash memory; if either verification fails, the network card will immediately discard the upgrade package and return a security error code to the host computer. This pre-verification step constitutes the first line of defense for firmware updates, effectively preventing risks caused by malicious code injection or data corruption, and ensuring the reliability and system stability of subsequent chip reset and new firmware loading processes from the source.

[0097] Prior to S100, the method also includes:

[0098] S110: The host machine performs an environment pre-check operation to determine whether the current network card supports firmware reset function and whether it is running virtual machine services or virtual functions.

[0099] S120: If the current network card supports firmware reset function and no virtual machine services or virtual functions are running, the host machine backs up the PCIe configuration space information of the current network card and stops the driver connected to the network card to disconnect the communication connection between the host operating system and the network card.

[0100] S130: If it is determined that the current network card does not support the firmware reset function, or if the attempt to shut down the virtual machine service or virtual function fails, the host machine terminates the firmware upgrade process and outputs an error message indicating that hot restart is not supported.

[0101] Steps S110-S130 are the environmental preparation and security verification work before the upgrade.

[0102] Before the firmware writing is officially performed, in order to ensure the security of the upgrade process and the integrity of the data, the host machine first performs a strict environmental pre-check operation (step S110).

[0103] Specifically, the management tool on the host machine first queries the network card's device capability register to confirm whether the current network card hardware and firmware version support the "Firmware Reset (FW Reset)" function. If not, the process is terminated directly. At the same time, the tool scans the system status to detect whether the current network card is carrying virtual machine (VM) services or has enabled virtual function (VF).

[0104] Because the network interface card (NIC) link is briefly interrupted during a hot reboot, if a virtual machine is passing through the NIC or running critical services during this time, it may cause the virtual machine to crash or lose data. Therefore, it is essential to ensure that services have been migrated or stopped before upgrading.

[0105] Step S130 is the exception handling step. If the system detects that it does not support hot restart or cannot safely shut down the relevant virtual machine / virtual function, the system will immediately terminate the upgrade process and output an error message. This prevents system failures caused by forcibly upgrading in an insecure environment.

[0106] Step S120 involves configuration backup and driver shutdown: After confirming the environment is secure, the host machine performs two key actions:

[0107] Backup PCIe configuration space: Reads and saves the current PCIe configuration register values ​​of the network card (such as BAR space size, interrupt vectors, MAC address register mapping, etc.). This is because subsequent chip resets will clear these volatile configurations. If not backed up, the network card will revert to its default values ​​after a reset, resulting in network failure or configuration loss.

[0108] Stop Driver: Stops the network card driver in the operating system. This is to disconnect the communication connection between the operating system kernel and the network card hardware, preventing the driver from triggering a kernel panic or generating a large number of error logs during the network card reset process due to the sudden disappearance of the hardware.

[0109] S200: After writing the firmware upgrade package information to the flash memory, the network card marks its own running status as pending activation.

[0110] The network interface card (NIC) internally runs another state update monitoring task (or a different state machine that reuses the same task). This task specifically listens for the physical event that "the firmware upgrade package has been successfully written to flash memory" (e.g., listening for the "write complete" interrupt signal or status bit of the Flash controller). Once the write operation is detected as complete, this task is automatically triggered, marking the NIC's current operating state as "pending effect".

[0111] After confirming that new data has been successfully written to Flash, the network card firmware does not immediately restart. Instead, it changes a specific status flag to "Upgrade Pending".

[0112] This status flag is typically stored in the network card's on-chip SRAM or a specific register. Its function is to tell the network card's internal logic: "The new firmware is ready, but it needs to wait for a specific trigger signal to load." This design decouples the "write" and "enable" actions, avoiding inconsistent states caused by accidental resets after the write operation is complete, and also providing a basis for accurately triggering resets later.

[0113] S300: The network card monitors the PCIe bus signals from the host machine through an internal listening task, and when it detects an endpoint hot reset signal from the host machine, it determines whether the current running status is pending activation.

[0114] S400: If the judgment result is yes, the network card responds to the endpoint hot reset signal and triggers the internal hardware logic to perform a chip reset operation.

[0115] S410: If the current operating state is determined to be not a pending state, the network card ignores the endpoint hot reset signal, does not perform the chip reset operation, and maintains the current normal operating state.

[0116] Steps S300, S400 and S410 are the implementation steps of the signal monitoring and intelligent triggering mechanism.

[0117] During this phase, the network interface card (NIC) enters a state of waiting for triggers, and an independent listener task runs internally. Additionally, the execution trigger signals for related actions in S100 and S200 can also be obtained by running the corresponding listener task.

[0118] Signal monitoring and status matching (step S300): The monitoring task continuously monitors PCIe bus signals from the host machine. When a host user executes a hot reset command (such as triggering the EP Hot Reset signal by writing to a register), the network card will capture the signal. At this time, the network card does not blindly perform a reset, but first checks whether the current running status is "pending effect".

[0119] Branching logic:

[0120] Scenario A: Status Match (Step S400): If the status is "Pending Activation", it means that the user has indeed performed a firmware update and requested activation. The network card will respond to the signal and execute the reset procedure.

[0121] Case B: Status mismatch (step S410): If the status is "normal operation" (i.e., no firmware update has been performed), even if an EP Hot Reset signal is received (which may be due to link training error or misoperation), the network card will ignore the signal, not perform a chip reset, and maintain the current service operation.

[0122] This dual confirmation mechanism of "signal + status" greatly improves the security of the system, effectively prevents unexpected network card restarts caused by PCIe link fluctuations or misoperations, and ensures the continuity of services.

[0123] Specifically, the S400 includes:

[0124] S401: After confirming that the network card is in a pending state, it parses the received endpoint hot reset signal and generates an internal reset trigger command.

[0125] S402: The firmware logic of the network card writes a preset reset activation value to the hardware reset control register located inside the network card chip according to the internal reset trigger instruction.

[0126] S403: When the hardware reset circuit inside the network card chip detects that the value in the hardware reset control register has changed to the reset activation value, it performs a chip reset operation on the network card chip.

[0127] Steps S401-S403 are the specific underlying implementation methods for chip-level reset.

[0128] When a reset is required, this invention triggers a chip reset through a hardware and software collaboration, which is the core physical process for achieving a "hot reboot".

[0129] Command parsing (step S401): The network card firmware parses the received EP Hot Reset signal and converts it into an internal reset trigger command.

[0130] Register write operation (step S402): The firmware logic writes a preset reset activation value (e.g., binary "1") to a dedicated hardware reset control register inside the network card chip. This register serves as a bridge connecting the firmware logic and the hardware reset circuit.

[0131] Hardware circuit response (step S403): The hardware reset circuit inside the network card chip (such as the existing YSA-100 network chip) monitors the value of this register in real time. Once it detects that the value has changed to an active value, the hardware circuit will immediately perform the following operations:

[0132] Cut off the clock: Temporarily disable the clock signal for the core logic of the chip.

[0133] Pulling the reset pin low: This pulls the internal reset signal line of the chip low, restoring all logic gates to their initial state. This achieves a chip-level reset, which in turn triggers a reset on the network interface card (NIC) chip to reload the new firmware package.

[0134] Traditional cold reboots achieve a reset by cutting off and then powering on the entire machine, which has a wide impact. In contrast, the chip reset in this step simulates the power-down-power-on process only within the network card chip. This is equivalent to powering down and then powering on the chip separately, but without physically disconnecting power and without affecting the power supply to the server motherboard and other components. This allows all components running on the chip (including the CPU core, DMA engine, MAC layer, etc.) to be completely cleared and reinitialized, providing a clean hardware environment for loading new firmware.

[0135] After performing a chip reset operation, the method further includes:

[0136] S410: The host PCIe controller detects a link loss signal caused by a chip reset operation and automatically initiates a link retraining process.

[0137] S420: The network card responds to the link retraining process and re-establishes the PCIe link with the host machine.

[0138] S430: After successfully re-establishing the PCIe link, the host performs a removal and re-scan operation on the PCIe bus to trigger a re-enumeration operation of the network card.

[0139] S440: The host reads the backed-up PCIe configuration space information and restores it to the re-enumerated network card device to restore the network card's initial configuration parameters.

[0140] S450: The host machine restarts the driver corresponding to the network card to restore the network card's data transmission function.

[0141] Steps S410-S450 are the link reconstruction and service recovery steps.

[0142] A chip reset will cause the PCIe link to be disconnected momentarily, after which the system will automatically enter the recovery process.

[0143] Link retraining (steps S410-S420):

[0144] The host machine's PCIe root complex detects a link down and automatically initiates a link retraining process.

[0145] After the network interface card (NIC) completes chip reset and initiates the underlying PHY layer logic, it responds to the training request, and both parties renegotiate parameters such as link width and speed to re-establish the PCIe link. This process is entirely automated by hardware, requiring no software intervention. This embodiment cleverly utilizes the inherent "self-healing" feature of the PCIe protocol (i.e., the link state machine and automatic link training mechanism inherent in the protocol standard) to handle active resets caused by firmware upgrades. Traditional solutions may require complex software polling or manual re-plugging of the device to restore the connection, while this embodiment, by triggering chip reset, naturally induces the PCIe link to enter the standard retraining process. This not only ensures high reliability of link recovery (because this is the most basic function of PCIe hardware), but also achieves zero software overhead in the recovery process. That is, during the link physical layer recovery phase, the host CPU does not need to execute any instructions, and the operating system is not even aware of the specific training details; it only receives a standard "device online" event after the link reconstruction is completed. This design greatly simplifies the software logic of hot restart, reduces the complexity of driver development, and significantly shortens the service interruption time window.

[0146] Device re-enumeration (step S430):

[0147] Once the link is established, the host operating system detects the new device connection and performs a remove / rescan operation.

[0148] The operating system rereads the network card's configuration space, allocates resources (such as memory addresses and interrupt numbers), and completes re-enumeration. At this point, the operating system recognizes the network card as a "new" device.

[0149] Configuration recovery and driver loading (steps S440-S450):

[0150] Configuration recovery: The host machine reads the PCIe configuration information backed up in step S120 and writes it back to the newly enumerated network interface cards (NICs). This step is crucial, as it ensures that user-defined parameters such as the NIC's MAC address, VLAN configuration, and MTU are not lost after the upgrade, achieving a seamless upgrade.

[0151] Driver loading: Finally, the host machine restarts the network card driver. After the driver is loaded, the network card can resume normal data transmission functionality.

[0152] S500: After completing the chip reset operation, the network card automatically reads the new version of firmware information from the flash memory, loads and runs it to complete the firmware hot reboot upgrade.

[0153] Automatic loading (step S500): During the bootloader phase after chip reset, the network card hardware automatically reads the firmware code from the flash memory. Since a new version of firmware has already been written in step S100, the firmware read and loaded this time must be the new version of firmware.

[0154] Thus, the network card has completed a smooth transition from the old version to the new version. Throughout the entire process, the server never lost power, the operating system did not restart, and other services were not affected. Only the network card itself underwent a brief reset and reconnection. Typically, the hot upgrade restart in this embodiment can be completed in tens of seconds to a minute. Compared to the existing cold start method that requires at least a few minutes or even longer, this embodiment better solves the technical problems of long time consumption and wide impact of traditional cold restarts.

[0155] As another possible embodiment of the present invention, after the network card completes the firmware hot reboot upgrade (step S500) and the host machine reloads the driver (step S450), the method further includes an efficient and direct version verification and result feedback mechanism (steps S510-S540). The core of this mechanism lies in using the network card's internal preset version information register as a "status beacon" between hardware and software, realizing second-level confirmation of the upgrade result.

[0156] Specifically, including:

[0157] S510: The network card automatically obtains the version identifier of the currently running firmware and writes the version identifier into the preset version information register inside the network card.

[0158] Step S510 is the firmware version self-reporting mechanism: After the network card completes the chip reset and successfully loads the new firmware version from the flash memory, the new firmware will automatically execute the version self-check program during its initialization phase.

[0159] Obtain the version identifier: The firmware logic extracts a unique identifier for the currently running version from its own code segment or build metadata. This identifier typically includes the major version number, minor version number, and patch number, such as v2.1.0.

[0160] Write to shared register: The firmware writes the version identifier directly to a specific version information register inside the network card chip, which can be directly accessed by the host machine via the PCIe bus.

[0161] Traditional verification methods often require the host machine to send complex query commands, which the firmware then receives, parses, processes, and returns data. This process is lengthy and susceptible to driver status fluctuations. In this solution, the version number is actively and directly written into a pre-defined register (i.e., the version information register) exposed to the host machine after firmware startup. The value that the host machine can directly read is the current actual firmware version, eliminating any tampering or caching delays in the intermediate stages.

[0162] Furthermore, this approach has the advantage of not relying on complex driver interactions. Even if the driver has not fully loaded all advanced features, as long as the PCIe link is established, the host machine can read the register through standard memory-mapped I / O (MMIO) operations. This means that verification can be completed in the earliest stages of driver initialization, greatly improving feedback speed.

[0163] Although this register is volatile, it always maintains the latest value during firmware operation. If the firmware fails to boot (such as due to a watchdog reset or getting stuck in an infinite loop), this register will not be updated or will retain the old / invalid value, which in itself is a kind of implicit failure signal.

[0164] After restarting the driver corresponding to the network card, the method also includes:

[0165] S520: The host machine reads the current firmware version number stored in the version information register through the PCIe bus.

[0166] S530: The host machine compares the current firmware version number it reads with the target upgrade version number.

[0167] Steps S520-S530 are the rapid reading and comparison steps on the host side.

[0168] Seamless read (step S520): During the network card driver restart process (or immediately after driver loading), the host initiates a simple read operation via the PCIe bus to directly read the contents of the aforementioned version information register. Since the register is located in the network card's BAR (Base Address Register) space, this operation only requires a few clock cycles and consumes almost no CPU resources.

[0169] Intelligent comparison (step S530): The host management tool will compare the "current running version number" it reads with the "target upgrade version number" specified by the user before the upgrade, either as a string or a numerical value.

[0170] S540: Based on the comparison results, generate a prompt message indicating whether the firmware upgrade was successful or failed.

[0171] Based on the comparison results, the system automatically generates a prompt message indicating whether the firmware upgrade was successful or failed, and outputs it to the user interface or log system.

[0172] For example, a success message will be displayed: if the comparison is consistent, "Upgrade successful, current version: vX.XX" will be output, and the "Pending activation status" flag can be automatically cleared to end the upgrade process.

[0173] Failure Alarm: If the comparison is inconsistent, output "Upgrade failed, current version is still: vY.YY" or "Version unknown", and trigger the alarm process (such as automatic rollback, sending email notification, etc.).

[0174] This embodiment simplifies the originally complex software query process into a single hardware read operation by introducing a version information register, a lightweight hardware interface. Compared to traditional solutions that require waiting for the driver to fully load and a communication channel to be established before querying the version, this solution reduces the verification time to the millisecond level, achieving the effect of knowing the result immediately after the upgrade.

[0175] Furthermore, in existing server architectures, a single host machine often has multiple network interface cards (NICs) mounted (e.g., 4, 8, or even more), and these NICs may be in different maintenance cycles or upgrade batches. This embodiment utilizes the independent bus device number and physical address space of each NIC in the PCIe topology to achieve a one-to-one precise mapping and physical isolation between the version information register and the specific NIC hardware. Compared to the difficulties in information aggregation and troubleshooting caused by existing technologies relying on global driver interfaces, this solution supports the host machine to concurrently read the values ​​of each independent register, thereby generating a refined status list containing "NIC ID - current version - target version". This allows users or operation and maintenance systems to intuitively and in real-time grasp the independent upgrade status of each NIC in the cluster (e.g., the NIC in slot 1 has been upgraded to v2.0, while the NIC in slot 2 remains at v1.0 due to a fault). This solves the technical pain points of "black box" upgrade status and difficulty in fault location in multi-NIC and heterogeneous environments, improving the transparency and management efficiency of operation and maintenance in complex server architectures.

[0176] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0177] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0178] In an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method is also provided.

[0179] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely in hardware, entirely in software (including firmware, microcode, etc.), or in a combination of hardware and software, collectively referred to herein as “circuit,” “module,” or “system.”

[0180] An electronic device according to this embodiment of the invention. The electronic device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the invention.

[0181] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0182] The memory stores program code that can be executed by a processor, causing the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention.

[0183] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0184] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0185] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0186] The electronic device can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the electronic device can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0187] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0188] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0189] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0190] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0191] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0192] Furthermore, the accompanying drawings are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes shown in the above drawings do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0193] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0194] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A network card firmware hot patching method, characterized in that, Includes the following steps: The system receives patch files for modules to be updated in the network interface card (NIC) basic firmware and parses and loads the patch files in the reserved area of ​​the NIC SRAM; the patch files contain updated target function code and preset address acquisition logic. While the patch file is being loaded, the preset address acquisition logic is executed to obtain all function names contained in the module to be updated and the current running address of the corresponding function in SRAM, and to generate a patch symbol table; the patch symbol table records the correspondence between module name, function name and running address; Based on the matching of the patch symbol table and the function jump table, the names of the functions to be updated in the function jump table that need to be updated are determined; The function jump table stores the correspondence between the function names and address pointers of certain specific functions in the basic firmware, some of which are functions marked as supporting hot patching in the source code. In the initial state, the address pointing information corresponding to each function name in the function jump table is set to point to the storage address of the original function in the basic firmware; Based on the name of the function to be updated, update the address pointing information in the function jump table so that it points to the storage address of the updated target function code in SRAM; In response to a call request to the target function, the system jumps to SRAM based on the updated function jump table to execute the corresponding code.

2. The network card firmware hot patching method according to claim 1, characterized in that, The step of matching the patch symbol table with the function jump table to determine the names of the functions to be updated in the function jump table includes: Iterate through the records in the patch symbol table and extract the module name and function name; Search the function jump table for an entry that matches both the module name and the function name; If a matching entry is found, it is identified as the name of the function to be updated, and the corresponding runtime address in the patch symbol table is obtained.

3. The network card firmware hot patching method according to claim 1, characterized in that, Also includes: Configure corresponding independent patch files for each functional module in the basic firmware, and configure a first run slot and a second run slot in SRAM for each patch file; The patch file is parsed and loaded into the reserved area of ​​the network card's SRAM, including: If the first running slot is in a running state, the parsed new patch code will be loaded into the second running slot; Updating the address pointer information in the function jump table includes: If the new patch code is successfully parsed and loaded in the second run slot, the address pointing information corresponding to the function name to be updated in the function jump table will be replaced with the address pointing information corresponding to the function name to be updated in the patch symbol table, so that it points to the code address in the second run slot.

4. The network card firmware hot patching method according to claim 3, characterized in that, After replacing the address pointer information corresponding to the function name to be updated in the function jump table with the address pointer information corresponding to the function name to be updated in the patch symbol table, the method further includes: Release the first running slot and mark the status of the first running slot as idle.

5. The network card firmware hot patching method according to claim 3, characterized in that, The steps for generating the function jump table include: During the compilation phase of the basic firmware, specific functions in the source code marked as supporting hot patching are identified; Extract the function name of the specific function, the storage address of the specific function in the basic firmware, and the module name of the module to which the specific function belongs; Based on the extracted function names, storage addresses, and module names, a correspondence is established to generate the function jump table, and the generated function jump table is linked to the final compiled base firmware.

6. The network card firmware hot patching method according to claim 5, characterized in that, It also includes the step of generating the basic symbol table: During the compilation phase of the basic firmware, the source code of each functional module is compiled and packaged to generate corresponding static library files; each static library file contains the full code data and symbol information of the corresponding functional module. Identify specific functions in the source code that are marked as supporting hot patching, and determine other functions and / or variables that the specific functions depend on as target dependency symbols; If the extracted target dependency symbol does not exist in the current base symbol table, then the name and corresponding address of the target dependency symbol are updated and added to the current base symbol table.

7. The network card firmware hot patching method according to claim 6, characterized in that, The patch file is a relocatable executable linker file; Before the step of parsing and loading the patch file in the reserved area of ​​the network card's SRAM, the method further includes: Read undefined symbols from the patch file; Query the basic symbol table to obtain the actual memory address corresponding to the undefined symbol; Based on the obtained actual memory address, the undefined symbols in the patch file are relocated to correct the call addresses within the patch file.

8. The network card firmware hot patching method according to claim 3, characterized in that, Also includes: During the process of loading the parsed new patch code into the second running slot, if a parsing error or verification failure is detected, the status of the second running slot is marked as a failure, and the code in the first running slot continues to run, while skipping the step of updating the corresponding address pointing information in the function jump table.

9. A non-transitory computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements a network card firmware hot patching method as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements a network card firmware hot patching method as described in any one of claims 1 to 8.

Images