A CPU pass-through architecture server-based in-band hard disk lighting method

Abstract

This invention discloses an in-band hard drive indicator light method for servers based on a CPU passthrough architecture, belonging to the field of server hardware management technology. The method first establishes the mapping relationship between the PCIe bus, device, and function numbers and the physical hard drive slots, pre-setting this mapping relationship in the baseboard management controller. Upon receiving a hard drive indicator light request for a specified drive letter, the method obtains the PCIe bus, device, and function numbers corresponding to the specified drive letter. It then constructs an indicator light command carrying this identifier and sends the command to the baseboard management controller via a standard out-of-band management protocol. The command is parsed to obtain the corresponding identifier, the mapping relationship is queried to determine the physical hard drive slot, and a control signal is sent to drive the corresponding hard drive indicator light. This method does not rely on the hard drive's own attributes, the mapping relationship is stable and reliable, and there is no need to dynamically maintain the mapping table, thus improving the reliability and versatility of in-band indicator light control.

Description

Technical Field

[0001] This invention relates to the field of server hardware management technology, and in particular to a method for lighting up in-band hard drives in a server based on a CPU passthrough architecture. Background Technology

[0002] With the rapid development of cloud computing, big data, and high-performance computing technologies, data centers are constantly expanding in scale. Servers, as the core computing devices in data centers, are seeing continuous improvements in storage capacity and processing power. To meet the demands of massive data storage and high-speed data access, the number and density of hard drives in servers are increasing daily, making hard drive management and maintenance a crucial part of data center operations. During server maintenance, quickly locating physical hard drives by monitoring the illumination or flashing of hard drive indicator lights is a fundamental operation for troubleshooting hard drive failures, replacing hard drives, and allocating storage resources. In traditional server storage architectures, hard drives are typically connected to the server motherboard via SAS or SATA expander backplanes, forming a unified SAS domain. Maintenance personnel can directly send commands within the in-band operating system using standard SCSI chassis service protocols to control the indicator light status of all hard drives under the expander. In recent years, to further improve storage system performance and reduce data transmission latency, CPU-to-hard drive architectures have become increasingly widespread. In this architecture, hard drives are directly connected to the CPU via a high-speed serial channel on the motherboard, without any intermediate expander devices, fully leveraging the read and write performance of the hard drives and making it suitable for applications with high performance requirements.

[0003] Current in-band hard drive LED activation solutions for CPU-to-hard drive architectures primarily employ a mapping method based on hard drive serial numbers to establish the correspondence between drive letters and physical slots. This approach requires reading the target hard drive's serial number within the in-band operating system and simultaneously obtaining the serial numbers of all hard drives in physical slots from the out-of-band management side. A mapping relationship is established through serial number matching before sending the LED activation command. Since reading the hard drive serial number depends on the hard drive's firmware support and the normal operation of the operating system driver, failures to obtain the serial number or inconsistencies may occur when the hard drive is in an abnormal state or when there are differences in implementation between hard drives from different manufacturers, resulting in the inability to establish a mapping relationship. Furthermore, in scenarios involving hot-swapping of hard drives, the correspondence between hard drive serial numbers and drive letters changes. The system needs to continuously monitor hardware events and periodically poll and update the mapping table, making the implementation logic complex and prone to inconsistencies. In addition, this solution relies on the out-of-band management interface provided by the server manufacturer to obtain the hard drive serial number. Differences in firmware interfaces between different manufacturers or generations of circuit board management controllers make the solution difficult to be universally applicable across different hardware platforms. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for lighting up the in-band hard disk of a server based on a CPU passthrough architecture.

[0005] The objective of this invention is achieved through the following technical solution: A method for activating LEDs on an in-band hard drive of a server with a CPU passthrough architecture is provided, the method comprising the following steps: S1. Establish the mapping relationship between PCIe bus, devices and function numbers and physical hard disk slots, and preset the mapping relationship in the baseboard management controller; S2. Receive a hard drive LED activation request for the specified drive letter, and obtain the PCIe bus, device, and function number corresponding to the specified drive letter; S3. Construct an LED lighting command carrying the PCIe bus, device, and function number, and send the LED lighting command to the board management controller via the standard out-of-band management protocol; S4. Parse the LED command to obtain the PCIe bus, device, and function number, query the mapping relationship to obtain the corresponding physical hard drive slot, and send control signals to drive the hard drive indicator light corresponding to the physical hard drive slot.

[0006] Furthermore, step S1 includes the following sub-steps: S1.1. During the server hardware design phase, the SerDes channel connection relationship between the CPU and the hard disk backplane is determined based on the CPU's PCIe channel allocation specifications and the physical layout of the hard disk backplane. S1.2. Based on the motherboard's hardware wiring design and the CPU's hardware specifications, determine the fixed PCIe root port allocation relationship during the server hardware design phase. S1.3. Combining the SerDes channel connection relationship and the PCIe root port allocation relationship, assign a unique corresponding PCIe bus, device and function number to each physical hard disk slot, assign a unique physical hard disk slot identifier to each physical hard disk slot, and generate a mapping table between PCIe bus, device and function number and physical hard disk slot. S1.4. Write the generated mapping table into the non-volatile firmware storage area of ​​the baseboard management controller. When the baseboard management controller firmware starts, automatically load the mapping table in the non-volatile firmware storage area into the running memory of the baseboard management controller.

[0007] Furthermore, step S2 includes the following sub-steps: S2.1. After receiving the hard drive light-up request, extract the specified drive letter information from the hard drive light-up request, traverse all storage device drive letters in the operating system device list, compare the extracted specified drive letter information with the storage device drive letters in the operating system device list, and verify the existence of the specified drive letter in the operating system device list. S2.2. For the specified drive letter that has passed verification, use the standard commands provided by the operating system to read the device node information corresponding to the specified drive letter and obtain the physical device information corresponding to the specified drive letter; S2.3. Extract the PCIe bus, device, and function number fields from the physical device information, check the number of segments and the character length of each segment in the PCIe bus, device, and function number fields, and confirm that the fields conform to the hexadecimal format requirements defined in the PCIe specification. S2.4. Store the verified PCIe bus, device, and function numbers to a temporary cache area. The temporary cache area uses the memory caching mechanism provided by the operating system for data storage.

[0008] Furthermore, step S3 includes the following sub-steps: S3.1. Read the stored PCIe bus, device, and function numbers from the temporary cache area, and use the PCIe bus, device, and function numbers as the target identifier parameters for the LED lighting command; S3.2. According to the message format of the standard out-of-band management protocol, the target identification parameters and indicator light control parameters are encapsulated into a complete light-on command message. A message header and message tail identifier are added to the light-on command message. The message header contains protocol version information and message length information, and the message tail contains checksum information. S3.3. Initiate a connection request to the standard management port of the baseboard management controller, send a connection request message to the standard management port of the baseboard management controller, receive the authentication challenge message returned by the baseboard management controller, and send an authentication response message to complete authentication and communication link establishment; S3.4. Through the established communication link, transmit the packaged LED lighting command message to the substrate management controller and wait for the substrate management controller to receive and confirm the message.

