An I2C address conflict processing method, device, equipment and storage medium

Abstract

This disclosure provides an I2C address conflict handling method, apparatus, device, and storage medium, relating to the field of computer technology and applied to BMC (Bus Management Center). The method first identifies address conflict events on the I2C bus and determines at least two conflicting devices and their address modification capabilities. Then, based on the address modification capability information, a target resolution strategy is selected from preset multi-level resolution strategies, and a target I2C address is matched to the target conflicting device from the address pool. Next, the target resolution strategy is executed, changing the I2C address of the target conflicting device to the target I2C address. Finally, the device address mapping table is updated, and the conflict handling information is recorded in a conflict tracing database. This solution achieves automated detection and resolution of I2C address conflicts, is compatible with various address modification capabilities, avoids manual intervention and secondary conflicts through dynamic address pool management and multi-level strategy adaptive selection, and establishes a full-process tracing mechanism, improving bus communication stability and operational efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to an I2C address conflict handling method, apparatus, device and storage medium. Background Technology

[0002] In servers and industrial control equipment, the I2C bus is widely used due to its simple interface and low I / O resource consumption. It is used to realize communication between the Baseboard Management Controller (BMC) and field-replaceable units (FRUs), temperature sensors, power modules, and other slave devices. However, in current technology, I2C slave devices mostly use static address allocation, and the 7-bit address space only supports 112 usable addresses, which is extremely limited. With the expansion of equipment, reuse of the same type of device, and the addition of hot-swappable FRUs, address overlap problems occur frequently. Once address conflicts occur, they will cause a series of serious consequences such as bus congestion, data corruption, and failure of device management functions, affecting system stability.

[0003] Current solutions for I2C address conflicts have several shortcomings. First, traditional solutions often rely on hardware address changes, such as configuring ADDR pins, soldering jumpers, or adjusting resistors, or manual intervention and simple bus scanning. These methods lack flexibility and cannot adapt to dynamic bus topology changes. When devices are hot-swapped or the system is expanded, the original configuration often becomes invalid, and it is difficult to trace the specific device and cause after a conflict occurs, resulting in high maintenance costs. Second, some solutions introduce I2C switch chips to achieve physical isolation to avoid conflicts, but this not only increases hardware costs but also only resolves address conflicts between different sub-buses, failing to address address overlap on the same sub-bus. Furthermore, the lack of dynamic management of address allocation can easily lead to wasted address resources or secondary conflicts. Summary of the Invention

[0004] This disclosure provides an I2C address conflict handling method, apparatus, device, and storage medium to at least solve the above-mentioned technical problems existing in the prior art.

[0005] According to a first aspect of this disclosure, an I2C address conflict handling method is provided, applied to a baseboard management controller (BMC), the method comprising:

[0006] In response to identifying address conflict events on the I2C bus, and determining at least two conflicting devices and their relocation capability information;

[0007] In response to the detection of an address conflict event, a target resolution strategy is selected from the preset multi-level resolution strategy based on the address relocation capability information of the conflicting device, and a target I2C address is matched for the target conflicting device from the address pool;

[0008] Execute the target resolution strategy to change the I2C address of the target conflicting device to the target I2C address;

[0009] Update the device address mapping table and record the conflict handling information to the conflict tracing database.

[0010] In one possible implementation, the step of responding to identify an address conflict event on the I2C bus and determining at least two conflicting devices and their relocation capability information includes:

[0011] Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip;

[0012] By detecting the integrity of the ACK signal returned from the device during the scanning process, an address conflict event is identified when at least two ACK responses are found for the same address.

[0013] In response to the identification of the address conflict event, the field replaceable unit (FRU) information at the conflicting address is read to obtain the unique identification information and device model information of each conflicting device, and to determine at least two conflicting devices and their relocation capability information.

[0014] In one possible implementation, selecting a target resolution strategy from a preset multi-level resolution strategy based on the address relocation capability information of the conflicting device includes:

[0015] Based on the address change capability information of the conflicting devices, according to a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategy, and the first compatible resolution strategy is determined as the target resolution strategy.

[0016] The multi-level solution strategies, ranked from highest to lowest priority, include:

[0017] The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address.

[0018] The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC controls the CPLD to output a level signal through its general-purpose input / output (GPIO) interface in conjunction with the complex programmable logic device (CPLD) to switch the state of the hardware address pins of the conflicting device and change the I2C address.

[0019] The subbus isolation allocation strategy is as follows: when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus.

[0020] The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation.

[0021] In one possible implementation, the hardware pin control addressing strategy includes:

[0022] The BMC generates hardware pin control instructions, which include a target device identifier, pin control signals, and execution timing requirements, and sends the instructions to the CPLD.

[0023] In response to the instruction, the CPLD outputs a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

[0024] In one possible implementation, matching a target I2C address from the address pool for a target conflicting device includes:

[0025] The BMC's built-in I2C address management module is invoked to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices.

[0026] The first currently unoccupied address is retrieved from the dynamic address area as a candidate address;

[0027] Determine whether the candidate address overlaps with the addresses of other allocated devices on the current I2C bus;

[0028] If there is no overlap, the candidate address is determined as the target I2C address.

[0029] In one possible implementation, after executing the target resolution strategy, the method includes:

[0030] In response to receiving feedback that the target resolution strategy has been successfully executed, a targeted scan is initiated on the target I2C address and the original address of the conflicting device before the change, and a function read command is sent to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device;

[0031] Once the verification is successful, it is confirmed that the address conflict event has been resolved.

[0032] In one possible implementation, updating the device address mapping table and recording conflict handling information to the conflict tracing database includes:

[0033] Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device;

[0034] The conflict handling information is written into the conflict tracing database. The conflict handling information includes at least the time of the conflict, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result and the operator information, and is associated with the device access fingerprint.

[0035] The conflict resolution information and the update results of the device address mapping table are synchronized to the IPMI system event log (SEL) of the intelligent platform management interface, so that they can be queried and displayed through the web management interface.

[0036] In one possible implementation, the method further includes:

