Fans PWM control not working on Gigabyte B560M DS3H V2 (ITE8689)

[PsychoRS]

Hi Frank,

I'm using your driver, packaged by ich77 for unRAID.

Board is a Gigabyte B560M DS3H, with an ITE8689. With your driver, I can see the fan's RPM (sensor-detect detects the 8689), but I'm facing the problem that the fans are not responding to any pwm changes. pwmconfig fires up, detect the fans, but when it tries to adjust the rpm while probbing, nothing happens.

If fact, fan speeds doesn't vary when I modify the contents of pwm1/2/3/4 via an echo 0.

root@Rei:/# pwmconfig
# pwmconfig version 3.6.0
This program will search your sensors for pulse width modulation (pwm)
controls, and test each one to see if it controls a fan on
your motherboard. Note that many motherboards do not have pwm
circuitry installed, even if your sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm controls.
The program will attempt to restore each fan to full speed
after testing. However, it is ** very important ** that you
physically verify that the fans have been to full speed
after the program has completed.

Found the following devices:
   hwmon0 is nvme
   hwmon1 is nvme
   hwmon2 is coretemp
   hwmon3 is acpitz
   hwmon4 is it8689

Found the following PWM controls:
   hwmon4/pwm1           current value: 255
   hwmon4/pwm2           current value: 255
   hwmon4/pwm3           current value: 255
   hwmon4/pwm4           current value: 255
   hwmon4/pwm5           current value: 255

Giving the fans some time to reach full speed...
Found the following fan sensors:
   hwmon4/fan1_input     current speed: 971 RPM
   hwmon4/fan2_input     current speed: 0 ... skipping!
   hwmon4/fan3_input     current speed: 1383 RPM
   hwmon4/fan4_input     current speed: 1363 RPM

Warning!!! This program will stop your fans, one at a time,
for approximately 5 seconds each!!!
This may cause your processor temperature to rise!!!
If you do not want to do this hit control-C now!!!
Hit return to continue: 

Testing pwm control hwmon4/pwm1 ...
  hwmon4/fan1_input ... speed was 971 now 976
    no correlation
  hwmon4/fan3_input ... speed was 1383 now 1377
    no correlation
  hwmon4/fan4_input ... speed was 1363 now 1363
    no correlation

