OS/2, eCS & ArcaOS - Technical > Programming

An XWorkplace CPU Temperature Widget for AMD CPUs

<< < (2/7) > >>

Lars:
Got a little further:

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.

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 ?

Dariusz Piatkowski:
Hey Lars!


--- Quote from: Lars on March 03, 2025, 07:47:50 am ---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.

--- End quote ---

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


--- Quote from: Lars on March 03, 2025, 07:47:50 am ---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 ?

--- End quote ---

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:


--- Code: ---+*_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]

--- End code ---

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:


--- Code: ---+*_SB_ T:[Device]
 Current state:
 Possible State:
   |
   +*PR00 T:[Package]
   |
   +*AR00 T:[Package]
   |
   +*PR20 T:[Package]
   |
   +*AR20 T:[Package]
   |
   +*PR21 T:[Package]
...

--- End code ---

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.

Lars:
Hi Dariusz,

my ACPI is crippled, it's very old and does not support many of the new ACPI objects. And then, I don't know if with our ACPI.PSD there is a way to overload ACPI tables on the fly.

But this webpage gave me the clue how for AMD you can read temperature directly from PCI config space:
https://www.alcpu.com/CoreTemp/howitworks.html

Then I found the AMD BIOS Writer's Guide:
https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/42301_15h_Mod_00h-0Fh_BKDG.pdf

The register to read is the "Reported Temperature Control" PCI config space register Device 18h Function 3 Byte Offset A4h  (so yes, in principle, the ACPI tables could be extended by AML code that just reads that specific PCI config space register but I am far from an expert on ACPI).

Now I need some time to "borrow" the XWorkplace Temperature Widget code and hack together a widget for AMD.
And then I have to find out exactly what AMD CPUs support that PCI config space register. Don't want to crash anyone's system ...


Rich Walsh:
Run 'testlog acpi' then look at the last 5000+ lines: it's all there. Also, run 'iasl.exe' to see if any of its many options are of use to you.

Lars:

--- Quote from: Rich Walsh on March 04, 2025, 10:15:58 am ---Run 'testlog acpi' then look at the last 5000+ lines: it's all there. Also, run 'iasl.exe' to see if any of its many options are of use to you.

--- End quote ---

It is there if your ACPI supports it. It does not work on my system: ACPI is of no help on my system. I also used "acpimanager" to get a visual representation of my ACPI. Nothing of use can be found in my ACPI tables.
I will need to use proprietary methods to read CPU temperature and AMD works differently than Intel: AMD uses PCI config space and Intel uses a dedicated MSR.

AcpiManager: https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/util/power/ACPIManager_00-14.zip

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version