[0037] The status of the address pool is maintained in real time, and the allocated addresses, their corresponding device unique identifiers, and the duration of occupation are recorded.

[0038] The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current status of the address pool.

[0039] In one possible implementation, the method further includes:

[0040] The address consistency check is initiated according to a preset cycle, scanning the device addresses on the current I2C bus and comparing them with the device address mapping table;

[0041] When an address mismatch is found during comparison, it is determined whether the mismatch is caused by address drift.

[0042] If the address is determined to be drifting, a secondary address negotiation will be triggered to reallocate the address, or a tiered alarm will be triggered to prompt the operation and maintenance personnel to intervene.

[0043] According to a second aspect of this disclosure, an I2C address conflict handling apparatus is provided, applied to a substrate management controller (BMC), the apparatus comprising:

[0044] The conflict identification module is used to respond to the identification of address conflict events on the I2C bus and to determine at least two conflicting devices and their relocation capability information.

[0045] The strategy selection module is used to respond to the identification of an address conflict event, select a target resolution strategy from the preset multi-level resolution strategies based on the address relocation capability information of the conflicting device, and match a target I2C address for the target conflicting device from the address pool;

[0046] The strategy execution module is used to execute the target resolution strategy and change the I2C address of the target conflicting device to the target I2C address;

[0047] The record update module is used to update the device address mapping table and record conflict handling information to the conflict tracing database.

[0048] In one possible implementation, the conflict identification module is further configured to:

[0049] Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip;

[0050] By detecting the integrity of the ACK signal returned from the device during the scanning process, an address conflict event is identified when at least two ACK responses are found for the same address.

[0051] In response to the identification of the address conflict event, the field replaceable unit (FRU) information at the conflicting address is read to obtain the unique identification information and device model information of each conflicting device, and to determine at least two conflicting devices and their relocation capability information.

[0052] In one possible implementation, the strategy selection module is further configured to:

[0053] Based on the address change capability information of the conflicting devices, according to a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategy, and the first compatible resolution strategy is determined as the target resolution strategy.

[0054] The multi-level solution strategies, ranked from highest to lowest priority, include:

[0055] The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address.

[0056] The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC controls the CPLD to output a level signal through its general-purpose input / output (GPIO) interface in conjunction with the complex programmable logic device (CPLD) to switch the state of the hardware address pins of the conflicting device and change the I2C address.

[0057] The subbus isolation allocation strategy is as follows: when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus.

[0058] The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation.

[0059] In one possible implementation, the policy execution module is further configured to execute the hardware pin control address change policy, including:

[0060] The BMC generates hardware pin control instructions, which include a target device identifier, pin control signals, and execution timing requirements, and sends the instructions to the CPLD.

[0061] In response to the instruction, the CPLD outputs a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

[0062] In one possible implementation, the policy selection module is further configured to match a target I2C address from the address pool for the target conflicting device, including:

[0063] The BMC's built-in I2C address management module is invoked to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices.

[0064] The first currently unoccupied address is retrieved from the dynamic address area as a candidate address;

[0065] Determine whether the candidate address overlaps with the addresses of other allocated devices on the current I2C bus;

[0066] If there is no overlap, the candidate address is determined as the target I2C address.

[0067] In one possible embodiment, the device further includes:

[0068] The verification module is used to, after executing the target resolution strategy, respond to receiving feedback information that the target resolution strategy has been successfully executed, initiate a targeted scan of the target I2C address and the original address of the conflicting device before the change, and send a function read command to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device.

[0069] Once the verification is successful, it is confirmed that the address conflict event has been resolved.

[0070] In one possible implementation, the record update module is further configured to:

[0071] Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device;

[0072] The conflict handling information is written into the conflict tracing database. The conflict handling information includes at least the time of the conflict, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result and the operator information, and is associated with the device access fingerprint.

[0073] The conflict resolution information and the update results of the device address mapping table are synchronized to the IPMI system event log (SEL) of the intelligent platform management interface, so that they can be queried and displayed through the web management interface.

[0074] In one possible implementation, the strategy selection module is further configured to:

[0075] The status of the address pool is maintained in real time, and the allocated addresses, their corresponding device unique identifiers, and the duration of occupation are recorded.

[0076] The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current status of the address pool.

[0077] In one possible embodiment, the device further includes:

[0078] The consistency verification module is used to initiate address consistency verification according to a preset period, scan the device addresses on the current I2C bus, and compare them with the device address mapping table;

[0079] When an address mismatch is found during comparison, it is determined whether the mismatch is caused by address drift.

[0080] If the address is determined to be drifting, a secondary address negotiation will be triggered to reallocate the address, or a tiered alarm will be triggered to prompt the operation and maintenance personnel to intervene.

[0081] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0082] At least one processor; and a memory communicatively connected to said at least one processor; wherein,

[0083] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described in this disclosure.

[0084] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in this disclosure.

[0085] This disclosure discloses an I2C address conflict handling method, apparatus, device, and storage medium applied to a BMC. The method first identifies address conflict events on the I2C bus and determines at least two conflicting devices and their address remapping capabilities. Then, based on this address remapping capability information, a target resolution strategy is selected from preset multi-level resolution strategies, and a target I2C address is matched to the target conflicting device from the address pool. Next, the target resolution strategy is executed, changing the target conflicting device's I2C address to the target I2C address. Finally, the device address mapping table is updated, and the conflict handling information is recorded in a conflict tracing database. This solution achieves automated detection and resolution of I2C address conflicts, is compatible with various address remapping capabilities, avoids manual intervention and secondary conflicts through dynamic address pool management and multi-level strategy adaptive selection, and establishes a full-process tracing mechanism, improving bus communication stability and operational efficiency.

[0086] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0087] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0088] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0089] Figure 1 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 1 ;

[0090] Figure 2 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 2 ;

[0091] Figure 3 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 3 ;

[0092] Figure 4 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 4 ;

[0093] Figure 5 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 5 ;

[0094] Figure 6 This illustration shows the implementation flow of the I2C address conflict handling method according to an embodiment of the present disclosure. Figure 6 ;

