Is there only one SMBus on PC Motherboards?

Question

I have connected two wires to the SMBus clock and data lines of my motherboard (manually soldered via wires, because there is no header). I wish to interface this bus to my microcontroller.

I hooked these up to my scope, and they show the correct 3.3V or thereabouts (this seems to me that the wires HAVE been connected since there is a pullup).

I can read and write to this SMBus via python-smbus on linux. The same SMBus even picks up the SPD eeproms on memory modules, so THIS smbus definitely works. But I cannot see any of this activity on my scope.

Is there only one SMBus on PC motherboards? Or are there multiple, and so I am hooking up my wires to the wrong places?

My Motherboard is an ASRock X58 Extreme 6 (Southbridge is ICH10R)

Answer 1

Have a look at the datasheet for the ICH10 family.

On page 214, it describes the SMBus. There is only one SMBus interface onboard for controlling/polling motherboard devices, but there's an additional slave SMBus, through which an external master device may send events to the ICH10. There's no way to use this programmatically from the computer's side. Section 5.20.7 on page 222 describes how this works and what you can do. It looks like it's used for lights-out management, external watchdogs, sensor telemetry, etc.

It could well be you've attached to that slave interface, which is why you're not seeing traffic. The pull-ups on those pins are probably there to protect high-impedance inputs.

Answer 2

How many busses there are depends on the system.

Currently (2017) many single processor socket motherboards use the single SMBus controller in the south bridge. This bus may be connected to BOTH the SMBus pins on the PCIe slots and is used for things like reading the DRAM config info from eeprom. Processors that use sockets with more pins, like the Intel Xeon E5 processors, have multiple extra I2C busses to talk to the memory eeproms, so don't share a single I2C bus between slots and motherboard devices.

If a card in a slot has a conflicting address, or puts bogus signals on the bus, the result is the system may not boot (it can't read the DIMM parameters to initialize the DRAM controllers) or may have operational problems with motherboard I2C devices like the temp/voltage monitors.

Unfortunately, the SMBus standard doesn't currently require devices to avoid very common I2C address, like 0x50-0x57 (DIMM SPD eeproms), so cards have been made that work fine on higher end servers with multiple busses but don't work on lower end servers with a shared bus. What addresses are used on a shared bus design will depend on the motherboard design and what memory slots are populated. You may have a system with 4 memory slots, 2 of what are populated, and a PCIe controller card that uses SMBus and everything works fine. When you go to add 2 more DIMMs, the system doesn't boot, and the reason is because the controller card SMBus address conflicts with the I2C address of the new DIMMs. The problem is the controller card, not the memory.

Workarounds include: putting tape on the SMBus pins of the controller card (see the Wikipedia article on PCIe for the correct pins), or some motherboards have a jumper to control if the SMBus is routed to the slots.

A long term solution would be to get the SMBus spec changed to reflect this reality of shared SMBus/I2C computers, and make addresses 0x50-0x57 and any other commonly used address for thermal sensors and such, prohibited for add on cards. The DIMM Serial Presence Detect (SPD) spec could also be clarified to spell out how devices on shared I2C busses can conflict, and perhaps make the case that taking steps to avoid address conflicts is a good idea. The Micron SPD spec I've seen talks about bit patterns and you have to read carefully to realize what I2C addresses will be consumed.