search

zeule / asus-ec-sensors

Linux HWMON sensors driver for ASUS motherboards to get sensor readings from the embedded controller
GNU General Public License v2.0
46 stars 21 forks source link

Possibly (or not) adding "ROG STRIX B550-F GAMING (WI-FI)"? #19

Closed VorpalBlade closed 2 years ago

VorpalBlade commented 2 years ago

I have a "ROG STRIX B550-F GAMING (WI-FI)" which works with the previously introduced WMI driver. However since this driver is supposed to be better and doesn't yet have support for that motherboard I thought I'd take a look at it.

I have however ran into an issue: The "BREC" method is a dummy as described in the README. Is that the end of the road for this attempt? I don't find the README entirely clear on this.

zeule commented 2 years ago

Hi,

sorry, I can't really understand the problem, because the asus-wmi-ec-sensors driver works via the mentioned BREC() function. If asus-wmi-ec-sensors works for you and shows any reading, I can't understand how BREC() can be a stub.

VorpalBlade commented 2 years ago

Maybe I misunderstood the news coverage on phoronix about this, but I do get proper sensor readings using the driver that was merged in 5.16 (https://bugzilla.kernel.org/show_bug.cgi?id=204807). I understood that this is what the ASUS WMI driver referred to? If not, I'm sorry about the confusion this caused.

The BREC function as decompiled by iasl from acpica 20211217-1 (Arch Linux package version) exactly matched the stub example in the README.

While I do have programming experience (including C/C++, though it has been a few years since I done any low level programming professionally), firmware stuff is a bit out of my field. What sort of information would be helpful in investigating this further?

zeule commented 2 years ago

Perhaps you use the WMI workaround for the nct6775 driver? That's completely different driver, which reads sensors from the Super I/O chip.

However, there is a T_Sensor on the list of the internal connectors for your board. As far as I know this sensor is always reported via EC registers (so this driver might be useful). Maybe my assumption that the BREC method should always be present is false. You can test if this driver provides any results copying one of the board entries and replacing board name with content of /sys/class/dmi/id/board_name. I would take the entry for "ROG STRIX X570-F GAMING" as the source.

I would be thankful for such an experiment. Please load the module manually via sudo insmod <file_name.ko> and do not install it for automatic loading. In the worst case you would need to power cycle your PC to reset EC state.

zeule commented 2 years ago

However, there is a T_Sensor on the list of the internal connectors for your board. As far as I know this sensor is always reported via EC registers

CPU OPT too, if you have that fan connected please add SENSOR_FAN_CPU_OPT.

VorpalBlade commented 2 years ago

Perhaps you use the WMI workaround for the nct6775 driver? That's completely different driver, which reads sensors from the Super I/O chip.

Aha, possibly. The motherboard sensors show up as nct6798-isa-0290, so similar but not quite the same sensor model number/name.

However, there is a T_Sensor on the list of the internal connectors for your board.

There is a connector for it. It is an optional extra which I don't have. In sensors there is one (temp5) which is always -62 C. I assume that might be the unconnected T_Sensor?

I would be thankful for such an experiment.

I should be able to get around to that during next week.

CPU OPT too, if you have that fan connected please add SENSOR_FAN_CPU_OPT.

I don't have that plugged in. I use 3 chassi fans and two CPU fans with a Y-split cable to a single CPU fan connector. If I remember correctly it is hard to reach the connector for one of the fans under the massive CPU tower cooler, but if I can do it I could try to test that.

zeule commented 2 years ago

nct6798

Yes, that the nct6775 driver, it handles other similar chips too.

There is a connector for it. It is an optional extra which I don't have. In sensors there is one (temp5) which is always -62 C. I assume that might be the unconnected T_Sensor?

Yes, that's very much possible.

VorpalBlade commented 2 years ago

I had some time to look into this today. It appears that HwInfo on Windows does not use the embedded controller either: hw_info

It does however appear to have a better idea than on Linux when it comes to scaling factors for the inputs etc.

Given this, it doesn't seem worth pursuing trying to patch the code to me, unless you still think that is worth a shot?

zeule commented 2 years ago

Thank you for the update! In the screenshot I don't find the following entries, present in the "Tech Specs" part of the board description at the ASUS web-site: CPU_Opt and AIO_PUMP PWM values and T_Sensor reading. Also there is no CPU current reading. They have to be somewhere and I know only two possible places: the Super I/O chip (Nuvoton 6798D in our case, and seems like it does not provide these entries) and the EC. If I were you and had anything connected to at least one of these headers, I would try to read EC registers using the ec_sys kernel module:

# modprobe ec_sys
# hexdump -C /sys/kernel/debug/ec/ec0/io

If there is anything it the output, we can continue via tuning this driver.

VorpalBlade commented 2 years ago

Well, that doesn't seem to go anywhere:

$ modprobe ec_sys
$ hexdump -C /sys/kernel/debug/ec/ec0/io
hexdump: /sys/kernel/debug/ec/ec0/io: No such file or directory
hexdump: all input file arguments failed
$ ls /sys/kernel/debug/ec
ls: cannot access '/sys/kernel/debug/ec': No such file or directory

This is on the stock unmodified Arch kernel. I have not tried modifying the asus-ec-sensors kernel driver to be loadable on this system:

$ make
[...]
$ sudo insmod ./asus-ec-sensors.ko
insmod: ERROR: could not insert module ./asus-ec-sensors.ko: No such device

As for CPU_Opt, I have not looked under Windows after I changed my cables, but under Linux it is fan7 according to lm_sensors on the nct6798 chip. Maybe HwInfo has some way to detect that it was selected as "not in use" in the UEFI settings before? Similar perhaps for the T_Sensor. I have not run any experiment with AIO_PUMP.

zeule commented 2 years ago

Thank you for the experiment!

I don't quite understand how this can be possible... The embedded controller should be present according to the ACPI specification. Does lsmod | grep ec_sys confirms the module is loaded? Unmodified asus-ec-sensors module must fail to load in the way you observe.

VorpalBlade commented 2 years ago 
$ lsmod | grep ec_sys
ec_sys                 16384  0

I checked on another computer (a Thinkpad) also running Arch Linux and on there loading ec_sys creates /sys/kernel/debug/ec with the files you mentioned.

zeule commented 2 years ago

Thank you for the experiment! Apparently, there is no ACPI EC installed in this motherboard model. Which is still a bit weird to me, because the EC also works as the keyboard controller and I have never seen a PC without it before.

VorpalBlade commented 2 years ago

@zeule Thanks for the help in diagnosing this. From what I read for the datasheet of the nct6798, it is a SuperIO chip and is capable of handling keyboard, UART and parallel port as well. And infrared apparently... So that might explain it.

Ristovski commented 2 years ago

On my ASUS PRIME B450M-A II there too isn't any /sys/kernel/debug/ec entry.

dmesg indeed shows no related ACPI EC messages, as if the EC device didn't exist at all.

Could it be that the EC somehow isn't exported via ACPI on some Asus mobos?

zeule commented 2 years ago

On my ASUS PRIME B450M-A II there too isn't any /sys/kernel/debug/ec entry. Could it be that the EC somehow isn't exported via ACPI on some Asus mobos?

Do you have any evidence that EC is present in this MB?

Ristovski commented 2 years ago

Do you have any evidence that EC is present in this MB?

I believe I do. That board (and many other Asus boards) use a Super I/O chip from ITE Tech inc., in my case it's the ITE IT8655E, which also appears to act as the EC. On other Asus boards, Nuvoton chips appear to be used instead. There is also a "EC Version" entry in my BIOS, further confirming the presence of some sort of EC.

The IT8655E is supported by a fork of the upstream it87 kernel driver, which allows it to report voltages and temperatures, by talking to it directly with inb/outb port instructions. However, this driver has been unmaintained for a long time, and still has several issues, mainly bad stability and reporting the wrong min/max values.

I was able to find a schematic of the ASUS PRIME B450M-A (note: not the II variant, which I have, but quite similar), which uses the same ITE chip, and it indeed seems pretty EC-y:

ACPI does not seem to define it as a EC chip, which in turn causes it not to get detected as one by the ACPI kernel driver, thus it does not get exposed in sysfs.

However, ACPI does seem to access the chip, consider the following from the it87 driver:

image

now compare it to this entry in my decompiled DSDT ACPI table:

image

The device itself in ACPI is \_SB.PCI0.SBRG.SIO1 which appears to be the same as what is used for board_info_zenith_ii_extreme https://github.com/zeule/asus-ec-sensors/blob/394695ea8260bda2797d19141c0372eda0c0e110/asus-ec-sensors.c#L59

I am fairly confident that this is also the case for the other Asus motherboards that are deemed unsupported for "not having an EC".

Perhaps it would be best if we opened a meta issue for such motherboards.

Here are my decompiled ACPI tables. Of note are the RSIO and WSIO methods, which access the same ASMX mutex mentioned in the readme. Note that RDEC/BREC and WREC/BWEC are unimplemented. All of the aforementioned methods are also exposed via WMI in the WMBD method.

BREC and BWEC seems to have been replaced by BRIO and BWIO.

ACPI_Asus_PRIME_B450MAII.zip