Address processing method of hardware device and electronic device

Abstract

This application provides a hardware device address processing method and an electronic device; applied to a Unified Extensible Firmware Interface (UEFI), wherein the UEFI is used to allocate addresses to a plurality of first hardware devices during initialization; the plurality of first hardware devices include a Baseboard Management Controller (BMC) and / or at least one second hardware device managed by the BMC; the method includes: in response to the triggering of an address update event of a hardware device, obtaining a first address of a target device associated with the address update event; the target device is any one of the plurality of first hardware devices; determining a first address information table based on the first address of the target device; writing the first address information table into a first register, and notifying the BMC to read the first address information table from the first register via an interrupt signal; wherein the BMC is used to perform Management Component Transport Protocol (MCTP) discovery based on the first address information table; the first register supports being read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register are independent of the operation of the electronic device's operating system.

Description

Technical Field

[0001] This application relates to communication technology, and more particularly to an address processing method for a hardware device and an electronic device. Background Technology

[0002] When the address of a hardware device is updated, since BMC currently does not have a good method to obtain the updated hardware device address, it may cause communication abnormalities and increase communication problems for the device. Summary of the Invention

[0003] This application provides an address processing method for a hardware device and an electronic device.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides an address processing method for a hardware device, applied to a Unified Extensible Firmware Interface (UEFI). The UEFI is used to allocate addresses to multiple first hardware devices during initialization. The multiple first hardware devices include a Baseboard Management Controller (BMC) and / or at least one second hardware device managed by the BMC. The method includes: in response to an address update event of a hardware device, obtaining a first address of a target device associated with the address update event; the target device is any one of the multiple first hardware devices; determining a first address information table based on the first address of the target device; writing the first address information table to a first register, and notifying the BMC to read the first address information table from the first register via an interrupt signal; wherein the BMC is used to perform Management Component Transport Protocol (MCTP) discovery based on the first address information table; the first register is readable and writable by both the BMC and the UEFI, and the read / write operations of the BMC and the UEFI on the first register are independent of the operating system of the electronic device.

[0005] This application provides an address processing method for a hardware device, applied to a BMC (Browser Control Center), which manages at least one second hardware device. The method includes: in response to receiving an interrupt signal, obtaining a first address information table by reading a first register; the first address information table is determined and written by a UEFI (User Equipment) based on a first address of a target device associated with the address update event, in response to an address update event of the hardware device; the first register is readable and writable by the BMC and the UEFI, and the read / write operations of the BMC and the UEFI on the first register are independent of the operation of the electronic device's operating system; based on the first address information table, performing MCTP (Multi-Channel Communication Protocol) discovery to allocate a logical address for each second hardware device and establish an MCTP communication route for each second hardware device.

[0006] This application provides an electronic device, which includes a UEFI and a plurality of first hardware devices, wherein the plurality of first hardware devices include a BMC and at least one second hardware device managed by the BMC; the UEFI is used to allocate addresses to the plurality of first hardware devices during initialization; the BMC is used to manage at least one second hardware device; wherein the UEFI is used to obtain a first address of a target device associated with the address update event in response to the triggering of an address update event of a hardware device; the target device is any one of the plurality of first hardware devices; a first address information table is determined based on the first address of the target device; the first address information table is written to a first register, and the BMC is notified to read the first address information table from the first register through an interrupt signal; the first register supports being read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the operating system of the electronic device; the BMC is used to obtain the first address information table by reading the first register in response to receiving an interrupt signal; and to perform MCTP discovery based on the first address information table to allocate logical addresses for each second hardware device and establish MCTP communication routes for each second hardware device. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 1 ; Figure 2 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 2 ; Figure 3 This is a schematic diagram of the hardware entity of an electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 3 ; Figure 4 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 5 ; Figure 5 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 6 ; Figure 6 This is a schematic diagram of the implementation flow of an address processing method for a hardware device provided in an embodiment of this application. Figure 7 ; Figure 7This is a schematic diagram illustrating a communication implementation between UEFI and BMC provided in an embodiment of this application.

[0008] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] This application provides an address processing method for a hardware device, applied to a Unified Extensible Firmware Interface (UEFI). The UEFI is used to allocate addresses to multiple first hardware devices during initialization. The multiple first hardware devices include a Baseboard Management Controller (BMC) and / or at least one second hardware device managed by the BMC. Figure 8 As shown, the method includes steps S100 to S120: Step S100: In response to the triggering of an address update event of a hardware device, obtain the first address of the target device associated with the address update event; the target device is any one of the plurality of first hardware devices; Here, the Unified Extensible Firmware Interface (UEFI) serves as a crucial bridge connecting hardware and the operating system in modern computer systems. It can be understood as the core software that runs first during computer startup, responsible for initializing the hardware and booting the operating system. Essentially, it's a standardized firmware interface that replaces the traditional basic input / output system. The basic workflow of UEFI includes the power-on initialization phase, the driver execution environment phase, the startup services phase, and the system handover phase. The driver execution environment phase is responsible for loading drivers, initializing most hardware, building the firmware tables required for system management, and ultimately preparing a usable hardware platform for the operating system. In essence, UEFI initializes multiple primary hardware devices during the driver execution environment phase.

[0011] Hardware devices refer to devices connected to a computer system via the Peripheral Component Interconnect Express (PCIe) bus. It is understood that the hardware devices in this application can also be referred to as PCIe devices.

[0012] In some implementations, the hardware device may include, but is not limited to, one of the following: a Baseboard Management Controller (BMC), a graphics card, a network card, a solid-state drive, a sound card, an accelerator card, etc.

[0013] The address of a hardware device is a crucial identifier used to locate and access device resources in the PCIe bus architecture, involving address space partitioning, the base address register (BAR) mechanism, and configuration procedures. It is understood that the address of the hardware device in this application can also be referred to as a PCIe address.

[0014] The baseboard manager is an embedded management chip on the server motherboard, independent of the main system, responsible for remote monitoring and management of hardware devices. It continues to function normally even if the main operating system crashes or the server is shut down, making it a key component for ensuring high server availability.

[0015] In some implementations, the second hardware device may include, but is not limited to, one of the following: a network card, a graphics card, a solid-state drive, an accelerator card, etc.

