koitsu
commented
6 years ago superiotool output is not helpful here, sorry to say. It gives me "some ideas" (specifically that one of the chips does live on SMBus, as "0x2e" looks like a slave address), but this is not how I approach adding support for motherboards. As per README.md, I rely entirely on information provided by the board vendor, to ensure that there is no chance of mishap or need to "reverse-engineer" or take "guesses" at things.
A good example of why I rely on vendor information is in doc/board-technical.md for the X7SBL series, where there are two Winbond/Nuvoton chips on the board, but only one is used for hardware monitoring. Talking to the wrong chip could very likely cause system instability. Other times, there are multiple chips used for monitoring (due to large numbers of sensors/fans/etc. that exceed capabilities of a single chip), such as in doc/board-technical.md for the X6DVA series. As you can see, every board varies.
What would be helpful is:
-
kenv | grep smbiosoutput -- there is information here I use to key off of for proper board identification. I care specifically aboutsmbios.planar.makerandsmbios.planar.product, but sometimes the other information is helpful. -
Information from Supermicro directly. I should be able to get this information from them via Email, as I have in the past; they're excellent in providing this type of detail. This, combined with IC documentation, is usually the best way to go about it. Supermicro sometimes makes hardware changes to their boards (adding in-line resistors, etc.) that can affect readings (example: doc/), and sometimes they disclose this information in their Emails.
-
Having an available X7DBU system that can be tested on for development purposes. This means accepting the possibility that the system may crash, act "anomalous" (lock up), or possibly reboot, so having physical access to the system is important. Any other problems would be unrelated. I have seen (during development, incorrect index registers being read from, due to a bug) an older Supermicro board/system lock up requiring a full power-cycle (a hard reset did not work!). If I had SSH and root access to the system (I'd need both, though locking down sudo to only run the path to the binary, as well as
gdb(installed from pkg/ports), that would be fine), that makes the process significantly faster. But if that cannot be done (for security, personal concern, etc.), that's OK too! In that scenario I would give you binaries built for 11.1-RELEASE-p10 to try, or make a specific branch in GitHub and have you compile the source code (requires you be a little familiar withgit, but not difficult), but this can take time (Emails back and forth, etc.).
It should be noted that the X7DBU is officially EoL'd, per Supermicro's website, and as doc/board-technical.md states, I do not know what their retention policies are on documentation for EoL'd boards. In other words: they may come back and say "sorry we don't have this info due to EoL", in which case I cannot add support for this board (again: I don't take risks, I only rely on vendor information -- stability is important).
Let me know if you want me to proceed, and I can start conversations with Supermicro.
AlmightyOatmeal
cdtweb
I would love support for my Supermicro X7DBU (Super IO: Winbond W83627HF/F/HG/G, Hardware Monitor: Winbond W83793G). I don't have much useful information yet but I'm working on it and I'm willing to provide as much information as advised.