No correlations were detected.
There is either no fan connected to the output of hwmon4/pwm1,
or the connected fan has no rpm-signal connected to one of
the tested fan sensors. (Note: not all motherboards have
the pwm outputs connected to the fan connectors,
check out the hardware database on http://www.almico.com/forumindex.php)

Did you see/hear a fan stopping during the above test (n)? n

It looks that there is no correlation between the data of pwmX inputs and the speed of the fans (as you can see, in this pwmconfig launch, all fans are set at full speed pwm, 255, but they aren't at their real full speed, looks like they are only controlled by BIOS and doesn't react to software changes.

unRAID 6.12.1

Thanks in advance.

[frankcrawford]

@PsychoRS thanks for the comments. I will see what I can find out, or if there is a way to actually adjust the fan speeds.

[eatoff8]

@PsychoRS thanks for the comments. I will see what I can find out, or if there is a way to actually adjust the fan speeds.

OK, I only just found this thread, I thought I was doing something wrong, as my Gigabyte AORUS B560I motherboard also appears not to allow fan control.

I too am running UnRAID, using the IT87 driver package from ich77

As part of my troubleshooting, I installed a third fan, and set the BIOS fan speed control to 100%. When using the dynamix autofan plugin, and trying to detect the fan, it does slow the fan down, but only the first attempt. same with setting the fan speed, it will work on the first attempt after a reboot. Any further attempts to change the fan speed do not result in any change, the fan speed will be stuck at whatever you set it to that first time.

Bizarre. And the way the detecting of the fan works that first time, the fan slowly ramps down from 100% (I can watch and hear it), then there is just no further control until you reboot the whole system.

EDIT: I am not using and ignore conflict (it87.ignore_resource_conflict=1), should I be?

[frankcrawford]

@eatoff8 thanks for the comment, that adds a bit more information, i.e. that it works once.

Also, no, there is no need to set it87.ignore_resource_conflicts=1 for this board, if it is a B560I AORUS PRO AX, as it is detected automatically.

[PsychoRS]

@PsychoRS thanks for the comments. I will see what I can find out, or if there is a way to actually adjust the fan speeds.

OK, I only just found this thread, I thought I was doing something wrong, as my Gigabyte AORUS B560I motherboard also appears not to allow fan control.

I too am running UnRAID, using the IT87 driver package from ich77

As part of my troubleshooting, I installed a third fan, and set the BIOS fan speed control to 100%. When using the dynamix autofan plugin, and trying to detect the fan, it does slow the fan down, but only the first attempt. same with setting the fan speed, it will work on the first attempt after a reboot. Any further attempts to change the fan speed do not result in any change, the fan speed will be stuck at whatever you set it to that first time.

Bizarre. And the way the detecting of the fan works that first time, the fan slowly ramps down from 100% (I can watch and hear it), then there is just no further control until you reboot the whole system.

EDIT: I am not using and ignore conflict (it87.ignore_resource_conflict=1), should I be?

Exact same behaviour as mine, fans slow down to stop the first time I click detect (or fire pwmconfig from the CLI) a then onwards fans doesn't respond anymore

[eatoff8]

@frankcrawford Thanks for all the help with the driver package! Bizarre that it works the first time, and then never again until after a reboot. Is there any kind of diagnostic or logs i can provide that could give you more clues?

@PsychoRS EXACT same behaviour. I thought i was going crazy that it worked and then it didnt.

[frankcrawford]

Unfortunately, no, there are no additional logs than what appears in dmesg

I will look at adding a few additional debug messages.

[demetera]

I have the same motherboard. I solved the issue with these steps (on Arch):

1) Installed package it87-dkms-git from AUR (current kernel linux headers are needed) 2) In file /etc/default/grub added (if still not there) GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax" 3) Run sudo grub-mkconfig -o /boot/grub/grub.cfg to refresh config 4) Reboot 4) Added kernel module with modprobe it87 force_id=0x8628 5) Tested with sensors. Also pwmconfig found new hwmon in /sys/class/hwmon 6) After testing added options it87 force_id=0x8628 to /etc/modprobe.d/it87.conf 7) added it87 line to file /etc/modules-load.d/modules.conf

Hope you've already solved the issue

[frankcrawford]

@demetera Thanks for that. It matches what I thought is the issue, i.e. we are using the wrong registers for the PWM configuration, but I hadn't had a chance to track them down. I'll test out your fix and, if there are now issues, will update the registers for the ITE8689 chipset.

Two questions, firstly, did you check the other sensor outputs, i.e. temp, power, etc, to ensure they are unchanged? Secondly, how did you pick this ID, was it just testing other valid chipsets, or was there something abut it that look appropriate?

[demetera]

Thanks for your comment @frankcrawford

1) Nope. I didn't check other sensor output, as I've configured it almost 2 years ago and didn't touch - because it's working, but I can test for the sake of the experiment. Guenter rejected to add IT8689 to the kernel : https://lore.kernel.org/all/CAA6C2x9Snh0jzCT7Z4+m4kA+StCfsWtESPC1C0s-uKXB6_fJWw@mail.gmail.com/T/

2) I've selected the ID after reading through this thread on the old lm-sensors repo : https://github.com/lm-sensors/lm-sensors/issues/154#issuecomment-1807084793

Cheers!

[frankcrawford]

@demetera thanks for the update. A quick test does seem to show that pwmconfig makes changes to the fan speed so it looks promising. As well, I can see in the driver the differences between the ITE8689E and IT8628E chipsets, and will look at rolling in some of those changes and see how it goes.

[frankcrawford]

@eatoff8 @PsychoRS How can you test this out? I would like to have it tested before pushing it to the main repo.

[PsychoRS]

@eatoff8 @PsychoRS How can you test this out? I would like to have it tested before pushing it to the main repo.

I can if you can give me some directions on how to test It on unRAID

[PsychoRS]

Nevermind, just changed id from 0x8689 to 0x8628..

