IT8696E on Gigabyte X870 AORUS Elite

[archiebug]

Hi-

It appears that the run of the Gigabyte AORUS X870 boards uses IT87952E and IT8696E. IT87952E is detected by the latest kernel, 6.12. I'm unable to track down any info on the IT8696E.

It appears that support has been added to HWMON64 and LibreHardwareMonitor (LibreHardwareMonitor/LibreHardwareMonitor#1510).

Outside of having a contact with Gigabyte or ITE, what info can I provide to help you out?

[triffid]

X870I Aorus Pro Ice (mini-ITX) seems to also use the IT8696E:

# grep . /sys/class/dmi/id/board_*
/sys/class/dmi/id/board_name:X870I AORUS PRO ICE
/sys/class/dmi/id/board_vendor:Gigabyte Technology Co., Ltd.

# sensors-detect
…
Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      Yes
Found unknown chip with ID 0x8696
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
…

# isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 86 96 00 00 2e 20 b3 20 00 00 80 30 88 40 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0a 10 0a 00 0a 20 00 00 00 00 00 00 00 00 00 00
70: 00 00 20 00 00 17 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 c0 00 00 00 00
c0: 01 00 00 40 00 ff ff ff 01 00 00 00 00 60 00 00
d0: b5 00 08 0a 00 fd ff ff 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 50 00 20 12 49 00 00 0a 7c
f0: 10 00 00 00 1d 00 0d 00 00 d0 49 60 ff fe 00 0f

[triffid]

~/Projects/it87 $ make
Makefile:2086: !!!! WARNING !!!!
Makefile:2087: This kernel was configured and installed by the package manager.
Makefile:2088: "make" should not be run manually here.
Makefile:2089: See also: https://wiki.gentoo.org/wiki/Project:Distribution_Kernel
Makefile:2090: See also: https://wiki.gentoo.org/wiki/Kernel/Configuration
Makefile:2091: !!!! WARNING !!!!
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: x86_64-pc-linux-gnu-gcc (Gentoo 13.3.1_p20241115 p1) 13.3.1 20241115
  You are using:           gcc (Gentoo 13.3.1_p20241115 p1) 13.3.1 20241115
  CC [M]  /home/triffid/Projects/it87/it87.o
  MODPOST /home/triffid/Projects/it87/Module.symvers
  CC [M]  /home/triffid/Projects/it87/it87.mod.o
  CC [M]  /home/triffid/Projects/it87/.module-common.o
  LD [M]  /home/triffid/Projects/it87/it87.ko
…
# insmod /home/triffid/Projects/it87/it87.ko force_id=0x8696
insmod: ERROR: could not insert module /home/triffid/Projects/it87/it87.ko: No such device
# dmesg
…
[100369.955312] it87: it87 driver version v1.0-169-g213db3a.20240922

🤷

[ninja-]

obviously "no such device" would be modprobe result as that's common behavior of platform drivers when they don't detect any supported device. and 0x8696 is not a device currently known to it87

[ninja-]

I would start with cloning a definition of similar device for example and see how it goes
https://github.com/frankcrawford/it87/blob/master/it87.c#L752

there seems to be a support in LibreHardwareMonitor project which tells you how many different sensor types are in this chip and which could be used to tune the flags with some trial and error

https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/blob/master/LibreHardwareMonitorLib/Hardware/Motherboard/SuperIOHardware.cs#L2176C60-L2176C67

[ninja-]

FEAT_FIVE_FANS, FEAT_SIX_TEMP, FEAT_FIVE_PWM("Control") would match data from LHM. Not sure about the voltage part

[triffid]

I've got it "working" by forcing the 0x8628 ID, but a few of the values look a bit bogus and I can't runtime-change fan PWM or temperature pairings or thresholds - so obviously the register layout is a little different.

I tried asking ITE for the datasheet, but they said it was a custom ASIC for a specific customer and they can't just hand it out - guess the next step is to ask Gigabyte and be surprised if they do anything other than ignore us or say no?

[Flat]

I have it working for the pro ice, if you want to try it
https://github.com/Flat/it87/tree/it8696

PWM only works for PCH fan though.

it8696-isa-0a40
Adapter: ISA adapter
CPU VCORE:          1.39 V  (min =  +0.00 V, max =  +3.06 V)
+3.3V:              3.39 V  (min =  +0.00 V, max =  +5.14 V)
+12V:              12.17 V  (min =  +0.00 V, max = +18.36 V)
+5V:                4.98 V  (min =  +0.00 V, max =  +7.65 V)
CPU VCORE SoC:      1.24 V  (min =  +0.00 V, max =  +3.06 V)
CPU VCORE Misc:     1.14 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
CPU VDDIO Memory:   1.36 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
+3VSB:              3.29 V  (min =  +0.00 V, max =  +6.12 V)
CMOS Battery:       3.14 V
+3.3V:              3.07 V
CPU_FAN:          4041 RPM  (min =   10 RPM)
SYS_FAN1:         1445 RPM  (min =   10 RPM)
PCH:              8881 RPM  (min =    0 RPM)
CPU_OPT:          1448 RPM  (min =   10 RPM)
System 1:          +51.0°C  (low  = +127.0°C, high = +127.0°C)
PCH:               +62.0°C  (low  = +127.0°C, high = +127.0°C)
CPU:               +60.0°C  (low  = +127.0°C, high = +127.0°C)
PCIEX16:           +55.0°C  (low  = +127.0°C, high = +127.0°C)
VRM MOS:           +59.0°C  (low  =  +0.0°C, high = -125.0°C)

[archiebug]

I have it working for the pro ice, if you want to try it https://github.com/Flat/it87/tree/it8696

PWM only works for PCH fan though.

it8696-isa-0a40
Adapter: ISA adapter
CPU VCORE:          1.39 V  (min =  +0.00 V, max =  +3.06 V)
+3.3V:              3.39 V  (min =  +0.00 V, max =  +5.14 V)
+12V:              12.17 V  (min =  +0.00 V, max = +18.36 V)
+5V:                4.98 V  (min =  +0.00 V, max =  +7.65 V)
CPU VCORE SoC:      1.24 V  (min =  +0.00 V, max =  +3.06 V)
CPU VCORE Misc:     1.14 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
CPU VDDIO Memory:   1.36 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
+3VSB:              3.29 V  (min =  +0.00 V, max =  +6.12 V)
CMOS Battery:       3.14 V
+3.3V:              3.07 V
CPU_FAN:          4041 RPM  (min =   10 RPM)
SYS_FAN1:         1445 RPM  (min =   10 RPM)
PCH:              8881 RPM  (min =    0 RPM)
CPU_OPT:          1448 RPM  (min =   10 RPM)
System 1:          +51.0°C  (low  = +127.0°C, high = +127.0°C)
PCH:               +62.0°C  (low  = +127.0°C, high = +127.0°C)
CPU:               +60.0°C  (low  = +127.0°C, high = +127.0°C)
PCIEX16:           +55.0°C  (low  = +127.0°C, high = +127.0°C)
VRM MOS:           +59.0°C  (low  =  +0.0°C, high = -125.0°C)

@Flat: I gave your updates a spin and it works. Here's my config for both chips. How did you come up with the offset calculations?

For the +3.3 V offset, try changing 6.8 to 6.49

                        v.Add(new Voltage("+3.3V", 1, 6.49F, 10));

# ITE IT87952
chip "it87952-isa-0a60"
        label temp1 "PCIe x4"
        label temp2 "External #2"
        label temp3 "System #2"
        label temp4 "PCIEX16"
        label temp5 "VRM MOS"
        label temp6 "VSOC MOS"
        label in0 "CPU Vcore"
        label in1 "DIMM I/O"
        label in2 "Chipset +0.82V"
        label in3 "Voltage #4"
        label in4 "CPU System Agent"
        label in5 "Chipset +1.8V"
        label in6 "Voltage #7"
        label in7 "+3V Standby"
        label in8 "CMOS Battery"
        label fan1 "SYS_FAN #5"
        label fan2 "SYS_FAN #6"
        label fan3 "SYS_FAN #4"

# ITE IT8696E
chip "it8696-isa-0a40"
        label in0 "CPU VCORE"
        label in1 "+3.3V"
        compute in1 @*((6.49/10)+1), @/((6.49/10)+1)
        label in2 "+12V"
        compute in2 @*((50/10)+1), @/((50/10)+1)
        label in3 "+5V"
        compute in3 @*((15/10)+1), @/((15/10)+1)
        label in4 "CPU VCORE SoC"
        label in5 "CPU VCORE Misc"
        label in6 "CPU VDDIO Memory"
        label in7 "+3VSB"
        label in8 "CMOS Battery"
        label fan1 "CPU_FAN"
        label fan2 "SYS_FAN #1"
        label fan3 "SYS_FAN #2"
        label fan4 "SYS_FAN #3"
        label fan5 "CPU_OPT"
        label temp1 "System 1"
        label temp2 "PCH"
        label temp3 "CPU"
        label temp4 "PCIEX16"
        label temp5 "VRM MOS"
        #label temp6 "External #1" # Will show -55C if open circuit (no thermistor plugged in)
        ignore temp6
        ignore intrusion0

[Flat]

@Flat: I gave your updates a spin and it works. Here's my config for both chips. How did you come up with the offset calculations?

I just used the basic formulas from "Voltage Computation Details" of the sensors.conf man page and took values from other gigabyte boards.

Looks like 6.49 works a lot better to give 3.3V though. The 12V and 5V probably need to be tweaked as well, but comparing the BIOS values they seemed pretty close.

I'm also not quite sure what in9 is, sensors seems to auto detect it as another +3.3V, but that could be wrong as well.

[archiebug]

@Flat: I gave your updates a spin and it works. Here's my config for both chips. How did you come up with the offset calculations?

I just used the basic formulas from "Voltage Computation Details" of the sensors.conf man page and took values from other gigabyte boards.

Looks like 6.49 works a lot better to give 3.3V though. The 12V and 5V probably need to be tweaked as well, but comparing the BIOS values they seemed pretty close.

I'm also not quite sure what in9 is, sensors seems to auto detect it as another +3.3V, but that could be wrong as well.

Interesting... in9 doesn't show up for me. Thanks for the link!

[Flat]

Interesting... in9 doesn't show up for me. Thanks for the link!

I have the X870I (Mini-ITX) so that could be the difference.

If you can give me the output of cat /sys/class/dmi/id/board_name I can add your board to the dmi match so you do not need to add acpi_enforce_resources=lax to your kernel cmdline either, (unless you don't need to).

[archiebug]

cat /sys/class/dmi/id/board_name
>X870 AORUS ELITE WIFI7

I think I see the in9 you are mentioning. For some reason, sensors is labeling it as "+3.3V" (under CMOS Battery). My conf labels in1 as "+3.3 V"

it8696-isa-0a40
Adapter: ISA adapter
CPU VCORE:        960.00 mV (min =  +0.00 V, max =  +3.06 V)
+3.3 V:             3.30 V  (min =  +0.00 V, max =  +5.05 V)
+12 V:             12.10 V  (min =  +0.00 V, max = +18.36 V)
+5 V:               5.01 V  (min =  +0.00 V, max =  +7.65 V)
CPU VCORE SoC:      1.25 V  (min =  +0.00 V, max =  +3.06 V)
CPU VCORE Misc:     1.14 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
CPU VDDIO Memory:   1.38 V  (min =  +0.00 V, max =  +3.06 V)  ALARM
+3 V Standby:       3.31 V  (min =  +0.00 V, max =  +6.12 V)
CMOS Battery:       3.19 V  
+3.3V:              3.07 V  
CPU_FAN:           329 RPM  (min =    0 RPM)
SYS_FAN #1:          0 RPM  (min =    0 RPM)
SYS_FAN #2:        787 RPM  (min =    0 RPM)
SYS_FAN #3:        804 RPM  (min =    0 RPM)
CPU_OPT:           746 RPM  (min =    0 RPM)
System 1:          +28.0°C  (low  = +127.0°C, high = +127.0°C)
PCH:               +45.0°C  (low  = +127.0°C, high = +127.0°C)
CPU:               +47.0°C  (low  = +127.0°C, high = +127.0°C)
PCIEX16:           +39.0°C  (low  = +127.0°C, high = +127.0°C)
VRM MOS:           +37.0°C  (low  =  +0.0°C, high = -125.0°C)

[triffid]

I have the X870I (Mini-ITX) so that could be the difference.

I also have the X870I (mini ITX) fwiw;

$ cat /sys/class/dmi/id/board_name
X870I AORUS PRO ICE

I'll give your branch a spin if you think more eyeballs on it will help

[Flat]

I've added the X870 AORUS ELITE WIFI7 to the DMI matching table on my branch.

I think I see the in9 you are mentioning. For some reason, sensors is labeling it as "+3.3V" (under CMOS Battery). My conf labels in1 as "+3.3 V"

Yes, that is the one. If you run sensors -u it will show you the raw input names i.e. in9. Still not sure what it actually relates to, but so far it is good enough for me as is.

I'll give your branch a spin if you think more eyeballs on it will help

Sure, always good to have more tests to ensure it works correctly and as expected.

[frankcrawford]

Folks, thanks for all this effort, I'll go through and add these definitions to this driver here, which will at least get it working with the updated driver.

I'll also look at if it can go into the mainline kernel yet, and if so push something upstream, although that will probably take a few months to appear.