Hey Lars!
1) the "SystemLoad" temperature widget from Digi only works for Intel CPUs. He is reading from an MSR to query the temperature value. And that MSR does not exist on AMD CPUs (unfortunately not all MSRs are part of the base X86 architecture ...). The XCenter widget (I think) also leads to repeated traps on my system (CPU: FX-8350, which is a Vishera release of the Bulldozer architecture) once the WPS attempts to load until the system finally completely freezes.
Ahh, to be somewhat expected given that the "olden way" of getting at this info was to query specific hardware locations...so as you found out given the lack of industry standard, which to be honest I can't imagine any vendor to ever agree on this type of stuff, they all want to do stuff 'their way', would require you to hit the CPU/CHIPSET specific locations on the new hardware
2) stumbled across a Windows utility to read out temperatures. And for AMD, they say that they are reading a register from the Northbridge (and that seemingly works for many later AMD CPUs and should also include the FX-8350 and @Dariusz it should therefore also include the FX-8370 ...). In order to find the spec: is the Northbridge built into the CPU or is is part of a separate chipset ?
So for our Vishera CPUs the Northbridge is actually contained on the CPU die. This actually is composed of the System Request Interface, Memory Controller, DRAM Controllers and crossbar (Copy & Paste from the 'AMD Piledriver BIOS and Kernel Developer's Guide). There still is a motherboard Northbridge, but that functionality is nowhere what it used to be. Instead stuff like 990FXA (which my MSI 990FXA-GD80 board has) handles the connectivity between the CPU and the rest of the system, so think along the lines of PCIe lanes, HyperTransport, etc. Southbridge on the other hand handles stuff like SATA, RAID, USB, conventional PCI bus, etc.
Some motherboards of course provide alternatives, so USB3 for example being implemented through a different chipset altogether.
As it happens that AMD BIOS and Kernel Dev Guide has a full listing of ALL the availble registers. So you could look that up (it is a PDF) and see if you match against what that Windows util is using?
Now, I will say this: it would be awfully nice to have the acpidecode utility so that the dump of your ACPI tables (which can be obtained through the our APIC implementation with acpidump) could be translated to a more human readable mapping
Having said that, way back when, as in around ACPI 3.18 the ACPI utils used to be released as a binaries. Since then the AOS releases have gone to all of these utils being lumped into the "samples" directory of the Toolkit, which of course you can try compiling. I suppose that's probably my next step seeing that doing so would at least give me the most up-to-date versions for the ACPI system we have today.
Regardless, I've attached two outputs:
1) acpi_object
- this is the result of the old acpitest.exe
2) acpi_tree
- this is actually a version of the acpidump that gives you a nice hierarchical snapshot of what hardware you currently have an most importnatly of all, which devices support which ACPI methods!!!
So here is a little section of it:
+*_PR_ T:[Scope]
|
+*SSDT T:[Region]
|
+*DCOR T:[Integer]
|
+*TBLD T:[Integer]
|
+*NPSS T:[Integer]
|
+*HNDL T:[Integer]
|
+*APSS T:[Package]
|
+*P001 T:[Processor]
|
+*TYPE T:[Integer]
|
+*_PDC T:[Method]
|
+*P002 T:[Processor]
|
+*TYPE T:[Integer]
|
+*_PDC T:[Method]
This represents the processor table where each P00x object shows an available _PDC method, which the ACPI 6.5a specs document as follows: "Processor Driver Capabilities – inform AML of processor driver capabilities.".
Now, I do not know that this is the right place for the full answer...well, I do, and it is NOT (LOL), but it certainly seems like a viable path to pursue b/c now I could take some of the Toolkit sample source code and modify to get the specific details I'm after.
Digging into this a tad more I do actually find the 'Thermal Zones' scope in that ACPI tree:
+*_SB_ T:[Device]
Current state:
Possible State:
|
+*PR00 T:[Package]
|
+*AR00 T:[Package]
|
+*PR20 T:[Package]
|
+*AR20 T:[Package]
|
+*PR21 T:[Package]
...
So at least one can look up the very specific syntax to use in order to get the specific 'temperature' details we are interested in.
More to come on this for sure as unlocking the ACPI approach would get us CPU/chipset agnostic way to query up the information...the big assumption here of course being that the ACPI implementation we are using isn't just Intel specific, and seeing how ACPI is an industry standard these days, I'm thinking this should cover non-Intel stuff as well.