[0009] Furthermore, step S4 includes the following sub-steps: S4.1. Receive the light-on command message from the in-band operating system, calculate the checksum of the light-on command message, compare the calculated checksum with the checksum information at the end of the light-on command message, and verify the integrity and format of the light-on command message. S4.2. Extract the PCIe bus, device, and function number parameters from the verified LED command message according to the field offsets specified in the protocol; S4.3. Read the mapping table in the running memory of the baseboard management controller, and compare the extracted PCIe bus, device and function numbers with the PCIe bus, device and function numbers in the mapping table entries according to the storage order of the mapping table entries; S4.4. Obtain the physical hard disk slot identifier corresponding to the successfully matched mapping table entry, check the value range of the physical hard disk slot identifier, and verify the validity of the physical hard disk slot identifier; S4.5. Generate the corresponding hardware control signal based on the physical hard drive slot identifier, and send the hardware control signal to the control circuit of the hard drive backplane.

[0010] Furthermore, in step S1, when the server hardware topology changes, a new mapping table of PCIe bus, device and function numbers and physical hard disk slots is generated. Server hardware topology changes include replacing the motherboard and replacing the hard disk backplane. When the baseboard management controller firmware starts, the server hardware topology information is automatically detected, and the detected hardware topology information is compared with the historical hardware topology information stored in the baseboard management controller. When the detected hardware topology information is inconsistent with the historical hardware topology information, the SerDes channel connection relationship between the CPU and the hard disk backplane and the PCIe root port allocation relationship are redefined, a new mapping table is generated, and the new mapping table is written to the firmware storage area of ​​the baseboard management controller, overwriting the original mapping table content.

[0011] Furthermore, in step S2.2, physical device information is obtained using the corresponding standard operating system commands for different types of hard drives. The hard drive types include NVMe hard drives and SATA hard drives. For NVMe hard drives, the standard NVMe device query command provided by the operating system is executed, and the complete system attribute information of the NVMe device is output. The PCIe bus, device, and function number fields are extracted from the output information. For SATA hard drives, the standard PCIe device query command provided by the operating system is executed, and the PCIe bus, device, and function number information of all SATA controllers is output. The standard SATA device query command provided by the operating system is executed, and the SATA controller port number information corresponding to the specified drive letter is output, thus determining the PCIe bus, device, and function number information corresponding to the SATA hard drive.

[0012] Furthermore, in step S3.2, the standard out-of-band management protocol includes the Smart Platform Management Interface Protocol and the Redfish Protocol. The Smart Platform Management Interface Protocol adopts a UDP-based transmission method and communicates through the local area network interface of the baseboard management controller. It supports encrypted transmission of commands and user authentication and is suitable for low-bandwidth, high-reliability management scenarios. The Redfish Protocol adopts a RESTful architecture style and communicates through HTTP and HTTPS protocols. It provides a standardized resource model and a unified operation interface and is suitable for high-bandwidth, standardized management scenarios.

[0013] Furthermore, in step S4, the hard disk indicator light is driven to perform the corresponding operation according to the indicator light control mode parameters contained in the light-up command. The indicator light control mode parameters include illumination mode parameters and flashing mode parameters. The illumination mode parameters include the level state information of the indicator light being constantly on, and the flashing mode parameters include the period information and duty cycle information of the indicator light flashing. The period information is used to control the time interval of indicator light state switching, and the duty cycle information is used to control the duration of the indicator light illumination state within one cycle.

[0014] Furthermore, in step S4.5, hardware control signals are sent to the corresponding hardware control chip via a hardware interface. The hardware control chip includes a complex programmable logic device (CPL) and a backplane management chip. The CPL communicates with the baseboard management controller via an I2C bus. After receiving the hardware control signals, it parses the physical hard disk slot identifier and indicator light control mode parameters in the hardware control signals and outputs the corresponding level signals to the hard disk indicator light circuit. The backplane management chip communicates with the baseboard management controller via a parallel interface, integrates the control logic of multiple hard disk indicator lights, and drives the corresponding indicator light pins to output level signals according to the internally preset correspondence between the physical hard disk slots and the indicator light pins.

[0015] The beneficial effects of this invention are: (1) By transferring the anchor point of the light mapping from the variable attributes of the hard disk to the fixed topology attributes of the server hardware, a stable identification correspondence is established, which fundamentally avoids the mapping failure problem caused by relying on the attributes of the hard disk itself. (2) There is no need to continuously monitor and update the mapping relationship in scenarios such as hot-swapping of hard drives, which simplifies the implementation logic of the system and effectively reduces the risk of inconsistent states during system operation; (3) The solution uses an industry standard out-of-band management protocol for communication, without relying on the proprietary interface of a specific vendor, which improves the universality and portability of the solution on different hardware platforms. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a method for lighting up LEDs on an in-band hard drive of a server based on a CPU passthrough architecture. Figure 2 The following is a flowchart illustrating the specific steps of a method for lighting up an in-band hard drive based on a CPU passthrough architecture server, provided as an example. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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.

[0018] Example 1 See Figure 1 This embodiment provides a method for lighting up the in-band hard drive of a server based on a CPU passthrough architecture. The method includes the following steps: S1. Establish the mapping relationship between PCIe bus, devices and function numbers and physical hard disk slots, and preset the mapping relationship in the baseboard management controller; S2. Receive a hard drive LED activation request for the specified drive letter, and obtain the PCIe bus, device, and function number corresponding to the specified drive letter; S3. Construct an LED lighting command carrying the PCIe bus, device, and function number, and send the LED lighting command to the board management controller via the standard out-of-band management protocol; S4. Parse the LED command to obtain the PCIe bus, device, and function number, query the mapping relationship to obtain the corresponding physical hard drive slot, and send control signals to drive the hard drive indicator light corresponding to the physical hard drive slot.

[0019] In some embodiments, step S1 includes the following sub-steps: S1.1. During the server hardware design phase, the SerDes channel connection relationship between the CPU and the hard disk backplane is determined based on the CPU's PCIe channel allocation specifications and the physical layout of the hard disk backplane. S1.2. Based on the motherboard's hardware wiring design and the CPU's hardware specifications, determine the fixed PCIe root port allocation relationship during the server hardware design phase. S1.3. Combining the SerDes channel connection relationship and the PCIe root port allocation relationship, assign a unique corresponding PCIe bus, device and function number to each physical hard disk slot, assign a unique physical hard disk slot identifier to each physical hard disk slot, and generate a mapping table between PCIe bus, device and function number and physical hard disk slot. S1.4. Write the generated mapping table into the non-volatile firmware storage area of ​​the baseboard management controller. When the baseboard management controller firmware starts, automatically load the mapping table in the non-volatile firmware storage area into the running memory of the baseboard management controller.

[0020] In some embodiments, step S2 includes the following sub-steps: S2.1. After receiving the hard drive light-up request, extract the specified drive letter information from the hard drive light-up request, traverse all storage device drive letters in the operating system device list, compare the extracted specified drive letter information with the storage device drive letters in the operating system device list, and verify the existence of the specified drive letter in the operating system device list. S2.2. For the specified drive letter that has passed verification, use the standard commands provided by the operating system to read the device node information corresponding to the specified drive letter and obtain the physical device information corresponding to the specified drive letter; S2.3. Extract the PCIe bus, device, and function number fields from the physical device information, check the number of segments and the character length of each segment in the PCIe bus, device, and function number fields, and confirm that the fields conform to the hexadecimal format requirements defined in the PCIe specification. S2.4. Store the verified PCIe bus, device, and function numbers to a temporary cache area. The temporary cache area uses the memory caching mechanism provided by the operating system for data storage.