[0016] In some implementations, an address update event can refer to a system power-on event, which is the process by which an electronic device goes from a completely power-off state (without any voltage supply) to having its hardware powered on and initialized, ultimately becoming ready for the operating system to run.

[0017] In some implementations, an address update event can refer to a hot-plug event, where a hot-plug event is an event in which a hardware device is inserted during system operation, the system detects this action, and takes appropriate action.

[0018] In this application, the target device is associated with the address update event. For example, when the address update event is a system power-on event, the target device may refer to the BMC. When the address update event is a hot-plug event, the target device may refer to a second hardware device that supports hot-plugging.

[0019] In some implementations, the first address of the target device can refer to either the address of the target device before the update or the address of the target device after the update. In this application, when the address update event is a hot-plug event, since a second hardware device is inserted into the system (i.e., the second hardware device is a newly connected device), the system does not include the address of the newly connected device. In this scenario, the first address of the target device refers to the address of the target device after the update. When the address update event is a system power-on event, it triggers a change in the address of the BMC. In this scenario, the first address of the target device can refer to the address of the target device before the update.

[0020] Step S110: Determine the first address information table based on the first address of the target device; Here, the first address information table stores the addresses assigned by UEFI to multiple first hardware devices.

[0021] In some implementations, when the first address represents the updated address, the first address is updated in the address information table currently stored in the UEFI to obtain the first address information table.

[0022] In some implementations, when the first address represents the address before the update, and when the first address is different from the updated address, the updated address is added to the address information table currently stored in the UEFI to obtain the first address information table. Alternatively, when the first address is the same as the updated address, the address information table currently stored in the UEFI is determined as the first address information table.

[0023] Step S120: Write the first address information table into the first register, and notify the BMC to read the first address information table from the first register via an interrupt signal; wherein, the BMC is used to perform Management Component Transport Protocol (MCTP) discovery based on the first address information table; the first register supports being read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the electronic device's operating system.

[0024] Here, the Management Component Transport Protocol (MCTP) is used to identify and enumerate all devices in the network that support the MCTP protocol, and to assign a unique endpoint identifier to each device, thus establishing the basis for management communication.

[0025] In some implementations, the BMC and UEFI exchange information through a first register. In practice, after the UEFI obtains the first address information table, it writes the first address information table into the first register. After the first register detects the presence of data, it triggers an interrupt to generate an interrupt signal to notify the BMC. After receiving the signal, the BMC reads the first address information table from the first register.

[0026] It should be noted that the BMC and UEFI are hardware execution entities independent of the main operating system, each with its own processor, memory, and runtime environment. Communication between these two hardware devices is based on an out-of-band communication mechanism. This communication process involves the BMC and UEFI writing data to the hardware register (i.e., the first register mentioned above) and reading the status, respectively, and notifying each other of completion using hardware interrupt signals. This communication process does not involve the scheduling and management of the operating system, but is completed collaboratively by the hardware devices in the electronic device. In this way, communication between the BMC and UEFI can still be achieved even when the operating system is not running.

[0027] In some implementations, firstly, the management controller defines a physical address for the managed second hardware device in its own configuration based on the address in the first address information table. Then, it sends a discovery request to the target device via the underlying physical bus. When a device that supports MCTP receives the discovery request, it replies to the BMC with a response containing its own endpoint identifier (EID). In this way, the BMC can establish an EID-to-physical address mapping for each second hardware device and create a communication endpoint.

[0028] In this embodiment, firstly, a first address information table is determined based on the first address of the target device associated with the address update event of the hardware device, such that the first address information table stores the updated first address of the target device. Then, the first address information table is written into a first register, enabling the BMC to obtain the first address information table through the first register. Thus, after determining the first address information table, the BMC can perform MCTP discovery based on the first address information table, allowing the BMC to establish a correct communication route between itself and at least one second hardware device it manages based on the updated address in the first address information table. Consequently, when the BMC receives information subsequently, it can correctly send the information to the corresponding second hardware device based on the address information carried in the information, improving the BMC's communication management capabilities for the second hardware device and reducing the occurrence of communication conflict events. Furthermore, the communication between BMC and UEFI is based on BMC and UEFI writing data to the hardware register (i.e., the first register mentioned above) respectively, and using hardware interrupt signals to notify each other to read the data. This communication process is completed collaboratively by multiple hardware devices in the electronic device, without relying on the operation of the electronic device's operating system. This allows the first address information table to be synchronized to BMC in a timely manner even without an operating system, further improving BMC's communication management capabilities for the second hardware device.

[0029] In some embodiments, the target device includes a BMC, and step S100 above includes at least one of steps S101 and S102: Step S101: During the hardware self-test phase, read the first address from the first register; the first address is the address written to the first register by the BMC before the hardware self-test phase; Here, the Power-On Self-Test (POST) phase is the initial hardware detection and initialization process executed by the system UEFI firmware during the computer startup process.

[0030] In this application, when the address update event is a system power-on event, the execution of the hardware self-test phase will be triggered.

[0031] In some implementations, a system power-on event can refer to a DC power cycle event. This means that the DC power cycle event involves completely cutting off the DC power supply to the motherboard of the server or device and then restoring power. This operation is typically performed by the BMC (Browser Control Center), and it does not trigger a power outage of the BMC. This is because the motherboard of the electronic device is designed with two independent power supplies: a standby power supply and a main power supply. When the BMC performs a DC power cycle operation, it temporarily cuts off the main power supply, causing the host system to completely power down and reset. However, the BMC itself continues to operate on the standby power supply and continues to respond to remote management commands.

[0032] It should be noted that during a DC power cycle event, a user may disable / enable a specific first hardware device via UEFI. When UEFI enters the hardware self-test phase, it allocates addresses for at least one managed first hardware device. Since at least one of these managed first hardware devices may be updated, the addresses allocated by UEFI to other first hardware devices may change. Therefore, in this scenario, the BMC can write the first address used by the BMC before the DC power cycle event into the first register. UEFI can then retrieve the first address by reading the data in the first register. Subsequently, the first address can be compared with the address reassigned by UEFI to the BMC to determine whether the BMC's address has changed.