[0095] Figure 7 A schematic diagram of the structure of an I2C address conflict handling device according to an embodiment of the present disclosure is shown;

[0096] Figure 8 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0097] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0098] This disclosure provides an I2C address conflict handling method, applied to a baseboard management controller (BMC), such as... Figure 1 As shown, the method includes:

[0099] Step 101: In response to identifying an address conflict event on the I2C bus, determine at least two conflicting devices and their relocation capability information.

[0100] In an I2C bus system managed by the BMC, multiple slave devices share the same physical bus. If two or more devices are configured with the same I2C address, an address conflict will occur, leading to bus communication disorder. The BMC, as the master controller, senses the bus status through continuous monitoring or active probing. When it detects abnormal response characteristics, it determines that an address conflict event has occurred. Address change capability information refers to whether the conflicting device has the potential to change its own I2C address; this information forms the basis for subsequent resolution strategy selection. While identifying conflict events, the BMC needs to further determine which specific devices are involved and understand the inherent address change possibility of each device, such as whether the device allows its communication address to be adjusted via external commands or physical means.

[0101] Step 102: In response to the identification of an address conflict event, based on the address relocation capability information of the conflicting device, select a target resolution strategy from the preset multi-level resolution strategies, and match a target I2C address for the target conflicting device from the address pool.

[0102] In this example, the BMC internally pre-configures multiple resolution strategies, organized according to a certain priority order to accommodate devices with different address remapping capabilities. When selecting a strategy, the BMC determines which strategy level is suitable for the currently conflicting device based on the acquired address remapping capability information and identifies that strategy as the target resolution strategy. Simultaneously, the BMC matches an unused I2C address from its maintained address pool as the target address for the conflicting device. The address pool is a resource set of all available I2C addresses centrally managed by the BMC, capable of dynamically providing free addresses and ensuring the uniqueness of newly allocated addresses across the entire bus.

[0103] Step 103: Execute the target resolution strategy to change the I2C address of the target conflicting device to the target I2C address.

[0104] In this example, the execution method may differ depending on the address relocation capability of the conflicting device. However, regardless of the method used, the entire process is completed automatically by the BMC without manual intervention. During execution, the BMC ensures that the address change operation does not affect the normal power supply and core function operation of the device; for example, the device can still maintain basic sensing or storage functions during the address relocation. By automating the traditionally manual address adjustment process, the efficiency and reliability of conflict resolution are significantly improved, while ensuring the continuity of device functionality.

[0105] Step 104: Update the device address mapping table and record the conflict handling information to the conflict tracing database.

[0106] In this example, after the address change operation is successfully completed, the BMC first updates the locally maintained device address mapping table, recording the new address and related identification information of the target conflicting device, to ensure that subsequent I2C communication can accurately address based on the latest address information.

[0107] Secondly, BMC records complete information about the conflict resolution in the conflict tracing database. This information includes at least the time of the conflict, the equipment involved, the resolution strategy adopted, and the execution result. These records provide traceable data support for subsequent troubleshooting, system auditing, and operation and maintenance analysis.

[0108] This disclosure provides an I2C address conflict handling method applied to a BMC (Bus Management System). The method first identifies address conflict events on the I2C bus and determines at least two conflicting devices and their address remapping capabilities. Then, based on this address remapping capability information, a target resolution strategy is selected from a preset multi-level resolution strategy, and a target I2C address is matched to the target conflicting device from the address pool. Next, the target resolution strategy is executed, changing the target conflicting device's I2C address to the target I2C address. Finally, the device address mapping table is updated, and the conflict handling information is recorded in a conflict tracing database. This solution achieves automated detection and resolution of I2C address conflicts, is compatible with various address remapping capabilities, and avoids manual intervention and secondary conflicts through dynamic address pool management and multi-level strategy adaptive selection. Simultaneously, it establishes a full-process tracing mechanism, improving bus communication stability and operational efficiency.

[0109] In one example, the response to identifying an address conflict event on the I2C bus and determining at least two conflicting devices and their relocation capability information, such as... Figure 2 As shown, it includes:

[0110] Step 201: Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip.

[0111] In this example, in a server or industrial control device, the I2C bus is extended into multiple sub-buses via an I2C switch chip (such as the TCA9548A) to connect more slave devices. The BMC, as the master controller, needs to establish a complete device topology view upon power-up or restart, therefore performing a full address scan on all accessible I2C channels. The scan covers all allocable I2C addresses 0x01~0x77, excluding protocol-reserved addresses (such as broadcast address 0x00 and reserved address blocks 0x78~0x7F) to ensure scan integrity and protocol compliance. Through a full address scan, the BMC can obtain the address occupancy status of all slave devices on the current I2C bus, regardless of whether the device is connected to the master bus or a sub-bus extended via the switch chip, thus avoiding detection blind spots caused by bus expansion.

[0112] Step 202: By detecting the integrity of the ACK signal returned from the device during the scanning process, when it is determined that there are at least two ACK responses for the same address, it is identified as an address conflict event.

[0113] In the I2C protocol, after the master device sends the slave device address, the addressed slave device pulls the SDA line low as an ACK (Acknowledge) signal in the 9th clock cycle. Normally, only one slave device should return an ACK response for each address. During scanning, the BMC detects the integrity of the ACK signal on the SDA bus. When it finds multiple consecutive ACK responses corresponding to the same address, it determines that the address is being used by multiple slave devices simultaneously, resulting in an address conflict. This "double acknowledgment" or "multiple acknowledgment" phenomenon is a direct manifestation of address conflicts at the physical layer. The BMC does not indirectly infer conflicts through subsequent read / write failures, but directly listens for abnormal characteristics in the ACK signal, enabling it to accurately locate the conflicting address immediately. Furthermore, the detection method based on ACK signal integrity is unaffected by the device's functional state, offering high reliability and real-time performance.

[0114] Step 203: In response to the identification of the address conflict event, read the field replaceable unit (FRU) information at the conflicting address to obtain the unique identification information and device model information of each conflicting device, and determine at least two conflicting devices and their relocation capability information.

