A method and apparatus for updating a switch card

Abstract

The application discloses an updating method and device of a riser card, and relates to the technical field of data processing. The method initiates updating through the interface of a basic input / output system, and the first memory of the basic input / output system stores a first firmware file, thereby avoiding the dependence on the management interface of a baseboard management controller for updating. Even if the baseboard management controller fails, the updating can still be completed by entering the basic input / output system during startup. The first firmware file is stored in the first memory, and the first firmware file can be prevented from being maliciously tampered with. In addition, the first firmware file is written into the corresponding riser card under the condition that the first check code and the second check code are consistent, the integrity of the first firmware file written into the riser card is ensured, and the problem that the riser card is invalid due to the damaged firmware is eliminated.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for updating an adapter card. Background Technology

[0002] In server hardware architecture, the riser card is a core component for enabling server expansion capabilities. It can be used to expand hardware such as graphics processors, high-speed network cards, and storage controllers. The integrity and compatibility of the riser card firmware directly determine the operational stability of the expanded hardware. Currently, riser card firmware updates are primarily performed by logging into the BMC (Baseboard Management Controller) management interface and uploading the firmware file to the BMC storage area. However, this firmware update method has limitations. When the BMC management interface is inaccessible, firmware updates may fail. Furthermore, data tampering or discrepancies can occur during firmware updates, leading to the updated riser card malfunctioning. Summary of the Invention

[0003] This application provides a method and device for updating an adapter card, which at least solves the problems in the related art where firmware updates for the adapter card cannot be performed when the BMC management interface cannot be logged in, and where data is tampered with or deviates during firmware updates, resulting in the updated adapter card not working properly.

[0004] Firstly, this application provides a method for updating a transfer card, including:

[0005] Receives user update selections for the adapter card in the update interface of the basic input / output system; wherein the update selections include firmware files provided by the first memory of the basic input / output system;

[0006] In response to the user's selection that the firmware file is provided by the first memory of the basic input / output system, the first firmware file of the adapter card is obtained from the first memory of the basic input / output system, and the first firmware file is copied to the second memory shared by the baseboard management controller and the basic input / output system;

[0007] The first firmware file is verified to obtain a first verification code, and the first verification code is sent to the baseboard management controller.

[0008] The receiving baseboard management controller compares the first checksum and the second checksum to obtain the comparison result; wherein, the second checksum is obtained by the baseboard management controller from verifying the first firmware file;

[0009] If the first verification code and the second verification code match, the first firmware file is written to the corresponding adapter card. After the first firmware file is successfully written, an update completion message is sent to the basic input / output system. The basic input / output system displays the update completion result on the boot screen.

[0010] Secondly, this application also provides an adapter card update device, comprising:

[0011] A receiving module is used to receive the user's update selection for the adapter card in the update interface of the basic input / output system; wherein the update selection includes a firmware file provided by the first memory of the basic input / output system;

[0012] The acquisition module is configured to, in response to a user selection that the firmware file is provided by the first memory of the basic input / output system, acquire the first firmware file of the adapter card from the first memory of the basic input / output system, and copy the first firmware file to a second memory shared by the baseboard management controller and the basic input / output system;

[0013] The verification module is used to verify the first firmware file to obtain the first verification code and send the first verification code to the baseboard management controller.

[0014] The receiving module is also used to receive the comparison result obtained by the baseboard management controller after comparing the first verification code and the second verification code; wherein, the second verification code is obtained by the baseboard management controller after verifying the first firmware file;

[0015] The writing module is used to write the first firmware file into the corresponding adapter card when the first check code and the second check code match, and to send an update completion message to the basic input / output system after the first firmware file is successfully written; the basic input / output system displays the update completion result on the boot screen.

[0016] Thirdly, this application also provides an electronic device, including:

[0017] Data storage device, used to store computer programs;

[0018] A data processor is used to implement the steps of the method as described in the first aspect when executing a computer program.

[0019] Fourthly, this application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a data processor, implements the steps of the method as described in the first aspect.

[0020] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a data processor, implements the steps of the method described in the first aspect.

[0021] This application provides a method and apparatus for updating an adapter card. The method involves receiving an update selection for the adapter card from a user in the update interface of a Basic Input / Output System (BIOS). When the user selects that the firmware file be provided by the first memory of the BIOS, the method retrieves the first firmware file of the adapter card from the first memory of the BIOS and copies it to a second memory shared by the BIOS and the Baseboard Management Controller (BMC). Thus, the update is initiated through the BIOS interface, and the first firmware file is stored in the BIOS's first memory, avoiding reliance on the BMC's management interface for updates. Even if the BMC malfunctions, the update can still be completed by booting into the BIOS. The storage of the first firmware file in the first memory prevents malicious tampering. Furthermore, the first firmware file is verified to obtain a first verification code, which is sent to the BMC. If the first and second verification codes match, the first firmware file is written to the corresponding adapter card, and after successful writing, an update completion message is sent to the BIOS. Therefore, by calculating and comparing the checksums separately, the problem of adapter card failure caused by corrupted firmware is prevented, ensuring the integrity of the first firmware file written to the adapter card. Attached Figure Description

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

[0023] Figure 1 An application scenario diagram corresponding to an adapter card update method provided in an embodiment of this application;

[0024] Figure 2 A flowchart illustrating a method for updating an adapter card according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the connection relationship of an adapter card provided in an embodiment of this application;

[0026] Figure 4 A flowchart illustrating a method for updating a transfer card, as provided in another embodiment of this application;

[0027] Figure 5 A schematic diagram of the structure of an adapter card update device provided in an embodiment of this application;

[0028] Figure 6This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

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

[0031] In server hardware architecture, the riser card is a core component for enabling server expansion capabilities. It can be used to expand hardware such as graphics processors, high-speed network cards, and storage controllers. The integrity and compatibility of the riser card firmware directly determine the operational stability of the expanded hardware. Currently, related technologies generally rely on the BMC management interface for riser card firmware updates. Maintenance personnel log into the BMC's web management interface via the network, upload the firmware file to the BMC's storage area, and the BMC sends an update command to the riser card and writes the firmware to complete the update.

