coreboot Console via SMBus — Part I
Introduction
Console programs are used in many systems to provide system access to the users. If you have worked with Embedded development boards, you would have mostly used a UART interface to access the board software. If you have worked in the web server side you mostly would have used a SSH (Linux) console.
Unfortunately not all mainboards (aka motherboard) have an accessible serial port. So we need other ways to access the console. coreboot supports multiple interesting ways to read this console messages. Some of them are Serial console, Network console, Audio console, Flash console, SPI console, etc. Each method has its own pros and cons. See console source file and wiki for more details. coreboot console is really useful for debugging. So we try to add more ways to access the console.
Lately I have been working on supporting the coreboot console via System Management Bus (SMBus). SMBus is a two-wire interface which is based on the principles of operation of I2C. SMBus, first proposed by Intel in 1995, was designed to allow a battery to communicate with the charger, the system host, and/or other power-related components in the system. SMBus provides a control bus for the system to pass messages to and from devices instead of using individual control lines, helping to reduce pin count and system wires.
Modern computer Random Access Memory (RAM) is governed by JEDEC Standards which includes a System Management Bus (SMBus) interface used for reading memory module capabilities and configuration from the SPD-EEPROMs. Therefore boards with socketed RAM have a somehow accessible SMBus. This can be used very early in the boot process to access the coreboot console.
Accessing the SMBus
The first step of the project is finding a way to access the bus. There are three ways to do this.
1. RAM Breakoutboard
As we know that the RAM slot has SMBus in it according to the JEDEC standards, we can design a breakoutboard to expose those SMBus pins. My mainboard has a DDR3 DIMM slot. So I designed a minimal DDR3 DIMM breakout board with only the SDA(Data line) and SCL(Clock line) pins of I2C/SMBus. You can find the (KiCAD) design files and a DDR3 DIMM datasheet which has the dimensions and pinouts here: https://github.com/drac98/ram-breakout-board.
It would be better if we add the Vcc and GND lines to the breakout board. Contributions are welcome to add a few more useful pins or more RAM breakout board generations i.e DDR4, DDR5.
Unfortunately I couldn’t get this board printed from a PCB manufacturing facility and verify the design dimensions because it would take about three weeks for this to be delivered to my location and it is a bit late for my project timeline. So I went with the screen printing option which is a manual process to design simple circuit boards. To verify the dimensions in an informal way, I just compared it to a real DIMM module with x1 scale in the screen.
The final board was few millimeters longer than the slot and I was able to easily remove the extra length with a sharp blade.
The SCL pin is in the front side of the board and the SDA line is in the back side of the board and right below the SCL pin. Each side has 120 pins and SCL is the 118th pin and SDA is the 238th pin. Refer the datasheet for pin assignments.
There are RAM extender boards which might also expose the pins.
Ex: DDR3 DIMM Exteders - https://mfactors.com/ddr3/
2. RAM Module SPD-EEPROM Pins
I have not tried this approach on my own so I can not guarantee that this approach would work. Theoretically this should work. The I2C EEPROM chip pin layout is as follows.
You can solder wires to the SCL and SDA pins of the chip in the RAM module. In some modules you will not have access to the EEPROM pins directly. You might be able to access it by de-soldering the chip but if a non-functional RAM is plugged, the mainboard might fail to boot.
3. PCIe Extender
Some mainboards(Not all!!) have SMBus also connected to its PCIe slot. Luckily you don’t have to design a breakout board for this as we have cheap PCIe extender cables widely available which we can use to expose the PCIe pins.
The pins 5 and 6 of Side B are respectively SCL and SDA lines. Pins 7 and 8 are Ground and +3.3v pins. You can easily connect an I2C sensor using these four pins.
If you can find a schematic for your mainboard, you can easily verify if your board has SMBus lines in PCIe slot.
Another small note I want to add is, if you are going to use a cheap extender cable as I did, make sure you remove any tapes used to cover the ribbon cable wires soldered to the pins and check which wire of the cable connects to which pin. In my cable the 4th wire of the ribbon cable is not connected instead the 5th wire is connected to the 4th pin of the PCIe. Also the SDA line is not connected. I did not know that and I spent a few days trying to figure out what is wrong with my wiring. (Sorry for the low quality image)
Verifying the Connection
Once you have access to the SMBus you can verify it by connecting an I2C slave device to the bus and reading its address using the i2cdetect utility. Read warnings in the man page before using this tool. I used an accelerometer-gyroscope sensor GY-521 which has the 0x68 I2C address. Most I2C sensors are compatible with SMBus. I also tested a BMP280 I2C pressure sensor and a INA3221 current and voltage monitor which has an I2C and SMBUS compatible interface.
First you need to identify the SMBus interface. In my case it is the bus 0.
Then you can probe the SMBus to see the addresses of the I2C devices connected to the bus. You can notice in the below results it is showing the address 0x68 which is the address of the sensor I connected. When connecting the sensor, make sure you have a common GND line. This is important to note if you are powering the sensor with an external power source.
A continuity test using a multimeter is also a really great way to check if a circuit path is closed.
If your connections are all good and you still can’t detect the device connected to the bus, there is a small chance that your specific I2C device is not compatible with SMBus. You can verify if this is the case by testing with different I2C devices.
SMBus vs I2C
The two protocols are compatible in most cases. The most important difference is that the SMBus has a timeout for communication and as a result SMBus has a minimum clock speed in the specification. Chapter 9 of this document mentions the differences.
Compatibility
Specifications for SMBus V[Input-High] and a fixed-level I2C device are not compatible, but the following apply.
• If minimum V[IH] of a target I2C device is 2.1V or less, compatibility is ensured.
• If minimum V[IH] of a given SMBus system is 3V or higher, compatibility is ensured.
Read SMBus Compatibility With an I2C Device for more info.
Now you have full power to connect any I2C device and control it through your PC. Remember, with great power comes great responsibility 😉
That is it for this write-up. I hope this was an interesting read!