[0115] In this example, after the BMC detects an address conflict, it establishes connections with multiple conflicting devices at that address via I2C communication commands and reads the FRU (Field Replaceable Unit) information associated with each device. FRU information is typically stored in EEPROM (Electrically Erasable Programmable Read-Only Memory) and includes key identifiers such as the device's unique serial number (SN), device model, manufacturer, and deployment location. By reading this information, the BMC can pinpoint which physical devices are involved in the address conflict and infer the address remapping capability of each conflicting device based on its model (e.g., whether it supports software address remapping or has hardware address pins). Finally, the BMC integrates the conflicting address, detailed information about each conflicting device, and the topology location on the bus to generate a conflict list, which is temporarily stored in a local cache.

[0116] In one example, selecting a target resolution strategy from a preset multi-level resolution strategy based on the relocation capability information of the conflicting device includes:

[0117] Based on the address change capability information of the conflicting devices, and in accordance with a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategies, and the first compatible resolution strategy is determined as the target resolution strategy.

[0118] In this example, the BMC (Browser Control Center) makes a step-by-step judgment based on the relocation capability information of the conflicting devices, according to a preset priority order. The highest priority strategy is the simplest to operate and has the least impact on the system, while the lowest priority strategy requires more resources or manual intervention. The BMC sequentially determines whether the current conflicting device is suitable for the applicable conditions of a certain level of strategy. Once the first suitable strategy is found, it is designated as the target solution strategy, and the BMC stops judging lower priority strategies, thus ensuring that the optimal solution path is always used while satisfying device capability constraints.

[0119] The multi-level solution strategies, ranked from highest to lowest priority, include:

[0120] The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address.

[0121] The software negotiation address change strategy is the highest priority solution in this example. This strategy is suitable for devices that support software-configurable addresses, such as some programmable sensors or self-developed FRU devices, which have internally readable and writable address configuration registers. When the BMC determines that the conflicting device has software address change capability, it establishes communication directly with the device via the I2C bus and writes the target I2C address into its address configuration register, completing the address change. This strategy is simple to operate, executes quickly, requires no additional hardware intervention, and minimizes system resource consumption.

[0122] The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC, in conjunction with the complex programmable logic device (CPLD), controls the CPLD to output level signals through its general purpose input / output (GPIO) interface to switch the state of the hardware address pins of the conflicting device and change its I2C address.

[0123] Hardware pin-controlled address remapping is the second-highest priority solution. This strategy is suitable for devices that lack software address remapping capabilities but possess hardware address pins. These devices typically determine their I2C address through the voltage levels of external pins such as ADDR, A0, A1, and A2. When the BMC determines that a conflicting device belongs to this category, it coordinates with a CPLD (Complex Programmable Logic Device) to implement the address change. As an onboard programmable logic device, the CPLD has abundant GPIO (General Purpose Input / Output) interface resources, enabling precise control of the output levels of external pins. The BMC sends pin control commands to the CPLD, which outputs corresponding voltage level signals to switch the hardware address pin states of the conflicting device, thereby changing the device's physical I2C address according to preset address combination rules. This strategy automates the traditional hardware configuration process that requires manual soldering of jumpers or adjustment of resistors, significantly reducing the need for manual intervention.

[0124] The subbus isolation allocation strategy stipulates that when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus.

[0125] When the BMC determines that a conflicting device neither supports software addressing nor has a hardware address pin (or hardware addressing attempts have failed), it employs a subbus isolation allocation strategy. The BMC controls an I2C switch chip (such as the TCA9548A) to switch the channel occupied by the conflicting device to an independent subbus, achieving physical channel isolation between this device and other devices. Through channel switching commands, the BMC ensures that subsequent I2C accesses from the conflicting device occur only on the independent subbus, thus avoiding interference with communication on the main bus and other channels. This strategy is suitable for some older or fixed-address devices; although it does not change the device's own address, it avoids the impact of address conflicts through topology adjustment.

[0126] The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation.

[0127] When the BMC determines that a conflicting device is completely unrelocatable (e.g., some older fixed-address devices) and cannot be resolved through subbus isolation, a tiered alarm mechanism is triggered using an alarm and manual intervention strategy. Alarm methods include, but are not limited to, web management interface pop-ups, SEL (System Event Log) recordings, and audible and visual alarms. Detailed information about the conflicting device and recommended solutions are provided to guide maintenance personnel in handling the issue. This strategy ensures that conflict resolution can still be completed through human-machine collaboration even in edge cases where automation methods cannot reach.

[0128] In one example, such as Figure 3 As shown, the hardware pin control addressing strategy includes:

[0129] Step 301: The BMC generates hardware pin control instructions, which include target device identifier, pin control signals and execution timing requirements, and sends the hardware pin control instructions to the CPLD.

[0130] In this example, after determining that a hardware pin-controlled address remapping strategy is to be adopted, the BMC generates a hardware pin control instruction. This instruction includes: a target device identifier, pin control signals, and execution timing requirements. The target device identifier is used to uniquely identify the physical device to be operated on, typically using the device serial number (SN) previously obtained from the FRU information. The pin control signals specify which address selection pins need to be operated on and the target level state after the operation, such as setting pin A0 high and keeping pin A1 low. The execution timing requirements specify the order and time constraints of level switching, ensuring that the operation process complies with the electrical characteristics of the device. After completing the instruction construction, the BMC sends the instruction to the CPLD through an on-board communication interface (such as LPC, eSPI, or dedicated GPIO).

[0131] Step 302: The CPLD responds to the hardware pin control command by outputting a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

[0132] In this example, after receiving the hardware pin control command from the BMC, the CPLD first parses the command, extracting the target device identifier, pin control signals, and execution timing requirements. Then, based on the parsing results, the CPLD outputs the corresponding level to the pin control signal through its GPIO interface. For example, if the command requires setting the A0 pin of a device to high, the CPLD switches the GPIO output connected to the A0 pin from low (typically 0V) to high (e.g., 3.3V); if the command requires the A1 pin to remain low, the corresponding GPIO maintains its current low state. These level signals directly affect the address selection pin of the conflicting device. According to the device's predefined address pin combination rules, a specific combination of pin levels corresponds to a unique I2C address. For example, for the LM75A temperature sensor, when the A0 pin is high and the A1 pin is low, its I2C address changes from the default value to 0x49. The physical address of the device can be reconstructed without manual intervention by controlling the CPLD. At the same time, since the level switching only changes the logic state of the address pin, it does not affect the power supply and core function operation of the device (such as the temperature measurement function of the sensor).