[0032] However, the firmware update method for related adapter cards is susceptible to problems. If the BMC (Browser Control Center) malfunctions, such as network interruption, corrupted BMC firmware, or lost login password, access to the management interface may be impossible, impacting firmware updates and server maintenance efficiency. Furthermore, firmware files are vulnerable to man-in-the-middle attacks during upload to the BMC, and the BMC typically only performs simple file size checks, failing to detect firmware data discrepancies. If corrupted firmware is written to the adapter card, it can cause the card to malfunction, increasing maintenance costs. Therefore, to address these technical issues and avoid over-reliance on the BMC for firmware updates, as well as problems with update failures and insufficient firmware security checks, [further measures are needed]. First, to avoid update disruptions caused by BMC failures, we consider using the Basic Input / Output System (BIOS), which is required to boot the server, as the update entry point. Update options are provided in the BIOS interface, and the firmware file is pre-stored in the BIOS's read-only memory, thus eliminating reliance on the BMC management interface and storage. Second, to address the security issues of firmware transmission and verification, we utilize a BIOS-BMC collaborative verification mechanism. The firmware file is temporarily stored in a shared static random access memory (SRAM), and both the BIOS and BMC generate and compare checksums to ensure the firmware file has not been tampered with or has any data discrepancies.

[0033] Figure 1 This application provides an example of an application scenario diagram corresponding to a method for updating an adapter card according to an embodiment of this application; for example... Figure 1 As shown, the application scenario includes: an update device 10, a baseboard management controller 11, a basic input / output system 12, and an adapter card 13. The update device 10 is communicatively connected to the baseboard management controller 11, the basic input / output system 12, and the adapter card 13.

[0034] Specifically, the update device 10 receives an update selection for the adapter card 13 from the user in the update interface of the basic input / output system 12; wherein the update selection includes a firmware file provided by the read-only memory of the basic input / output system 12. When the update device 10 determines that the user has selected the firmware file to be provided by the read-only memory of the basic input / output system 12, the update device 10 retrieves the first firmware file of the adapter card 13 from the read-only memory of the basic input / output system 12 and copies the first firmware file to the static random access memory temporary storage area block shared by the baseboard management controller 11 and the basic input / output system 12. Subsequently, the update device verifies the first firmware file to obtain a first verification code, and sends the first verification code to the baseboard management controller 11; then it receives the comparison result obtained by the baseboard management controller 11 after comparing the first verification code and the second verification code; wherein, the second verification code is obtained by the baseboard management controller 11 from verifying the first firmware file; if the first verification code and the second verification code match, the update device 10 writes the first firmware file into the corresponding adapter card 13, and after the first firmware file is successfully written, the update device 10 sends an update completion message to the basic input / output system 12. The basic input / output system 12 displays the update completion result on the boot screen.

[0035] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0036] Figure 2 A flowchart illustrating a method for updating an adapter card according to an embodiment of this application is shown below. Figure 2 As shown, the execution subject of this embodiment is an adapter card update method apparatus. This adapter card update method apparatus can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc; alternatively, it can be implemented through a physical device integrating or installing the relevant computer program, such as a chip or electronic device. The electronic device may be a computer or a server, etc. The adapter card update method provided in this embodiment includes the following steps:

[0037] Optionally, in this embodiment, the adapter card update method apparatus can be a BIOS. Optionally, the adapter card update method can be applied to AMD servers.

[0038] S201, Receive update selections for the adapter card from the user in the update interface of the basic input / output system; wherein the update selections include firmware files provided by the first memory of the basic input / output system.

[0039] Optionally, in this embodiment, the first memory is described as a BIOS ROM (Read-Only Memory).

[0040] Optionally, during server startup, the BIOS first loads the initialization program, at which point the user can access the BIOS adapter card firmware update interface using a shortcut key. Optionally, the shortcut key can be Del, F2, etc.

[0041] Specifically, the adapter card firmware update interface provides update options, including firmware files provided by the BIOS ROM. It should also be noted that the update interface offers an option not to update; if the user chooses not to update, the server's boot process will continue.

[0042] It should be noted that the BIOS is the only program that can directly access hardware during the server startup phase. The hardware it can access includes adapter cards, ROM, and SRAM (Static Random Access Memory). It does not depend on the BMC to run. Even if the BMC fails, the BIOS can still load normally. Therefore, initiating an update through the BIOS interface can avoid dependence on the BMC.

[0043] S202, In response to the user's selection that the firmware file is provided by the first memory of the basic input / output system, the first firmware file of the adapter card is obtained from the first memory of the basic input / output system, and the first firmware file is copied to the second memory shared by the baseboard management controller and the basic input / output system.

[0044] Optionally, in this embodiment, the second memory is described as an SRAM temporary block shared by the BMC and BIOS.

[0045] Specifically, when it is determined that the user has selected to provide the firmware file from the BIOS ROM, the BIOS ROM is accessed via the bus. This ROM pre-stores the first firmware file of the verified adapter card. The ROM is a read-only storage medium; once data is written, it cannot be maliciously tampered with, thus ensuring the integrity of the source firmware.

[0046] Next, copy the first firmware file to the SRAM temporary storage block shared by the BMC and BIOS, such as a 1MB SRAM partition with the address range preset to 0x000000-0x07FFFF.

[0047] It should be noted that SRAM has a faster read and write speed than ROM / Flash, which can improve the efficiency of subsequent verification and writing; this partition enables bidirectional access between BMC and BIOS through hardware configuration, providing a data exchange carrier for BMC and BIOS collaborative verification.

[0048] S203. Verify the first firmware file to obtain the first verification code, and send the first verification code to the baseboard management controller.

[0049] Optionally, a preset verification algorithm is used to perform integrity calculations on the first firmware file in the SRAM temporary storage block to obtain a first checksum. The preset verification algorithm can be CRC32, MD5, or SHA-256. The first checksum is a digital fingerprint of the first firmware file; if any data in the first firmware file is tampered with or deviated from, the checksum will change.

[0050] Subsequently, the first checksum is sent to the BMC via a communication link (such as an LPC bus), along with the address information of the SRAM temporary storage block, so that the BMC can read the first firmware file.

[0051] S204. The baseboard management controller receives the comparison result obtained by comparing the first verification code and the second verification code; wherein, the second verification code is obtained by the baseboard management controller by verifying the first firmware file.

[0052] Optionally, after receiving the first check code, the BMC reads the first firmware file from the shared SRAM temporary storage block according to the address information of the provided SRAM temporary storage block, and calculates the second check code using the same check algorithm as in S203.

[0053] Next, the BMC compares the first checksum with the second checksum bit by bit to generate a comparison result. Optionally, the comparison result may include whether they match or not, and the comparison result is fed back to the update method device of the adapter card via a communication link.

[0054] It should be noted that by calculating the second check code through BMC and comparing it with the first check code, it is possible to avoid the situation where the first firmware file is deviated or tampered with, and to prevent the erroneous first firmware file from being written to the corresponding adapter card.

[0055] S205. If the first verification code and the second verification code match, the first firmware file is written to the corresponding adapter card. After the first firmware file is successfully written, an update completion message is sent to the basic input / output system. The basic input / output system displays the update completion result on the boot screen.