[0021] In some embodiments, step S3 includes the following sub-steps: S3.1. Read the stored PCIe bus, device, and function numbers from the temporary cache area, and use the PCIe bus, device, and function numbers as the target identifier parameters for the LED lighting command; S3.2. According to the message format of the standard out-of-band management protocol, the target identification parameters and indicator light control parameters are encapsulated into a complete light-on command message. A message header and message tail identifier are added to the light-on command message. The message header contains protocol version information and message length information, and the message tail contains checksum information. S3.3. Initiate a connection request to the standard management port of the baseboard management controller, send a connection request message to the standard management port of the baseboard management controller, receive the authentication challenge message returned by the baseboard management controller, and send an authentication response message to complete authentication and communication link establishment; S3.4. Through the established communication link, transmit the packaged LED lighting command message to the substrate management controller and wait for the substrate management controller to receive and confirm the message.

[0022] In some embodiments, step S4 includes the following sub-steps: S4.1. Receive the light-on command message from the in-band operating system, calculate the checksum of the light-on command message, compare the calculated checksum with the checksum information at the end of the light-on command message, and verify the integrity and format of the light-on command message. S4.2. Extract the PCIe bus, device, and function number parameters from the verified LED command message according to the field offsets specified in the protocol; S4.3. Read the mapping table in the running memory of the baseboard management controller, and compare the extracted PCIe bus, device and function numbers with the PCIe bus, device and function numbers in the mapping table entries according to the storage order of the mapping table entries; S4.4. Obtain the physical hard disk slot identifier corresponding to the successfully matched mapping table entry, check the value range of the physical hard disk slot identifier, and verify the validity of the physical hard disk slot identifier; S4.5. Generate the corresponding hardware control signal based on the physical hard drive slot identifier, and send the hardware control signal to the control circuit of the hard drive backplane.

[0023] In some embodiments, in step S1, when the server hardware topology changes, a new mapping table of PCIe bus, device and function numbers and physical hard disk slots is generated. The server hardware topology change includes replacing the motherboard and replacing the hard disk backplane. When the baseboard management controller firmware starts, the server hardware topology information is automatically detected, and the detected hardware topology information is compared with the historical hardware topology information stored in the baseboard management controller. When the detected hardware topology information is inconsistent with the historical hardware topology information, the SerDes channel connection relationship between the CPU and the hard disk backplane and the PCIe root port allocation relationship are redefined, a new mapping table is generated, and the new mapping table is written to the firmware storage area of ​​the baseboard management controller, overwriting the original mapping table content.

[0024] In some embodiments, in step S2.2, physical device information is obtained using the corresponding standard operating system commands for different types of hard drives. The hard drive types include NVMe hard drives and SATA hard drives. For NVMe hard drives, the standard NVMe device query command provided by the operating system is executed to output the complete system attribute information of the NVMe device. The PCIe bus, device, and function number fields are extracted from the output information. For SATA hard drives, the standard PCIe device query command provided by the operating system is executed to output the PCIe bus, device, and function number information of all SATA controllers. The standard SATA device query command provided by the operating system is executed to output the SATA controller port number information corresponding to the specified drive letter, thereby determining the PCIe bus, device, and function number information corresponding to the SATA hard drive.

[0025] In some embodiments, in step S3.2, the standard out-of-band management protocol includes the Smart Platform Management Interface Protocol and the Redfish Protocol. The Smart Platform Management Interface Protocol adopts a UDP-based transmission method and communicates through the local area network interface of the baseboard management controller. It supports encrypted transmission of commands and user authentication and is suitable for low-bandwidth, high-reliability management scenarios. The Redfish Protocol adopts a RESTful architecture style and communicates through HTTP and HTTPS protocols. It provides a standardized resource model and a unified operation interface and is suitable for high-bandwidth, standardized management scenarios.

[0026] In some embodiments, in step S4, the hard disk indicator is driven to perform the corresponding operation according to the indicator control mode parameters included in the lighting command. The indicator control mode parameters include lighting mode parameters and flashing mode parameters. The lighting mode parameters include the level state information of the indicator being constantly lit, and the flashing mode parameters include the period information and duty cycle information of the indicator flashing. The period information is used to control the time interval of indicator state switching, and the duty cycle information is used to control the duration of the indicator being lit within one cycle.

[0027] In some embodiments, in step S4.5, hardware control signals are sent to the corresponding hardware control chip via a hardware interface. The hardware control chip includes a complex programmable logic device (CPL) and a backplane management chip. The CPL communicates with the baseboard management controller via an I2C bus. After receiving the hardware control signals, it parses the physical hard disk slot identifier and indicator light control mode parameters in the hardware control signals and outputs the corresponding level signals to the hard disk indicator light circuit. The backplane management chip communicates with the baseboard management controller via a parallel interface, integrates the control logic of multiple hard disk indicator lights, and drives the corresponding indicator light pins to output level signals according to the internally preset correspondence between physical hard disk slots and indicator light pins.

[0028] Example 2 This embodiment provides a specific implementation process for an in-band hard drive indicator light method based on a CPU pass-through architecture server. This process establishes a correspondence between fixed topology attributes of the server hardware and physical hard drive slots, achieving precise control from the operating system drive letter to the hard drive indicator light. It is applicable to CPU-connected hard drive architecture servers without expanders, solving problems such as insufficient reliability, complex dynamic maintenance, and limited versatility inherent in traditional hard drive serial number mapping schemes. Figure 2 As shown, the specific implementation process is as follows: Step 1. Establish mapping relationships and preset: Step 1.1. Determine the SerDes channel connection relationship between the CPU and the hard drive backplane: SerDes is short for serializer and deserializer, a high-speed serial communication technology used to achieve high-speed serialization and parallelization of data in long-distance transmission. In this embodiment, the SerDes channel serves as the data transmission channel between the CPU and the hard drive backplane, and its connection relationship is determined during the server hardware design phase. During the schematic design phase of the server hardware design, based on the CPU's PCIe channel allocation specifications and the physical layout of the hard drive backplane, the SerDes channel corresponding to each CPU's PCIe channel, as well as the physical hard drive slot on the hard drive backplane connected to each SerDes channel, are determined, forming a complete channel connection relationship document. During the PCB routing design phase, routing is performed according to the channel connection relationship document, ensuring that the impedance matching, signal integrity, and electromagnetic compatibility of each SerDes channel meet the design requirements, avoiding signal transmission errors or performance degradation caused by routing problems. After routing is completed, the signal quality of the SerDes channel is simulated and verified using simulation tools to ensure that the channel can stably transmit high-speed data.

[0029] Step 1.2. Determine the fixed PCIe root port allocation relationship during the server hardware design phase: The PCIe root port is a hardware module integrated into the CPU to provide the PCIe bus interface. It is the entry point for communication between PCIe devices and the CPU. Each PCIe root port corresponds to an independent PCIe bus domain. In this embodiment, the allocation relationship of the PCIe root ports is determined by the motherboard's hardware routing design and the CPU's hardware specifications, and remains fixed after hardware production. Based on the motherboard's hardware routing design and the CPU's hardware specifications, determine the CPU pins and motherboard routing corresponding to each PCIe root port, as well as the SerDes channel connected to each PCIe root port, clarifying the number of each PCIe root port in the system and its corresponding hardware resources. During the hardware design phase, it is necessary to allocate the resources of the PCIe root ports reasonably to ensure that each root port has sufficient bandwidth and resources to support the connected hard disk devices, avoiding resource conflicts or insufficient bandwidth problems. At the same time, it is necessary to record the allocation of each PCIe root port in detail in the hardware design document as the basis for subsequent generation of the mapping table.