[0133] In one example, the address pool is used to match a target I2C address for the target conflicting device, such as... Figure 4 As shown, it includes:

[0134] Step 401: Call the I2C address management module built into the BMC to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices.

[0135] The BMC integrates an I2C address management module, which is responsible for maintaining the I2C address resources of the entire system. The address pool is the I2C address set by the BMC, divided into three categories: The first category is reserved addresses. According to the I2C protocol, address range 0x00 is defined as a broadcast address, used by the master device to send general commands to all slave devices; address range 0x78~0x7F are protocol-reserved addresses used to mark unallocable addresses. The second category is the fixed address area, allocated to core devices that cannot be relocated, such as power modules and BIOS chips. Their I2C addresses are usually fixed by hardware design and cannot be adjusted by software or external pins. The third category is the dynamic address area, used for dynamic allocation by relocatable devices. This area is a flexible buffer in the address pool, typically set to a contiguous address space (e.g., 0x49~0x5F), specifically serving devices with relocation capabilities or those dynamically connected due to hot-plugging.

[0136] When a new address needs to be allocated to a target conflicting device, the BMC calls the I2C address management module to query the current status of the address pool and obtain the occupancy status of all addresses in the dynamic address area.

[0137] Step 402: Retrieve the first currently unoccupied address from the dynamic address area as a candidate address.

[0138] In this example, after querying the current status of the dynamic address space, the I2C address management module traverses and searches the dynamic address space to find the first address that is not currently occupied by any device as a candidate address. Specifically, the BMC checks each address in the dynamic address space in ascending order to see if it has been marked as allocated, and determines the first free address encountered as a candidate address.

[0139] Step 403: Determine whether the candidate address overlaps with other allocated device addresses on the current I2C bus.

[0140] In this example, since the address pool records only the occupancy of address resources, there may be other existing device addresses on the bus that are not managed by the address pool, such as certain core devices with fixed addresses (e.g., power modules, BIOS chips) or other pre-configured slave devices. Therefore, after initially determining the candidate address, the BMC needs to further verify whether the address overlaps with the addresses of other allocated devices on the current I2C bus. The BMC compares the candidate address with all known allocated device addresses on the current bus one by one to confirm whether there are address conflicts.

[0141] Step 404: If there is no overlap, the candidate address is determined as the target I2C address.

[0142] In this example, once the verification confirms that the candidate address does not overlap with any of the currently allocated device addresses on the bus, the BMC officially designates the candidate address as the target I2C address and generates the corresponding address allocation instruction, which is then fed back to the BMC main control module for subsequent address change operations. If the verification finds overlap, it returns to step 402 to continue searching for the next candidate address until a truly usable free address is found.

[0143] In one example, the method after executing the target resolution strategy includes:

[0144] In response to receiving feedback that the target resolution strategy has been successfully executed, a targeted scan is initiated on the target I2C address and the original address of the conflicting device before the change, and a function read command is sent to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device; when the verification is successful, it is confirmed that the address conflict event has been resolved.

[0145] In this example, after executing the target resolution strategy (such as software negotiation addressing, hardware pin control addressing, or subbus isolation allocation), the BMC needs to wait for and receive feedback from the execution layer. For example, in the hardware pin control addressing strategy, the CPLD returns feedback to the BMC indicating success or failure after completing the level switch; in the software negotiation addressing strategy, the BMC can directly obtain the return status of the register write operation. Once the BMC receives feedback indicating successful execution of the target resolution strategy, it enters the verification phase.

[0146] The verification phase comprises two operations: targeted scanning and function reading. First, the BMC initiates a targeted scan of two key addresses: one is the target I2C address recently assigned to the target conflicting device, and the other is the original conflicting address of the device before the change. This targeted scan differs from a full address scan, focusing only on these two specific addresses to confirm address occupancy. The BMC sends addressing commands to these two addresses respectively, detecting their respective ACK responses: if the target address receives only a response from the target conflicting device, and the original address receives only a response from another conflicting device, it indicates that the two addresses have been uniquely identified, and there is no longer a double acknowledgment issue.

[0147] Secondly, the BMC sends function read commands to the target conflicting devices, such as a temperature read command for a temperature sensor and a data read command for a storage device. By verifying that the device can respond normally to the function commands and return the expected data, the BMC further confirms that the device's communication function is normal after the address change and has not been damaged by the address change operation. The selection of function read commands depends on the device type, but its core purpose is to verify the integrity of the device's service functions after the address change.

[0148] Once the verification of both dimensions passed, BMC finally confirmed that the address conflict incident had been completely resolved.

[0149] In one example, the update of the device address mapping table and the recording of conflict handling information to the conflict tracing database are described, such as... Figure 5 As shown, it includes:

[0150] Step 501: Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device.

[0151] In this example, the device address mapping table is a core data structure maintained locally by the BMC, used to record the correspondence between all managed devices on the current I2C bus and their assigned addresses. After the address change of the target conflicting device is successfully completed and verified, the BMC immediately updates the mapping table, writing key data such as the new address of the target conflicting device, its unique identifier, deployment location, and relocation time into the table. The unique identifier typically includes the device serial number (SN) obtained from the FRU, ensuring unique identification of the physical device; the deployment location identifies the physical installation location of the device in the system, such as a CPU heatsink module or power supply backplane; and the relocation time records the timestamp of the address change operation.

[0152] Step 502: Write the conflict handling information into the conflict tracing database. The conflict handling information includes at least the conflict occurrence time, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result, and the operator information, and associates it with the device access fingerprint.