PS: No, sorry, it's not working as expected, Fans slow down on pwnconfig test but never spin up again.

Testing pwm control hwmon5/pwm1 ...
  hwmon5/fan1_input ... speed was 1496 now 736
    It appears that fan hwmon5/fan1_input
    is controlled by pwm hwmon5/pwm1
Would you like to generate a detailed correlation (y)? y
    PWM 255 FAN 860
    PWM 240 FAN 738
    PWM 225 FAN 725
    PWM 210 FAN 732
    PWM 195 FAN 730
    PWM 180 FAN 725
    PWM 165 FAN 730
    PWM 150 FAN 730
    PWM 135 FAN 725
    PWM 120 FAN 730
    PWM 105 FAN 730
    PWM 90 FAN 725
    PWM 75 FAN 777
    PWM 60 FAN 732
    PWM 45 FAN 725
    PWM 30 FAN 725
    PWM 28 FAN 731
    PWM 26 FAN 725
    PWM 24 FAN 725
    PWM 22 FAN 732
    PWM 20 FAN 731
    PWM 18 FAN 725
    PWM 16 FAN 730
    PWM 14 FAN 731
    PWM 12 FAN 725
    PWM 10 FAN 730
    PWM 8 FAN 731
    PWM 6 FAN 726
    PWM 4 FAN 732
    PWM 2 FAN 730
    PWM 0 FAN 725

As you can see, the fan slow downs a bit (from 1400RPM to around 800RPM) when /sys/class/hwmon5/pwm1_enable is set to 1 (manual) by pwmconfig, but pwm control is non-existent. I can echo 225, 220, 120, 0... to /sys/class/hwmon5/pwm1 and the fan doesn't react, just have to set pwm1_enable to 2 (auto) again for the fan autoadjust.

[eatoff8]

As you can see, the fan slow downs a bit (from 1400RPM to around 800RPM) when /sys/class/hwmon5/pwm1_enable is set to 1 (manual) by pwmconfig, but pwm control is non-existent. I can echo 225, 220, 120, 0... to /sys/class/hwmon5/pwm1 and the fan doesn't react, just have to set pwm1_enable to 2 (auto) again for the fan autoadjust.

I was so hopeful. @frankcrawford is there a list of other chipset id's we could try? If there arent too many it could just be a process of elimination

[frankcrawford]

@eatoff8 that is also what I saw, which is why I was interested in getting it tested further. I also don't think it is as simple as different chipsets to try as they are all very similar. The issue may also be how pwmconfig expects to modify the configuration vs what is available. I may need to see if I can access another chipset that does work to see how they expect it to work.

The current change is that it allows the user to "turn the fan off", but in reality, that isn't doing this, it is just dropping the speed significantly, not actually stopping it, which may not be the same at all.

[PsychoRS]

Yes, the fan never stops in my case. It just moves between 1200-750 rpm in a very narrow pwm_input range. And its an Arctic P12 PWM with a range of 0-1800rpm.

I will be happy to test anything you need.

[demetera]

Hi guys,

@frankcrawford ite8689 didn't work for me. Only 0x8628. If i have to test with other parameters, please let me know, which ones to apply.

