Hallo Michael, On Wed, 13 Apr 2011 12:06:59 +0200, Michael Fuckner wrote: > Supermicro just gave me the following information: > > To access all SPDs, you have to pull low GPIO49 (IO_0x528 bit 17) first. > Then pull low GPIO52 (IO_0x528 bit 20) to access first CPU > memory(0x50~0x55); pull high GPIO52 to access 2nd CPU memory(0x50~0x55). I am surprised because AllMEMDIMM.ini suggests that GPIO 53 and 52 are used, not 47 and 52. > I can't find anything about GPIO49/52,53 in Datasheet for 5500/5520 chipset > http://www.intel.com/assets/pdf/datasheet/321328.pdf > > So it is probably connected to ICH10 > http://www.intel.com/Assets/PDF/datasheet/319973.pdf > > but I don't know how to use this information My own workstation board happens to have a similar (but slightly different) GPIO-based SMBus multiplexing scheme. I wanted to look into it but could never find the time. Your request gave me an opportunity to look into it again. As a first step, I've improved isadump and isaset to support 32-bit I/O access: http://marc.info/?l=lm-sensors&m=130264185604706&w=2 http://marc.info/?l=lm-sensors&m=130264189004750&w=2 With these two patches applied, you should be able to control the multiplexer from user-space. First of all, check the base I/O address of the GPIO registers, because the values provided by Supermicro are off by 16 compared to what I have: # setpci -s 00:1f.0 48.l It returns 00000501 for me, for I/O base 0x500. If it is the same for you, you can dump the GPIO registers with: # isadump -f -L 0x500 64 Preliminary note: wrong setup of GPIO could have disastrous effects on your hardware. If at any point you are unsure of what you're doing, you better just stop and ask. The operations described by Supermicro would then be achieved with the following commands: : Pull GPIO49 low # isaset -f -L 0x538 0x00000000 0x00020000 : Pull GPIO52 low: # isaset -f -L 0x538 0x00000000 0x00100000 : Pull GPIO52 up: # isaset -f -L 0x538 0x00100000 0x00100000 Note the 0x538 when your Supermicro contact said 0x528. 0x528 would be correct only if the I/O base is 0x4f0 instead of 0x500... but I'd be surprised if it is the case. Of course this is all a hack and the kernel drivers won't notice the multiplexer change happening in their backs. So if you happen to have the same number of memory modules for both CPUs, plugged in symmetrical sockets, "sensors" (and "decode-dimms") will nicely report the values from the currently selected bus segment, but you can't see all modules at once. For this, proper multiplexing support in the kernel will be needed, which is a lot more work. Patience... -- Jean Delvare http://khali.linux-fr.org/wishlist.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