[0153] In this example, the conflict tracing database is a dedicated repository established by the BMC to store historical conflict events, providing comprehensive data support for troubleshooting and operational analysis. The BMC writes detailed information about each conflict resolution into this database, including at least the conflict occurrence time, the original conflict address, the target I2C address, the resolution strategy used, the execution result, and the operator information. The operator information distinguishes whether the conflict resolution was handled automatically by the BMC or manually by maintenance personnel. Furthermore, the BMC associates this conflict resolution information with device access fingerprints. An access fingerprint is a set of unique identifiers for a device, typically including its MAC address, serial number (SN), and access timestamp. Through this association, each conflict record can be accurately traced back to the specific physical device and its access history.

[0154] Step 503: Synchronize the conflict handling information and the update results of the device address mapping table to the Intelligent Platform Management Interface (IPMI) System Event Log (SEL) for querying and display through the Web management interface.

[0155] In this example, IPMI (Intelligent Platform Management Interface) is a widely adopted standard interface in server management, and its SEL (System Event Log) is used to record important events in the system. BMC synchronizes conflict resolution information and the updated device address mapping table results to the IPMI SEL, enabling these events to be integrated into the server's standard log management system. The synchronized information includes at least the time the conflict occurred, the devices involved, the resolution strategy adopted, and the resolution result. Furthermore, BMC visualizes this information through a web management interface, allowing operations and maintenance personnel to query conflict history and resolution processes remotely via the management platform, gaining a comprehensive understanding of the occurrence and resolution of I2C address conflicts without logging into the local server.

[0156] In one example, the method further includes:

[0157] The address pool is maintained in real time, recording allocated addresses, their corresponding device unique identifiers, and usage durations. The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current state of the address pool.

[0158] First, the BMC maintains the address pool in real time, continuously recording the allocated addresses and their corresponding device unique identifiers and occupancy durations. Whenever the BMC allocates a dynamic address to a device, it marks the address as allocated in the address pool and records the device's unique identifier (such as the serial number SN obtained from the FRU), while also recording the start timestamp of the address allocation as the basis for calculating the occupancy duration.

[0159] Secondly, the BMC periodically checks the online status of devices on the bus and reclaims the dynamic addresses released by offline devices based on the detection results. In actual operation, devices may disappear from the bus due to hot-plugging, failure, or system power-down. However, if the dynamic addresses they occupy are not reclaimed, it will result in a waste of address resources and may even lead to the depletion of the dynamic address space. The BMC detects the online status of each device through timed or event-triggered methods. When it confirms that a device that has been allocated a dynamic address is offline and no longer needs to retain its address, the BMC marks the address as free and reclaims it to the dynamic address space for subsequent reallocation by other devices.

[0160] In one example, such as Figure 6 As shown, the method further includes:

[0161] Step 601: Start address consistency verification according to the preset cycle, scan the device addresses on the current I2C bus, and compare them with the device address mapping table.

[0162] In this example, the BMC initiates address consistency checks at a preset period. This period can be configured according to reliability requirements, for example, it is set to run every 30 minutes by default. The specific operation of the consistency check is as follows: the BMC scans all device addresses on the current I2C bus to obtain the actual address occupancy, and then compares the scan results with the locally maintained device address mapping table. The device address mapping table records the addresses that the BMC believes each device should occupy; while the scan results reflect the actual address status on the physical bus. Therefore, through this periodic comparison, the BMC can promptly detect differences between the two.

[0163] Step 602: When an address mismatch is found during comparison, determine whether the mismatch is caused by address drift.

[0164] In this example, when an address mismatch is detected during comparison, the BMC needs to further determine whether the mismatch is caused by address drift. Address drift refers to an unexpected and sporadic change in the I2C address of a device due to physical layer factors such as voltage fluctuations, poor pin contact, decreased signal integrity, or device aging. This drift differs from normal address conflicts (such as those caused by a newly connected device). The device itself has not been replaced, but its response address has changed, resulting in a mismatch with the mapping table record, which may lead to communication failure or data mistransmission. The BMC determines whether the mismatch is due to address drift by analyzing specific characteristics of the mismatch, such as whether the mismatched device has a recent hot-plugging history or is a known device susceptible to physical factors.

[0165] Step 603: If it is determined to be address drift, trigger a second address negotiation to reallocate the address, or trigger a tiered alarm to prompt the operation and maintenance personnel to intervene.

[0166] In this example, if address drift is determined, the BMC will trigger subsequent processing according to preset policies. One approach is to trigger secondary address negotiation: the BMC attempts to re-establish communication with the drifting device, reassign it a usable target address, and update the device address mapping table, thereby automatically resolving the address drift issue. Another approach is to trigger tiered alarms: when automatic negotiation fails or system policies require manual intervention, the BMC prompts maintenance personnel to intervene through web interface pop-ups, SEL log recordings, or audible and visual alarms, while providing detailed information about the drifting device to facilitate rapid manual location and repair.

[0167] This disclosure also provides an I2C address conflict handling device applied to a baseboard management controller (BMC), such as... Figure 7 As shown, the device includes:

[0168] The conflict identification module 701 is used to respond to the identification of address conflict events on the I2C bus and to determine at least two conflicting devices and their relocation capability information.

[0169] The strategy selection module 702 is used to respond to the identification of an address conflict event, select a target resolution strategy from the preset multi-level resolution strategies according to the address relocation capability information of the conflicting device, and match a target I2C address for the target conflicting device from the address pool;

[0170] The strategy execution module 703 is used to execute the target resolution strategy and change the I2C address of the target conflicting device to the target I2C address.

[0171] The record update module 704 is used to update the device address mapping table and record conflict handling information to the conflict tracing database.

[0172] In one example, the conflict identification module 701 is further used for:

[0173] Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip;

[0174] By detecting the integrity of the ACK signal returned from the device during the scanning process, an address conflict event is identified when at least two ACK responses are found for the same address.

[0175] In response to the identification of the address conflict event, the field replaceable unit (FRU) information at the conflicting address is read to obtain the unique identification information and device model information of each conflicting device, and to determine at least two conflicting devices and their relocation capability information.

