-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asus-ec-sensors does not expose any fan speeds on Asus Crosshair X670E Hero motherboard #42
Comments
Hi, this driver is not universal in the sense that it can't detect available sensors. They have to be predefined for each board model, which is easy to do when you have an access to the hardware. The readme outlines what to do, and feel free to ask any questions. For this board you need to use the So, you need to add a definition for Crosshair X670 Hero, possibly populate it with all the possible sensors, and then test which ones actually work. To my knowledge, reading non-existent sensors should not damage the hardware, but might lock PWM fans at zero or max mode until power cycled. Adding motherboard definitions includes finding out which ACPI mutex to use for guarding access to the hardware. I can help you with that if you share a dump of the DSDT ACPI table. With this I encourage you to contribute to the project, please. Good luck! |
I can get you the dsdt output. I did that for the asus-wmi-sensors driver dev. |
Thanks, I will find out the mutex name, while you can start with copying definitions for Crosshair X670E Hero. You need to copy over the If in the end we discover that sensor sets for 670E and 670 are identical, we will merge declarations for those boards. |
I'm not following you. What does copying the existing structure in the C file do? |
Sorry. I'm suggesting to start with copying over sensor definition for Crosshair X670E Hero, a very similar board. Just to test you can change board name here: https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors.c#L491. If that works fine, just duplicate lines 491 and 492 and supply your board name in the copy. If you need to change the sensor set, copy the structure those lines referring to (board_info_crosshair_x670e_hero) and make changes in the copy. |
You are confused. I AM using a Crosshair X670E Hero board. That board is covered by your driver. |
Oh, sorry I did not realize the typo in the name. |
This driver does not know how to get the sensor/fan to EC register map out of the UEFI code, so, yes, you have to find it out by trial and error. I'd indeed suggest to take the amd 500 family as an example, and look around the Motherboard and VRM sensors, already discovered for the AMD 600 family. |
Alternatively, you can use the ec_sys kernel module, get a dump of the first bank of the EC registers, and look for numbers, similar to what you are looking for. |
I have a teammate using your sensor driver on his Asus Crosshair VIII Hero board which use the X570 chipset. |
How would I do this part. How to to get a dump from the EC registers? I see the module available. After loading it, how to get a dump? |
Sorry, I again can't follow. What's the intent of copying sensors output? If you want to know which sensors might be present, you have them in the UEFI UI for this board. Those are all non-controllable by user (temperatures, voltages, fans without PWM). ec_sys (https://github.com/torvalds/linux/blob/master/drivers/acpi/ec_sys.c) is just another kernel mode. If you build your kernel yourselves, you can enable it. Otherwise its presence depends on the distribution, I guess. to make a dump, modprobe the module and then issue |
I have the ec_sys module in my kernel. I can load it. I just did not know how to get anything out of it. |
|
I suspect you somehow got a dump of the second EC bank. Do you have the "Water Out" sensor connected and "Water In" not? |
Yes I have a Water Out sensor connected and displaying the correct temp. No Water In sensor connected. |
Those are here: "00000000 d8 26". "d8" is a blank value for temperature sensors, here it is at the "Water In" register (second bank, register 0x0, "26" is Water Out (38 in decimal, that is 38 degrees Celsius). Now, some software (can be this very driver) switched the EC to the second bank. Usually it happens only temporarily and the current bank is reset to 0 (the first bank). Thus, could you, please, try to take another snapshot using the ec_sys? |
I re-ran the command and got a different dump output.
|
Now this looks like the first bank (look, there is 2c at register 0x32, which should be motherboard temperature and 2c is 44⁰C). So, there might be an unconnected temperature sensors at 0x6a (showing the blank value now), a fan at 0x4a (at 1149 RPMs), there might be something at 0x41-0x43 range, and so on. |
LibreHardwareMonitor users discovered a CPU Optional Fan (two bytes) sensor for this generation at 0xb0, but the whole 0xb line in your dump is empty. |
Haha LOL. Well it might all be obvious to you, but to me it is all gobblygook. I don't know how to read the registers and know what they represent. |
I'm only using the CPU_FAN, AIO_PUMP and FAN4 headers on the board currently. Along with the WATER OUT sensor. |
Here are the rules:
|
But all of them are PWM controlled, aren't they? If so, their readings should be in the Super I/O chip, not the EC controller. |
I can convert hex to decimal. But I have to know what the rows and columns in the output represent. This is the mysterious part. No, none of the fans are PWM. 3 pin voltage control only. |
I don't use any PWM components. Only full speed for every component as all my hosts run flat out 24/7 crunching science. Temps have be limited to the environment. |
The row is address divided by 16 with '0' appended, the column is the address mod 16, the gap is between 7 and 8. So, to get the address just combine together those two:
"04" is located in the 0x040 row and column 10, which is 'a' in hex. Thus it is inside the register with address 0x4a.
But in principle those RPMs are controllable, right? That's what I meant by "PWM controlled". If there is a way to control a fan, it is not exposed via EC. |
No, a 3 pin fan is not PWM controllable. Ground,+12V power and sense wire. The only way to control speed is to reduce the voltage supplied to the fan. +12V is full rated speed of the fan. +7V is 7/12 of full rated speed. |
If the header is (in principle) controllable via the UEFI UI, it will not be exposed via EC, no matter which fan is connected. |
In the UEFI, to run full-speed you either have to disable fan control or in this Zen 4 UEFI, the setting is just 'Full-Speed' |
So you are saying that no fans are ever exposed by EC? So how does asus-ec-sensors expose all the fans on my teammates Crosshair VIII Hero motherboard? |
OK, so there is a fan control for this header. Hence I'm pretty sure fan RPM reading is not exposed via EC.
No, only those which are controllable. For example (I have the CH VIII myself), the chipset fan is not controllable and is exposed via EC. |
I'm still very confused. What does the EC expose or does not expose? Only those controllable? |
Uncontrollable. Mainly temperatures. |
I assume your driver bearing ec in its name means it is reading the EC registers. Does it also read the WMI registers to get the readings that are controllable? |
Here is the list of all sensors discovered so far: https://github.com/zeule/asus-ec-sensors/blob/master/asus-ec-sensors.c#L99 |
OK, that matches the sensors output of my friend's board he has published for me. |
That's correct.
There is no such a thing as "WMI register", at least not in ASUS boards. At some point ASUS exposed the whole hardware monitoring system via the WMI, but is not the case anymore. There are WMI calls to read from the Super I/O chip register and EC registers, but they are extremely slow. The previous version of this driver used that method and the speed was around 10 bytes per second (reading the full set on already mentioned C8H took 3 seconds). I don't do that anymore.
That's not entirely correct: not all board models have the whole sensor set. |
So why hasn't anybody just copied lines 204-237 into the static const struct at line 240 and just see what pops up? |
I still use the asus-wmi-sensors driver for all my Crosshair VII Hero boards. Works great, never any issue. |
How should I know?
Yes, that's the generation with the whole hardware monitoring system exposed via WMI, and all the values read in a single WMI call. |
So that leaves it to me to be the guinea pig and try this I guess. The only ones I really would want are the fan speeds for CPU_FAN, AIO_PUMP and FAN4. |
All three are user-controllable, likely not exposed via EC. Is there a driver for the Super I/O chip for this board? |
Yes, the stock nct6775 driver in > 6.3 kernels pick up the SIO.
Much of which is gobbly-gook without a scaling conf file. I fudged something that sort of works for the Vcore. Not even the correct formula., but close. The two fans exposed are the correct rpms but not identified correctly. Other fan headers are missing entirely. Fan2 should be Fan6 logically based on location. Board identifier Fan2 is unpopulated. Fan4 and Fan5 missing. The stock k10temp picks up the cpu temps from sysfs.
This is what asus-ec-sensors shows:
|
It is interesting the CPU in EC corresponds to the second CCD temperature, which is the lowest one. What is fan7 in the nct6775 output? |
Fan7 is CPU_Fan. Fan2 is AIO_PUMP Both are located at the top of the board next to each other. CPU_OPT is also located next to them and is unoccupied. Fan_1, Fan_2 and Fan_3 are next to each other on the bottom of the board. Fan_4 is on the front, middle of the board. AIO_PUMP, CPU_FAN and CPU_OPT at the top of the board. Logically, counting counter-clockwise from the bottom left of the board, the headers should be identifed: Fan_1, Fan_2, Fan_3, Fan_4, Fan_5, Fan_6 and Fan_7 or in the board naming vernacular, Fan_1, Fan_2, Fan_3, Fan_4, AIO_PUMP, CPU_FAN and CPU_OPT FAN_2 should be identified as FAN5 and FAN_7 should be identifed as Fan6 logically. Fan4 has my D5 pump on it and is missing entirely. |
Hi, I also have the same motherboard Let me know if there is something i can provide |
Hi, @UnAfraid, and thank you for the willing to help! Well, we are missing many reading that HWInfo is aware of. If you want to spend an hour or two locating registers with those, I and other users, I guess, will appreciate that. There a a few tools you can use. If you familiar with C#, you can grab a copy of Libre Hardware Monitor sources, where I duplicated this driver, and start tinkering. Or any of the tools that print out EC registers and a hex calculator will help to locate sensors. LibreHardwareMonitor itself can dump EC registers (included in the hardware report). My suggestion is to begin with locating registers those values are changing with time, and then try them out in LHM, monitoring reading and comparing them to ASUS software or HWInfo. |
Hi @zeule, Yes i am familiar with C#, i'll have a look. Thanks for the info. |
There is a second bank of registers, maybe some sensors are there, like water temperatures? |
How much data is contained inside one bank of registers 256? |
I doubt the second dump shows a second EC bank, because there should be two water temperature sensors at the beginning, and blank value for temperature sensors in ASUS EC is -40 (216 unsigned, 0xd8), and I don't see those values in the dump. It you have another monitoring software running, it very well can switch banks and registers while LHM creates the dump. In that case the dumps are corrupted. And, of course, assuming that you modified
It depends on the sensor data size: many of them are one-byte values (temperature, current), others span two bytes (fan RPMs, voltages, as far as I remember). |
I ensured no other software was using the EC while i was reading it and made some changes to GetReport to make sure i capture both of the banks.
|
Looks good. |
Forgot this was still open. |
Installed the latest release and have VRM temps and Water Out temps now. That is very welcome.
I was hoping that the driver would expose the fan header speeds on the board. Sadly it does not. None found.
Out of the seven headers on the board, the nct6775 driver only finds the output of two headers, fan2 and fan7 are the only ones found as identified by sensors on the nct6775 driver output.
But fan2 is mislabeled by the driver as the physical Fan2 header is unoccupied. It should be labeled as physical header Fan6.
The fan header Fan4 on the motherboard where I have my pump plugged into is missing for example.
The Bios sensors page finds all the fan header outputs as reference.
The text was updated successfully, but these errors were encountered: