Using an i2c sniffer (http://www.totalphase.com/products/aardvark-i2cspi/), I built a custom harness with a DIMM riser and hooked it up to the SDA/SCL/GND pins on an LRDIMM I had in the chassis, then I did the following:
1) booted the system. 2) Ran `stress` tool to heat up the memory. 3) Ran super micro’s ipmicfg query. 4) Ran my OpenIPMI scanning program (attached). > $ stress -m 8 > stress: info: [2278] dispatching hogs: 0 cpu, 0 io, 8 vm, 0 hdd > > $ sudo ./ipmicfg -nm cpumemtemp > CPU#0 = 30(c) > CPU#1 = 34(c) > [CPU#0]CHANNEL#0, DIMM#0(P1_DIMMA1) = 24(c) > [CPU#1]CHANNEL#0, DIMM#0(P2_DIMME1) = 26(c) > $ sudo ./ipmicfg -nm cpumemtemp > CPU#0 = 35(c) > CPU#1 = 38(c) > [CPU#0]CHANNEL#0, DIMM#0(P1_DIMMA1) = 25(c) > [CPU#1]CHANNEL#0, DIMM#0(P2_DIMME1) = 27(c) > <snip> > $ sudo ./ipmicfg -nm cpumemtemp > CPU#0 = 38(c) > CPU#1 = 40(c) > [CPU#0]CHANNEL#0, DIMM#0(P1_DIMMA1) = 30(c) > [CPU#1]CHANNEL#0, DIMM#0(P2_DIMME1) = 32(c) Remembering this i2c Addressing Summary: WP=Write Protection +----------------+--------------+----------+----+------+ | Memory Area | Device Type | Chip En | RW | Hex | | Function | [b7 b6 b5 b4]|[b3 b2 b1]|[b0]| Base | +----------------+--------------+----------+----+------+ | R/W Temp Reg | 0 0 1 1 | A2 A1 A0 | RW | 0x18 | +----------------+--------------+----------+----+------+ | Set-WP | | 0 0 1 | 0 | | | Clear-WP | | 0 1 1 | 0 | | | PermSet-WP | 0 1 1 0 | A2 A1 A0 | 0 | 0x30 | | Read-SWP | | 0 0 1 | 1 | | | Read-PSWP | | A2 A1 A0 | 1 | | +----------------+--------------+----------+----+------+ | Repeat Mem Buf | 1 0 1 1 | A2 A1 A0 | RW | 0x40 | +----------------+--------------+----------+----+------+ | R/W SPD memory | 1 0 1 0 | A2 A1 A0 | RW | 0x50 | +----------------+--------------+----------+----+------+ | Mem Buffer | 1 0 1 1 | A2 A1 A0 | RW | 0x58 | +----------------+--------------+----------+----+------+ What I noticed in the i2c-sniff.log (attached) were the following transactions: 1) Partial read of 0x50 -> 0x57 (twice) 2) Entire read of SPD at 0x50 (where there is one LRDIMM Installed) 3) Training via 0x58 4) Polling of temp 0x18 i.e. it seems that something is continuously polling the i2c bus for the temperature, which I presume is the BMC. I then ran a program I’ve written `ipmi-i2c-scan.c` (attached), in the hope that I could scan out on that i2c bus, and see those transactions. Alas no. all I saw were the continued poll of the 0x18 temp register. I’ve attached the output of the program (i2c-scan.log), I did seem to read some data but certainly not at addresses I expected, nor data I know. I’m not sure what to make of this all, I was really hoping to gain access to the memory buffer @ 0x58, and that would have to be via that BMC chip on this system as far as I can tell. Any pointers gratefully received. A. On 18 Mar 2014, at 12:07, Alun Evans <[email protected]> wrote: > > On 18 Mar 2014, at 11:51, Alun Evans <[email protected]> wrote: > >> Hi Corey, >> >> thanks for the reply, more inline, >> >> On 18 Mar 2014, at 06:15, Corey Minyard <[email protected]> wrote: >> >>> On 03/17/2014 03:53 PM, Alun Evans wrote: >>>> Hello, >>>> >>>> I was going over "A Gentle Introduction with OpenIPMI", unfortunately the >>>> section I was really after was the Direct i2c access :) >>>> >>>> I was wondering if anyone had any experience in this area? >>> >>> I've had a little. It's generally not that useful except for some very >>> specific instances. >>> >>>> >>>> Looking at the i2c 7-bit addressing scheme, it seems that the 3-bit select >>>> addresses allow up to 8 slave devices of the following types and base i2c >>>> addresses: >>>> >>>> o Temperature sensor (0x18) >>>> o EEPROM memory (0x50) >>>> o LRDIMM Buffer (0x58) >>>> >>>> Using "ipmitool sensor" and Supermicro's "ipmicfg -nm cpumemtemp", I'm >>>> able to dump the temperature of the DIMMs, meaning 0x18 must be connected >>>> on both DIMMs. >>> >>> The idea of IPMI is that the BMC handles reading these values for you. >>> The sensors should be available as IPMI sensors and the EEPROM memory >>> should be available as FRU data. You shouldn't have to use the direct >>> interface; it would be odd if there were sensors out there that were not >>> managed by the BMC, and EEPROM memory that wasn't available through a >>> FRU interface. >> >> I seemingly can’t dump the DIMM’s eeprom out via the FRU, maybe something >> hasn’t been setup correctly by supermicro, but I’m really stumbling along in >> this area. >> > > Here’s the output from ipmi_ui: > >> mcs > > (0 20) - active > (2 20) - active > (5 20) - active > > MC (0 20) - active > provides_device_sdrs: n > device_available: n > chassis_support: y > bridge_support: n > ipmb_event_generator: y > ipmb_event_receiver: y > fru_inventory_support: y > sel_device_support: y > sdr_repository_support: y > sensor_device_support: y > device_id: 20 > device_revision: 1 > fw_revision: 3.13 > version: 2.0 > manufacturer_id: 002a7c > product_id: 0630 > aux_fw_revision: 00 00 00 00 > SEL count: 6 entries, 6 slots used > >> entities > 32.64 (memory_device) unknown present > 32.80 (memory_device) unknown present > > Entity 32.64 () present > name = first(32.64) > type = unknown > entity id string = memory_device > is not fru > present sensor not always there > > Sensors for entity 32.64: > 32.64.P1-DIMMA1~TEMP - P1-DIMMA1 TEMP > > Sensor 32.64.P1-DIMMA1~TEMP: > still there if entity not present > name = first(32.64).P1-DIMMA1 TEMP > value = 24.000000 (18) > <snip> > >> fru 32.64 > No FRU for entity 32.64 > > - Looking at the code, I guess that fru is there it would have dumped the spd > info. > > > A. > > >>>> >>>> I've been trying to get the same working via the openipmicmd's ipmb >>>> interface. >>> >>> The IPMB interface is something completely different. That's for >>> accessing other BMCs on the I2C bus. >>> >> >> Ah, I see. I’d thought it was sort of a tunnelling protocol to tunnel i2c >> requests to private management busses. >> >>>> >>>> I've hacked up my own ipmi_devintf with some printk's to see the >>>> transactions, but I'm not sure that is helping me so much. >>>> >>>> Being able to at least dump out the EEPROM would be great, but I'm really >>>> looking to get to the LRDIMM buffer for some system diagnostic and debug >>>> support. >>>> >>>> >>>> any pointers gratefully received. >>> >>> Hopefully you don't need the I2C access. It's a pain to use and IPMI >>> should abstract that for you. >> >> Well I really need to get to the lrdimm buffer which is at 0x58+SA[0:3], >> which I suspect isn’t typically exposed via sensors or FRU? >> >> thanks, >> >> >> A. >> >> -- >> Alun Evans > > -- > Alun Evans > http://badgerous.net/
i2c-scan.log
Description: Binary data
i2c-sniff.log
Description: Binary data
ipmi-i2c-scan.c
Description: Binary data
-- Alun Evans http://badgerous.net/
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