@PsychoRS My goal was to minimise the fan noise eventually. I have a profile in BIOS - to start the fan to cool, when temp exceeds 70 deg. When temperature drops down below the threshold - fan is still taking his journey to rotate (i guess it's motherboard feature)

[eatoff8]

Yes, the fan never stops in my case. It just moves between 1200-750 rpm in a very narrow pwm_input range. And its an Arctic P12 PWM with a range of 0-1800rpm.

So controlling the fan speed does work? you just cant get it to stop? Or there is no control, it just one time drops to 750rpm until you restart?

My use case is for cooling my hard drives in UnRAID. I want to set a minimum speed (say 800rpm) and then depending on the temp of the HDDs ramp the speed up. I dont want to actually stop the fan, just ramp it up and down (not stop).

[PsychoRS]

Yes, the fan never stops in my case. It just moves between 1200-750 rpm in a very narrow pwm_input range. And its an Arctic P12 PWM with a range of 0-1800rpm.

So controlling the fan speed does work? you just cant get it to stop? Or there is no control, it just one time drops to 750rpm until you restart?

My use case is for cooling my hard drives in UnRAID. I want to set a minimum speed (say 800rpm) and then depending on the temp of the HDDs ramp the speed up. I dont want to actually stop the fan, just ramp it up and down (not stop).

No, the fan isn't controllable. It ramps down to around 800rpm but never goes back to 1300-1500 (high speed). I'm also wanting to use it as any array fan for unRAID.

[frankcrawford]

I'm pretty sure it should be controllable but for some reason it either goes to automatic or full, not allowing manual mode, which pmwconfig expects.

However, in reality for both jobs you mention automatic may do, as it allows you to set cutoff points where the fan spins up at certain rates, until it reaches a max and then stays there.

It is the same as what pmwconfig does in software, but just done in firmware.

I'll put together some notes about what needs to be set for it to work.

[frankcrawford]

@demetera the current driver for the it8689 chipset doesn't seem to do PWM controls properly, and the setting for 0x8628 just happens to trip something that does make some variation to the fan speed but not in any real controlled manner.

The fact it does something indicates that there is some ability there, and I'm trying to figure out what is the trigger, and hence update the driver to do it properly.

BTW, the 0x8628 value is almost exactly the same as it is believed to be an earlier model of the chipset, just with an auto-on/off feature enabled.

[PsychoRS]

I'm pretty sure it should be controllable but for some reason it either goes to automatic or full, not allowing manual mode, which pmwconfig expects.

However, in reality for both jobs you mention automatic may do, as it allows you to set cutoff points where the fan spins up at certain rates, until it reaches a max and then stays there.

It is the same as what pmwconfig does in software, but just done in firmware.

I'll put together some notes about what needs to be set for it to work.

Yes Frank, but what I want to achieve is to set the fan speed according to HDD's temperature, something that auto control from the firmware/BIOS doesn't allow to do (you just can choose CPU Temp or MB Temp). For that reason I'm trying to get manual control with pwmconfig, so I can choose my HDD cage as source for referenced temp to control the fan speed (something that unRAID can do via a plugin, but at first you need to have manual PWM control of the fan).

Thanks for your work.

[Jarikk]

I have encountered the same problem with the Gigabyte Z690M AORUS ELITE motherboard and the IT8689 chipset.

However, I've finally figured out how to make it work. The main idea is to disable the motherboard's control of HDD fans. Unfortunately, I couldn't find an option to completely disable the control of specific fans in the BIOS settings. Instead, I set a very high CPU temperature threshold(like 80-90C), causing the HDD fans to spin up. The key is to prevent the motherboard from initiating the HDD fans so that I can control them from Unraid.

[eatoff8]

The main idea is to disable the motherboard's control of HDD fans.

The method I tried was to enable the fan at the full speed setting. you are saying to disable the fan completely? have it switched off?

Might be something i can try over the next week.

[Jarikk]

The method I tried was to enable the fan at the full speed setting. you are saying to disable the fan completely? have it switched off?

Exactly! I wasn't successful in controlling the HDD fans from Unraid until I made sure that the motherboard never starts these fans.

[frankcrawford]

That is very interesting. Unfortunately without some documentation from ITE it is hard to see how to program this.

I'll see what I can find, but keep up the search.

[eatoff8]

The method I tried was to enable the fan at the full speed setting. you are saying to disable the fan completely? have it switched off?

Exactly! I wasn't successful in controlling the HDD fans from Unraid until I made sure that the motherboard never starts these fans.

So, I just tried this, and yes, it works. I ran through PWMCONFIG multiple times and the fan ramped up and down every time (not just first time). I then set the autofan control based on HDD temps, and it adjusts the fan speed, stops the fan etc as required.

This is how I set up the fan curve and other settings to get it working

Setting it to full speed did not work at all, that was how i was trying it previously.

[frankcrawford]

Guys, thanks for this. I wonder if I can program it to set the curve like that before doing the rest, as there are other registers that seem to be related to how this curve is done.

[demetera]

So, I just tried this, and yes, it works. I ran through PWMCONFIG multiple times and the fan ramped up and down every time (not just first time). I then set the autofan control based on HDD temps, and it adjusts the fan speed, stops the fan etc as required.

This is how I set up the fan curve and other settings to get it working

Setting it to full speed did not work at all, that was how i was trying it previously.

Hooray! After BIOS upgrade to F9 I tried this layout (Gigabyte B560M DS3H V2 with ITE 8689) I've set manual limit on 82 C and it works on CPU fan too and I'm still on 0x8628. Thanks a lot guys!

[frankcrawford]

For everyone following this thread on the failure to set the fan speed, I've come across the reason for the problem, and possible coding to fix it in https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/251

However, as the code is fairly complex, it will be a while before I can get to looking at adding it, so don't expect a quick fix.

[Giger22]

For everyone following this thread on the failure to set the fan speed, I've come across the reason for the problem, and possible coding to fix it in LibreHardwareMonitor/LibreHardwareMonitor#251

However, as the code is fairly complex, it will be a while before I can get to looking at adding it, so don't expect a quick fix.

Same here, Aorus X570 Master. I can set fans that are under it8688-isa-0a40 but I cannot set other fans (even rpm values are wrong) for it8792-isa-0a60.

https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/issues/251#issuecomment-1753939335 https://gitlab.com/coolercontrol/coolercontrol/-/issues/64 https://www.reddit.com/r/gigabyte/comments/s0qi18/fancontrol_not_detecting_controls_for_certain_fans/

[martinclaus1]

Hi guys, I also have problems with pwm control on Gigabyte B760M GAMING X DDR4 with ITE8689. This board has four 4-pin connectors, one for the CPU and the others for sys_fans. If I connect two PWM fans, sys_fan_1 (pwm2) and sys_fan_2 (pwm3), the first one stops spinning after a while when the fans are controlled by fancontrol. It twitches occasionally.

I compared all pwm related hwmon files and found out that the pwn2_freq file content changes after some time from 23437 to 187500. Changing it back to 23437 makes the fan spinning again, but something overrides it after a while again.

So far, I think that only sys_fan_1 (pwm2) is affected. I guess that it's not fan related because after swichting the fans, the same behavior is shown on the other fan.

Are there already any ideas how it could be fixed permanently?

The fancontrol config looks like this:

INTERVAL=10
DEVPATH=hwmon3=devices/platform/it87.2624
DEVNAME=hwmon3=it8689
FCTEMPS=hwmon3/pwm2=hwmon3/temp1_input hwmon3/pwm3=hwmon3/temp1_input
FCFANS=hwmon3/pwm2=hwmon3/fan2_input hwmon3/pwm3=hwmon3/fan3_input
MINTEMP=hwmon3/pwm2=20 hwmon3/pwm3=20
MAXTEMP=hwmon3/pwm2=60 hwmon3/pwm3=60
MINSTART=hwmon3/pwm2=150 hwmon3/pwm3=150
MINSTOP=hwmon3/pwm2=150 hwmon3/pwm3=150
MINPWM=hwmon3/pwm2=150 hwmon3/pwm3=150
MAXPWM=hwmon3/pwm2=255 hwmon3/pwm3=255

[d3vilguard]

+1 GB B550M Aorus Elite rev 1.3, 8689, Arch. Fan RPM is shown but it seems that the mobo forces it to Auto. Using fan2go. Setting the minimal RPM for the fans there does let me ramp up the fans through Linux but otherwise no control. This board will fail to load the module without options it87 ignore_resource_conflict=1 tho during boot it says that a bad line is ignored in /etc/modprobe.d/it87.conf.

Removing the fan curve in bios does seem to make the fans controllable, not a solution really tho. Bios also seems to freak out doing that. Reducing 1 header to zero completely messes up the others.

[axet]

Same for "Gigabyte H610M H DDR4" // IT8689E-BXA. pwmconfig can't control fan speeds, only slow down it a bit as reported before.

I've tested that lax grub option not required, but booth force_id and ignore resource conflict are (without any of it 'sensors' failed to report any hardware info).

/etc/modprobe.d/it87.conf
options it87 force_id=0x8628 ignore_resource_conflict=true

/etc/modules-load.d/it87.conf
it87

Not sure if it is related. But when I set 'PWM' control in Gigabyte BIOS "Smart Fan", fan start to work at full speed, and seems fan control get broken. But when I set it to 'Voltage' it works as expected.

[frankcrawford]

@axet the current code should detect an IT8689E, but I suspect an IT8689-BXA is actually a different chip. Can you run sensors-detect to see what chipIDs are actually detected.

On the other side of the PWM control not working, it is a list of things to follow up, but currently not something I have had a chance to get into.

[axet]

Trying family `ITE'...                                      Yes
Found unknown chip with ID 0x8689

[frankcrawford]

@axet I was thinking about this last night and am wondering which it87 module you have loaded? The one from this repo, or the one from the kernel mainline?

Can you do modinfo it87 and see what it reports? Alternatively do dmesg | grep it87 and see if it reports a version number.

[axet]

That is how I do it:

git clone https://github.com/frankcrawford/it87
cd it87
./dkms-install.sh

filename:       /lib/modules/6.10.3-amd64/updates/dkms/it87.ko.xz
version:        v1.0-157-g043eae2.20240428
license:        GPL

EDIT: updating to the recent release, let use no force option, but ignore_resource_conflict still required.

[frankcrawford]

@axet ah, that is a bit better then. Yes, to not need the ignore_resource_conflict option, I need to update the list of motherboards, because upstream they don't allow it to happen automatically, and I can't think of any simpler test.

For me to add it, please run cat /sys/class/dmi/id/board_vendor and cat /sys/class/dmi/id/board_name and send me the output.

[axet]

"Gigabyte Technology Co., Ltd." // "H610M H DDR4"

[frankcrawford]

Given it is a Micro ATX, I assume it only has a single ITE chip on the motherboard? Is that correct?

[axet]

When I looked at board I only seen one. But I didn't expect two EC on a single board ever.

• https://www.gigabyte.com/Motherboard/H610M-H-DDR4-rev-11-13/sp#sp
• https://static.gigabyte.com/StaticFile/Image/Global/01c7f41064df284fd6872acd75789994/Product/31462

[frankcrawford]

Yeah. The bigger boards with many, many fans, etc, can have 2 chips. But for your board I wouldn't expect so.

If you pull the latest git update, that I've only just pushed, you shouldn't need to set ignore_resource_conflict=true any more either.

[axet]

Thanks. Do you have datasheet for IT8689? I've seen it can be requrested from ITE directly using support email. It should have all registers / memory address information related to fan and voltages.

[frankcrawford]

@axet no I don't have the datasheet, I've tried to request them many times and they ignore me. If you do get it, then it will be very appreciated. If you can setup a long term contact it would be even better.

[frankcrawford]

@axet

I don't know why this hasn't shown up in the github issue yet, but to explain why it is as complex as it is, is covered in the actual commit for it to the mainline kernel, i.e. 

On various Gigabyte boards, incorrectly entering configuration mode causes the second Super-IO chip to generate LPC bus access errors. This was preivously fixed by ensuring that the second chip receives the code to enter configuration mode before the first chip.

On discussion with people who have access to the specification documents it was noted that this is wrong, and you should not enter or leave configuration mode for the second chip, as it is enable during initialisation and should not be changed.

In particular, this was found to be the case on the Gigabyte X670E Aorus Master board, where it was reporting a totally wrong chip ID (0x8883) using the previous method.  This was corrected by not entering configuration mode, and this has been found to still work with older boards.

As such the main process is:

1) Lock the memory, but does not perform a SIO entry (previously it would have performed an SIO entry).

2) Attempt to read the chipID.  This should be safe no matter which chip we have.

3) If step (2) fails, then perform SIO entry and retry chipID read.  For older chips and on failure it acts similarly to prior to this patch.

4) Set the sio_data->type, similar to previously.

5) If we have not performed an SIO entry, and this is not a chip type with the NOCONF feature, then it will perform an SIO entry at this point.

6) Proceed with setup as prior to this patch.

7) Any following access to the SIO registers will invoke the SIO entry and SIO exit steps unless it is a chip with the NOCONF feature set. This was set up in the previous patches in this patchset.

8) Update to the exit based on if it had performed a SIO entry or not.

I didn't add into there, but we check a chip exists before we use the force_id parameter, to avoid doing anything to non-existent memory.

Regards Frank

On Sun, 2024-08-18 at 22:43 -0700, axet wrote:

@frankcrawford [1] I'm working on it. In your code you do check chip- id using the following: port 0x2e, and data 0x20 to get chip it And if it fails you check force_id param is set. Why are you doing it? As I know to get chip id you need to send the sequince: b'\x87\x01\x55\x55' And you will get correct id from port 0x2e and 0x2f using data offset of 0x20 and 0x21. I guess that is the correct way of reading chip_type id. I'm asking this, because I have interesting idea how to recover ITE chip information related to fan control and temperatures. But I need few details. — Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. You are receiving this because you were mentioned.Message ID: @.***>

[1] @frankcrawford https://github.com/frankcrawford [2] view it on GitHub https://github.com/frankcrawford/it87/issues/11#issuecomment-2295712673 [3] unsubscribe https://github.com/notifications/unsubscribe-auth/ABZHBDXHU3KUF3WPMCVSDDTZSGAYFAVCNFSM6AAAAAAZVZHVSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVG4YTENRXGM

[axet]

My comment didn't show up because I wan't to rewrite it and make question more clean.

Since we have no docs (yet, or ever) I suggest we could extract some information from EFI bios binaries.

Turns out EFI is modular which can be parsed and extracted module by module.

Here is a tool https://github.com/LongSoft/UEFITool which can do the job.

Using this tool and Gigabyte firmware for my motherboard (H610 with IT8689 EC) file I able to find some ITE related modules I assume works with the chip to extract system information like voltage, fan, temp. And to my surprise this mother (which having IT8689E chip on board) but having no references in the firmware file for IT8689. But at the same time I found two different ITE chips: IT8688 and IT8728. What is that? Could it be that those chips are 100% compatible with IT8689? I do not know yet.

I've extracted related blobs and turns out those blobs are PE compatible blobs. Basically Microsoft Windows exectuables. A bit of topic information: even worse I found NTFS support in my bios firmware but no EXT4 or LUKS support.

Extracted PE files can be analyzed using IDAPRO which I did and found out a few already known commands like "87 01 55 55" for chip initialization. Not much yet.

My initial question was how to it87 driver controls fans speeds so I could find related IO ports operations in extracted blobs using disassembler. And another solution could be based on fact that motherboard firmware only contains code for IT8728 and it8688 could we reuse what we know from those chips datasheets? Since we have no it8689 docs...

[frankcrawford]

@axet that is very interesting, and something I haven't tried previously. Certainly, in my code, the it8689 is treated essentially the same as an it8688, so they almost certainly have the same configuration. On the other hand the it8728 does look substantially different, at least for the hwmon part.

If you look at the code within it87.c then you will see this definition:

        case it8628:
        case it8686:    
        case it8688:        
        case it8689:        
                data->REG_FAN = IT87_REG_FAN;
                data->REG_FANX = IT87_REG_FANX;
                data->REG_FAN_MIN = IT87_REG_FAN_MIN;
                data->REG_FANX_MIN = IT87_REG_FANX_MIN;
                data->REG_PWM = IT87_REG_PWM;
                data->REG_TEMP_OFFSET = IT87_REG_TEMP_OFFSET_8686;
                data->REG_TEMP_LOW = IT87_REG_TEMP_LOW_8686;
                data->REG_TEMP_HIGH = IT87_REG_TEMP_HIGH_8686;
                break;

where these arrays are given earlier.

However, with datasheets, I have never been able to get any for ITE86XX chipsets, only for ITE87XX, and then only for old ones. Gigabyte and ITE are really hard to get a decent response from.

[frankcrawford]

P.S. I am lead to believe that such datasheets exist, because another developer on Windows systems, where they can actually pay some money and enter NDAs has access to some of them.

Also, if we are going further with this, it would be best to open a new issue, rather than continuing with this particular one.