Request: Support Prime X470-Pro board

[darcagn]

Board: "PRIME X470-PRO" - uses \AMW0.ASMX

I simply added the following lines to the asus_ec_dmi_table:

    DMI_EXACT_MATCH_BOARD(VENDOR_ASUS_UPPER_CASE, "PRIME X470-PRO",
		SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_TEMP_T_SENSOR |
		SENSOR_TEMP_VRM | SENSOR_FAN_CPU_OPT |
		SENSOR_FAN_WATER_FLOW | SENSOR_CURR_CPU),

Compiled and loaded kernel module, run sensors and I get:

asusec-isa-0000
Adapter: ISA adapter
CPU_Opt:        0 RPM
Water_Flow:  1769 RPM
Chipset:      +57.0°C  
CPU:          +62.0°C  
Motherboard:  +36.0°C  
T_Sensor:     -40.0°C  
VRM:          +21.0°C  
CPU:          36.00 A

The T_Sensor I assume is working but showing -40.0C because I have no sensor actually plugged in.

However the Water_Flow reading I am seeing is incorrect; that reading is actually for the fan plugged into the CPU_OPT connector on my board.
When I plug a fan into AIO_PUMP or W_PUMP I am getting a spinning fan but sensors doesn't show any reading on CPU_Opt (so it's not just a matter of them being reversed or something).
Another question I have is why CHA_FAN1, CHA_FAN2, CHA_FAN3, etc. readings aren't supported on any of these boards. Are they just not exposed in this way or is something more needed to support them?

[zeule]

Thank you for the submission! This is the first one for the 400-series chipset, so things can be unexpectedly different from the 500-series we dealt with so far. I would not be surprised, in particular, if sensor addresses are different. However, I had an impression that all the monitoring sensors for X470 boards are provided by the asus_wmi_sensors driver. Or, perhaps, you are here because of the noted bugs for this motherboard model?

You can try to poke around 0xb0 address looking for the correct registers, of course.

Not all the sensors are published via EC, look for fans in the Super I/O chip (one of the nctXXX drivers, perhaps?), you can also check out this kernel bug.

[darcagn]

You are correct that I can get proper readings for my Prime X470-Pro board from the asus_wmi_sensors driver, but unfortunately you are also correct that I have encountered bugs while using it. Specifically, after some time I will come back to the computer and find all of the fans stuck on full blast until reboot. This can occur with Windows system monitoring software, too (including ASUS's own software, from what I've heard), and hasn't been fixed in years of BIOS updates, including the current newest. For some, they have the opposite problem (fans stopping completely) so I don't feel I can trust anything that is using the WMI interface. As for the Super I/O chip, this board uses an ITE8665E, which has no official support under Linux, only an abandoned unmaintained driver that gives me problems (and also seems to suffer from the same acpi_enforce_resources=lax bug).

As for this driver,

• I was able to dig out a temperature probe and I can confirm that the temperatures reported for T_Sensor are correct when a probe is connected.
• I wrote a script to assist in testing many different registers, but I don't think I've found anything more except it appears that there's a 2-byte value representing CPU voltage at 0xa2?

asusec-isa-0000
Adapter: ISA adapter
CPU_milliVolt: 1082 RPM		/* 2-byte value at 0x00, 0xa2 */
CPU_Opt:          0 RPM		/* at 0xbc instead of 0xb0 */
Chipset:        +62.0°C
CPU:            +51.0°C
Motherboard:    +41.0°C
T_Sensor:       -40.0°C
VRM:            +21.0°C
CPU:             4.00 A

• I loaded asus-ec-sensors and asus-wmi-sensors side-by-side and they agree with one another.