[0056] Optionally, if the received comparison results are consistent, it means that the first firmware file is complete and has not been tampered with, and a write permission command can be sent to the BMC; if the comparison results are inconsistent, the update process can be terminated directly.

[0057] Optionally, after receiving the write permission instruction, the BMC writes the first firmware file in the SRAM temporary block to the firmware storage area (such as the EEPROM on the adapter card) of the adapter card through the hardware interface (such as PCIe bus, I2C bus).

[0058] Optionally, after the BMC completes the writing, it sends an update completion message to the BIOS; after receiving the message, the BIOS displays the update result in text form on the server's boot screen, making it convenient for users to intuitively obtain the status.

[0059] Optionally, if the BMC write fails, an update failure message is sent to the BIOS.

[0060] This application provides a method for updating an adapter card. The method involves receiving a user's update selection for the adapter card in the update interface of the Basic Input / Output System (BIOS). When the user selects that the firmware file be provided by the first memory of the BIOS, the method retrieves the first firmware file of the adapter card from the first memory of the BIOS and copies it to a second memory shared by the PCB management controller and the BIOS. Thus, the update is initiated through the BIOS interface, and the first firmware file is stored in the BIOS first memory, avoiding reliance on the management interface of the PCB management controller for updates. Even if the PCB management controller malfunctions, the update can still be completed by booting into the BIOS. The storage of the first firmware file in the first memory prevents malicious tampering. Furthermore, the first firmware file is verified to obtain a first verification code, which is sent to the PCB management controller. If the first and second verification codes match, the first firmware file is written to the corresponding adapter card, and after successful writing, an update completion message is sent to the BIOS. Therefore, by calculating and comparing the checksums separately, the problem of adapter card failure caused by corrupted firmware is prevented, ensuring the integrity of the first firmware file written to the adapter card.

[0061] Figure 3 This is a schematic diagram of the connection relationship of an adapter card provided in an embodiment of this application; as shown Figure 3As shown, it should be noted that before updating the adapter card, in terms of hardware, the 12C1, 12C2 and 12C3 channels built into the central processing unit (CPU) are first used. Each 12C is connected to a corresponding adapter card, that is, 12C1 connects to adapter card 1, 12C2 connects to adapter card 2, and 12C3 connects to adapter card 3, forming an equivalent expansion path.

[0062] This connection method enhances the system's resource scalability and I / O bandwidth: each riser card supports the access of multiple expansion cards, meeting the heterogeneous computing power and high-speed interconnection needs of different services. Each channel operates in parallel, achieving load balancing, and redundant paths enhance the system's reliability and fault tolerance; a failure in one channel will not affect the normal operation of other channels, ensuring service continuity. Furthermore, the hardware settings of each adapter card can be flexibly configured to meet specific needs.

[0063] Optionally, you can create an option in the BIOS setup to control the generation of boot entries for each CPU group, and update the boot entries accordingly. The specific steps are as follows:

[0064] First, UNI files are used to store text strings in the user interface. Since UNI files can be dynamically loaded during startup, users can load strings for specific languages ​​as needed, without having to pre-load strings for all languages. Optionally, the control options are named I2C1 Riser control, I2C2 Riser control, and I2C3 Riser control. An update option button is added to the BIOS setup. Optionally, update options include: using firmware files in the BIOS ROM, flashing with external firmware files, and keeping the current state unchanged. Using the BIOS ROM button updates the adapter card using the firmware file in the BIOS. Selecting the external flash button allows insertion of external devices such as USB drives for firmware updates. Keeping the current state unchanged skips the current update screen and maintains normal boot.

[0065] Next, the layout path of the digitally signed certificate and defined options under setup is verified through the SD file, ensuring that only signed firmware and operating systems can be loaded, and also fixing the location of updates under BIOS setup. This SD file may contain a public key certificate or hash value list used to verify the digital signature of the firmware / operating system. The BIOS reads this SD file at boot, compares the loaded firmware signature with the preset valid signatures in the file, and only allows matching firmware to run. The SD file may define the paths of security-related options in the BIOS setup interface, such as specifying the location of the "Secure Boot" configuration menu, or restricting user modification permissions for certain boot options. Finally, a C file is used to associate specific implementation functions; for example, it may allow options to use firmware files from the BIOS ROM, or allow loading boot paths from external files. Optionally, the policies defined in the SD file can be implemented through C language code. For example, the C code may decide whether to load firmware from the BIOS internal ROM or from external storage (such as a USB flash drive or network) based on the configuration in the SD file. The C code may parse the boot path rules in the SD file to restrict the system to loading firmware files only from specified partitions or files.

[0066] As an optional implementation, based on any of the above embodiments, obtaining the first firmware file of the adapter card from the first memory of the basic input / output system includes the following steps:

[0067] First, based on a preset address range, a file read instruction is sent to the first memory of the basic input / output system.

[0068] Optionally, a standardized file read command is sent to the BIOS ROM based on a preset address range. This preset address range is the storage area of ​​the first firmware file in the ROM, pre-configured, such as the 0xA00000~0xB00000 address range, and can be adjusted through the BIOS parameter configuration interface.

[0069] Next, the system receives the first firmware file sent by the first memory of the basic input / output system. If the first firmware file is not received within a preset time, the file read command is resent.

[0070] Optionally, the adapter card's update device waits to receive the first firmware file returned by the BIOS ROM via the bus and starts a built-in timer. If the complete first firmware file is received before the timer expires, subsequent operations are performed; if the file is not received after the timer expires, a retry process is initiated.

[0071] The preset time is the time set by default for receiving the first firmware file. Optionally, the preset time range can be 500ms-2s, which can be adapted according to the ROM type.

[0072] Finally, in response to the failure to receive the first firmware file after exceeding the preset number of retries, a read failure message is sent to the basic input / output system, wherein the read failure message includes a preset address range.

[0073] Optionally, if the first firmware file is not received within a preset time, the file read command will be automatically resent, and the number of retries will be accumulated. The preset number of retries is a pre-set maximum number of times the file read command will be resent; optionally, the preset number of retries can be 3-5 times to avoid excessive retries that could decrease update efficiency. It should be noted that the timer resets with each retry.

[0074] Optionally, if the first firmware file is not received after the cumulative number of retries exceeds the preset number of retries, the read is determined to have failed, and a read failure message is immediately sent to the BIOS update interface to enable maintenance personnel to quickly locate the fault. Optionally, the read failure message must include the fault type, preset address range, and number of retries.

[0075] This application provides an update method for an adapter card. It accurately locates the firmware storage location by using a preset address range to ensure accurate reading of the target; it can handle occasional failures by using a preset timeout retry to improve the fault tolerance of firmware reading; and it can guide maintenance personnel to locate the fault in the corresponding storage area by feeding back failure information after exceeding the number of retries, thus simplifying the troubleshooting process.

