Tyan S2932 support?

[edgeman16]

Any chance of supporting the Tyan S2932? (http://www.tyan.com/Motherboards_S2932-E_S2932WG2NR-E) Chipset appears to be Nvidia NFP3600? according to Tyan's website.

I have a machine with it, it is non-production so I can assist with testing/etc.

[edgeman16]

Sorry, further reading suggests Chipset SMSC DME5017

[koitsu]

Can you please communicate with Tyan regarding the following questions?

1. Verify that the SMSC chip they're using is in fact the DME5017 and not a sub-model? Silkscreening on chips and documentation on websites does not always reflect reality, as some chips can operate in an emulation mode or the documentation is wrong (see doc/BOARDS for proof),
2. Verify that the SMSC chip is wired to SMBus, and if so, what its slave address is,
3. Provide full register documentation (SMBus offsets, value data format/syntax, etc.), including calculation formulas (as some vendors add resistors/etc. between sensors and the H/W monitoring chip -- see doc/BOARDS and doc/BUGS for proof).

I cannot find official documentation for this exact model of chip. It appears SMSC was purchased by Microchip in August 2012: http://www.microchip.com/pagehandler/en-us/technology/smsc_legacy/home.html

If the H/W monitoring chip lacks SMBus and/or is not tied to SMBus, then no, this motherboard cannot be supported. You may want to try ports/sysutils/xmbmon (xmbmon package) as it supports LPC I/O. Please let me know regarding the SMBus support either way (because doc/SUPPORTED contains a list of boards which bsdhwmon cannot support due to such limitations).

Thanks!

[edgeman16]

Doesn't look like I'm going to get anything from Tyan:

Please help to understand the S2932 was end of life for years. There’s no more resource to provide technical support. Is there anything I can do to poke at it at all? I tried mbmon but I'm not having any luck. Says it needs setuid root even though I'm running it as root. Googled and it says my kern.securelevel might be on but it's not. Either way I'll close this issue, it's not something bsdhwmon will be able to do I think.

[edgeman16]

FYI the Tyan datasheet lists the chip as "SMSC SCH5017 Super I/O chip w/ temperature sensing" Unfortunately that not enough information for you still. Best I could find. http://www.tyan.com/datasheets/DataSheet-S2932-SI.pdf

[koitsu]

Actually that's super helpful, specifically that it's an SMSC SCH5017 and not DME5017. Specification sheet for the chip in question: ftp://ftp.smsc.com/pub/Data_Briefs/5017db.pdf -- and Microchip has a summarised version here: http://www.microchip.com/wwwproducts/Devices.aspx?product=SCH5017

The sheet denotes that this chip has support for LPC as well as SMBus. Quoting: "The hardwre monitoring block of the SCH5017 is accessible via the System Management Bus (SMBus)."

The questions then become:

1) If Tyan wired up SMBus support (they would know this), 2) If so, what the SMBus slave address for the device is (there is possibly a default), 3) What the SMBus offsets/registers are and their format (i.e. official chip documentation from SMSC; it may be possible to find this online or simply ask Microchip for it), 4) If Tyan applied resistors to any of the input sensor pins on the chip (which would skew calculation formulas).

Other comments in passing (be sure to read all of this please, there's a surprise at the end):

It's very possible that Linux lm-sensors has support for this chip, but possibly only via LPC interface (whose values/offsets aren't the same as SMBus). The official www.lm-sensors.org site appears to be down so I'm not able to determine if they have SMSC SCH5017 support or not. Furthermore. Reverse-engineering lm-sensors code is extremely tedious (it's definitely not elegant).

I found this ticket for Debian that shows a log indicating SMSC probing may in fact use SMBus (I see mention of 0x4e/0x4f -- this looks like an SMBus slave address, but probably for a different chip): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588355

And finally, I just found this: ftp://ftp.tyan.com/Softwave/lms/2932.sensors.conf