[0176] In one example, the policy selection module 702 is further configured to:

[0177] Based on the address change capability information of the conflicting devices, according to a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategy, and the first compatible resolution strategy is determined as the target resolution strategy.

[0178] The multi-level solution strategies, ranked from highest to lowest priority, include:

[0179] The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address.

[0180] The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC controls the CPLD to output a level signal through its general-purpose input / output (GPIO) interface in conjunction with the complex programmable logic device (CPLD) to switch the state of the hardware address pins of the conflicting device and change the I2C address.

[0181] The subbus isolation allocation strategy is as follows: when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus.

[0182] The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation.

[0183] In one example, the policy execution module 703 is further configured to execute the hardware pin control address change policy, including:

[0184] The BMC generates hardware pin control instructions, which include a target device identifier, pin control signals, and execution timing requirements, and sends the hardware pin control instructions to the CPLD.

[0185] The CPLD responds to the hardware pin control command by outputting a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

[0186] In one example, the policy selection module 702 is further configured to match a target I2C address from the address pool for the target conflicting device, including:

[0187] The BMC's built-in I2C address management module is invoked to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices.

[0188] The first currently unoccupied address is retrieved from the dynamic address area as a candidate address;

[0189] Determine whether the candidate address overlaps with the addresses of other allocated devices on the current I2C bus;

[0190] If there is no overlap, the candidate address is determined as the target I2C address.

[0191] In one example, the device further includes:

[0192] The verification module 705 is used to, after executing the target resolution strategy, respond to receiving feedback information that the target resolution strategy has been successfully executed, initiate a targeted scan of the target I2C address and the original address of the conflicting device before the change, and send a function read instruction to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device.

[0193] Once the verification is successful, it is confirmed that the address conflict event has been resolved.

[0194] In one example, the record update module 704 is further configured to:

[0195] Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device;

[0196] The conflict handling information is written into the conflict tracing database. The conflict handling information includes at least the time of the conflict, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result and the operator information, and is associated with the device access fingerprint.

[0197] The conflict resolution information and the update results of the device address mapping table are synchronized to the IPMI system event log (SEL) of the intelligent platform management interface, so that they can be queried and displayed through the web management interface.

[0198] In one example, the strategy selection module 702 is further configured to:

[0199] The status of the address pool is maintained in real time, and the allocated addresses, their corresponding device unique identifiers, and the duration of occupation are recorded.

[0200] The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current status of the address pool.

[0201] In one example, the device further includes:

[0202] The consistency verification module 706 is used to start address consistency verification according to a preset period, scan the device addresses on the current I2C bus, and compare them with the device address mapping table;

[0203] When an address mismatch is found during comparison, it is determined whether the mismatch is caused by address drift.

[0204] If the address is determined to be drifting, a secondary address negotiation will be triggered to reallocate the address, or a tiered alarm will be triggered to prompt the operation and maintenance personnel to intervene.

[0205] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0206] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0207] like Figure 8 As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0208] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0209] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the I2C address conflict resolution method. For example, in some embodiments, the I2C address conflict resolution method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the I2C address conflict resolution method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform an I2C address conflict handling method by any other suitable means (e.g., by means of firmware).

[0210] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0211] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0212] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0213] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0214] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0215] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0216] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0217] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0218] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for I2C address conflict handling, the method comprising: The method, applied to a baseboard management controller (BMC), includes: In response to identifying address conflict events on the I2C bus, and determining at least two conflicting devices and their relocation capability information; In response to the detection of an address conflict event, based on the address relocation capability information of the conflicting device, a target resolution strategy is selected from a preset multi-level resolution strategy, and a target I2C address is matched for the target conflicting device from the address pool, including: Based on the address change capability information of the conflicting devices, according to a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategy, and the first compatible resolution strategy is determined as the target resolution strategy. The multi-level solution strategies, ranked from highest to lowest priority, include: The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address. The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC controls the CPLD to output a level signal through its general-purpose input / output (GPIO) interface in conjunction with the complex programmable logic device (CPLD) to switch the state of the hardware address pins of the conflicting device and change the I2C address. The subbus isolation allocation strategy is as follows: when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus. The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation. Execute the target resolution strategy to change the I2C address of the target conflicting device to the target I2C address; Update the device address mapping table and record the conflict handling information to the conflict tracing database.

2. The method of claim 1, wherein, The response to identifying an address conflict event on the I2C bus and determining at least two conflicting devices and their relocation capability information includes: Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip; By detecting the integrity of the ACK signal returned from the device during the scanning process, an address conflict event is identified when at least two ACK responses are found for the same address. In response to the identification of the address conflict event, the field replaceable unit (FRU) information at the conflicting address is read to obtain the unique identification information and device model information of each conflicting device, and to determine at least two conflicting devices and their relocation capability information.

3. The method of claim 1, wherein, The hardware pin control addressing strategy includes: The BMC generates hardware pin control instructions, which include a target device identifier, pin control signals, and execution timing requirements, and sends the hardware pin control instructions to the CPLD. The CPLD responds to the hardware pin control command by outputting a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

4. The method according to claim 1, characterized in that, The process of matching a target I2C address from the address pool for a target conflicting device includes: The BMC's built-in I2C address management module is invoked to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices. The first currently unoccupied address is retrieved from the dynamic address area as a candidate address; Determine whether the candidate address overlaps with the addresses of other allocated devices on the current I2C bus; If there is no overlap, the candidate address is determined as the target I2C address.

5. The method according to claim 1, characterized in that, After executing the target resolution strategy, the method includes: In response to receiving feedback that the target resolution strategy has been successfully executed, a targeted scan is initiated on the target I2C address and the original address of the conflicting device before the change, and a function read command is sent to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device; Once the verification is successful, it is confirmed that the address conflict event has been resolved.

6. The method according to claim 1, characterized in that, The process of updating the device address mapping table and recording conflict handling information in the conflict tracing database includes: Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device; The conflict handling information is written into the conflict tracing database. The conflict handling information includes at least the time of the conflict, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result and the operator information, and is associated with the device access fingerprint. The conflict resolution information and the update results of the device address mapping table are synchronized to the IPMI system event log (SEL) of the intelligent platform management interface, so that they can be queried and displayed through the web management interface.