[0076] As an optional implementation, based on any of the above embodiments, obtaining the first firmware file of the adapter card from the first memory of the basic input / output system includes the following steps:

[0077] First, the unique identifier of the adapter card is obtained, and the target firmware storage partition is located based on the unique identifier. Multiple firmware storage partitions are pre-allocated in the first memory of the basic input / output system. Each firmware storage partition is used to store the firmware file of the corresponding adapter card, and each firmware storage partition is named with the unique identifier of the corresponding adapter card.

[0078] Optionally, the unique identifier of the adapter card to be updated can be read via a hardware bus. This hardware bus can be a PCIe (Peripheral Component Interconnect Express, high-speed serial bus standard) bus or an I2C (Inter-Integrated Circuit) bus. It should be noted that this unique identifier must satisfy the requirements of device uniqueness and direct readable characteristics.

[0079] Optionally, during the reading process, the unique identification information of the target adapter card (such as the current adapter card: PCIe ID 10DE:1E81) can be displayed on the update interface for user confirmation to avoid accidental selection.

[0080] Optionally, the BIOS ROM can be pre-partitioned to create multiple independent firmware storage partitions. The size of each firmware storage partition is preset based on the maximum size of the adapter card's firmware file, such as allocating 1MB to each firmware storage partition.

[0081] Optionally, after obtaining the unique identifier of the adapter card, the identifier format is automatically parsed to generate the corresponding firmware storage partition name, and the target firmware storage partition is located through the partition index table of the ROM, avoiding reading the firmware storage partitions of other adapter cards. The target firmware storage partition is the firmware storage partition corresponding to the firmware file of the adapter card to be updated.

[0082] Optionally, depending on the compatible adapter card model, a firmware storage partition can be manually added through the firmware partition management interface of the BIOS and a unique identifier can be bound to ensure that the firmware storage partition corresponds one-to-one with the adapter card.

[0083] Next, the first firmware file is read from the target firmware storage partition, and the file name of the first firmware file contains a signature that matches the unique identifier of the adapter card.

[0084] Specifically, a read command is sent to the target firmware storage partition to read the firmware file stored within that partition, i.e., the first firmware file. The filename of the first firmware file has a pre-set unique identifier, for example, if the filename is "FW_10DE1E81_V2.1.bin", the identifier is "10DE1E81". Optionally, after reading the filename, the identifier is extracted and compared with the unique identifier of the target adapter card (e.g., "10DE:1E81" converted to "10DE1E81").

[0085] Optionally, if the feature code extracted from the filename of the first firmware file matches the feature code converted from the unique identifier of the target adapter card, the subsequent process is executed. If the feature codes do not match, it is determined that the first firmware in the target firmware storage partition is incompatible with the target adapter card, the reading is immediately terminated, and the firmware mismatch is displayed on the update interface to avoid writing incorrect firmware.

[0086] Optionally, if no firmware storage partition matching the unique identifier is found, the update interface will display the message "No corresponding firmware partition found. Please configure it through the BIOS partition management interface first," and provide a shortcut option to jump to the partition configuration interface.

[0087] This application provides an adapter card update method that uses a unique identifier to locate the corresponding named firmware storage partition, enabling accurate storage and retrieval in multi-adaptor card scenarios and avoiding firmware confusion between different adapter cards.

[0088] It should be noted that the method provided in this embodiment is particularly suitable for scenarios where a server is simultaneously expanded with multiple adapter cards of different types. Maintenance personnel do not need to remember the correspondence between firmware and adapter cards; they can quickly locate partitions using only a unique identifier, and multiple adapter cards can be updated in batches.

[0089] As an optional implementation, based on any of the above embodiments, the first firmware file embeds the matching information of the adapter card, and the method further includes the following steps:

[0090] First, the matching information of the adapter card is extracted from the preset fields in the header of the first firmware file. The matching information includes the model of the target adapter card and the target interface number.

[0091] Optionally, a predefined matching information field can be pre-defined in the header of the first firmware file. For example, the predefined field may be the first 16 bytes to avoid the firmware code area and ensure that it does not affect firmware operation. Bytes 0-7 store the target adapter card model, and bytes 8-16 store the target interface number, both in ASCII format.

[0092] It should be noted that this preset field is written by the manufacturer during the firmware creation stage and is bound to the server hardware interface specifications. For example, if it supports Slot3 with 4.0 x16 channels, the corresponding interface number in the firmware header is set to "PCIe-Slot3".

[0093] Optionally, the target adapter card model and target interface number can be obtained by reading preset fields from the header of the first firmware file and parsing them using ASCII codes. During the parsing process, if the preset fields contain garbled characters or are incomplete, the firmware header information is directly determined to be corrupted, the process is terminated, and a prompt is displayed.

[0094] Optionally, the actual model of the adapter card to be updated can be obtained by reading its hardware model register (such as the "Product Name" field in the PCIe configuration space) via the PCIe / I2C bus. The physical interface number of the adapter card to be updated can then be read using the slot detection module built into the BMC or BIOS. For example, the BIOS detects the slot address via PCIe RootComplex and maps it to the interface number marked on the server panel, ensuring consistency with the interface number format in the firmware header.

[0095] Next, the model number of the target adapter card is compared with the model number of the adapter card to be updated, and the target interface number is compared with the actual interface number. If the model number of the target adapter card matches the model number of the adapter card to be updated, and the target interface number matches the actual interface number, the first firmware file is copied to the second storage.

[0096] Optionally, if the target adapter card model matches the actual adapter card model to be updated, then proceed to interface number comparison; if the model comparison does not match, then terminate the process and display "model mismatch" on the update interface.

[0097] Optionally, if the target interface number matches the actual interface number, the compatibility verification is deemed successful, and subsequent operations are performed; if the interface numbers do not match, the process is terminated, an interface number mismatch is displayed, and a prompt is made to confirm the physical interface location of the adapter card.

[0098] This application provides a method for updating an adapter card. By extracting the model and target interface number of the target adapter card from preset fields in the firmware header and comparing them with the actual model and interface number of the adapter card to be updated, the method ensures that the firmware matches the adapter card model and avoids compatibility issues caused by incorrect physical interfaces of the same model of device. This significantly improves the accuracy of firmware updates and hardware compatibility.

[0099] As an optional implementation, based on any of the above embodiments, the first firmware file is verified to obtain a first verification code, including the following steps:

[0100] First, the first firmware file is split into multiple data segments according to a first preset byte. A cyclic redundancy check algorithm is used to calculate multiple data segments to obtain multiple temporary check values.