[0030] Step 1.3. Generate a mapping table between PCIe bus, device, and function numbers and physical hard drive slots: PCIe bus, device, and function numbers are unique identifiers for PCIe devices in a computer system, consisting of a bus number, device number, and function number. They are used by the operating system and hardware management unit to identify and access PCIe devices. In this embodiment, each physical hard drive slot corresponds to a unique PCIe bus, device, and function number. Combining the SerDes channel connection relationship and the PCIe root port allocation relationship, a unique corresponding PCIe bus, device, and function number is assigned to each physical hard drive slot, along with a unique physical hard drive slot identifier. The physical hard drive slot identifier is a numerical code used to distinguish different physical hard drive slots. A one-to-one mapping between the PCIe bus, device, and function numbers and the corresponding physical hard drive slot identifiers is generated, thus creating a mapping table between PCIe bus, device, and function numbers and physical hard drive slots. The mapping table is stored in the form of a two-dimensional table. Each row corresponds to a physical hard disk slot, and each column stores the PCIe bus number, PCIe device number, PCIe function number and physical hard disk slot identifier, ensuring that the mapping table has a clear structure and is easy to query and maintain.

[0031] Step 1.4. Write the mapping table to the non-volatile firmware storage area of ​​the baseboard management controller: The baseboard management controller is a dedicated management processor independent of the server's main CPU and operating system, used to implement functions such as hardware monitoring, remote management, and fault diagnosis of the server. In this embodiment, the baseboard management controller is responsible for receiving the LED command sent in-band and executing hardware control operations. The non-volatile firmware storage area is the storage medium in the baseboard management controller used to store firmware and configuration data. Its characteristic is that the data will not be lost after power failure. In this embodiment, it is used to store the mapping table to ensure that the mapping relationship remains valid after the server is powered off and restarted. The generated mapping table is written to the non-volatile firmware storage area of ​​the baseboard management controller. When the baseboard management controller firmware starts, the mapping table in the non-volatile firmware storage area is automatically loaded into the baseboard management controller's running memory. The running memory is the memory space used by the baseboard management controller to temporarily store running data and programs. Its read and write speed is much higher than that of the non-volatile storage medium, which can improve the query speed of the mapping table. The firmware startup process of the baseboard management controller is divided into a boot phase, an initialization phase, and a running phase. The loading of the mapping table is completed in the initialization phase. After the firmware loading and basic hardware initialization are completed in the boot phase, the system enters the initialization phase, reads the mapping table in the non-volatile firmware storage area and loads it into the running memory, and then enters the running phase to wait for the management commands sent in-band.

[0032] In some embodiments, the mapping table can also be manually updated through the remote management interface of the baseboard management controller. When the server hardware topology changes but automatic detection is not triggered, the administrator can upload the new mapping table to the baseboard management controller through the remote management tool. The baseboard management controller writes the new mapping table to the non-volatile firmware storage area and reloads it into the running memory.

[0033] Step 1.5. Detect Server Hardware Topology Changes and Update the Mapping Table: Server hardware topology refers to the physical connection relationships between various hardware components within the server, including the connection methods and location relationships of components such as the CPU, motherboard, hard drive backplane, and expansion cards. In this embodiment, changes in server hardware topology will cause changes in the correspondence between PCIe bus, device, and function numbers and physical hard drive slots. When the baseboard management controller firmware starts, it automatically detects the server hardware topology information and compares the detected hardware topology information with the historical hardware topology information stored in the baseboard management controller. When the detected hardware topology information is inconsistent with the historical hardware topology information, the SerDes channel connection relationship between the CPU and the hard drive backplane and the PCIe root port allocation relationship are redefined, a new mapping table is generated, and the new mapping table is written to the firmware storage area of ​​the baseboard management controller, overwriting the original mapping table content. Server hardware topology changes include replacing the motherboard and replacing the hard drive backplane. Replacing the motherboard will cause changes in the PCIe root port allocation relationship, and replacing the hard drive backplane will cause changes in the connection relationship between the SerDes channel and the physical hard drive slots. The baseboard management controller detects hardware topology changes by reading electronic tag information on the motherboard and hard drive backplane. The electronic tags store unique identification and configuration information of the hardware components. When the baseboard management controller starts up, it reads the electronic tag information of all hardware components and compares it with the historically stored electronic tag information. If an inconsistency is found, it indicates that the hardware topology has changed.

[0034] In some implementations, when the server hardware topology changes but the automatic detection mechanism is not triggered, the administrator can send a topology detection command through the local or remote management interface of the baseboard management controller to trigger the baseboard management controller to execute a manual topology detection process. Upon receiving the manual topology detection command, the baseboard management controller will pause all currently executing management tasks, rescan all PCIe root ports, obtain the PCIe bus, device, and function number information of all currently connected PCIe devices, and then compare the obtained PCIe bus, device, and function number information with the entries in the original mapping table one by one. If a difference is found between the obtained PCIe bus, device, and function number information and the entries in the original mapping table, it indicates that the hardware topology has indeed changed. The baseboard management controller will, based on the current hardware connection status, redetermine the SerDes channel connection relationship between the CPU and the hard drive backplane and the PCIe root port allocation relationship, and generate a new mapping table. After generating the new mapping table, the baseboard management controller will write the new mapping table to the non-volatile firmware storage area, overwriting the original mapping table content, and reload the new mapping table into the running memory, then resume normal management task execution. The manual topology detection mechanism, as a supplement to the automatic detection mechanism, can effectively solve the problem of automatic detection failure or missed detection, and ensure that the mapping table is always consistent with the current hardware topology.

[0035] Step 2. Obtain the identification information of the target hard drive: Step 2.1. Receive and verify the specified drive letter information in the hard drive light-up request: The hard drive light-up request is an instruction sent by the user or server management software to control the status of the hard drive indicator lights. The instruction contains the drive letter information of the target hard drive and the indicator light control mode information. In this embodiment, the hard drive light-up request is received by the light-up agent tool running in the in-band operating system. The drive letter is the name assigned by the operating system to the storage device for identification and access. In Unix-like operating systems, drive letters usually start with / dev. In this embodiment, the drive letter is the identifier of the hard drive that needs to be lighted up, specified by the user or management software. After receiving the hard drive light-up request, the specified drive letter information in the hard drive light-up request is extracted. All storage device drive letters in the operating system device list are traversed. The operating system device list is a list maintained by the operating system to record all identified hardware devices in the current system, including information such as the name, type, and status of each device. The extracted specified drive letter information is compared with the storage device drive letters in the operating system device list to verify the existence of the specified drive letter in the operating system device list.

[0036] The operating system maintains the device list through the udev device management system. When a new hardware device is connected to the system, udev automatically creates the corresponding device node and adds it to the device list; when a hardware device is removed from the system, udev automatically deletes the corresponding device node and removes it from the device list. The specific implementation of traversing the device list involves reading all subdirectory names under the operating system's / sys / block directory. Each subdirectory name corresponds to a drive letter for a storage device. The extracted drive letter information is compared with these subdirectory names. If a matching name exists, it means the specified drive letter exists; otherwise, it means the specified drive letter does not exist, and the LED agent tool will return an error message.