The hullabaloo at the top is to get old Linux kernels working with nForce 2 SMBus; on FreeBSD support for this chip should be available via the nfsmb(4) driver. I see some "force settings" at the very bottom of this that indicate something. I do not know what force_adm1027 means, but the addresses 0x2c, 0x2d, and 0x2e look like SMBus slave addresses.

The rest of the file gives me calculation formulas for voltages (sort of), and pin-to-label matches, but it also gives me the name of an employee at Tyan who may or may not still work there (note date).

What's hard for me to understand here is that what's listed/mentioned is an LM85 chip. I think the 2c/2d/2e in the wildcard strings represent SMBus offsets, meaning that this chip and/or what Tyan did was implement some kind of "emulation layer" to make the device appear as a LM85 on certain slave addresses. This worries me greatly, as I do not know just how reliable/accurate this is. But if all the sensors do in fact reside across multiple slave addresses, then yes, bsdhwmon can be modified to support such (the Supermicro X6DVA/X6DVL/X6DAL is a great example -- it has two H/W monitoring chips on it, tied to different slave addresses, solely to provide a enough sensors).

I also found this, which further supports my concerns (although it looks like lm-sensors detected the wrong chip here -- this is exactly why bsdhwmon will never use "auto-detection" and is very stringent/specific; I don't like "making guesses", I like definitive information): http://marc.info/?l=lm-sensors&m=125890685013819

Finally there's this: http://www.spinics.net/lists/lm-sensors/msg40827.html -- odds are DME1737 is a different chip than the DME5017.

Welcome to why getting documentation from the actual hardware vendor (Tyan) is most definitive. You may want to try sending an Email to Raphael Deng at Tyan (if he still works there) and see if maybe he can provide some register documentation for the Tyan S2932. You're welcome to CC me (jdc@koitsu.org) if needed. They absolutely have to have this information because whoever programmed the BIOS (which presumably shows H/W monitoring details) would have needed the same register reference (although they may have used LPC interface).

In the meantime, assuming you are OK with the possibility of the system crashing or misbehaving after doing this, you can try loading the nfsmb(4) driver (if it isn't loaded already; see dmesg and/or pciconf and/or kldstat) and see how many /dev/smb* devices appear that correlate with the nForce 2 SMBus controller (see pciconf -lvbc) and then use smbmsg -f /dev/smbX -p to "probe" for potential devices. Again, huge warning: this is dangerous and can leave the system or its underlying chips (ex. the nForce 2 chip) in a weird state requiring either a system reset or power-cycle.

[koitsu]

I'm reopening this until we've exhausted all avenues.

[edgeman16]

My email to Raphael bounced. Tried googling and found https://www.linkedin.com/pub/raphael-deng/10/a62/b19 Looks like he doesn't work at Tyan anymore, but when he did it was for 9 years as a firmware engineer... Definitely the right person. I could try contacting them but it may not be appropriate.

[koitsu]

I have an account on LinkedIn, so I'll send him a message there. He might not have information (or remember something from 9 years ago), but he might know of someone there who could provide what's needed.

[koitsu]

I've sent a friend invite to him on LinkedIn with an explanation of my intentions (hard to do in 300 characters). Let's wait and see.

[koitsu]

It's been a full month now and Raphael sadly has not responded to my LinkedIn request. This is a disappointment (generally speaking). It might be worth digging around Linux or lmsensors mailing lists to see if any other Tyan employees are lurking + might know who to talk to.

Sadly it's like this in the industry -- there's often one single employee deep within the bowels of a company that holds the answers to the low-level technical details needed to make something work, and when that employee leaves, all that knowledge is effectively lost.

[koitsu]

It's been about 1.5 years since this issue was last touched. Due to lack of public details available for this board from the vendor, and my own attempts at reaching out at responsible individuals have failed, I'm going to have to say this isn't plausible to do right now. I would be more than happy to re-open this if/when said information can be discovered or made available. Sorry! I never like turning down good requests. :(

[edgeman16]

No problem, you did what you could :) Thanks