[0101] The first preset byte is a pre-configured byte length used to split the first firmware file into multiple data segments. Optionally, the value of the first preset byte can range from 1KB to 100KB and can be adjusted through the BIOS parameter interface.

[0102] For example, if the size of the first firmware file is 128KB and the first preset byte is set to 1KB, the first firmware file is split into 128 consecutive data segments in address order to ensure no overlap and no omission.

[0103] Optionally, a temporary check value can be calculated for each of the split data segments by calling a built-in cyclic redundancy check algorithm (such as CRC32). It should be noted that the calculation should be performed in the order in which the data segments are split to avoid inconsistent check results due to out-of-order processing.

[0104] Optionally, if a data reading error occurs during the calculation of a data segment, the data segment is immediately marked as "invalid," and the calculation is retried after rereading the data segment. If the calculation is still invalid after multiple retried calculations, the verification is terminated and a data anomaly is indicated.

[0105] Next, the multiple temporary check values ​​are summed to obtain the first check code; and the first check code is associated with the version number of the first firmware file.

[0106] Optionally, the temporary check values ​​of each valid data segment are summed. The summation formula is: First check code = Temporary check value 1 + Temporary check value 2 + Temporary check value N, where N is the total number of data segments.

[0107] It should be noted that if a data segment is tampered with, the temporary checksum of that data segment will change, facilitating traceability. Furthermore, the summation of multiple data segments is more difficult to maliciously forge than a single checksum, thus offering higher security.

[0108] Optionally, the version number can be extracted from the filename of the first firmware file, and the first verification code can be concatenated with the version number to form "verification code-version number", which is stored in the temporary data register of the BIOS and displayed in real time on the BIOS update interface.

[0109] It should be noted that when comparing verification codes, BMC can simultaneously obtain the version number. If a discrepancy occurs, it can directly pinpoint the firmware version that failed the verification without needing to check the version separately, thus improving troubleshooting efficiency.

[0110] This application provides a method for updating an adapter card. It uses a cyclic redundancy check (CRC) algorithm to verify the split data segments and sums the temporary check values ​​to generate a first checksum. This segmented processing improves computational efficiency. Furthermore, associating the checksum with the firmware version number binds the checksum result to the version, enhancing the traceability of checksum records during later maintenance.

[0111] As an optional implementation, based on any of the above embodiments, if the first verification code and the second verification code match, the first firmware file is written into the corresponding adapter card, including the following steps:

[0112] First, if the first and second verification codes match, an initialization command is sent to the corresponding adapter card.

[0113] Optionally, an initialization command can be sent to the target adapter card via the BMC. This initialization command is used to clear the old data cache area of ​​the adapter card's firmware storage area to avoid the overlap of old and new firmware data.

[0114] Optionally, if the BMC does not receive initialization completion information from the adapter card within the preset timeout period, it will retry sending the initialization command; if the retry fails, it will determine that the adapter card hardware is faulty, terminate the writing process, and display "Adapter card initialization failed".

[0115] Secondly, in response to receiving the initialization completion information returned by the adapter card, the first firmware file is split into multiple write sub-data blocks according to the second preset bytes.

[0116] Optionally, based on a second preset byte, the first firmware file is split into multiple consecutive write sub-data blocks. The second preset byte is a pre-set byte length used to split the first firmware file into multiple write sub-data blocks. Optionally, the value of the second preset byte can be consistent with the minimum erase block size of the adapter card's storage unit, such as a common 2KB / 4KB erase block size for EEPROM, which can reduce write time; if the storage unit does not have a fixed erase block size, the value of the second preset byte can range from 1KB to 100KB.

[0117] For example, if the first firmware file is 128KB and the second preset byte is set to 2KB, it is divided into 64 write sub-data blocks. Each write sub-data block can be appended with a 2-byte sub-block number. The sub-block number is used for sorting and verification when the adapter card receives the data.

[0118] Then, multiple write sub-data blocks are written to the adapter card in sequence, and after all the write sub-data blocks have been written, a firmware verification command is sent to the adapter card.

[0119] Optionally, the BMC sends the write sub-data blocks to the adapter card one by one via the hardware bus (PCIe / I2C) according to the splitting order. Optionally, after receiving the sub-data block, the adapter card first verifies whether the sub-block numbers are consecutive, and then performs a simple check on the write sub-data block, such as calculating the byte sum. If both are normal, it returns a sub-block reception success response to the BMC. If the BMC does not receive a response or receives a "sub-block reception failed" feedback, it immediately retransmits the write sub-data block; if multiple retransmissions still fail, it records the sub-block number and continues writing the next write sub-data block.

[0120] Finally, the adapter card verifies the first firmware file and sends back the verification result. If the verification result is satisfactory, the first firmware file is confirmed to have been successfully written.

[0121] Specifically, after all write sub-data blocks have been sent, the BMC sends a "firmware verification command" to the adapter card, triggering the adapter card to perform integrity verification on the first firmware file in its own storage unit. The adapter card must use the same verification logic as S203 to ensure a unified verification standard. Specifically, after the adapter card calculates the verification value, it compares it with the second verification code pre-sent by the BMC to generate a "verification passed" or "verification failed" result. The BMC receives the verification result. If the verification result is passed, it sends a write success message to the BIOS; if the verification result is failed, it analyzes the location of the verification failure and sends feedback to the BIOS that "the firmware file needs to be rewritten."

[0122] This application provides an update method for an adapter card. By sending an initialization command before writing, the adapter card is ensured to be in an appropriate writing state. By writing sub-data blocks in blocks, the impact of a single transmission interruption can be reduced. If a single block fails, only the corresponding sub-data block needs to be retransmitted, thus improving write fault tolerance. By triggering the adapter card's self-verification, the integrity of the firmware written to the adapter card is confirmed.

[0123] As an optional implementation, based on any of the above embodiments, copying the first firmware file to a second memory shared by the baseboard management controller and the basic input / output system includes the following steps:

[0124] First, the remaining storage space of the second memory is checked.

[0125] In this embodiment, SRAM is used as the second memory.

[0126] Optionally, a storage space query command is sent to the SRAM controller to read the remaining storage space of the shared SRAM temporary storage area block. The size relationship between the remaining storage space and the preset storage space needs to be determined. This preset storage space value is a pre-set storage space value, which can be 1.2 times the size of the first firmware file, reserving 20% ​​redundant space for storing temporary verification marks and address mapping tables during the copying process. For example, if the first firmware file is 128KB, the preset storage space is set to 153.6KB (rounded up to 154KB).

[0127] Optionally, if the remaining storage space is greater than or equal to the preset storage space, it indicates that the remaining storage space can meet the writing requirements, and subsequent writing operations can continue.

[0128] Secondly, if the remaining storage space of the second memory is less than the preset storage space, a data clearing command is sent to the second memory.