[0037] Step 2.2. Obtain the physical device information corresponding to the specified drive letter: Physical device information refers to information related to the hardware device itself, including manufacturer information, model information, serial number information, and bus information. In this embodiment, the physical device information is used to extract the PCIe bus, device, and function number corresponding to the target hard drive. For the specified drive letter that has passed verification, the device node information corresponding to the specified drive letter is read using standard commands provided by the operating system. The device node is a special file used by the operating system to represent hardware devices, located in the / dev directory of the operating system. By reading the device node, detailed information about the device can be obtained, thus obtaining the physical device information corresponding to the specified drive letter.

[0038] For different types of hard drives, corresponding standard operating system commands are used to obtain physical device information. Hard drive types include NVMe and SATA hard drives. NVMe hard drives are solid-state drives based on the Non-Volatile Memory Host Controller Interface (NVISI) specification, characterized by high bandwidth and low latency. In this embodiment, the NVMe hard drive is directly connected to the CPU's PCIe root port. For the NVMe hard drive, the standard NVMe device query command provided by the operating system is executed, outputting complete system attribute information of the NVMe device. The PCIe bus, device, and function number fields are extracted from the output information. SATA hard drives are based on the Serial Advanced Technology Attached Interface (SATA), including mechanical hard drives and solid-state drives. In this embodiment, the SATA hard drive is connected to the CPU's PCIe root port through a SATA controller. For the SATA hard drive, the standard PCIe device query command provided by the operating system is executed, outputting the PCIe bus, device, and function number information of all SATA controllers. The standard SATA device query command provided by the operating system is also executed, outputting the SATA controller port number information corresponding to the specified drive letter, thus determining the PCIe bus, device, and function number information corresponding to the SATA hard drive.

[0039] In some specific implementations, when the hard drive is in an abnormal state, traditional solutions based on the hard drive serial number cannot obtain the hard drive's serial number information, resulting in the inability to perform the LED activation operation. The technical solution of this embodiment can effectively solve this problem. When the hard drive fails, goes offline, or is in a read-only state, the hard drive firmware may not be able to respond normally to the command to read the serial number, resulting in traditional solutions being unable to obtain valid serial number information, thus failing to establish the mapping relationship between the drive letter and the physical slot. In this embodiment, even if the hard drive is in an abnormal state, as long as the hard drive's PCIe link remains connected, the operating system can still recognize the hard drive's PCIe device, thereby obtaining the corresponding PCIe bus, device, and function number information. Specifically, when the hard drive fails, the operating system will mark the hard drive as abnormal in the device list, but will not immediately delete the hard drive's device node. The PCIe bus, device, and function number information can still be obtained by reading the attribute file under the / sys directory of the device node. After obtaining the BDF information, the method of this embodiment can be used to send an LED activation command to the baseboard management controller to achieve physical location of the abnormal hard drive, facilitating maintenance personnel to replace the faulty hard drive in a timely manner and reducing server downtime.

[0040] In some embodiments, physical device information can also be obtained through the application programming interface (API) provided by the operating system. The API is a set of functions provided by the operating system for applications to access system resources. By calling the relevant functions, the physical device information corresponding to the specified drive letter can be obtained directly without executing command line commands and parsing the output results.

[0041] Step 2.3. Extract and verify the PCIe bus, device, and function number fields: Extract the PCIe bus, device, and function number fields from the physical device information. Check the number of segments and the character length of each segment to confirm that the fields conform to the hexadecimal format requirements defined in the PCIe specification. The PCIe specification stipulates that the PCIe bus, device, and function numbers consist of three hexadecimal segments, representing the bus number, device number, and function number, respectively. The length and value range of each segment are clearly defined. In this embodiment, checking the field format can avoid subsequent operation failures due to information extraction errors. Specifically, the bus number consists of two hexadecimal digits, with a value range of 00 to FF; the device number consists of two hexadecimal digits, with a value range of 00 to 1F; and the function number consists of one hexadecimal digit, with a value range of 0 to 7. The specific verification steps are as follows: First, the extracted fields are split into three substrings by colons and periods, corresponding to the bus number, device number, and function number, respectively. Then, the length of each substring is checked to ensure it meets the requirements: the bus number and device number must be two digits long, and the function number must be one digit long. Next, each substring is checked to ensure that the characters are valid hexadecimal characters, which include 0 to 9 and A to F. Finally, the value of each substring is checked to ensure it is within the specified range. If all checks pass, the field format is correct; if any check fails, the field format is incorrect, and the lighting agent tool will return an error message.

[0042] Step 2.4. Store the verified PCIe bus, device, and function numbers to a temporary cache area: The temporary cache area is a memory space allocated by the operating system for applications to temporarily store data. It features fast read / write speeds, and the data is cleared after the program exits or the system restarts. In this embodiment, the temporary cache area is used to store the verified PCIe bus, device, and function numbers for subsequent use in constructing LED commands. The temporary cache area uses the operating system's memory caching mechanism for data storage. This mechanism manages the allocation, use, and release of the cache area, ensuring secure and efficient data access. The temporary cache area stores data in key-value pairs, where the key is the specified drive letter and the value is the corresponding PCIe bus, device, and function number information. This facilitates quick retrieval of the corresponding BDF information based on the drive letter. When the LED lighting agent tool exits or the system restarts, the operating system automatically releases the memory space occupied by the temporary cache area, preventing memory leaks.

[0043] Step 3. Construct and send the light-on command: Step 3.1. Read the PCIe bus, device, and function numbers from the temporary cache area: Read the stored PCIe bus, device, and function numbers from the temporary cache area. Use the PCIe bus, device, and function numbers as the target identifier parameter for the LED lighting command. The target identifier parameter is used in the LED lighting command to specify the hard drive to be lit. In this embodiment, the target identifier parameter is the PCIe bus, device, and function number, rather than the hard drive serial number or physical slot number in the traditional solution. When reading data from the temporary cache area, use the specified drive letter information as the key to look up the corresponding PCIe bus, device, and function number information. If the lookup is successful, the obtained BDF information is used as the target identifier parameter; if the lookup fails, it indicates that an error occurred in the previous storage operation, and the LED lighting agent tool will return an error message.

[0044] Step 3.2. Encapsulate the LED lighting command message according to the message format of the standard out-of-band management protocol: The standard out-of-band management protocol is a communication protocol used to realize remote server management. Its characteristic is that it does not depend on the running status of the server's main CPU and operating system. Even if the server's main operating system crashes, the server can still be managed through the out-of-band management protocol. In this embodiment, the standard out-of-band management protocol is used to transmit LED lighting commands between the in-band operating system and the baseboard management controller. According to the message format of the standard out-of-band management protocol, the target identification parameters and indicator light control parameters are encapsulated into a complete LED lighting command message. A message header and a message trailer identifier are added to the LED lighting command message. The message header contains protocol version information and message length information, and the message trailer contains checksum information. The protocol version information is used to identify the version of the out-of-band management protocol used to ensure that both communicating parties can correctly parse the message; the message length information is used to identify the total length of the message, making it convenient for the receiver to read the complete message; the checksum information is used to verify whether the message has been damaged or tampered with during transmission.