[0033] Step S102: During the hardware self-test phase, the initial address allocated to the BMC is determined to be the first address; the initial address is used to ensure that the BMC functions normally after startup.

[0034] In some implementations, a system power-on event can refer to the event of plugging the power cord of an electronic device into an AC power outlet. It is understood that under this operation, the BMC is in a power-off state, and the data stored in the BMC may be lost in this scenario. This will trigger the BMC to initialize when it starts up, thereby triggering the UEFI to reallocate addresses for the BMC and at least one second hardware device managed by it.

[0035] It should be noted that when an electronic device's power cord is plugged into an AC power outlet, during the device's startup process, the UEFI firmware allocates an early address to the BMC (the aforementioned first address) during the hardware initialization phase. This ensures the device is accessible during system hardware initialization, supporting remote management, monitoring, and basic display functions. Subsequently, when the UEFI performs device enumeration, if a new PCIe device (such as an M.2 solid-state drive or network card) is detected, it may trigger a PCIe resource reallocation mechanism, potentially changing the BMC's address. The UEFI can then determine whether the BMC's address has changed by comparing the first address with the address allocated to the BMC during the device enumeration phase.

[0036] In some embodiments, after allocating a first address to the BMC, the UEFI writes the first address into a first register so that the BMC can obtain the first address through the first register, thereby ensuring the normal operation of the BMC's remote management, monitoring and basic display functions.

[0037] In this embodiment of the application, by enabling the UEFI to obtain the first address of the BMC before the device update event, the UEFI can compare the first address with the address allocated to the BMC at the time of the device update event to determine whether the address of the BMC has changed. This can reduce communication anomalies caused by the BMC communicating with incorrect address information.

[0038] In some embodiments, step S110 may further include steps S111 and S112: Step S111: Determine the second address allocated to the BMC during the hardware self-test phase, and the third address allocated to the at least one second hardware device; In this application, when multiple first hardware devices include a BMC and at least one second hardware device managed by the BMC, if the address update event is a system power-on event, the event will trigger the UEFI to allocate an address for the BMC and at least one second hardware device.

[0039] In some implementations, UEFI assigns addresses to each second hardware device and BMC through its built-in address allocation service.

[0040] During implementation, during the system startup phase, the UEFI firmware first scans the BMC to identify its configuration requirements, and then allocates addresses to the BMC based on the BMC's device type and system resource pool (such as memory address range and I / O port space).

[0041] Step S112: If the first address and the second address are different, determine the first address information table based on the second address and the third address corresponding to the at least one second hardware device.

[0042] In this application, after obtaining the second address allocated to the BMC, the second address is compared with the first address of the BMC to determine whether the address of the BMC has changed. If it has changed, the second address and the third address corresponding to at least one second hardware device are stored in the data table created by UEFI to obtain the first address information table.

[0043] In some implementations, when the first address and the second address are the same, the address information table currently stored in the UEFI is determined as the first address information table.

[0044] In some implementations, the second address and the third address of each second hardware device are updated in the address information table currently stored in the UEFI to obtain the first address information table.

[0045] In some implementations, the second address and the third address of each second hardware device are stored in a newly created data table to obtain a first address information table, and the address information table currently stored in the UEFI is deleted.

[0046] In this embodiment, the addresses assigned by the UEFI to the BMC and at least one second hardware device are stored in a data table created by the UEFI to obtain a first address information table. This allows the BMC to obtain the updated first address information table before communication, enabling the BMC to perform MCTP communication based on the first address information table and reducing the occurrence of communication anomalies.

[0047] In some embodiments, step S110 may further include step S113: Step S113: If the second address and the first address are different, write the first message to the first register and notify the BMC to read the first message through the interrupt signal; the first message is used to make the BMC suspend the application of the currently stored second address information table in order to wait to receive the first address information table.

[0048] In this application, when the second address and the first address are different, meaning the BMC's address has been updated, the UEFI can generate a first message, write it into the first register, and notify the BMC to read the first message via an interrupt signal. It is understood that this first message indicates that the BMC's address has been updated, allowing the BMC to suspend the application of the currently stored second address information table after reading the first message.

[0049] It should be noted that when BMC manages communication with the second hardware device, it does so based on its own address information. If BMC communicates with the second hardware device using incorrect address information, communication errors will occur. In this scenario, suspending BMC's application of the first address can prevent BMC from managing communication with the second hardware device using an incorrect first address.

[0050] In this embodiment, the BMC is made to suspend the application of the currently stored second address information table by the first message. This prevents the BMC from using an incorrect second address information table to implement communication management of at least one second hardware device, reducing the occurrence of communication anomalies and thereby improving the BMC's communication management capability for the second hardware device.

[0051] In some embodiments, the target device includes a third hardware device, which is a hot-swappable device among the at least one second hardware device. Step S100 above includes steps S103 and S104: Step S103: During the operation phase of the operating system, first information is obtained from the data storage area of ​​the BMC through the keyboard controller style interface; the first information includes the device information of the third hardware device; Here, the Keyboard Controller Style (KCS) interface is a standard system interface defined in the Intelligent Platform Management Interface Specification for in-band management communication between the host and the board management controller. This interface simulates the communication method of a keyboard controller in an electronic device, mapping a fixed set of registers (command, data, status) in the host input / output (I / O) address space via a low-pin-count bus. This allows the system firmware (UEFI / BIOS) or the Intelligent Platform Management Interface driver in the operating system to send commands to the BMC and receive responses in byte-level transmission, enabling basic management functions such as sensor data reading, information querying, and power status control.

[0052] Hot-swappable devices are hardware devices that can be safely inserted or removed while the system is running (without turning off the power or restarting the operating system) without causing system failure, data corruption, or requiring a restart.

[0053] In some implementations, the hot-swappable device may include, but is not limited to, one of the following: a network interface card (NIC), an accelerator card, etc.

[0054] In some implementations, during the operating system's runtime phase, when a hot-swappable device is inserted into an electronic device, the BMC can detect updates to the hot-swappable device via the I2C bus and obtain the updated device information.