[0129] Optionally, if the remaining storage space is less than the preset storage space, a data clearing instruction is sent to the SRAM controller. This data clearing instruction must include a clear address range and a clearing method. The clear range can be the complete address segment of a shared SRAM temporary storage area block to avoid leaving residues after clearing only a portion of the area. The clearing method can be hardware zeroing; if the SRAM does not support hardware zeroing, software can be used to write 0s page by page.

[0130] Finally, after receiving feedback that the second memory has been cleared, the first firmware file is copied to the second memory at a preset transmission rate.

[0131] The preset transmission rate is a preset transmission rate based on the hardware characteristics of SRAM.

[0132] Optionally, the first firmware file can be written segment by segment in ascending address order via the LPC / PCIe bus. Optionally, the ratio of copied bytes to total bytes can be calculated in real time and the copying progress can be displayed on the BIOS update interface. If a "bus error" or "write timeout" occurs during the copying process, the copying should be paused immediately, the transfer rate reduced, and the process retried.

[0133] It should be noted that when copying the firmware file to the SRAM temporary storage block shared by the BMC and BIOS, if the SRAM temporary storage block has insufficient remaining space due to residual data from previous operations, direct copying will trigger a data overflow, causing the new firmware to be corrupted or the copying process to be interrupted. Furthermore, if the SRAM temporary storage block is not completely cleared, old data may overlap with some addresses of the new firmware, causing mixed data to be read during subsequent verification, leading to a false judgment that the firmware has been tampered with.

[0134] The present application provides an update method for an adapter card. By pre-detecting the remaining storage space of the SRAM temporary storage area block, the firmware copy interruption caused by insufficient space can be avoided, ensuring that the data is stored completely. When space is insufficient, the old data is actively cleared to eliminate the interference of historical residual data on the new firmware.

[0135] Figure 4 This is a flowchart illustrating an update method for an adapter card according to another embodiment of this application; as an optional implementation, based on any of the above embodiments, the update option further includes providing a firmware file from an external device.

[0136] It should be noted that when the server boots up and enters the firmware update interface of the BIOS adapter card, in addition to the firmware file option provided by the BIOS ROM mentioned earlier, there is also an option to provide the firmware file by an external device. Compatible external devices include USB flash drives or external hard drives. This method is suitable for scenarios where BIOS ROM space is insufficient or where on-site firmware updates are required, such as data center maintenance and rapid firmware version iteration scenarios.

[0137] like Figure 4 As shown, specifically, the method further includes the following steps:

[0138] S301. In response to the user's selection that the firmware file is provided by an external device, obtain the path of the external device's storage directory.

[0139] Optionally, connected external devices can be enumerated via the USB bus to identify device types (such as USB flash drives, external hard drives). If no external device is detected, the interface will display the message "No available external device detected, please insert a USB storage device".

[0140] Optionally, the root directory path of the external device can be read automatically. If the user stores the firmware in a subdirectory, the subdirectory path can be manually entered or selected through the interface.

[0141] S302. Based on the path, query the storage directory of the external device for an update package with a preset name and obtain the update package; wherein, the update package includes a second firmware file and a standard checksum.

[0142] Optionally, to avoid user misselection, the update package name format can be "Riser_[adapter card model]_[firmware version]_Update.zip", for example "Riser_GPU3090_V2.2_Update.zip".

[0143] Optionally, based on the obtained storage directory path, the files in the storage directory are traversed, and update packages that match the preset names are filtered out; if there are multiple matching update packages, such as versions V2.1 and V2.2 of the same model, they are displayed in the interface list for the user to select the target version.

[0144] Optionally, after the user selects the update package, the update package can be parsed through the decompression module to extract the second firmware file and the standard checksum. The standard checksum is the checksum value of the second firmware file pre-calculated by the manufacturer.

[0145] S303. Copy the second firmware file to the second memory shared by the baseboard management controller and the basic input / output system.

[0146] Optionally, before copying the second firmware file to the shared second storage, a remaining storage space check is performed. It should be noted that the technical effect of this S303 solution is the same as that of the S202 solution described above, and will not be repeated here.

[0147] S304. Verify the second firmware file to obtain a third verification code, send the third verification code to the baseboard management controller, and receive the comparison result between the third verification code and the standard verification code from the baseboard management controller.

[0148] Optionally, an algorithm consistent with the standard checksum is used to perform integrity calculations on the second firmware file in the second memory to obtain a third checksum. The third checksum and the parsed standard checksum are then sent to the BMC for verification.

[0149] Optionally, BMC compares the third checksum with the standard checksum to ensure they are completely identical. Additionally, BMC verifies the format of the standard checksum, excluding invalid checksums, such as garbled characters caused by file corruption. BMC returns the comparison result, which includes: "Checksum matches," "Checksum does not match," and "Standard checksum is invalid." If the comparison result is "Checksum does not match" or "Standard checksum is invalid," the process is immediately terminated, and the message "Standard checksum is invalid; please download the official update package again" is displayed.

[0150] S305. If the third check code and the standard check code match, write the second firmware file into the adapter card, and after the second firmware file is successfully written, send an update completion message to the basic input / output system.

[0151] Optionally, the second firmware file is split into sub-data blocks according to a second preset byte, and written into the adapter card block by block.

[0152] Optionally, if the second firmware file is written successfully, the BMC sends an update completion message to the BIOS, and the BIOS displays "External device update successful" on the boot screen. If the second firmware file writing fails, the reason for the failure can be displayed on the BIOS boot screen.

[0153] It should be noted that relying solely on the firmware file provided by the BIOS ROM has limitations:

[0154] First, BIOS ROM capacity is typically 16MB-64MB. If a server needs to accommodate multiple adapter cards or firmware versions, insufficient ROM space can easily occur. Second, when manufacturers release new firmware versions, the BIOS ROM needs to be re-flashed using specialized tools, making on-site updates by maintenance personnel impossible. External devices (such as USB flash drives and portable hard drives) offer advantages in terms of large storage capacity and convenient firmware updates.

[0155] It should be noted that the external device can store multiple versions of firmware for a large number of adapter cards, avoiding the problem of insufficient BIOS ROM capacity. This is especially suitable for server clusters that require maintenance of various adapter card models. Maintenance personnel do not need to flash the BIOS ROM; they only need to download the official update package to the external device to complete the firmware update on-site, adapting to the manufacturer's rapidly evolving firmware.

[0156] As an optional implementation, based on any of the above embodiments, the update package with a preset name is queried from the storage directory of the external device based on the path, and the update package is obtained, including the following steps:

[0157] First, iterate through all files in the storage directory of the external device and filter data packets whose file names match the preset names.