[0045] Standard out-of-band management protocols include the Intelligent Platform Management Interface (IPMI) protocol and the Redfish protocol. The IMI protocol is a widely used standard protocol for server management. It uses UDP-based transmission and communicates through the LAN interface of the baseboard management controller. It supports encrypted command transmission and user authentication, making it suitable for low-bandwidth, high-reliability management scenarios. The IMI request message structure includes a network function code, command code, data length, data field, and checksum field. The network function code identifies the function category of the command, the command code identifies the specific command, the data length indicates the length of the data field, the data field carries the command's parameter information, and the checksum field verifies the integrity of the message. The Redfish protocol is a next-generation server management protocol based on a RESTful architecture. It communicates via HTTP and HTTPS protocols, providing a standardized resource model and a unified operation interface, suitable for high-bandwidth, standardized management scenarios. The Redfish request message structure includes an HTTP method, URI, request headers, and request body. The HTTP method specifies the operation type, the URI specifies the resource to be operated on, the request headers carry protocol-related information, and the request body carries the command's parameter information.

[0046] In some embodiments, other standard out-of-band management protocols can also be used for communication, such as the Simple Network Management Protocol (SMMP), which is a standard protocol for network device management. SMMP describes the status and configuration information of devices by defining a management information base, and supports remote monitoring and configuration of devices.

[0047] Step 3.3. Complete authentication and establish a communication link: Initiate a connection request to the standard management port of the baseboard management controller, send a connection request message to the standard management port of the baseboard management controller, receive the authentication challenge message returned by the baseboard management controller, and send an authentication response message to complete authentication and establish a communication link. Authentication is to ensure that only authorized users or applications can send management commands to the baseboard management controller, preventing unauthorized access and operation. In this embodiment, a challenge-response mechanism is used for authentication. The baseboard management controller generates a random challenge value and sends it to the client. The client encrypts the challenge value using a pre-shared key and returns it to the baseboard management controller. The baseboard management controller verifies the correctness of the encryption result, and establishes a communication link after successful verification. The challenge value is a randomly generated byte sequence, typically 16 or 32 bytes in length. The baseboard management controller uses a hardware random number generator to generate the challenge value, ensuring its randomness and unpredictability. The client uses the HMAC-SHA256 algorithm to encrypt the challenge value, and the encryption key is a shared key pre-configured between the baseboard management controller and the lamp agent tool. After receiving the encrypted response value, the baseboard management controller encrypts the challenge value using the same key and algorithm, and then compares the encryption result with the received response value. If they match, the authentication is successful; if they do not match, the authentication fails, the baseboard management controller will refuse to establish a communication link and return an error message.

[0048] In some implementations, to enhance communication security, after authentication, the lighting agent and the baseboard management controller negotiate a session key for encrypting command messages during subsequent communication. The session key negotiation employs the Diffie-Hellman key exchange algorithm, which securely exchanges keys over insecure communication channels, ensuring that only the communicating parties can access the session key. Specifically, the lighting agent and the baseboard management controller each generate a private key and a public key, then send the public key to each other. Both parties use their private key and the other's public key to calculate an identical shared key, which is the session key. The session key is valid for one communication session. When the communication session ends, the session key is automatically destroyed, and a new session key is renegotiated for the next communication. Using the session key to encrypt command messages effectively prevents eavesdropping or tampering during transmission, thus improving communication security.

[0049] Step 3.4. Transmitting the LED Lighting Command Message and Waiting for Acknowledgment: Through the established communication link, the encapsulated LED lighting command message is transmitted to the baseboard management controller, awaiting acknowledgment from the baseboard management controller. Upon receiving the LED lighting command message, the baseboard management controller returns an acknowledgment message to the sender, informing them that the message has been successfully received. If the sender does not receive the acknowledgment message within a set time, it will resend the LED lighting command message to ensure reliable command transmission. The acknowledgment message contains the message's sequence number and reception status information. The sequence number identifies the corresponding LED lighting command message, and the reception status information informs the sender whether the message has been successfully received. If the reception status information is successful, it indicates that the baseboard management controller has successfully received the LED lighting command message; if the reception status information is unsuccessful, it indicates that an error occurred during message reception, and the LED lighting agent will resend the LED lighting command message.

[0050] In some implementations, to address the issue of lost LED lighting command messages due to network instability, the LED lighting proxy tool implements a sliding window-based retransmission mechanism to ensure reliable transmission of command messages to the baseboard management controller. The proxy tool assigns a unique sequence number to each sent LED lighting command message and stores the message in a transmission buffer, while simultaneously starting a timer. When a receive acknowledgment message is received from the baseboard management controller, the proxy tool removes the corresponding message from the transmission buffer and stops the corresponding timer. If no receive acknowledgment message is received before the timer expires, the proxy tool considers the message lost and retransmits it. The size of the sliding window can be dynamically adjusted according to network conditions. When network conditions are good, the sliding window size is increased to improve transmission efficiency; when network conditions are poor, the sliding window size is decreased to reduce the number of retransmissions. The number of retransmissions is set to a preset value. If no receive acknowledgment message is received after the preset number of retransmissions, the proxy tool returns an error message informing the user that the LED lighting operation has failed and prompting the user to check the network connection or the status of the baseboard management controller.

[0051] Step 4. Parse the command and drive the indicator light: Step 4.1. Receive and verify the integrity and format of the LED lighting command message: Receive the LED lighting command message from the in-band operating system, calculate the checksum of the LED lighting command message, and compare the calculated checksum with the checksum information at the end of the LED lighting command message to verify the integrity and format of the LED lighting command message. The checksum is a value obtained by performing specific mathematical operations on the message content. It is used to verify whether the message has been damaged or tampered with during transmission. If the calculated checksum is inconsistent with the checksum at the end of the message, it indicates that an error occurred during transmission, and the board management controller will discard the message and request a retransmission. Different out-of-band management protocols use different checksum algorithms. The intelligent platform management interface protocol uses an 8-bit cyclic redundancy check algorithm, while the Redfish protocol uses the checksum mechanism built into the TCP protocol. The specific steps for calculating the checksum are to first accumulate all bytes of the message header and data fields in sequence, and then take the modulo of the accumulated result to obtain the checksum value. After receiving a message, the baseboard management controller recalculates the checksum using the same algorithm, and then compares the calculated checksum with the checksum at the end of the message. If they match, it means the message is complete and has not been tampered with; if they do not match, it means an error occurred during the transmission of the message.

[0052] Step 4.2. Extract PCIe bus, device, and function number parameters from the LED light command message: Extract the PCIe bus, device, and function number parameters from the verified LED light command message according to the field offsets specified in the protocol. The field offset refers to the number of bytes from the starting position of a field in the message relative to the message header, as defined by the out-of-band management protocol specification. In this embodiment, the required parameters can be accurately extracted from the message using the field offset. For messages from the Intelligent Platform Management Interface Protocol, the PCIe bus, device, and function number parameters are located at the beginning of the data field, with an offset of 0 and a length of 4 bytes. For messages from the Redfish protocol, the PCIe bus, device, and function number parameters are located in the JSON object of the request body, extracted using the key "pcieBdf". After extracting the parameters, the format needs to be validated again to ensure that the parameters conform to the format requirements defined by the PCIe specification, avoiding subsequent operation failures due to incorrect parameters.

[0053] Step 4.3. Query the mapping table to obtain the corresponding physical hard disk slot identifier: Read the mapping table in the baseboard management controller's running memory. According to the storage order of the mapping table entries, compare the extracted PCIe bus, device, and function numbers with the PCIe bus, device, and function numbers in the mapping table entries. A mapping table entry is each row of data in the mapping table, containing a PCIe bus, device, and function number and the corresponding physical hard disk slot identifier. In this embodiment, by comparing each entry one by one, a mapping table entry matching the extracted PCIe bus, device, and function number can be found. When the number of mapping table entries is small, a sequential query algorithm is used, comparing each entry one by one until a matching entry is found or all entries are traversed. When the number of mapping table entries is large, a hash query algorithm is used, using the PCIe bus, device, and function number as the hash key to calculate the hash value, and then directly locating the corresponding mapping table entry based on the hash value, improving query speed. When loading the mapping table, the baseboard management controller automatically selects an appropriate query algorithm based on the number of entries in the mapping table to ensure query efficiency.