[0055] In some implementations, the device information may include device identification information, device location information, and device management information. The device identification information may include, but is not limited to, device model, device serial number, and device name; the device location information may include, but is not limited to, the slot where the device is located and the device's physical location identifier; and the device management information may include, but is not limited to, the device firmware version and hardware version.

[0056] Step S104: Determine the fourth address of the third hardware device based on the device information of the third hardware device; In some implementations, after obtaining the device information of the third hardware device, UEFI allocates an address for the third hardware device based on the device information.

[0057] The above step S110 includes step S114: Step S114: Update the fourth address to the third address information table to obtain the first address information table; the third address information table is the address information table currently stored by the UEFI.

[0058] In some implementations, the obtained fourth address is updated in the third address information table to obtain the first address information table.

[0059] In some implementations, after the BMC obtains the first address information table, it performs MCTP discovery based on the fourth address of the third hardware device in the first address information table to establish a communication channel between the BMC and the third hardware device.

[0060] In some implementations, the BMC performs address conflict detection on at least one second hardware device under its management based on the obtained third address information table.

[0061] In this embodiment, when the target device is a third hardware device, the fourth address is updated in the first address information table. This allows the BMC to obtain the first address information table, thereby establishing a communication route with the third hardware device, enabling communication management of the third hardware device, and also promptly identifying address conflicts between the fourth address and at least one second hardware device managed by the BMC, reducing the occurrence of communication anomalies. In some embodiments, step S120 may include steps S121 and S122: Step S121: If it is determined that the first length corresponding to the first address information table is greater than the preset storage length of the first register, the first address information table is split based on the preset storage length to obtain multiple target data to be sent; In some implementations, the preset storage length may be determined based on the storage length of the first register. It is understood that the preset storage length may be less than or equal to the storage length of the first register.

[0062] In one example, the preset storage length can be 16 bytes.

[0063] It is understandable that when the first length is greater than the preset storage length, that is, after the UEFI and BMC communicate once, the BMC cannot obtain the entire contents of the first address information table. In this scenario, the first address information table needs to be split according to the preset storage length, so that the first address information table is sent to the BMC in multiple times.

[0064] For example, with a first length of 32 bytes and a preset storage length of 8 bytes, the first address information can be split into 4 target data based on the preset storage length.

[0065] In this application, the length of the target data can be less than or equal to the preset storage length.

[0066] Step S122: For each target data, write the target data and the target identifier of the target data into the first register; the target identifier is used to characterize the transmission progress of multiple target data; after determining that the BMC has completed reading the target data, clear the first register to proceed with writing the next target data.

[0067] In some implementations, after the UEFI writes the target data and target identifier into the first register, it notifies the BMC to read the target data from the first register via an interrupt signal. After the BMC reads the target data from the first register, it clears the target data stored in the first register to wait for the next target data to be written.

[0068] In some implementations, after the UEFI divides the first address information table, it can inform the BMC of the number of target data to be divided, so that the BMC can determine the current transmission progress of multiple target data based on the target identifier of the obtained target data.

[0069] For example, if the first address information table is divided into 4 target data, the UEFI can set the target identifier to 1 when sending the target data for the first time. In this way, when the BMC reads the target data, it can obtain the target identifier and compare it with the number of target data obtained in advance, and determine that it is necessary to perform 3 more read operations from the first register.

[0070] Understandably, UEFI can only write target data back into the first register after clearing the target data stored in the first register.

[0071] In some implementations, after each read of target data from the first register, the BMC merges the read data, thus obtaining the first address information table after the data reading is complete. In this embodiment of the application, by dividing the first address information table into multiple target data and sending them in multiple batches, the storage space requirement of the first register is reduced, so that the electronic device does not need to set up a first register with a large memory, thereby reducing the production cost of the electronic device.

[0072] This application provides an address processing method for a hardware device, applied to a BMC (Browser Control Center), wherein the BMC manages at least one second hardware device, such as... Figure 1 As shown, the method includes steps S200 and S210: Step S200: In response to receiving an interrupt signal, the first address information table is obtained by reading the first register; the first address information table is determined and written by the UEFI in response to the triggering of an address update event of the hardware device, based on the first address of the target device associated with the address update event; the first register supports being read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the electronic device's operating system; In some implementations, when the first length of the first address information table is less than or equal to the preset storage length, the BMC can directly read the first address information table from the first register.

[0073] In some implementations, when the first length of the first address information table is greater than the preset storage length, the UEFI divides the first address information table into multiple target data and writes them into the first register in multiple batches. In this way, the BMC can read multiple target data from the first register and merge them to obtain the first address information table.

[0074] Step S210: Based on the first address information table, perform MCTP discovery to allocate a logical address for each second hardware device and establish an MCTP communication route for each second hardware device.

[0075] Here, the logical address is an abstract address used to identify endpoints in the MCTP network. It does not directly correspond to the physical hardware address, but is managed by the MCTP protocol layer.

[0076] MTCP communication routing refers to the process of selecting a path from the BMC to each second hardware device for MTCP messages in a network and ensuring that the messages can be delivered accurately along that path.

[0077] In some implementations, the BMC obtains its own second address from the first address information table, generates an MCTP discovery request based on the second address, and broadcasts or directs the MCTP discovery request to at least one second hardware device under its management. After receiving the MCTP discovery request, at least one second hardware device will reply with response information including its own EID and other information. The BMC then creates a corresponding logical channel for each second hardware device based on these response information and establishes a mapping relationship between the logical channel and the address information of each second hardware device in the first address information table, thereby completing device discovery and protocol stack binding.

[0078] In this embodiment, after determining the first address information table, the BMC can perform MCTP discovery based on the first address information table. This allows the BMC to establish a correct communication route between itself and at least one second hardware device it manages, based on the updated address in the first address information table. Consequently, when the BMC receives information, it can correctly send the information to the corresponding second hardware device based on the address information carried in the information, improving the BMC's communication management capability for the second hardware device and reducing communication conflict events. Furthermore, the communication between the BMC and UEFI is based on the BMC and UEFI respectively writing data to the hardware register (i.e., the aforementioned first register) and using hardware interrupt signals to notify each other to read the data. This communication process is completed collaboratively by multiple hardware devices in the electronic device, without relying on the operating system of the electronic device. This ensures that the first address information table can still be synchronized to the BMC in a timely manner even without an operating system, further improving the BMC's communication management capability for the second hardware device.