asuswmisensors-isa-0000
Adapter: ISA adapter
CPU Core Voltage:          1.08 V
+12V Voltage:             12.16 V
+5V Voltage:               4.99 V
3VSB Voltage:              3.33 V
CPU Fan:                 2472 RPM
Chassis Fan 1:            786 RPM
Chassis Fan 2:              0 RPM
Chassis Fan 3:              0 RPM
AIO Pump:                   0 RPM
Water Pump:                 0 RPM
CPU OPT:                    0 RPM
CPU Temperature:          +51.0°C
Motherboard Temperature:  +41.0°C
Chipset Temperature:      +62.0°C
Tsensor 1 Temperature:   +216.0°C

• (although the above examples show no t_sensor installed and a lot of disconnected fans, at the time of testing I did have PWM fans connected to every connector and the t_sensor was installed -- I just disconnected them before writing this post because having 5 extra fans hanging out the side of my case wasn't comfortable 😀)
• in HWiNFO in Windows, the ASUS EC only has chipset temp, T_sensor temp, CPU_OPT fans, CPU current, and CPU power. We already have these and more, and I don't see anything else, so I guess this is all we'll be able to get from the EC for this board.

Please let me know if there's anything else you need from me to have the board supported. Thanks!

[zeule]

Thank you for the detailed explanation! Is the following brief summary correct?

1. CPU_Opt_X470 fan at the 0x00bc (in place of Water_Flow for 500-series).
2. CPU voltage at 0x00a2 (SENSOR_IN_CPU).
3. This is the correct list of sensors: SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_VRM | SENSOR_FAN_CPU_OPT_X470 | SENSOR_CURR_CPU | SENSOR_IN_CPU.
4. The mutex name is the same as for the 500-series: \AMW0.ASMX.

[darcagn]

That's all correct! 👍

[zeule]

Great! Thank you for the detailed investigation results! I'll post changeset here and cc you for a patch submission.

[zeule]

CPU core voltage sensor is found at the same address for Crosshair VIII Hero.

[zeule]

@darcagn, since you did not make your email public for the GitHub profile, could you, perhaps, send me an email so I can cc you for the HWMON patch? Thanks!

[KeithMyers]

I added my ROG Crosshair VII Hero to the source file and compiled. See my post at Issue#14

[darcagn]

Attaching the DSDT for PRIME X470-PRO, in case that helps.

PRIME X470-PRO.zip

I conclude that for the 400-series I need an independent set of sensor definitions and also have to correct signess for the CPU current (have to encode it in the sensor address). Thus, adding support for your board will take some days.

No worries on this, take all the time you need, I'm just happy to help. 😃

BTW, not sure if you got my email, it's my github username at protonmail dot com.

[zeule]

Thank you for the DSDT, I read it and here follows what I found.

The UPEC method reads from the EC and updates the SENB array with sensor readings:

Method (UPEC, 0, Serialized)
{
      If ((Acquire (_GL, 0x03E8) == Zero))
      {
          WECR (0xFF, Zero)
          Local0 = RECR (0x3A)
          NU12 = Local0
          Local0 = RECR (0x3D)
          NU13 = Local0
          Local0 = RECR (0xBC)
          Local1 = RECR (0xBD)
          Local0 = ((Local0 << 0x08) | Local1)
          NU14 = Local0
          Release (_GL)
          Return (Zero)
      }

    Return (Ones)
}

There are only 3 sensors here, whose readings are placed in NU12, NU13, and NU14. The method locks mutex _GL, which is the global ACPI lock (and not AMW0.ASMX, which is used to guard access to the Super I/O chip).
Now, these 3 NU elements are referenced from the INFO package and are "Chipset Temperature", "Tsensor 1 Temperature", and "CPU OPT". The RECR methods reads the given EC register. Thus the mapping is the following:

0x3A -> "Chipset Temperature"
0x3D -> "Tsensor 1 Temperature"
(0xBC << 8) | 0xBD -> "CPU OPT" ("Water Flow" for 500-series)

But we know already that there are CPU, MB, and VRM temperature in the EC registers, and you also found the CPU core voltage.

[zeule]

BTW, not sure if you got my email, it's my github username at protonmail dot com.

Yes, I did, thank you.

[zeule]

@darcagn, could you, please, check whether the kernel guards access to the EC with the global lock?

# modprobe ec_sys
# cat /sys/kernel/debug/ec/ec0/use_global_lock

[darcagn]

Sure! That command returns N
(This is on 5.15.13-gentoo kernel)

[zeule]

Thank you, needed to verify my conclusion deduced from the DSDT code, because there are number of workarounds in the kernel for ASUS boards. So typical of ASUS software engineering: instead of declaring the EC as guarded by the global lock and let OSes handle that, let's acquire it manually in every method we write to access the EC...

[zeule]

@darcagn, I pushed a new branch with the board support included and would appreciate a test run with the hardware, please.

[darcagn]

Compiled and tested from new branch; two issues:

• Water_Flow shows up (and matches CPU_Opt) when it shouldn't be supported
• CPU Core Voltage is not showing up when it should be supported

asusec-isa-0000
Adapter: ISA adapter
CPU_Opt:     2097 RPM
Water_Flow:  2097 RPM
Chipset:      +62.0°C  
CPU:          +64.0°C  
Motherboard:  +41.0°C  
T_Sensor:     +27.0°C  
VRM:          +21.0°C  
CPU:          44.00 A 

So I went into the source and removed SENSOR_FAN_WATER_FLOW and replaced with SENSOR_IN_CPU_CORE and now I get exactly what I expect, and matching with asus-wmi-sensors

asusec-isa-0000
Adapter: ISA adapter
CPU Core:      1.43 V  
CPU_Opt:     2111 RPM
Chipset:      +62.0°C  
CPU:          +65.0°C  
Motherboard:  +41.0°C  
T_Sensor:     +27.0°C  
VRM:          +21.0°C  
CPU:          27.00 A  

asuswmisensors-isa-0000
Adapter: ISA adapter
CPU Core Voltage:          1.40 V  
+12V Voltage:             12.16 V  
+5V Voltage:               4.99 V  
3VSB Voltage:              3.33 V  
CPU Fan:                 2509 RPM
Chassis Fan 1:           1119 RPM
Chassis Fan 2:              0 RPM
Chassis Fan 3:              0 RPM
AIO Pump:                   0 RPM
Water Pump:                 0 RPM
CPU OPT:                 2111 RPM
CPU Temperature:          +66.0°C  
Motherboard Temperature:  +41.0°C  
Chipset Temperature:      +62.0°C  
Tsensor 1 Temperature:    +27.0°C  

[zeule]

Thank you! Sorry for the mistake in the sensors definition. I'm making the following change:

--- a/asus-ec-sensors.c
+++ b/asus-ec-sensors.c
@@ -185,7 +185,7 @@ struct ec_board_info {
 static const struct ec_board_info __initconst board_prime_x470_pro = {
  .sensors = SENSOR_SET_TEMP_CHIPSET_CPU_MB | SENSOR_TEMP_T_SENSOR |
    SENSOR_TEMP_VRM | SENSOR_FAN_CPU_OPT_V1 |
-   SENSOR_FAN_WATER_FLOW | SENSOR_CURR_CPU,
+   SENSOR_CURR_CPU | SENSOR_IN_CPU_CORE,
  .mutex_path = ACPI_GLOBAL_LOCK_PSEUDO_PATH,
 };

Now I need a good solution to replace these _V0 and _V1 CPU opt sensors and then I can submit these changes to the mainline.

[zeule]

Are there any news, @darcagn ?

[darcagn]

Sorry for not getting back to you sooner. I've been running watch -n 2 sensors 'asusec-*' in a terminal window off and on for several days at a time and haven't had a problem, I'd say it's stable.

[zeule]

Thank you, I will prepare and submit these changes to the mainline kernel then. I will need a "Tested-by" comment from you, as we already discussed, but can't promise when I will push these changes out, as my personal time flow is complicated while my country fights back the Russian invasion.

[zeule]

Mainlined.