[0054] Step 4.4. Verify the validity of the physical hard drive slot identifier: Obtain the physical hard drive slot identifier corresponding to the successfully matched mapping table entry, check the value range of the physical hard drive slot identifier, and verify the validity of the physical hard drive slot identifier. The value range of the physical hard drive slot identifier is determined by the number of physical slots on the server hard drive backplane. In this embodiment, checking the value range of the physical hard drive slot identifier can avoid incorrect LED operation caused by mapping table errors. When the baseboard management controller starts up, it reads the configuration information of the hard drive backplane, obtains the number of physical slots on the hard drive backplane, and determines the value range of the physical hard drive slot identifier. If the obtained physical hard drive slot identifier is within the value range, it means that the identifier is valid; if the identifier is not within the value range, it means that there is an error in the mapping table, and the baseboard management controller will return an error message, indicating that the in-band operating system LED operation failed.

[0055] Step 4.5. Generate hardware control signals and send them to the control circuit of the hard drive backplane: Generate corresponding hardware control signals based on the physical hard drive slot identifiers and send the hardware control signals to the control circuit of the hard drive backplane. Hardware control signals are electrical signals used to control the operation of hardware circuits. In this embodiment, the hardware control signals include physical hard drive slot identifiers and indicator light control mode information, used to control the indicator light status of the specified physical hard drive slot.

[0056] Hardware control signals are sent to the corresponding hardware control chip via a hardware interface. The hardware control chip includes a complex programmable logic device (CPL) and a backplane management chip. A CPL is a programmable digital logic device that allows users to configure its internal logic circuits to achieve specific functions. In this embodiment, the CPL communicates with the baseboard management controller via an I2C bus. After receiving the hardware control signals, it parses the physical hard disk slot identifier and indicator light control mode parameters from the hardware control signals and outputs the corresponding level signals to the hard disk indicator light circuit. The I2C bus is a serial communication bus used for short-distance communication between integrated circuits, characterized by few pins and a simple structure.

[0057] The I2C bus communication timing includes start signal, stop signal, data transmission signal, and acknowledge signal. The baseboard management controller acts as the master device, and the complex programmable logic device (CPLD) acts as the slave device. The master device initiates communication, and the slave device responds. The backplane management chip is an integrated circuit specifically designed for hard drive backplane management, integrating functions such as hard drive indicator light control, temperature monitoring, and power management. In this embodiment, the backplane management chip communicates with the baseboard management controller via a parallel interface, integrating control logic for multiple hard drive indicator lights. Based on the internally preset correspondence between physical hard drive slots and indicator light pins, it drives the corresponding indicator light pins to output level signals. A parallel interface is a communication interface that transmits multiple bits of data simultaneously, characterized by high transmission speed. The number of data lines in a parallel interface is typically 8 or 16 bits, enabling the simultaneous transmission of control signals for multiple physical hard drive slots.

[0058] In some embodiments, the hardware control chip may also be a field-programmable gate array (FPGA), which is a high-density programmable logic device with higher logic resources and faster operating speed, and is capable of implementing more complex control logic.

[0059] Step 4.6. Drive the hard drive indicator light according to the indicator light control mode parameters: Based on the indicator light control mode parameters contained in the lighting command, drive the hard drive indicator light to perform the corresponding operation. The indicator light control mode parameters include illumination mode parameters and blinking mode parameters. The illumination mode parameters contain the level state information for the indicator light to remain constantly on, used to control the hard drive indicator light to maintain a constant illumination state. The blinking mode parameters contain the blinking period information and duty cycle information for the indicator light. The period information is used to control the time interval between indicator light state switching, and the duty cycle information is used to control the duration of the indicator light's illumination state within one cycle. The hard drive indicator light circuit typically consists of an LED and a current-limiting resistor. The anode of the LED is connected to the output pin of the hardware control chip, and the cathode is connected to ground through the current-limiting resistor. When the hardware control chip outputs a high level, the LED conducts, and the indicator light illuminates; when the hardware control chip outputs a low level, the LED is cut off, and the indicator light turns off. For the blinking mode, the hardware control chip will alternately output high and low levels according to the set period and duty cycle, causing the indicator light to blink at the set frequency.

[0060] In some specific implementations, to ensure users can promptly understand the execution result of the LED lighting operation, the baseboard management controller sends an operation result feedback message to the in-band operating system after completing the operation. This message includes information on whether the operation was successful and the current status of the hard drive indicator lights. The operation result feedback message is encapsulated using the same out-of-band management protocol format as the LED lighting command message and transmitted to the LED lighting agent tool via the previously established communication link. Upon receiving the feedback message, the LED lighting agent tool parses the operation result information and indicator light status information and displays this information to the user. If the LED lighting operation is successful, the feedback message will include the target hard drive's PCIe bus, device and function number information, the corresponding physical hard drive slot identifier information, and the current indicator light status information. If the LED lighting operation fails, the feedback message will include the reason for the failure, such as the PCIe bus, device and function number not existing, the physical hard drive slot identifier being invalid, or hardware control chip communication failure. Users can understand the execution status of the LED lighting operation based on the feedback information. If the operation fails, they can troubleshoot and handle the problem according to the cause of failure, improving the efficiency and convenience of operation and maintenance.

[0061] In some embodiments, the indicator light control mode parameters may further include an off mode parameter, which is used to control the hard disk indicator light to remain off and to turn off the indicator light after the hard disk positioning is completed.

[0062] This embodiment establishes a stable and reliable mapping relationship between the PCIe bus, device and function numbers, and physical hard drive slots by transferring the anchor point of the indicator light mapping from the variable attributes of the hard drive to the fixed topology attributes of the server hardware. This avoids mapping failures caused by hard drive serial number acquisition failures, thus improving the reliability of indicator light control. The mapping relationship remains stable throughout the server's lifecycle, eliminating the need for dynamic maintenance of the mapping table in scenarios such as hard drive hot-swapping, simplifying the system implementation logic and reducing system complexity and maintenance costs. Communication is achieved using a standard out-of-band management protocol, independent of specific vendors' proprietary interfaces for baseboard management controllers, improving the versatility and portability of the solution across different hardware platforms. It enables precise control from the operating system drive letter to the physical hard drive indicator light in a CPU-to-hard drive architecture without expanders, meeting the need for rapid physical hard drive location in data center server maintenance and improving the efficiency and accuracy of server maintenance. Furthermore, the technical solution of this embodiment also has good scalability, supporting different types of hard drives and different out-of-band management protocols, making it suitable for various application scenarios. By adding mechanisms such as manual topology detection, abnormal hard disk BDF acquisition, command retransmission, and operation result feedback, the reliability, stability, and ease of use of the solution are further improved, which can better meet the needs of practical engineering applications.