[0079] In some embodiments, the above method further includes steps S230 and S240: Step S230: In response to receiving an MCTP packet, determine the fifth address in the MCTP packet; Here, an MTCP packet refers to a network data packet processed or transmitted based on the MTCP protocol stack.

[0080] It is understandable that the MTCP packet carries address information, which includes information indicating the recipient of the MTCP packet.

[0081] In some implementations, after receiving an MTCP packet, the BMC parses the MTCP packet to obtain the fifth address in the MTCP packet.

[0082] Step S240: If the fifth address is not included in the first address information table, discard the MCTP packet.

[0083] It is understood that the first address information table contains the address information of the BMC and at least one second hardware device managed by the BMC. The first address information table does not include the fifth address. That is to say, the recipient of the MTCP packet does not include the BMC and / or any second hardware device managed by the BMC.

[0084] In some implementations, the BMC discards the MCTP packet if it determines that the recipient of the MTCP packet does not include the BMC, and / or any second hardware device managed by the BMC.

[0085] In some implementations, when the first address information table includes a fifth address, this fifth address may be the same as the BMC's address. In this scenario, the recipient of the MTCP packet is the MTCP packet itself. Alternatively, the fifth address may be the same as the address of a second hardware device managed by the BMC. In this scenario, the recipient of the MTCP packet is that second hardware device. Thus, upon receiving the MTCP packet, the BMC can send it to the corresponding second hardware device based on the mapping information established during MTCP discovery.

[0086] In this embodiment, after obtaining the first address information table, the BMC can identify and discard erroneous MTCP packets based on the first address information table. This effectively reduces the occurrence of communication anomalies and improves the BMC's communication management capabilities for the second hardware device.

[0087] In some embodiments, the BMC includes a second register, which is used to acquire and store a second address of the BMC; the above method further includes steps S250 to S270: Step S250: In response to receiving an MCTP packet, determine the sixth address in the MCTP packet; In some implementations, after receiving an MTCP packet, the BMC parses the MTCP packet to obtain the fifth address in the MTCP packet.

[0088] In this application, the second register is customized during the production of the BMC chip, and this second register is used to update the BMC's address in real time. In this way, after each MTCP packet is received, the BMC can compare the sixth address in the MTCP packet with the address stored in the second register to determine whether the target object of the MTCP packet is the BMC.

[0089] Step S260: Based on the sixth address and the second address, determine whether the target object of the MCTP packet is the BMC; In some implementations, if the sixth address is the same as the second address, the target object is determined to be a BMC. If the sixth address is different from the second address, the target object of the MCTP packet is determined to be a BMC.

[0090] Step S270: If the target object is not the BMC, perform a first operation; the first operation includes one or more of the following: discarding the MCTP packet, updating the device address of the BMC used in MCTP communication to the second address.

[0091] In this embodiment, by configuring a second register in the BMC, the BMC can obtain the current address information through the data stored in the second register when it receives an MTCP packet, compare it with the MTCP packet, and identify whether the MTCP packet was sent incorrectly. This can effectively reduce the occurrence of communication anomalies.

[0092] This application provides an electronic device 300, such as... Figure 2 As shown, the electronic device 300 includes a UEFI 301 and a plurality of first hardware devices 302, wherein the plurality of first hardware devices includes a BMC and at least one second hardware device managed by the BMC; the UEFI is used to allocate addresses to the plurality of first hardware devices during initialization; the BMC is used to manage at least one second hardware device; wherein, The UEFI is configured to, in response to an address update event triggered by a hardware device, obtain a first address of a target device associated with the address update event; the target device is any one of a plurality of the first hardware devices; based on the first address of the target device, determine a first address information table; write the first address information table into a first register, and notify the BMC to read the first address information table from the first register via an interrupt signal; the first register supports reading and writing by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the operating system of the electronic device; The BMC is used to respond to receiving an interrupt signal by reading the first address information table from the first register; based on the first address information table, it performs MCTP discovery to allocate a logical address for each second hardware device and establish an MCTP communication route for each second hardware device.

[0093] Currently, there is a problem where input / output (IO) firmware cannot be managed out-of-band through the XClarity Controller (XCC). This is due to MCTP communication failure caused by device address conflicts / changes. Among them, the MTCP communication failure is mainly due to the following two aspects: (1) When Intel Virtual RAID technology (VROC) is enabled, the Intel Management Engine (Intel ME) cannot distinguish between device addresses located in the VROC virtual PCIe segment and the physical PCIe segment. This will result in Intel ME failing to send packets to the correct receiving object. For example, if BMC is located at 0:1:0.0 and Drive 0 is located at 10000:1:0.0, since Intel ME cannot distinguish between device addresses located in the VROC virtual PCIe segment and the physical PCIe segment, Intel ME sends packets that should be forwarded to Drive 0 to BMC, causing chaos in BMC's MCTP communication address management, thereby causing BMC to lose its normal management ability for conflicting devices. (2) After the server restarts, the PCIe device topology changes, causing the PCIe address of the BMC's PCIe device to change, which in turn causes the BMC to be unable to discover and use its real PCIe address as early as possible in MCTP communication.

[0094] This application provides two different embodiments to address the MTCP communication failure problem. These two embodiments are a long-term solution and a short-term solution. The short-term solution modifies the BMC chip by integrating a specific register (i.e., the aforementioned second register) onto the BMC chip, enabling this register to acquire and store the BMC's current PCIe address in real time. The long-term solution is used to enable UEFI to send a device information table storing the PCIe addresses of the BMC and other important PCIe devices to the BMC through an independent and reliable channel TWR during the early stages of POST startup and the PCIe device enumeration process.

[0095] I. Short-term plan This application provides a method for determining the address information of a hardware device, such as... Figure 3 As shown, the method includes steps S400 to S406: Step S400: UEFI initialization.

[0096] Here, UEFI initialization is the core process of computer system startup or firmware management. This operation is responsible for completing hardware self-test, firmware service loading, and startup environment preparation before the operating system takes over.

