Exposing the System Management Bus
It's the weekend, it's raining, pubs ?? are closed, and COVID19 has us shuttered in; again! Time for some hardware hacking.
The following article will explore exposing the System Management Bus (SMB/SMBus) on a common-as-muck PC motherboard, for the purpose of attaching assorted sensors for fun, profit, and primarily boredom.
Background
The exponential growth in circuit complexity over the previous century necessitated the development of a standard mechanism for lightweight communication between integrated circuits.
To this end, in 1982 Philips Semiconductors, now NXP Semiconductors , created I2C (eye-squared-cee). A multi-master, multi-slave, packet-switched, single-ended, synchronous, serial communication bus.
This initial development led to a proliferation of competing and related bus technologies from major players in the industry, with the System Management Bus being Intel and Duracell's contribution in 1994 .
Environment
We'll be attempting to extend a Hewlett Packard (HP) 20-e011a All-in-One Desktop PC . The first slab of silicon I purchased in Australia while awaiting initial VISA approval in 2016 .
Exploration
Prior to any modifications, we must understand the current environmental behaviour of the selected hardware under our chosen Operating System, FreeBSD 13 .
Sat Sep 4 09:41:39 AEST 2021
FreeBSD/amd64 (enceladus) (ttyv0)
login: root
Password:
Sep 4 09:41:59 enceladus login[984]: ROOT LOGIN (root) ON ttyv0
Last login: Sat Sep 4 09:34:23 on ttyv0
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories: https://www.FreeBSD.org/security/
FreeBSD Handbook: https://www.FreeBSD.org/handbook/
FreeBSD FAQ: https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums: https://forums.FreeBSD.org/
Documents installed with the system are in the /usr/local/share/doc/freebsd
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout: man hier
To change this login announcement, see motd(5).
root@enceladus:~ # dmesg | egrep --ignore-case "smb|smbus|iic|i2c|twi"
intsmb0: <AMD FCH SMBus Controller> at device 20.0 on pci0
smbus0: <System Management Bus> on intsmb0
smbus0: <unknown device> at addr 0xa0
root@enceladus:~ #
Fantastic! We've identified an SMBus interface on PCI device 20, provided by an AMD FCH SMBus Controller .
root@enceladus:~ # pciconf -lv | grep --before-context=3 --after-context=3 "SMBus Controller"
subclass = USB
intsmb0@pci0:0:20:0: class=0x0c0500 rev=0x42 hdr=0x00 vendor=0x1022 device=0x780b subvendor=0x103c subdevice=0x2b54
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH SMBus Controller'
class = serial bus
subclass = SMBus
hdac1@pci0:0:20:2: class=0x040300 rev=0x02 hdr=0x00 vendor=0x1022 device=0x780d subvendor=0x103c subdevice=0x2b54
root@enceladus:~ #
Using the PCI ID we can track down the kernel driver responsible for the SMBus controller.
amd_chipset.h line 29 :
o FCHs where the SMBus controller device has a PCI Device ID of 0x780b1022 and a revision greater than or equal to 0x41 (integrated into "Mullins" processors, code named "ML")
Modern computer Random Access Memory (RAM) is governed by JEDEC Standards , since the year 2000 , which includes an SMBus interface to communicate memory module capabilities and configuration.
The JEDEC DDR SDRAM specification or standard defines all required aspects of 64Mb through 1Gb DDR SDRAMs with X4/X8/X16 data interfaces. It includes a whole variety of elements including features, functionality, AC and DC parametrics, packages and pin assignments.
The next phase of the investigation involves probing the bus for active devices via the smbmsg command.
root@enceladus:~ # man smbmsg
SMBMSG(8) FreeBSD System Manager's Manual SMBMSG(8)
NAME
smbmsg – send or receive messages over an SMBus
SYNOPSIS
smbmsg [-f dev] -p
smbmsg [-f dev] -s slave [-F fmt] [-c cmd] [-w] [-i incnt] [-o outcnt]
[outdata ...]
DESCRIPTION
The smbmsg utility can be used to send or receive messages over an SMBus,
see smbus(4).
...
SEE ALSO
printf(3), sysexits(3), smb(4), smbus(4)
The SMBus specification, https://www.smbus.org/specs/.
HISTORY
The smbmsg utility first appeared in FreeBSD 5.3.
AUTHORS
The smbmsg utility and this manual page were written by J?rg Wunsch.
FreeBSD 13.0-RELEASE May 16, 2004 FreeBSD 13.0-RELEASE
(END)
root@enceladus:~ # smbmsg -p
smbmsg: Cannot open /dev/smb0: No such file or directory
root@enceladus:~ # ls /dev
acpi atkbd0 crypto fido kbd1 midistat null sequencer0 ttyv1 ttyv9 ugen2.1 usbctl
ada0 audit ctty full kbd2 mixer0 pass0 sndstat ttyv2 ttyva ugen2.2 wmistat0
ada0p1 auditpipe devctl geom.ctl kbdmux0 mixer1 pass1 stderr ttyv3 ttyvb ugen2.3 xpt0
ada0p2 bpf devctl2 gpt klog mixer2 pci stdin ttyv4 ufssuspend uhid0 zero
ada0p3 bpf0 devstat hpet0 kmem mlx5ctl pfil stdout ttyv5 ugen0.1 uinput zfs
ada0p4 cd0 dumpdev input log music0 pts sysmouse ttyv6 ugen0.2 ukbd0
apm console efi io mdctl netdump random tcp_log ttyv7 ugen1.1 urandom
apmctl consolectl fd kbd0 mem netmap reroot ttyv0 ttyv8 ugen1.2 usb
root@enceladus:~ #
Smells like a missing device driver.
The previous man page mentioned?smb(4)?(Generic I/0 device driver) and?smbus(4)?(Uniform, modular and architecture-independent system for the implementation of drivers to control various SMB devices). Is our current?stack ?missing those artefacts?
root@enceladus:~ # kldstat
Id Refs Address Size Name
1 44 0xffffffff80200000 1f11ef8 kernel
2 1 0xffffffff82112000 ae38 cryptodev.ko
3 1 0xffffffff8211d000 67feb0 zfs.ko
4 1 0xffffffff82af8000 3378 acpi_wmi.ko
5 1 0xffffffff82afc000 9217 if_rtwn_pci.ko
6 1 0xffffffff82b06000 19130 rtwn.ko
7 1 0xffffffff82b20000 3218 intpm.ko
8 1 0xffffffff82b24000 2180 smbus.ko
9 1 0xffffffff82b27000 2340 uhid.ko
10 1 0xffffffff82b2a000 3380 usbhid.ko
11 1 0xffffffff82b2e000 31f8 hidbus.ko
12 1 0xffffffff82b32000 3320 wmt.ko
root@enceladus:~ #
We appear to be missing the?smb(4) character device driver, let's load it.
root@enceladus: ~ # kldload smb.ko
smb0: <SMBus generic I/O on smbus0>
root@enceladus:~ # ls /dev
acpi atkbd0 crypto fido kbd1 midistat null sequencer0 ttyv0 ttyv8 ugen1.2 usb
ada0 audit ctty full kbd2 mixer0 pass0 smb0 ttyv1 ttyv9 ugen2.1 usbctl
ada0p1 auditpipe devctl geom.ctl kbdmux0 mixer1 pass1 sndstat ttyv2 ttyva ugen2.2 wmistat0
ada0p2 bpf devctl2 gpt klog mixer2 pci stderr ttyv3 ttyvb ugen2.3 xpt0
ada0p3 bpf0 devstat hpet0 kmem mlx5ctl pfil stdin ttyv4 ufssuspend uhid0 zero
ada0p4 cd0 dumpdev input log music0 pts stdout ttyv5 ugen0.1 uinput zfs
apm console efi io mdctl netdump random sysmouse ttyv6 ugen0.2 ukbd0
apmctl consolectl fd kbd0 mem netmap reroot tcp_log ttyv7 ugen1.1 urandom
root@enceladus:~ # smbmsg -p
Probing for devices on /dev/smb0:
Device @0xa0: rw
Device @0x60: rw
Great! Two recognised devices are on the only discovered bus within the system. What remains is the tricky task of identifying what lies behind each address. We can be reasonably confident at least one of these addresses relates to the?DIMM , specifically the?Serial Presence Detect EEPROM (SPD) ?and perhaps a temperature sensor? ???
root@enceladus:~ # pkg install i2c-tools
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100% 163 B 0.2kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 213.0kB/s 00:31
Processing entries: 100%
FreeBSD repository update completed. 30742 packages processed.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
i2c-tools: 4.1
Number of packages to be installed: 1
Proceed with this action? [y/N]: y
[1/1] Installing i2c-tools-4.1...
[1/1] Extracting i2c-tools-4.1: 100%
oot@enceladus:~ # decode-dimms
# decode-dimms version $Revision$
Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others
Decoding EEPROM: 0xA0
---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-116 OK (0x9359)
# of bytes written to SDRAM EEPROM 176
Total number of bytes in EEPROM 256
Fundamental Memory type DDR3 SDRAM
Module Type SO-DIMM
---=== Memory Characteristics ===---
Maximum module speed 1600 MHz (PC3-12800)
Size 4096 MB
Banks x Rows x Columns x Bits 8 x 16 x 10 x 64
Ranks 1
SDRAM Device Width 8 bits
Bus Width Extension 0 bits
tCL-tRCD-tRP-tRAS 11-11-11-28
Supported CAS Latencies (tCL) 11T, 10T, 9T, 8T, 7T, 6T, 5T
---=== Timings at Standard Speeds ===---
tCL-tRCD-tRP-tRAS as DDR3-1600 11-11-11-28
tCL-tRCD-tRP-tRAS as DDR3-1333 9-9-9-24
tCL-tRCD-tRP-tRAS as DDR3-1066 7-7-7-19
tCL-tRCD-tRP-tRAS as DDR3-800 6-6-6-14
---=== Timing Parameters ===---
Minimum Cycle Time (tCK) 1.250 ns
Minimum CAS Latency Time (tAA) 13.125 ns
Minimum Write Recovery time (tWR) 15.000 ns
Minimum RAS# to CAS# Delay (tRCD) 13.125 ns
Minimum Row Active to Row Active Delay (tRRD) 6.000 ns
Minimum Row Precharge Delay (tRP) 13.125 ns
Minimum Active to Precharge Delay (tRAS) 35.000 ns
Minimum Active to Auto-Refresh Delay (tRC) 48.125 ns
Minimum Recovery Delay (tRFC) 260.000 ns
Minimum Write to Read CMD Delay (tWTR) 7.500 ns
Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns
Minimum Four Activate Window Delay (tFAW) 30.000 ns
---=== Optional Features ===---
Operable voltages 1.5V, 1.35V
RZQ/6 supported? Yes
RZQ/7 supported? Yes
DLL-Off Mode supported? Yes
Operating temperature range 0-95 degrees C
Refresh Rate in extended temp range 2X
Auto Self-Refresh? No
On-Die Thermal Sensor readout? No
Partial Array Self-Refresh? No
Module Thermal Sensor No
SDRAM Device Type Standard Monolithic
---=== Physical Characteristics ===---
Module Height 30 mm
Module Thickness 2 mm front, 2 mm back
Module Width 67.6 mm
Module Reference Card B revision 1
Rank 1 Mapping Standard
---=== Manufacturer Data ===---
Module Manufacturer Samsung
DRAM Manufacturer Samsung
Manufacturing Location Code 0x02
Manufacturing Date 2015-W40
Assembly Serial Number 0x00299181
Part Number M471B5173EB0-YK0
Number of SDRAM DIMMs detected and decoded: 1
root@enceladus:~ #
Bingo! The readout indicates the SPD?EEPROM?is at 0xA0. However, no mention of the device housed at 0x60 and it appears unlikely its a temperature sensor on the DIMM:
On-Die Thermal Sensor readout? No
Partial Array Self-Refresh? No
Module Thermal Sensor No
?Qué es 0x60?
Using jedec_dimm ?we can probe the sysctl interface and confirm our current understanding, perhaps pry additional information from the system?
root@enceladus:~ # kldload jedec_dimm
jedec_dimm0: <DDR3 DIMM> at addr 0xa0 on smbus0
root@enceladus:~ # sysctl -a | grep "smb"
dev.jedec_dimm.0.%parent: smbus0
dev.smb.0.%parent: smbus0
dev.smb.0.%pnpinfo:
dev.smb.0.%location:
dev.smb.0.%driver: smb
dev.smb.0.%desc: SMBus generic I/O
dev.smb.%parent:
dev.smbus.0.%parent: intsmb0
dev.smbus.0.%pnpinfo:
dev.smbus.0.%location:
dev.smbus.0.%driver: smbus
dev.smbus.0.%desc: System Management Bus
dev.smbus.%parent:
dev.intsmb.0.%parent: pci0
dev.intsmb.0.%pnpinfo: vendor=0x1022 device=0x780b subvendor=0x103c subdevice=0x2b54 class=0x0c0500
dev.intsmb.0.%location: slot=20 function=0 dbsf=pci0:0:20:0
dev.intsmb.0.%driver: intsmb
dev.intsmb.0.%desc: AMD FCH SMBus Controller
dev.intsmb.%parent:
root@enceladus:~ #
Nada! Still no hint to the source of the device at 0x60, but! It reinforces that 0xA0 relates to the SPD EEPROM.
Disclaimer: I failed to capture all of my actions prior to the following kerfuffle.
Random probing to glean information!? It's called desperation.
root@enceladus:~ # smbmsg -s 0x60 -c 1 -i 1
0xff
root@enceladus:~ # smbmsg -s 0x60 -c 2 -i 1
0xff
...
root@enceladus:~ # smbmsg -s 0x60 -c 1 -i 32 -F %02x
smbmsg: # input bytes out of range: 32
root@enceladus:~ # smbmsg -s 0x60 -c 0 -o 1 0x80
root@enceladus:~ # smbmsg -s 0x60 -c 1 -i 1
smbmsg: Error performing SMBus IO: Device not configured
Borked! The device has become unresponsive, rebooting fails to restore behaviour, shutdown with power disconnected for a period fails to return functionality, popping the CMOS battery fails to reset the device, most likely the change is backed by persistent storage. At this stage, we've dug a hole and are at a loss to the source of the device.
Time to pop the hood!
After studying the?motherboard ?we've identified a number of points of interest supporting SMBus or compatible interfaces. However, following the traces and performing continuity testing shows no direct connectivity to the interface on the SODIMM; with the obvious exception of the Super IO Chip Embedded Controller.
Perhaps the SODIMM is addressable at 0xA0 and 0x60? Let's dig deeper into the design of the Samsung?M471B5173EB0-YK0 ?module.
Page nine of the AT34C02D?datasheet?indicates we have multiple addresses for the SPD EEPROM?1010?(Ah) and?0110?(6h). ??
领英推荐
We can confirm our discovery on page two of the?JEDEC EE1002 and EE1002A Serial Presence Detect (SPD) EEPROMS Standard.
Mystery solved, the SMBus is a known quantity with well-defined behaviour. Before we proceed with exposing the interface we need to address the disappearance of the device at 0x60.
root@enceladus: ~ # smbmsg -p
Probing for devices on /dev/smb0:
Device @0xa0: rw
Previously we issued a write command to the device at 0x60, command code zero, length of one byte, with a value of 0x80. This confirmed we had a responsive device, with the knock-on effect of kicking it off the bus.
root@enceladus:~ # smbmsg -s 0x60 -c 0 -o 1 0x80
root@enceladus:~ # smbmsg -s 0x60 -c 1 -i 1
smbmsg: Error performing SMBus IO: Device not configured
It won't come as any surprise the datasheet holds the answer.
We've enabled the 'Permanent Software Write Protect' covering the lower 128 bytes from 0x00 to 0x7F. If we wanted to overclock this memory module or tweak its configuration this might be of concern. Solutions on the table include replacing the EEPROM and reflashing its contents or paying $18 to get another stick of RAM.
It has no impact on the task at hand, let's turn a blind eye and move on.
The machine now has well-defined characteristics, we're ready to proceed to the next phase by exposing the SMBus for external devices.
Implementation
The first thing we must do is obtain the pinout for the SODIMM and identify the Serial Clock (SCL), Serial Data (SDA), GND, and VDC?lines for our sensors to piggyback on.
Whinge: How is it 2021 and LinkedIn doesn't have the ability to render tabular data?!
Next, we need to solder mechanical connections to the identified pins with enough wire to feed out of the air vent on the rear of the computer housing.
Given the precision required we'll use Enamel CU 0.25mm (33 SWG) wire soldered to 13x strand multicore 0.4038mm (26 AWG) and isolated from the surrounding environment with a heat shrink sleeve.
The resulting solder joints look like a bulldog chewing on a hot plate of beans — but they work.
Due to the wires, and ample superglue to take some of the mechanical stress, the fit is a tad fat for the?cam-in locking connector , nothing a bit of force won't overcome.
Validation
Powered ?? on and no magic smoke. ?? We've got a reading of 3.395VDC?across VDDSPD/VSS?and the serial clock line under the scope shows a positive result, lets hook up some peripherals!
The hardware design is a bespoke evaluation board for assorted sensors however, any SMB compliant device, operating on 3.3VDC, will function.
Jobs a good'un, two new devices have appeared on the bus.
The only outstanding mystery is due to the incorrect addresses. I'd expected 0x1E and 0x6B but saw 0x3C and 0xD6 respectively.
SMBus addresses are 7-bits and we are on an 8-bit system, shifting right by 1 gives the expected result. Perhaps?the smbmsg?command source code will shed some light on the matter?
root@enceladus:~ # cd /usr/src/usr.sbin/smbmsg
root@enceladus:~ # emacs +104 smbmsg.c
Searching the FreeBSD mailing list led to a?2008 ?entry?smbmsg(8): slave address confusion?
It seems that smbmsg is another victim in "Great SMBus Slave Address Confusion" - there are two schools: one that think that slave address is (addr >> 1) and there other thinks that slave address is (addr & ~0x1). It seems that smb driver in FreeBSD takes the first approach, but smbmsg is keen on the second.
Conclusion
We've shown it's possible to expose the SMBus to external devices on modern computer platforms that follow the JEDEC memory standards and busted a little boredom.
If you crave that 90s retro World Wide Web experience, I highly recommend visiting the official SMBus website at https://smbus.org/ .
Sales Relationship Manager at Easy Credit financial services
3 年[email protected]
There are 65 reasons why you need me filling your Cloud, DevOps and SRE jobs.
3 年"pubs are closed" - this bit really resonated with me.