[0158] Optionally, based on the obtained storage directory path, all subdirectories are recursively traversed starting from the root directory of the target storage directory to ensure no omissions. Optionally, based on the preset name format "Riser_[adapter card model]_[firmware version]Update.zip", semi-fuzzy matching is used, requiring the file name to contain "Riser[adapter card model]", allowing flexibility in the "firmware version" field to avoid filtering failures due to differences in version number formats.

[0159] Secondly, if multiple data packets with the same preset name are found, the most recently created data packet is selected as the update packet based on the data packet creation time.

[0160] Optionally, if multiple data packets that meet the criteria are selected, such as versions V2.1 and V2.2 of the same model, the precise creation time of each data packet can be read through the metadata of the external device file system (such as the "creation timestamp" of FAT32 and the "file creation time" field of NTFS); then the multiple data packets are sorted from newest to oldest according to their creation time, and the "most recently created" data packet is selected as the target update packet.

[0161] Optionally, if multiple data packets were created at the exact same time, they can be sorted by file size, and the data packet with the larger number of bytes can be selected; if the data packets are also the same size, the user should be prompted to make a manual selection.

[0162] Finally, if no data packet matching the preset name is found, a data packet acquisition failure message is sent to the basic input / output system.

[0163] Optionally, if no data packet matching the preset name is found, a data packet retrieval failure message is sent to the BIOS update interface. This message may include a fault cause, a correct format example, and troubleshooting suggestions to help the user quickly troubleshoot the problem.

[0164] This application provides an update method for an adapter card. By traversing the storage directory of an external device and filtering data packets with preset names, the method avoids selecting irrelevant files by mistake. When multiple data packets meet the conditions, the method selects the most recent data packet based on its creation time to select the latest firmware version. If no matching packet is found, the method sends a data packet to obtain failure information, which facilitates users to quickly troubleshoot problems.

[0165] Figure 5 This is a schematic diagram of the structure of an adapter card update device provided in one embodiment of this application; as shown. Figure 5 As shown, the adapter card update device provided in this embodiment is located in an electronic device. The adapter card update device 40 provided in this embodiment includes: a receiving module 41, an acquiring module 42, a verification module 43, and a writing module 44.

[0166] Specifically, the receiving module 41 is used to receive the user's update selection for the adapter card in the update interface of the basic input / output system; wherein the update selection includes a firmware file provided by the first memory of the basic input / output system; the obtaining module 42 is used to, in response to the user's selection that the firmware file is provided by the first memory of the basic input / output system, obtain the first firmware file of the adapter card from the first memory of the basic input / output system, and copy the first firmware file to the second memory shared by the baseboard management controller and the basic input / output system; the verification module 43 is used to verify the first firmware file to obtain a first verification code, and send the first verification code to the baseboard management controller; the receiving module 41 is also used to receive the comparison result obtained by the baseboard management controller after comparing the first verification code and the second verification code; wherein the second verification code is obtained by the baseboard management controller after verifying the first firmware file; the writing module 44 is used to write the first firmware file to the corresponding adapter card if the first verification code and the second verification code match, and after the first firmware file is successfully written, send update completion information to the basic input / output system; the basic input / output system displays the update completion result on the boot screen.

[0167] Optionally, when the acquisition module 42 acquires the first firmware file of the adapter card from the first memory of the basic input / output system, it is specifically configured to: send a file read instruction to the first memory of the basic input / output system based on a preset address range; receive the first firmware file sent by the first memory of the basic input / output system; if the first firmware file is not received within a preset time, resend the file read instruction; and in response to the failure to receive the first firmware file after exceeding a preset number of retries, send a read failure message to the basic input / output system, wherein the read failure message includes the preset address range.

[0168] Optionally, when the acquisition module 42 acquires the first firmware file of the adapter card from the first memory of the basic input / output system, it is specifically used to: acquire the unique identifier of the adapter card and locate the target firmware storage partition according to the unique identifier; wherein, multiple firmware storage partitions are pre-allocated in the first memory of the basic input / output system, each firmware storage partition is used to store the firmware file of the corresponding adapter card, and each firmware storage partition is named with the unique identifier of the corresponding adapter card; read the first firmware file from the target firmware storage partition, and the file name of the first firmware file contains a feature code that matches the unique identifier of the adapter card.

[0169] Optionally, the first firmware file may contain matching information for the adapter card.

[0170] Optionally, an adapter card update device may also include a comparison module.

[0171] Optionally, the acquisition module 42 is further configured to: extract the matching information of the adapter card from the preset fields in the header of the first firmware file, the matching information including the model of the target adapter card and the target interface number; the comparison module is configured to: compare the model of the target adapter card with the model of the adapter card to be updated, and compare the target interface number with the actual interface number; the writing module 44 is further configured to: copy the first firmware file to the second storage if the model of the target adapter card matches the model of the adapter card to be updated, and the target interface number matches the actual interface number.

[0172] Optionally, when verifying the first firmware file to obtain the first verification code, the verification module 43 is specifically used to: split the first firmware file into multiple data segments according to the first preset bytes, calculate multiple temporary verification values ​​by using a cyclic redundancy check algorithm for the multiple data segments; sum the multiple temporary verification values ​​to obtain the first verification code; and associate the first verification code with the version number of the first firmware file.

[0173] Optionally, when the writing module 44 writes the first firmware file into the corresponding adapter card if the first verification code and the second verification code match, it is specifically configured to: send an initialization command to the corresponding adapter card if the first verification code and the second verification code match; in response to receiving the initialization completion information returned by the adapter card, split the first firmware file into multiple write sub-data blocks according to the second preset bytes; write the multiple write sub-data blocks into the adapter card sequentially, and after all the multiple write sub-data blocks have been written, send a firmware verification command to the adapter card; receive the verification result fed back by the adapter card after verifying the first firmware file, and if the verification result is qualified, confirm that the first firmware file has been successfully written.

[0174] Optionally, when copying the first firmware file to the second memory shared by the baseboard management controller and the basic input / output system, the acquisition module 42 is specifically used to: detect the remaining storage space of the second memory; if the remaining storage space of the second memory is less than the preset storage space, send a data clearing command to the second memory; and after receiving feedback that the second memory has been cleared, copy the first firmware file to the second memory at a preset transmission rate.

[0175] Optionally, the update option also includes providing firmware files from an external device.

[0176] Optionally, the acquisition module 42 is further configured to: in response to the user's selection that the firmware file be provided by an external device, acquire the path of the storage directory of the external device; based on the path, query the storage directory of the external device for an update package with a preset name, and acquire the update package; wherein the update package includes a second firmware file and a standard checksum; and copy the second firmware file to a second memory shared by the baseboard management controller and the basic input / output system. The verification module 43 is further configured to: verify the second firmware file to obtain a third checksum, send the third checksum to the baseboard management controller, and receive the comparison result between the third checksum and the standard checksum from the baseboard management controller. The writing module 44 is further configured to: if the comparison between the third checksum and the standard checksum is consistent, write the second firmware file into the adapter card, and after the second firmware file is successfully written, send update completion information to the basic input / output system.