[0097] In some implementations, when the system is powered on again after a complete power outage, the UEFI can be triggered to perform an initialization operation.

[0098] Step S401: UEFI scans and identifies PCIe devices during the DXE phase.

[0099] Here, the Driver Execution Environment (DXE) is a crucial stage in the UEFI boot process, responsible for performing most of the system initialization work and establishing the foundation for loading the operating system (such as Windows).

[0100] In some implementations, during the DXE phase, UEFI constructs a hardware topology diagram of PCIe devices by scanning PCIe devices, clarifying the hierarchical relationships (such as root bridge, switch, and endpoint devices) and connection methods between hardware devices.

[0101] Step S402: UEFI creates a device information table.

[0102] Here, the device information table is used to store information such as the unique identifier and segment number of each PCIe device.

[0103] Step S403: Intel ME sends an MTCP data packet to BMC.

[0104] It should be noted that because Intel ME cannot recognize virtual PCIe segments, the BMC may receive data packets belonging to devices with address conflicts at this stage.

[0105] Step S404: The BMC identifies the PCIe address (i.e., the sixth address) from a specific register (i.e., the second register mentioned above).

[0106] Here, the specific register can correspond to a specific chip, such as the ASpeed ​​chip. That is, the ASpeed ​​chip's registers are used to update the BMC's current PCIe address in real time. Thus, the BMC obtains the current PCIe address from the ASpeed ​​chip's registers and compares it with the address information carried in the MTCP data packet received in step S404.

[0107] It should be noted that in order for the BMC to obtain its actual PCIe address, this embodiment customizes the BMC during the production stage by adding an ASpeed ​​chip. The ASpeed ​​chip's registers are then used to update the BMC's current PCIe address in real time. Understandably, this short-term method relies on improvements to the BMC chip and needs to be introduced during the BMC production stage. For currently used devices, this method cannot obtain the BMC's current PCIe address, and therefore has certain limitations.

[0108] Step S405: The BMC judges the packets sent by the ME and ignores the erroneous packets forwarded by the ME.

[0109] Here, firstly, the BMC parses the received MCTP data packets to obtain the target PCIe address (i.e., the sixth address mentioned above) and the target PCIe device EID. Then, the BMC compares the data obtained in step S405 (i.e., the second address mentioned above) with the target PCIe device address to obtain the comparison result. If the comparison result matches, the BMC executes the operation corresponding to the MTCP packet; if the comparison result does not match, the BMC discards the MTCP data packet.

[0110] Step S406: BMC generates logs.

[0111] Here, if the comparison results are inconsistent, the BMC generates a log message indicating that an MCTP packet with an incorrect PCIe address was detected and discarded. This log message provides administrators with basic data for maintaining electronic devices, allowing them to determine the cause of the erroneous MCTP packet received by the BMC and perform maintenance on the electronic device accordingly.

[0112] II. Long-term plan As explained above, the short-term solution involves improvements to the BMC's hardware, which has certain limitations. Therefore, this application proposes a long-term solution. This long-term solution utilizes a mailbox communication mechanism to enable communication between the UEFI and the BMC. Based on this communication, the BMC can obtain the updated device information table and apply it to its applications.

[0113] During the early stages of POST startup and the PCIe device enumeration process, UEFI sends a device information table (i.e., the first address information table) containing the PCIe addresses of the BMC and other hardware devices to the BMC via a mailbox communication mechanism. It should be noted that the communication between the BMC and UEFI using this mailbox communication mechanism is independent of the running state of the ME or operating system (OS), and can send data exceeding the storage capacity of the TWR register via a handshake protocol. Furthermore, if the handshake protocol is implemented on the Management Message Bus (MMB) quasi-interface, the physical layer can flexibly choose trusted write registers, such as the TWR register, the Enhanced Serial Peripheral Interface (eSPI), or even a Field-Programmable Gate Array (FPGA) as the transmission medium.

[0114] This long-term solution includes two scenarios: AC power-on and DC power cycle. In the DC power cycle scenario, the BMC will not lose power, but users may disable / enable PCIe devices in the UEFI settings, causing changes in the PCIe address allocations of other PCIe devices. In this scenario, the UEFI compares the currently allocated PCIe address with the previous PCIe address of the BMC. If there is a change, it notifies the BMC to send the latest device information table via mailbox communication. The AC power-on scenario is equivalent to plugging and unplugging the power cord. In this case, the BMC will lose power, resulting in data loss and requiring the UEFI to reinitialize. This scenario also causes changes in the addresses of PCIe devices.

[0115] The following describes the methods for determining the address information of hardware devices in the scenarios of power cord insertion into AC power socket and DC power circulation.

[0116] This application provides a method for determining the address information of a hardware device in a DC power supply cycle event scenario, such as... Figure 4 As shown, the method includes steps S501 to S508: Step S501: BMC puts the current address into TWR.

[0117] Here, the current address refers to the PCIe address used by the BMC before the DC power cycle event (i.e., the first address mentioned above), which is used for MCTP communication.

[0118] It should be noted that this step is to allow UEFI to compare its newly assigned PCIe address with the BMC's (i.e., the second address mentioned above) during the startup process. If there is a change in the BMC's PCIe address, UEFI will notify the BMC. If there is no change, the BMC will not need to update its device information table.

[0119] In this application, the UEFI and BMC communicate through a mailbox communication mechanism. During implementation, the BMC puts the current address into the TWR (i.e., the first register mentioned above) and informs the UEFI that it can read the data in the TWR through an interrupt message.

[0120] Step S502: POST Startup.

[0121] Here, POST boot is the process by which the computer automatically runs the BIOS program after the power is turned on. Its main task is to detect the hardware status and ensure that the system can start normally.

[0122] Step S503: UEFI obtains the address before BMC.

[0123] Here, in step S501, the BMC places the PCIe address prior to the DC power cycle event on the TWR. Thus, the UEFI obtains the address prior to the BMC by reading the contents of the TWR.

[0124] In this application, the PCIe device address is allocated by UEFI during hardware initialization. During a DC power cycle event, the user may enable / disable the PCIe device, which will cause the UEFI to change the allocation of the PCIe address, thereby causing the BMC's PCIe address transmission to change.