7. The method according to claim 4, characterized in that, The method further includes: The status of the address pool is maintained in real time, and the allocated addresses, their corresponding device unique identifiers, and the duration of occupation are recorded. The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current status of the address pool.

8. The method according to claim 1 or 6, characterized in that, The method further includes: The address consistency check is initiated according to a preset cycle, scanning the device addresses on the current I2C bus and comparing them with the device address mapping table; When an address mismatch is found during comparison, it is determined whether the mismatch is caused by address drift. If the address is determined to be drifting, a secondary address negotiation will be triggered to reallocate the address, or a tiered alarm will be triggered to prompt the operation and maintenance personnel to intervene.

9. An I2C address conflict handling device, characterized in that, The device, applied to a baseboard management controller (BMC), includes: The conflict identification module is used to respond to the identification of address conflict events on the I2C bus and to determine at least two conflicting devices and their relocation capability information. The strategy selection module is used to respond to the identification of an address conflict event, select a target resolution strategy from the preset multi-level resolution strategies based on the address relocation capability information of the conflicting device, and match a target I2C address for the target conflicting device from the address pool; The strategy selection module is further used for: Based on the address change capability information of the conflicting devices, according to a preset priority order, it is determined whether the conflicting devices are compatible with the corresponding resolution strategy, and the first compatible resolution strategy is determined as the target resolution strategy. The multi-level solution strategies, ranked from highest to lowest priority, include: The software negotiation address change strategy involves the BMC directly writing the target I2C address to the address configuration register of the conflicting device via the I2C bus when it is determined that the conflicting device supports the software configuration address. The hardware pin-controlled addressing strategy determines that when the conflicting device has no software addressing capability but has hardware address pins, the BMC controls the CPLD to output a level signal through its general-purpose input / output (GPIO) interface in conjunction with the complex programmable logic device (CPLD) to switch the state of the hardware address pins of the conflicting device and change the I2C address. The subbus isolation allocation strategy is as follows: when it is determined that the conflicting device cannot be re-addressed through software negotiation or hardware pin control, the BMC controls the I2C switch chip to switch the channel where the conflicting device is located to an independent subbus. The alarm and manual intervention strategy is used to trigger a hierarchical alarm by the BMC when it is determined that the conflicting device is completely unrelocatable, so as to prompt the operation and maintenance personnel to intervene and handle the situation. The strategy execution module is used to execute the target resolution strategy and change the I2C address of the target conflicting device to the target I2C address; The record update module is used to update the device address mapping table and record conflict handling information to the conflict tracing database.

10. The apparatus according to claim 9, characterized in that, The conflict identification module is further used for: Perform a full address scan on all allocable addresses mounted on the I2C main bus and the sub-buses extended through the I2C switch chip; By detecting the integrity of the ACK signal returned from the device during the scanning process, an address conflict event is identified when at least two ACK responses are found for the same address. In response to the identification of the address conflict event, the field replaceable unit (FRU) information at the conflicting address is read to obtain the unique identification information and device model information of each conflicting device, and to determine at least two conflicting devices and their relocation capability information.

11. The apparatus according to claim 9, characterized in that, The policy execution module is further configured to execute the hardware pin control address remapping policy, including: The BMC generates hardware pin control instructions, which include a target device identifier, pin control signals, and execution timing requirements, and sends the hardware pin control instructions to the CPLD. The CPLD responds to the hardware pin control command by outputting a level corresponding to the pin control signal through its GPIO interface to drive the address selection pin of the conflicting device to a high or low level to change the I2C address.

12. The apparatus according to claim 9, characterized in that, The strategy selection module is further configured to match a target I2C address from the address pool for the target conflicting device, including: The BMC's built-in I2C address management module is invoked to query the current status of the address pool; the address pool includes at least a dynamic address area for dynamic allocation by repositionable devices. The first currently unoccupied address is retrieved from the dynamic address area as a candidate address; Determine whether the candidate address overlaps with the addresses of other allocated devices on the current I2C bus; If there is no overlap, the candidate address is determined as the target I2C address.

13. The apparatus according to claim 9, characterized in that, The device further includes: The verification module is used to, after executing the target resolution strategy, respond to receiving feedback information that the target resolution strategy has been successfully executed, initiate a targeted scan of the target I2C address and the original address of the conflicting device before the change, and send a function read command to the conflicting device to verify the uniqueness of the target I2C address and the communication validity of the conflicting device. Once the verification is successful, it is confirmed that the address conflict event has been resolved.

14. The apparatus according to claim 9, characterized in that, The record update module is further used for: Update the locally maintained device address mapping table to record the new address, unique device identifier, deployment location, and address change time of the target conflicting device; The conflict handling information is written into the conflict tracing database. The conflict handling information includes at least the time of the conflict, the original conflict address, the target I2C address, the resolution strategy adopted, the execution result and the operator information, and is associated with the device access fingerprint. The conflict resolution information and the update results of the device address mapping table are synchronized to the IPMI system event log (SEL) of the intelligent platform management interface, so that they can be queried and displayed through the web management interface.

15. The apparatus according to claim 12, characterized in that, The strategy selection module is also used for: The status of the address pool is maintained in real time, and the allocated addresses, their corresponding device unique identifiers, and the duration of occupation are recorded. The online status of devices on the bus is periodically checked, and dynamic addresses released by offline devices are reclaimed to update the current status of the address pool.

16. The apparatus according to claim 9 or 14, characterized in that, The device further includes: The consistency verification module is used to initiate address consistency verification according to a preset period, scan the device addresses on the current I2C bus, and compare them with the device address mapping table; When an address mismatch is found during comparison, it is determined whether the mismatch is caused by address drift. If the address is determined to be drifting, a secondary address negotiation will be triggered to reallocate the address, or a tiered alarm will be triggered to prompt the operation and maintenance personnel to intervene.

17. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

18. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-8.

Images