[0177] Optionally, when the acquisition module 42 queries and acquires an update package with a preset name from the storage directory of an external device based on a path, it specifically performs the following: traversing all files in the storage directory of the external device and filtering data packets whose file names match the preset name; if multiple data packets with the same preset name are found, selecting the most recently created data packet as the update package based on the data packet creation time; if no data packet with the same preset name is found, sending a data packet acquisition failure message to the basic input / output system.

[0178] It should be noted that the technical effects of the adapter card update device in this embodiment have been explained in the embodiment of the adapter card update method described above, and therefore will not be repeated in this embodiment.

[0179] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, as shown below. Figure 6 As shown, the electronic device 50 provided in the embodiments of this application includes: a data storage device 51 and a data processor 52.

[0180] The data storage 51 stores a computer program, and the data processor 52 is configured to run the computer program to perform the steps in any of the above-described adapter card update method embodiments.

[0181] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described adapter card update method embodiments when running.

[0182] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0183] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a data processor, implements the steps in any of the above-described adapter card update method embodiments.

[0184] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a data processor, implements the steps in any of the above-described adapter card update method embodiments.

[0185] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0186] The solution provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for updating an adapter card, characterized in that, include: The system receives user update selections for the adapter card in the update interface of the basic input / output system; wherein the update selections include firmware files provided by the first memory of the basic input / output system. In response to the user's selection of the firmware file provided by the first memory of the basic input / output system, the first firmware file of the adapter card is obtained from the first memory of the basic input / output system, and the first firmware file is copied to the second memory shared by the baseboard management controller and the basic input / output system; The first firmware file is verified to obtain a first verification code, and the first verification code is sent to the baseboard management controller. The system receives a comparison result obtained by the baseboard management controller after comparing the first verification code and the second verification code; wherein the second verification code is obtained by the baseboard management controller after verifying the first firmware file. If the first verification code and the second verification code match, the first firmware file is written to the corresponding adapter card. After the first firmware file is successfully written, an update completion message is sent to the basic input / output system. The basic input / output system displays the update completion result on the boot screen.

2. The method according to claim 1, characterized in that, The step of retrieving the first firmware file of the adapter card from the first memory of the basic input / output system includes: Based on a preset address range, a file read instruction is sent to the first memory of the basic input / output system; Receive the first firmware file sent by the first memory of the basic input / output system; If the first firmware file is not received within the preset time, the file read command is resent. If the first firmware file is not received after a preset number of retries, a read failure message is sent to the basic input / output system, wherein the read failure message includes the preset address range.

3. The method according to claim 1, characterized in that, The step of retrieving the first firmware file of the adapter card from the first memory of the basic input / output system includes: The unique identifier of the adapter card is obtained, and the target firmware storage partition is located according to the unique identifier; wherein, multiple firmware storage partitions are pre-allocated in the first memory of the basic input / output system, each firmware storage partition is used to store the firmware file of the corresponding adapter card, and each firmware storage partition is named with the unique identifier of the corresponding adapter card. The first firmware file is read from the target firmware storage partition, and the file name of the first firmware file contains a feature code that matches the unique identifier of the adapter card.

4. The method according to claim 3, characterized in that, The first firmware file contains matching information for the adapter card, and the method further includes: Extract the matching information of the adapter card from the preset fields in the header of the first firmware file. The matching information includes the model and target interface number of the target adapter card. The model of the target adapter card is compared with the model of the adapter card to be updated, and the target interface number is compared with the actual interface number. If the model of the target adapter card matches the model of the adapter card to be updated, and the target interface number matches the actual interface number, then the first firmware file is copied to the second memory.

5. The method according to claim 1, characterized in that, The step of verifying the first firmware file to obtain a first verification code includes: The first firmware file is split into multiple data segments according to a first preset byte, and a cyclic redundancy check algorithm is used to calculate multiple temporary check values ​​for the multiple data segments. The multiple temporary verification values ​​are summed to obtain the first verification code; and the first verification code is associated with the version number of the first firmware file.

6. The method according to claim 1, characterized in that, The step of writing the first firmware file into the corresponding adapter card when the first verification code and the second verification code match includes: If the first verification code and the second verification code match, an initialization command is sent to the corresponding adapter card. In response to receiving the initialization completion information returned by the adapter card, the first firmware file is split into multiple write sub-data blocks according to the second preset bytes; Multiple write sub-data blocks are sequentially written into the adapter card, and after all multiple write sub-data blocks have been written, a firmware verification command is sent to the adapter card; The adapter card receives the verification result after verifying the first firmware file, and if the verification result is qualified, it confirms that the first firmware file has been successfully written.

7. The method according to claim 1, characterized in that, The step of copying the first firmware file to the second memory shared by the baseboard management controller and the basic input / output system includes: The remaining storage space of the second memory is detected; If the remaining storage space of the second memory is less than the preset storage space, a data clearing command is sent to the second memory; After receiving feedback that the second memory has been cleared, the first firmware file is copied to the second memory at a preset transmission rate.

8. The method according to any one of claims 1-7, characterized in that, The update option also includes providing firmware files from an external device; the method further includes: In response to the user's selection of the firmware file provided by the external device, the path of the external device's storage directory is obtained; Based on the path, an update package with a preset name is queried from the storage directory of the external device, and the update package is obtained; wherein, the update package includes a second firmware file and a standard checksum; Copy the second firmware file to the second memory shared by the baseboard management controller and the basic input / output system; The second firmware file is verified to obtain a third verification code, and the third verification code is sent to the baseboard management controller. The baseboard management controller then compares the third verification code with the standard verification code. If the third verification code and the standard verification code match, the second firmware file is written into the adapter card, and after the second firmware file is successfully written, an update completion message is sent to the basic input / output system.

9. The method according to claim 8, characterized in that, The step of querying the storage directory of the external device for an update package with a preset name based on the path, and obtaining the update package, includes: Traverse all files in the storage directory of the external device and filter data packets whose file names match the preset names; If multiple data packets with the same preset name are found, the most recently created data packet is selected as the update packet based on the data packet creation time. If no data packet matching the preset name is found, a data packet retrieval failure message is sent to the basic input / output system.

10. An electronic device, characterized in that, include: Data storage device, used to store computer programs; A data processor, configured to implement the steps of the update method for the adapter card as described in any one of claims 1-9 when executing the computer program.

Images