[0125] Step S504: UEFI notifies BMC of PCIe address change.

[0126] Here, the UEFI determines that the BMC's PCIe address has changed before and after the DC power cycle event, and informs the BMC of the new PCIe address through the mailbox communication mechanism.

[0127] It should be noted that when the BMC learns that its PCIe address has changed, it discards the previously used PCIe address (in step S501) and waits for the UEFI to send the device information table to the BMC via TWR after allocating PCIe addresses for all PCIe devices.

[0128] Step S505: UEFI enumerates other PCIe devices.

[0129] Here, when UEFI is initialized, it enumerates other PCIe devices on the electronic device. This enumeration process takes a long time. Therefore, during this stage, BMC needs to stop using the previous PCIe addresses until UEFI completes the enumeration and generates a device information table based on the PCIe addresses allocated to all PCIe devices and sends it to BMC.

[0130] Step S506: UEFI sends the device information table to BMC via TWR.

[0131] Step S507: BMC performs MCTP discovery using the updated device information table.

[0132] Here, BMC obtains the device information table through TWR and performs MTCP discovery based on the device information table.

[0133] Step S508: BMC identifies address conflict events.

[0134] Here, the BMC can obtain its own PCIe address and the PCIe addresses of other PCIe devices managed by the BMC based on the device information table. Thus, when the BMC receives an MTCP packet, it determines whether the recipient of the MTCP packet is the BMC based on the address information carried in the MTCP packet. If it is not the BMC, the MTCP packet is discarded, and a log is recorded for further investigation and resolution.

[0135] This application provides a method for determining the address information of a hardware device in a scenario where a power cord is inserted into an AC power socket, such as... Figure 5 As shown, the method includes steps S601 to S607: Step S601: POST Startup.

[0136] Step S602: UEFI puts the PCIe address of the BMC into the TWR.

[0137] It should be noted that the BMC chip usually integrates a PCIe controller to use the BMC as a PCIe device. In this way, UEFI will initialize the BMC in the early stages and assign a PCIe address to the BMC. This PCIe address is used to enable the BMC to maintain basic functions.

[0138] In some implementations, UEFI places the PCIe address of the BMC allocated earlier (i.e., the first address mentioned above) in TWR so that the BMC can obtain the PCIe address.

[0139] Step S603: BMC obtains the PCIe address through TWR.

[0140] Here, after the BMC starts up, it obtains the PCIe address assigned to the BMC by the UEFI through the TWR in order to perform MCTP discovery / communication.

[0141] Step S604: BMC performs MCTP discovery.

[0142] Step S605: UEFI reassigns an address to the BMC (i.e., the second address mentioned above).

[0143] As explained above, UEFI will assign an early temporary PCIe address to BMC during the Early Video function. Later, during the DXE enumeration process, UEFI will reallocate addresses for all PCIe devices. In other words, the PCIe address of BMC may change during the DXE phase.

[0144] Step S606: UEFI notifies BMC of PCIe address change.

[0145] Here, during the AC power-on process, after the UEFI assigns a new PCIe address to the BMC in step S605, the UEFI identifies whether the BMC's PCIe address has changed. If it is determined that the address has changed, the UEFI notifies the BMC that its PCIe address has changed, so that the BMC needs to wait for the updated address information table.

[0146] Step S607: BMC performs MCTP discovery using the updated device information table.

[0147] It should be noted that PCIe devices may change during operating system runtime, such as during hot-swapping, which could lead to the addition or deletion of BDF addresses, thus affecting MCTP communication. In this scenario, after the BMC detects a conflict, it actively triggers an out-of-band system interrupt, and the UEFI Runtime interrupt response service sends the PCIe device address changes required by the BMC to the BMC.

[0148] Step S608: BMC identifies address conflict events.

[0149] Here, the BMC can obtain its own PCIe address and the PCIe addresses of other PCIe devices managed by the BMC based on the device information table. Thus, when the BMC receives an MTCP packet, it determines whether the recipient of the MTCP packet is the BMC based on the address information carried in the MTCP packet. If it is not the BMC, the MTCP packet is discarded, and a log is recorded for further investigation and resolution.

[0150] This application provides a method for determining the address information of hardware devices in an OS runtime scenario, such as... Figure 6 As shown, the method includes steps S701 to S707: Step S701: A hot-plug event occurs during operating system runtime.

[0151] It should be noted that hot-plugging PCIe devices will also cause changes to the PCIe address. In this scenario, UEFI can communicate with BMC through interrupt response codes while the OS is running.

[0152] Step S702: The BMC performs device detection via the I2C bus.

[0153] Here, when a PCIe device is hot-plugged, the BMC can detect the PCIe device through the out-of-band I2C bus to determine whether a PCIe device has been added or removed. When an update to a PCIe device is detected, the BMC can actively trigger an interrupt so that the UEFI can obtain the slot / device type information (i.e., the device information mentioned above) of the updated PCIe device through the interrupt response code.

[0154] Step S703: The BMC writes the slot / device type information into the data storage area.

[0155] Here, after performing device detection, the BMC writes the detected slot / device type information into the data storage area, so that the UEFI can obtain the data in the data storage area by triggering the UEFI interrupt response code.

[0156] Step S704: UEFI obtains data from the data storage area through the KCS interface.

[0157] Here, UEFI can obtain the slot / device type information of the updated PCIe device from the data storage area.

[0158] Step S705: UEFI sends the PCIe address assigned to the updated PCIe device to TWR.

[0159] Step S706: The BMC performs MTCP discovery on the updated PCIe device.

[0160] Here, UEFI obtains the updated PCIe address of the PCIe device and performs MTCP discovery based on that address.

[0161] Step S707: BMC checks for address conflicts.

[0162] In some implementations, the BMC performs conflict detection based on the PCIe address and its own stored data table of managed PCIe addresses.

[0163] This application provides a method for UEFI and BMC to communicate via TWR, such as... Figure 7 Figure 8 As shown, steps S801 to S808 are included: Step S801: The UEFI writes the data and information identifier of the device information table into the TWR for the first time.

[0164] In some implementations, 32 bytes of information can be stored in the TWR, and the positions at TWR