[0063] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for in-band hard disk lighting based on a CPU pass-through architecture server, characterized in that, Includes the following steps: S1. Establish the mapping relationship between PCIe bus, devices and function numbers and physical hard disk slots, and preset the mapping relationship in the baseboard management controller; S2. Receive a hard drive LED activation request for the specified drive letter, and obtain the PCIe bus, device, and function number corresponding to the specified drive letter; S3. Construct an LED lighting command carrying the PCIe bus, device, and function number, and send the LED lighting command to the board management controller via the standard out-of-band management protocol; S4. Parse the LED command to obtain the PCIe bus, device, and function number, query the mapping relationship to obtain the corresponding physical hard drive slot, and send control signals to drive the hard drive indicator light corresponding to the physical hard drive slot.

2. The method according to claim 1, characterized in that, Step S1 includes the following sub-steps: S1.

1. During the server hardware design phase, the SerDes channel connection relationship between the CPU and the hard disk backplane is determined based on the CPU's PCIe channel allocation specifications and the physical layout of the hard disk backplane. S1.

2. Based on the motherboard's hardware wiring design and the CPU's hardware specifications, determine the fixed PCIe root port allocation relationship during the server hardware design phase. S1.

3. Combining the SerDes channel connection relationship and the PCIe root port allocation relationship, assign a unique corresponding PCIe bus, device and function number to each physical hard disk slot, assign a unique physical hard disk slot identifier to each physical hard disk slot, and generate a mapping table between PCIe bus, device and function number and physical hard disk slot. S1.

4. Write the generated mapping table into the non-volatile firmware storage area of ​​the baseboard management controller. When the baseboard management controller firmware starts, automatically load the mapping table in the non-volatile firmware storage area into the running memory of the baseboard management controller.

3. The method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S2.

1. After receiving the hard drive light-up request, extract the specified drive letter information from the hard drive light-up request, traverse all storage device drive letters in the operating system device list, compare the extracted specified drive letter information with the storage device drive letters in the operating system device list, and verify the existence of the specified drive letter in the operating system device list. S2.

2. For the specified drive letter that has passed verification, use the standard commands provided by the operating system to read the device node information corresponding to the specified drive letter and obtain the physical device information corresponding to the specified drive letter; S2.

3. Extract the PCIe bus, device, and function number fields from the physical device information, check the number of segments and the character length of each segment in the PCIe bus, device, and function number fields, and confirm that the fields conform to the hexadecimal format requirements defined in the PCIe specification. S2.

4. Store the verified PCIe bus, device, and function numbers to a temporary cache area. The temporary cache area uses the memory caching mechanism provided by the operating system for data storage.

4. The method according to claim 1, characterized in that, Step S3 includes the following sub-steps: S3.

1. Read the stored PCIe bus, device, and function numbers from the temporary cache area, and use the PCIe bus, device, and function numbers as the target identifier parameters for the LED lighting command; S3.

2. According to the message format of the standard out-of-band management protocol, the target identification parameters and indicator light control parameters are encapsulated into a complete light-on command message. A message header and message tail identifier are added to the light-on command message. The message header contains protocol version information and message length information, and the message tail contains checksum information. S3.

3. Initiate a connection request to the standard management port of the baseboard management controller, send a connection request message to the standard management port of the baseboard management controller, receive the authentication challenge message returned by the baseboard management controller, and send an authentication response message to complete authentication and communication link establishment; S3.

4. Through the established communication link, transmit the packaged LED lighting command message to the board management controller and wait for the board management controller to receive and confirm the message.

5. The method according to claim 1, characterized in that, Step S4 includes the following sub-steps: S4.

1. Receive the light-on command message from the in-band operating system, calculate the checksum of the light-on command message, compare the calculated checksum with the checksum information at the end of the light-on command message, and verify the integrity and format of the light-on command message. S4.

2. Extract the PCIe bus, device, and function number parameters from the verified LED command message according to the field offsets specified in the protocol; S4.

3. Read the mapping table in the running memory of the baseboard management controller, and compare the extracted PCIe bus, device and function numbers with the PCIe bus, device and function numbers in the mapping table entries according to the storage order of the mapping table entries; S4.

4. Obtain the physical hard disk slot identifier corresponding to the successfully matched mapping table entry, check the value range of the physical hard disk slot identifier, and verify the validity of the physical hard disk slot identifier; S4.

5. Generate the corresponding hardware control signal based on the physical hard drive slot identifier, and send the hardware control signal to the control circuit of the hard drive backplane.

6. The method according to claim 1, characterized in that, In step S1, when the server hardware topology changes, a new mapping table of PCIe bus, device and function numbers and physical hard disk slots is generated. Server hardware topology changes include replacing the motherboard and replacing the hard disk backplane. When the baseboard management controller firmware starts, the server hardware topology information is automatically detected and compared with the historical hardware topology information stored in the baseboard management controller. When the detected hardware topology information is inconsistent with the historical hardware topology information, the SerDes channel connection relationship between the CPU and the hard disk backplane and the PCIe root port allocation relationship are redefined, a new mapping table is generated, and the new mapping table is written to the firmware storage area of ​​the baseboard management controller, overwriting the original mapping table content.

7. The method according to claim 3, characterized in that, In step S2.2, physical device information is obtained using the corresponding standard operating system commands for different types of hard drives. The hard drive types include NVMe hard drives and SATA hard drives. For NVMe hard drives, the standard NVMe device query command provided by the operating system is executed, and the complete system attribute information of the NVMe device is output. The PCIe bus, device, and function number fields are extracted from the output information. For SATA hard drives, the standard PCIe device query command provided by the operating system is executed, and the PCIe bus, device, and function number information of all SATA controllers is output. The standard SATA device query command provided by the operating system is executed, and the SATA controller port number information corresponding to the specified drive letter is output, thus determining the PCIe bus, device, and function number information corresponding to the SATA hard drive.

8. The method according to claim 4, characterized in that, In step S3.2, the standard out-of-band management protocol includes the intelligent platform management interface protocol and the Redfish protocol. The intelligent platform management interface protocol adopts a UDP-based transmission method and communicates through the local area network interface of the baseboard management controller. It supports encrypted transmission of commands and user authentication and is suitable for low-bandwidth, high-reliability management scenarios. The Redfish protocol adopts a RESTful architecture style and communicates through HTTP and HTTPS protocols. It provides a standardized resource model and a unified operation interface and is suitable for high-bandwidth, standardized management scenarios.

9. The method according to claim 1, characterized in that, In step S4, the hard disk indicator light is driven to perform the corresponding operation according to the indicator light control mode parameters contained in the light-up command. The indicator light control mode parameters include illumination mode parameters and flashing mode parameters. The illumination mode parameters include the level state information of the indicator light being constantly on, and the flashing mode parameters include the period information and duty cycle information of the indicator light flashing. The period information is used to control the time interval of indicator light state switching, and the duty cycle information is used to control the duration of the indicator light illumination state within one cycle.

10. The method according to claim 5, characterized in that, In step S4.5, hardware control signals are sent to the corresponding hardware control chip via a hardware interface. The hardware control chip includes a complex programmable logic device (CPL) and a backplane management chip. The CPL communicates with the baseboard management controller via an I2C bus. After receiving the hardware control signals, it parses the physical hard disk slot identifier and indicator light control mode parameters in the hardware control signals and outputs the corresponding level signals to the hard disk indicator light circuit. The backplane management chip communicates with the baseboard management controller via a parallel interface, integrates the control logic of multiple hard disk indicator lights, and drives the corresponding indicator light pins to output level signals according to the internally preset correspondence between the physical hard disk slots and the indicator light pins.

Images