Heat up that iron, you’re going to want to try this one: [Hugatry] is adding hardware to his laptop by tapping into the i2c lines on the memory module. We love this because the penalty for borking memory during the soldering process is much lower than when soldering directly to a motherboard!
Until we watched the video after the break we hadn’t realized that memory modules usually have an i2c EEPROM on them. This is actually a standard called Serial Presence Detect which allows the BIOS to poll the memory and configure automatically. It seems ironic that we knew the Raspberry Pi HAT standard uses this same trick but didn’t know it was on computer memory as well.
Hardware-wise this provides an easy method of soldering your own equipment to the bus. From there it becomes a software hack. Linux, of course, makes this quite easy and that is demonstrated by [Hugatry] with an LM75 temperature sensors. We would like to hear from our Windows and OSX using readers on how the i2c bus can be accessed within those OS’s.
This is as old and as I understand it lmsensors should be able to detect this as they already detect the eeprom on memory modules.
Right. This is more than a decade old. We were doing it in the early XP days. Then again it never got really popular because the few of is who tried it saw it was neat but practically useless. There’s the risk of clashing with existing I2C devices with the same addresses, there’s the hassle of writing drivers to use it (quite a pain on Windows, especially with all of the different chipsets), there’s the complete non-portability of the device (wanna use this? replace one of your hopefully-compatible RAM sticks with this!), and of course the risk of damaging the I2C bus master device.
Today a $1 microcontroller will do a better job all-around, and there’s tons of good and cheap options if it has to be connected to the PC as well. Too little, too late. Sorry.
That’s wild, I never knew that.
Done it some 10 years ago. AFAIR I was using I2C GPIO expander to control some relays. Under linux with lmsensors it works like a charm. On Windows I have used dlportio to access my chipset’s (Sis630) SMBUS controller directly – totally unportable of course. There are good programs/libs that access I2C under windows (like SPEEDFAN) but I don’t know any open source solution.
cool.. must try.
Could be interesting to add galvanically isolated I2C lines which you can mess up as much as you want without risking blowing up the motherboard due to a misconnection (accidental or not).
To save $1 for a uC and look cool, some people are willing to risk their motherboard…
Should really look into at least adding a I2C switch for level translation + 5V tolerant, hotswap support – for external components as one side might not be powered up, I2C address space isolation etc.
your pc is full of them, also usb ports everywhere (pcie) , http://hackaday.com/2014/06/18/i2c-from-your-vga-port/
Your chipset might have a i2c bus or two aswell with testpins, use some pogopins or adapter.
Any word on the behavior of various BIOSes if the serial presence detect EEPROM is nonexistent or the device you’ve attached spews something that probably isn’t valid RAM configuration data back in response to the BIOS poking it?
Having to manually configure wouldn’t be a big deal; but if your BIOS refuses to do anything but automagically do the wrong thing, that would spoil your day a bit…
I2C can be daisychained so it shouldn’t interfere with the eeprom at all as long as the address of the added device is different.
This is usually the SMBus, an extension to I2C which is essentially an I2C bus running round most of your mainboard, the same exact bus is the one in all the PCIe slots. It may also connect to the clock generator and a few on-board components and temperature sensors, fan drivers…
Some servers with a lot of memory may have dedicated I2C busses for memory.
As long as you don’t collide with an address it will work fine, memory SPD memory sits somewhere in 0x5X range.
wherein I have a difficult time understanding how the i2c linux “drivers” make any sense…
Certainly motherboards don’t use *one* i2c bus for RAM, DDC, PCIe, and more… At the time I first encountered the I2C driver, it was for a BTTV device, which IIRC had its own PCI-to-i2c converter… But, I knew there were other I2C channels on the mobo/cards… So, how does it make sense that one “driver” could handle all these different busses…? And the *identical* (and limited) address-spaces within them? Nevermind that most I2C devices can’t be *detected*… they don’t have a configuration-register.
So, then… now we’re at PCIe, and you’re suggesting that PCIe cards have I2C on them, but what configures which address (of a mere 128) that I2C device is located?
And, you can’t tell me that things like the SPD and DDC I2C systems are on the *same* I2C channel, that wouldn’t make an ounce of sense; I’m almost certain those device-address-ranges overlap.
Motherboards don’t necessarily use “one” PCI or USB bus, either, but they still use one “driver”. The I2C layer is just a hardware abstraction layer, it just defines the interaction methods. There’s a hardware-specific driver which implements those methods.
You’re also mixing up a driver for the *bus* and a driver for the *device.* Typically if you want to add an I2C device you have to specify that it’s there via a sysfs interface. lmsensors and the like probe for well-known I2C devices, but you’re still better off adding it yourself somehow.
You would think so except for one small difference. It’s not a true I2C bus. The bus going throughout the motherboard and extended on PCIe is called the SMBus. It’s protocol is very similar to that of the I2C bus to the point where you can talk to I2C devices using it, however there are some differences that make it work on the PC. For instance a device on the SMBus must always ACK, a device on I2C is allowed to delay it’s response. There is also a timeout function and combining the above two you get around the problem of a device locking up the bus. This all leads into one very critical piece of information: By implementing timeouts and requiring ACKs SMBus also allows for device discovery and for dynamic address allocation and hot-plugging of items on the bus via what is called ARP (Address Resolution Protocol) for the bus. The spec even suggests the master should scan the bus every 10 seconds to detect any new slaves.
Now as for bus layout, the motherboard has one and only one such bus, the SMBus running through it. It sorts out the RAM, PCIe, all powermanagement, fan management, and pretty much every other running statistic you can pull from your computer including temperature (and yes SPD is part of this). Whether or not PCI cards opt to partake in this is up to the vendor. My graphics card displays all temperatures via SMBus, I’ve seen some need their own driver. Two things you mentioned however were separate from all of this. DDC does not exist as a bus on the motherboard. It exists only on the graphics adapter and out to the cable, designed only to talk to monitors and it’s entirely up to the GPU to support this. It has nothing to do with the rest of the system and is not connected to the SMBus. Likewise your BTTV example is similar. The lm-sensors manual actually specifically calls out TV tuners and other V4L devices as likely devices that carry their own i2c bus for their own purposes.
Naturally devices connected to your BTTV and to DDC are completely separate from the SMBus which runs through the rest of the computer and wouldn’t cause a device address overlap. Just as well really as skim reading the modern DDC spec I wonder if you would even be able to talk to an I2C device on that bus as E-DDC which has been around for over 10 years now has an incompatible address scheme.
Correction thinking about it I2C would work on E-DDC as a slave would simply ignore the incompatible address scheme as garbage. But you couldn’t put another master on that bus, at least not a standard one.
Great explanation, Garbz, thanks! (and Pat, as well). I think I have it sorted-out in my mind, now :)
FYI: Philips (formally now NXP+Freescale=???) had a patent on I2C which thankfully now expired. Their lawyers had been busy especially in the few years before patent expired.
They still (as far as I know) have a trademark on the term i2c, which why you’ll occasionally see i2c referred to as TWI (“Two Wire Interface”) by companies that don’t have a license.
I took TWI as to mean that it supports just enough of the i2c to work with most devices but not with all. Take a look at the AVR 8-bit product line and what happens to the i2c line as the processor goes through a power cycle.
“Buying an I2C to USB adapter would’ve been easy… but where’s the fun in that?” :)
Mike: In a pseudo-answer to an OSX-related pondering…
I can vouch for that the same idea is doable via a *video*-port’s (HDMI/VGA…) DDC (using I2C) bus… with the added-bonus that it’s available on external ports.
DDC was, at one point, actually *intended* to be used for things like touch-screen interfaces, but that never really caught-on; and possibly as a result, many(most?) I2C drivers over DDC are somewhat hokey, since the bus is generally only used *once* upon boot… In OSX10.5.8 (the last I used) on my system, it was actually bit-banged, and did-so with some really-shitty spin-loops that halted the entire operating-system to a *very* noticeable-extent…
https://sites.google.com/site/geekattempts/misc-notes/osx-i2c
I don’t know about the RAM’s I2C interface, it may be the same, maybe not. And, it’s plausible even OSX’s DDC implementation has been improved since 10.5.8.
The cool thing, *I thought* about using DDC was that it meant that there was potentially a 400kbps serial-port sitting in the most-convenient locations–my laptop’s display and my external VGA/DVI port–just waiting to be used… but because of the OS/KEXT-level implementation I was lucky to pull ~300b/s with the entire computer halting noticeably while doing-so . Maybe Linux handles it better. As I understand it, as far as DDC goes, it’s somewhat dependent on the video-card manufacturer’s willingness to share those details… and it seems for the system I was using NVidia wasn’t willing to share those details with Apple’s open-source community… which meant bit-banging and spin-loops. I did, at one point, intend to revise those KEXTs for my needs… at least removing the CPU-blocking delays in favor of less-accurate delays allowing the CPU to do other tasks (like update the mouse position!)…
NOTE: This is all based on *my understanding*… I’m human, I could be wrong.
…
But, yeah, I2C at 400kb/s with a simple (possibly arduino?) converter, could *easily* result in a full/continuous 115.2kbps RS232 interface which could be used for *much more* sophisticated things than a simple few-byte temperature-transmission. Shoulda/coulda been enough for a wacom-tablet and GIMP. Maybe I didn’t try hard enough :)
Bus pirate…
try running a bus-pirate into the lid of a laptop ;p
I remember when laptops had DIMM slots with a little plastic cover over them, so you could add more RAM. Back when RAM was expensive, even compared to the cost of a machine. IBM were particularly good for expansion, my old P133 Thinkpad was a joy to use. The keyboard flipped up, with 3 bays underneath, they could take an HDD, floppy / CD drive (the right-hand one that was open to the outside), or a battery. So you could swap the CD drive for a second battery and the thing would run for months.
>Sees picture at top of page
>Slaps forehead
>”Hm, I see.”
It’s probably much safer to use the I2C lines on the VGA/HDMI/DVI DDC pins, as there’s no direct possibility of destroying your memory sticks, plus you don’t have to rewire it all the time when you decide to replace the memory or something.
“All the time?” How often do you replace your computer’s memory?
I want to use this the other way around; (not to hack into my computer’s memory) but to make use of the stack of old memory modules from old, discarded computers. I would need more guidance, though (it can’t be as easy as it sounds)?
The actual memory isn’t accessible trough the I2C interface, there’s just an I2C EEPROM sitting on the DIMM modules that contains the timing parameters, serial number, etc..
aww, that’s too bad.
Most often these are 1kbit chips, aka 128 bytes.
I didn’t know there was i2c in the RAM. I did know that most TV cards use I2c and had thought about tapping into that.
Better yet… I think RTLSDR sticks use I2C internally. That could be great for turning an upconverter on and off or switching between antennas. How about doing that and hacking the driver so that requesting a frequency below 30MHz automatically turns the upconverter on and selecting a frequency over that bypasses it? Antenna switching could be automated by frequency the same way.
The i2c in the RAM is part of the SMBus on the motherboard. It also comes out via pins 5 and 6 on every PCIe slot. The bus is shared with temperature sensors and fan speed sensors and controllers.
long late back in the 1984, the automatic check and ! configuration for extension hardware is born in the Amiga
https://en.wikipedia.org/wiki/Autoconfig
keep in mind, that the access to this extension hardware (needed driver entry points) are also found on the same hardware and bus. So no need for driver-disc or installation. even booting the OS was possible from the extension – cool !
No driver issues because no incompatible driver
Nobody is mentioning the i2c bus on the vga port…
http://hackaday.com/2014/06/18/i2c-from-your-vga-port/
ctrl-f “vga” easily finds 3 posts mentioning the VGA I2C interface posted before your post.
Wonder why no ram manufacturer has stuck an i2c PWM controller on their ram modules and added software controlled blinking lights?
Need vs. cost perhaps?
Do you mean like these?
https://www.youtube.com/watch?v=ehtx9rA0D8A
Do you mean like these?
https://www.youtube.com/watch?v=ehtx9rA0D8A