[16] -TWR

[31] are used to write data into the device information table.

[0165] In some implementations, other bits at position TWR[4] in TWR can be used to represent the information identifier of the data written.

[0166] Step S802: UEFI writes an interrupt signal into TWR.

[0167] In some implementations, bit 1 at position TWR[4] in TWR is used as an interrupt to notify BMC to read data from TWR.

[0168] Step S803: BMC parses the read data.

[0169] Step S804: Clear the data in TWR.

[0170] Step S805: UEFI writes the data and information identifier of the device information table to TWR for the second time.

[0171] Step S806: UEFI writes an interrupt signal into TWR.

[0172] In some implementations, bit 1 at position TWR[4] in TWR is used as an interrupt to notify BMC to read data from TWR.

[0173] Step S807: BMC aggregates the data read twice.

[0174] Step S808: Clear the data in TWR.

[0175] Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0176] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0177] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the above-described method.

[0178] It should be noted that the descriptions of the above-described storage media, computer program products, and device embodiments are similar to the descriptions of the above-described method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of the storage media, computer program products, and devices of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0179] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0180] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0181] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0182] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0183] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0184] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0185] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0186] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for address processing of a hardware device, applied to a Unified Extensible Firmware Interface (UEFI), wherein the UEFI is used to allocate addresses to a plurality of first hardware devices during initialization; the plurality of first hardware devices include a Baseboard Management Controller (BMC) and / or at least one second hardware device managed by the BMC; the method includes: In response to the triggering of an address update event of a hardware device, obtain the first address of the target device associated with the address update event; The target device is any one of the plurality of first hardware devices; Based on the first address of the target device, a first address information table is determined; The first address information table is written to the first register, and the BMC is notified to read the first address information table from the first register via an interrupt signal; wherein, the BMC is used to perform Management Component Transport Protocol (MCTP) discovery based on the first address information table; The first register can be read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the electronic device's operating system.

2. The method based on claim 1, wherein, The target device includes a BMC, and obtaining the first address of the target device associated with the address update event includes at least one of the following: During the hardware self-test phase, the first address is read from the first register; the first address is the one that the BMC wrote into the first register before the hardware self-test phase. During the hardware self-test phase, the initial address allocated to the BMC is determined to be the first address; the initial address is used to ensure that the BMC functions normally after startup.

3. The method based on claim 2, wherein, The step of determining the first address information table based on the first address of the target device includes: Determine the second address allocated to the BMC during the hardware self-test phase, and the third address allocated to the at least one second hardware device; If the first address and the second address are different, the first address information table is determined based on the second address and the third address corresponding to the at least one second hardware device.

4. The method based on claim 3, wherein, The method further includes: If the second address and the first address are different, the first message is written to the first register, and the BMC is notified to read the first message through the interrupt signal; the first message is used to make the BMC suspend the application of the currently stored second address information table, so as to wait to receive the first address information table.

5. The method according to any one of claims 1 to 4, wherein, The target device includes a third hardware device, which is a hot-swappable device among the at least one second hardware device. Obtaining the first address of the target device associated with the address update event includes: During the operation of the operating system, first information is obtained from the data storage area of ​​the BMC through the keyboard controller style interface; the first information includes the device information of the third hardware device. Based on the device information of the third hardware device, the fourth address of the third hardware device is determined; The step of determining the first address information table based on the first address of the target device includes: The fourth address is updated in the third address information table to obtain the first address information table; the third address information table is the address information table currently stored by the UEFI.

6. The method according to any one of claims 1 to 4, wherein, Writing the first address information table into the first register, and notifying the BMC to retrieve the first address information table from the first register via an interrupt signal, includes: If it is determined that the first length corresponding to the first address information table is greater than the preset storage length of the first register, the first address information table is split based on the preset storage length to obtain multiple target data to be sent; For each target data, the target data and its target identifier are written into the first register; the target identifier is used to characterize the transmission progress of multiple target data; after determining that the BMC has completed reading the target data, the first register is cleared to allow the writing of the next target data.

7. A method for address processing of a hardware device, applied to a BMC (Browser Control Center), the BMC being used to manage at least one second hardware device, the method comprising: In response to receiving an interrupt signal, the first address information table is obtained by reading the first register; The first address information table is determined and written by UEFI in response to an address update event of a hardware device, based on the first address of the target device associated with the address update event; The first register supports reading and writing by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the electronic device's operating system; Based on the first address information table, MCTP discovery is performed to allocate a logical address for each second hardware device and establish an MCTP communication route for each second hardware device.

8. The method based on claim 7, wherein, The method further includes: In response to receiving an MCTP packet, the fifth address in the MCTP packet is determined; If the fifth address is not included in the first address information table, the MCTP packet is discarded.

9. The method based on claim 7, wherein, The BMC includes a second register, which is used to acquire and store a second address of the BMC; the method further includes: In response to receiving an MCTP packet, determine the sixth address in the MCTP packet; Based on the sixth address and the second address, determine whether the target object of the MCTP packet is the BMC; If the target object is not the BMC, perform a first operation; the first operation includes one or more of the following: discarding the MCTP packet, updating the device address of the BMC used in MCTP communication to the second address.

10. An electronic device, the electronic device comprising UEFI and a plurality of first hardware devices, wherein, The plurality of first hardware devices include a BMC, and at least one second hardware device managed by the BMC; the UEFI is used to allocate addresses to the plurality of first hardware devices during initialization; the BMC is used to manage at least one second hardware device; wherein, The UEFI is configured to, in response to the triggering of an address update event of a hardware device, obtain a first address of a target device associated with the address update event; the target device is any one of a plurality of the first hardware devices; and determine a first address information table based on the first address of the target device. The first address information table is written into the first register, and the BMC is notified to read the first address information table from the first register via an interrupt signal; the first register can be read and written by the BMC and the UEFI, and the read and write operations of the BMC and the UEFI on the first register do not depend on the operation of the electronic device's operating system; The BMC is used to respond to the received interrupt signal by reading the first address information table from the first register; based on the first address information table, it performs MCTP discovery to allocate a logical address for each second hardware device and establish an MCTP communication route for each second hardware device.

Images