AM4 Mobos used for Ryzen

[The Main Man]

For IT87 you can find out-of-tree driver here

I patched the kernel driver just to add my sensor (IT8613E) but I ripped the code from there.
I was getting resource conflict though so I had to patch DSDT as well

[depontius]

Thanks, I've got that page bookmarked. I may have to be back here asking about the DSDT stuff at some point. I've had the stuff sitting in my cart for a while, and an hour or two ago Newegg told me that some price-breaks are about to expire, so I think an order may be in order tonight. But first I found an SSD tutorial, and need to read that and then select the right one.

[The Main Man]

Sure, if needed I can walk you through it, you might not need to do that, only this could work :

Code: Select all

# modprobe it87 ignore_resource_conflict=1

I mean, it will work for sure, in my case the problem was that the system would shutdown after some random number of hours, usually 12 maybe less maybe more.
BIOS would access that area responsible for thermal monitoring, which IT87 uses as well and then it wouldn't get the correct readings, it would think that the CPU temperature is above 127C and it would shutdown.
I've disabled that in BIOS but it would still do it, so I had to fix that in DSDT

[saellaven]

I'm looking to build a new system soon, a Zen-3 arch, at the moment I'm thinking Ryzen-7 3700X.

Finding the right motherboard is the problem. I've usually bought ASUS, long ago Tyan, and my most recent mobo is Asrock. But more recently I've seen that IT-87 is no longer in the regular kernel, and someone had suggested a different brand in order to avoid IT87. I just checked my cart on Newegg and see that I have an Asrock board there, so I must have given up on that advice.

Anyway on this thread I saw something about an out-of-tree IT87 driver, but don't find anything like that in the portage tree. That and searching also jogged a memory about an "asus_atk0110" driver, so I'm not sure how that fits in.

Can anyone comment about getting lm-sensors working with Ryzen boards, and if this should be driving my decision away from Asrock?

I'm using an Asus Prime X570 Pro with my 3700X. It uses the nct6775 driver and everything just works (currently running vanilla linux 5.8.5 and lm-sensors 3.6.0, BIOS 2606 installed)

Code: Select all

sensors
nct6798-isa-0290
Adapter: ISA adapter
in0:                      920.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      744.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.25 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      896.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     368.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     544.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     976.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      757 RPM  (min =    0 RPM)
fan2:                     1119 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +40.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
CPUTIN:                    +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN0:                   +26.0°C    sensor = thermistor
AUXTIN1:                   +40.0°C    sensor = thermistor
AUXTIN2:                   +21.0°C    sensor = thermistor
AUXTIN3:                   +26.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +43.5°C
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C
PCH_CHIP_TEMP:              +0.0°C
PCH_CPU_TEMP:               +0.0°C
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

k10temp-pci-00c3
Adapter: PCI adapter
Vcore:       931.00 mV
Vsoc:          1.09 V
Tctl:         +50.8°C
Tdie:         +50.8°C
Tccd1:        +40.0°C
Icore:         5.00 A
Isoc:          5.75 A

[depontius]

I'm looking to build a new system soon, a Zen-3 arch, at the moment I'm thinking Ryzen-7 3700X.

Finding the right motherboard is the problem. I've usually bought ASUS, long ago Tyan, and my most recent mobo is Asrock. But more recently I've seen that IT-87 is no longer in the regular kernel, and someone had suggested a different brand in order to avoid IT87. I just checked my cart on Newegg and see that I have an Asrock board there, so I must have given up on that advice.

Anyway on this thread I saw something about an out-of-tree IT87 driver, but don't find anything like that in the portage tree. That and searching also jogged a memory about an "asus_atk0110" driver, so I'm not sure how that fits in.

Can anyone comment about getting lm-sensors working with Ryzen boards, and if this should be driving my decision away from Asrock?

I'm using an Asus Prime X570 Pro with my 3700X. It uses the nct6775 driver and everything just works (currently running vanilla linux 5.8.5 and lm-sensors 3.6.0, BIOS 2606 installed)

Code: Select all

sensors
nct6798-isa-0290
Adapter: ISA adapter
in0:                      920.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.28 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                        1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      744.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.25 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      896.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     368.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     544.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     976.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                      757 RPM  (min =    0 RPM)
fan2:                     1119 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                        0 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +40.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
CPUTIN:                    +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN0:                   +26.0°C    sensor = thermistor
AUXTIN1:                   +40.0°C    sensor = thermistor
AUXTIN2:                   +21.0°C    sensor = thermistor
AUXTIN3:                   +26.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +43.5°C
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C
PCH_CHIP_TEMP:              +0.0°C
PCH_CPU_TEMP:               +0.0°C
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

k10temp-pci-00c3
Adapter: PCI adapter
Vcore:       931.00 mV
Vsoc:          1.09 V
Tctl:         +50.8°C
Tdie:         +50.8°C
Tccd1:        +40.0°C
Icore:         5.00 A
Isoc:          5.75 A

That's worth knowing. Right now I have an Asrock B550M Steel Legend sitting in my cart, but I'm not terribly vested in it. I've puzzled a bit about which of the AMD 5xx chipsets to get - X570 vs B550. The former was earlier and seems to have more raw performance, but the latter is newer and has some nice features. Plus the performance of the former may be in areas not terribly important to me.

[Anon-E-moose]

Don't know anything about the b550's, but I would make sure there's a clear upgrade path with the ryzen if you go that way.

Like saellaven, I bought the prime x570 pro, w/3770x and I've been happy with it.

Edit to add: I just looked at the asrock board, micro-atx, not a lot of pci slots, whereas the asus prime is a regular atx size, so there's a size constraint, if you need it.

[nick_gentoo]

For IT87 you can find out-of-tree driver here

I patched the kernel driver just to add my sensor (IT8613E) but I ripped the code from there.
I was getting resource conflict though so I had to patch DSDT as well

I am also interested in this, hoping that I'll be able to use the onboard IT8686E.
Is it possible to simply replace the it87.c file of a newer kernel, or should the two files be merged somehow (as the linked file is 2 years old)?

[The Main Man]

For IT87 you can find out-of-tree driver here

I patched the kernel driver just to add my sensor (IT8613E) but I ripped the code from there.
I was getting resource conflict though so I had to patch DSDT as well

I am also interested in this, hoping that I'll be able to use the onboard IT8686E.
Is it possible to simply replace the it87.c file of a newer kernel, or should the two files be merged somehow (as the linked file is 2 years old)?

That's not possible, you can't just replace that file, even though the same guy wrote those drivers they are different .
If out-of-tree driver is working fine for you there shouldn't be a problem to make a patch.
The patch I made for me is just for my sensor, I didn't add them all because I have no need for them.
I might take a look later to see if I can add your sensor.

Meanwhile here's the patch I use

Code: Select all

--- a/drivers/hwmon/it87.c	2020-08-26 14:43:49.315721428 +0200
+++ b/drivers/hwmon/it87.c	2020-08-27 17:16:49.184790191 +0200
@@ -63,7 +63,7 @@
 
 enum chips { it87, it8712, it8716, it8718, it8720, it8721, it8728, it8732,
 	     it8771, it8772, it8781, it8782, it8783, it8786, it8790,
-	     it8792, it8603, it8620, it8622, it8628 };
+	     it8792, it8603, it8613, it8620, it8622, it8628 };
 
 static unsigned short force_id;
 module_param(force_id, ushort, 0);
@@ -153,6 +153,7 @@
 #define IT8786E_DEVID 0x8786
 #define IT8790E_DEVID 0x8790
 #define IT8603E_DEVID 0x8603
+#define IT8613E_DEVID 0x8613
 #define IT8620E_DEVID 0x8620
 #define IT8622E_DEVID 0x8622
 #define IT8623E_DEVID 0x8623
@@ -433,6 +434,15 @@
 		  | FEAT_AVCC3 | FEAT_PWM_FREQ2,
 		.peci_mask = 0x07,
 	},
+	[it8613] = {
+		.name = "it8613",
+		.suffix = "E",
+		.features = FEAT_NEWER_AUTOPWM | FEAT_12MV_ADC | FEAT_16BIT_FANS
+		  | FEAT_TEMP_PECI | FEAT_FIVE_FANS
+		  | FEAT_FIVE_PWM | FEAT_IN7_INTERNAL | FEAT_PWM_FREQ2
+		  | FEAT_AVCC3,
+		.peci_mask = 0x07,
+	},
 	[it8620] = {
 		.name = "it8620",
 		.suffix = "E",
@@ -573,6 +583,8 @@
 		lsb = 109;
 	else
 		lsb = 160;
+	if (data->type == it8613)
+		lsb = 110;
 	if (data->in_scaled & BIT(nr))
 		lsb <<= 1;
 	return lsb;
@@ -2449,6 +2461,9 @@
 	case IT8790E_DEVID:
 		sio_data->type = it8790;
 		break;
+	case IT8613E_DEVID:
+		sio_data->type = it8613;
+		break;	
 	case IT8603E_DEVID:
 	case IT8623E_DEVID:
 		sio_data->type = it8603;
@@ -2610,6 +2625,43 @@
 
 		sio_data->beep_pin = superio_inb(sioaddr,
 						 IT87_SIO_BEEP_PIN_REG) & 0x3f;
+	} else if (sio_data->type == it8613) {
+		int reg27, reg29, reg2a;
+
+		superio_select(sioaddr, GPIO);
+
+		/* Check for pwm3, fan3, pwm5, fan5 */
+		reg27 = superio_inb(sioaddr, IT87_SIO_GPIO3_REG);
+		if (reg27 & BIT(1))
+			sio_data->skip_fan |= BIT(4);
+		if (reg27 & BIT(3))
+			sio_data->skip_pwm |= BIT(4);
+		if (reg27 & BIT(6))
+			sio_data->skip_pwm |= BIT(2);
+		if (reg27 & BIT(7))
+			sio_data->skip_fan |= BIT(2);
+
+		/* Check for pwm2, fan2 */
+		reg29 = superio_inb(sioaddr, IT87_SIO_GPIO5_REG);
+		if (reg29 & BIT(1))
+			sio_data->skip_pwm |= BIT(1);
+		if (reg29 & BIT(2))
+			sio_data->skip_fan |= BIT(1);
+
+		/* Check for pwm4, fan4 */
+		reg2a = superio_inb(sioaddr, IT87_SIO_PINX1_REG);
+		if (!(reg2a & BIT(0)) || (reg29 & BIT(7))) {
+			sio_data->skip_fan |= BIT(3);
+			sio_data->skip_pwm |= BIT(3);
+		}
+
+		sio_data->skip_pwm |= BIT(0); /* No pwm1 */
+		sio_data->skip_fan |= BIT(0); /* No fan1 */
+		sio_data->skip_in |= BIT(3);  /* No VIN3 */
+		sio_data->skip_in |= BIT(6);  /* No VIN6 */
+
+		sio_data->beep_pin = superio_inb(sioaddr,
+						 IT87_SIO_BEEP_PIN_REG) & 0x3f;					 
 	} else if (sio_data->type == it8620 || sio_data->type == it8628) {
 		int reg;
 

[nick_gentoo]

Thanks!
I'll give it a try this weekend, and also have a better look at the diff between the in-tree and out-of-tree files.

[nick_gentoo]

For IT87 you can find out-of-tree driver here

I patched the kernel driver just to add my sensor (IT8613E) but I ripped the code from there.
I was getting resource conflict though so I had to patch DSDT as well

I am also interested in this, hoping that I'll be able to use the onboard IT8686E.
Is it possible to simply replace the it87.c file of a newer kernel, or should the two files be merged somehow (as the linked file is 2 years old)?

That's not possible, you can't just replace that file, even though the same guy wrote those drivers they are different .
If out-of-tree driver is working fine for you there shouldn't be a problem to make a patch.
The patch I made for me is just for my sensor, I didn't add them all because I have no need for them.
I might take a look later to see if I can add your sensor.

Maybe I'm lucky, but it seems to be working directly with the out-of-tree driver (after many kernel rebuilds). Thank you for the hints!
The key for me was to compile it87 as a module (I had it built-in) and load it as you showed:

Code: Select all

# modprobe it87 ignore_resource_conflict=1

Combined with the lm-sensors config file taken from https://github.com/lm-sensors/lm-sensor ... AMING.conf (my board is a Gigabyte B450 AORUS PRO), the measured voltages now start to make sense.
I'll wait and see how it behaves.

[The Main Man]

Maybe I'm lucky, but it seems to be working directly with the out-of-tree driver (after many kernel rebuilds). Thank you for the hints!
The key for me was to compile it87 as a module (I had it built-in) and load it as you showed:

Code: Select all

# modprobe it87 ignore_resource_conflict=1

Combined with the lm-sensors config file taken from https://github.com/lm-sensors/lm-sensor ... AMING.conf (my board is a Gigabyte B450 AORUS PRO), the measured voltages now start to make sense.
I'll wait and see how it behaves.

If you are compiling and using out-of-tree driver you don't need to rebuild kernel, just disable in kernel it87, of course with every kernel update you would have to make that driver manually each time.
You can auto load that module by making "/etc/modules-load.d/it87.conf" with "it87" inside that file, also you will need to make this file "/etc/modprobe.d/it87.conf" and place this inside "options it87 ignore_resource_conflict=1"

btw I was looking at your sensor and tried to make a patch so that you would avoid using out-of-tree driver and have it always built in the kernel, but it's little more complicated than mine was, it's not a problem to patch it but I'm not sure would it work or not, it has more stuff.

[nick_gentoo]

If you are compiling and using out-of-tree driver you don't need to rebuild kernel, just disable in kernel it87, of course with every kernel update you would have to make that driver manually each time.
You can auto load that module by making "/etc/modules-load.d/it87.conf" with "it87" inside that file, also you will need to make this file "/etc/modprobe.d/it87.conf" and place this inside "options it87 ignore_resource_conflict=1"

That's cool, and I remember reading about this some time ago, I'll check how to do it.

btw I was looking at your sensor and tried to make a patch so that you would avoid using out-of-tree driver and have it always built in the kernel, but it's little more complicated than mine was, it's not a problem to patch it but I'm not sure would it work or not, it has more stuff.

I also saw this, that's why I gave up on it and switched completely to the out-of-tree driver. Luckily it works for me. And it's a pity that some datasheet/documentation does not exist, from searching around it seems to be a pretty common device.

[nikolis]

Gigabyte b550 visionD, 5950x, 2x1tb 970evo plus, 2x16gb ram.
Upgrade my old fx8350.

[yellowzip]

Moved from Asus to Gigabyte (X570-AORUS-ELITE), intel to AMD and Nvidia to Radeon on my long overdue rebuild at the end of 2020 - loving it!

[xineg]

Ryzen 5 3600X
Gigabyte x570 Gaming X
Kingston HyperX Fury 3200Mhz RAM (16GB)
I use CFLAGS="-O2 -march=znver2" for everything and to get -march=znver2 I used gentoo-sources and chose the AMD ZEN 2 in make menu config . Nothing I'm saying here is any different than the wiki. I am very pleased with the MB, it is the cheapest x570 board but is of very sturdy build, it's like 6mm plate steel and is very heavy, I'm sure this thing could take extreme temps. Gigabyte bios are nothing flash but you can overclock easily once you realize how it works. It did automatically put my 3200 ram at < 2600 but this was easy to fix. Actually it put pretty conservative values for everything. Interesting part was that it set my 3.8 GHz cpu with 4.6 boost with a voltage of 1.006 and the cpu temp was running idle at 32 to 40 degrees Celsius, and when I turned boost off and set the cpu at a set 4.0 GHz it put the voltage to 1.104 (Vcore) and now the cpu idles at 27 to 30 Celsius. These cpus seem to like low voltages for some reason and they run like a demon

[Antikapitalista]

Micro-Star International MSI X470 Gaming Plus Max

The best one for me in terms of (features+performance)/price ratio. A cheap one, yet no junk.

[NeddySeagoon]

I've just got an "ASUS System Product Name/ROG CROSSHAIR VIII DARK HERO."

It's got features I know I won't use like Wifi6 and Bluetooth but I wanted a fanless motherboard and there isn't a lot of choice.
Not because they don't exist, they are mostly all "Arriving Soon".

I am having a few teething troubles. Some of the sensors don't work as the kernel module and ACPI fight over the device.

If I build amdgpu into the kernel, I get a panic because it tries to kill init.
When its a module, its just an Oops but it works.

The Wifi and Bluetooth are disabled is the BIOS,

It boots with syslinux, not grub2 but an efi stub kernel works too. I won't be trying grub2,

[Anon-E-moose]

I am having a few teething troubles. Some of the sensors don't work as the kernel module and ACPI fight over the device.

I had to add this to the kernel command line to make acpi and sensors work properly on my asus board, acpi_enforce_resources=no

Code: Select all

    acpi_enforce_resources= [ACPI]
            { strict | lax | no }
            Check for resource conflicts between native drivers
            and ACPI OperationRegions (SystemIO and SystemMemory
            only). IO ports and memory declared in ACPI might be
            used by the ACPI subsystem in arbitrary AML code and
            can interfere with legacy drivers.
            strict (default): access to resources claimed by ACPI
            is denied; legacy drivers trying to access reserved
            resources will fail to bind to device using them.
            lax: access to resources claimed by ACPI is allowed;
            legacy drivers trying to access reserved resources
            will bind successfully but a warning message is logged.
            no: ACPI OperationRegions are not marked as reserved,
            no further checks are performed.

[Tony0945]

It boots with syslinux, not grub2 but an efi stub kernel works too. I won't be trying grub2,

Give refind a try. Works fine on my Asus Prime X-570 Pro

Apologies for not posting a hardware review before you chose your system. I've been sick. kidney stones. You wouldn't believe the pain.

[nikolis]

@Tony0945
I hope you'll get better soon. (You did not drink water?)

[Tony0945]

@Tony0945
I hope you'll get better soon. (You did not drink water?)

Thank you. I hate water. Never have voluntarily drank it (srunk it?). Coffee, milk, juice. Yes

[NeddySeagoon]

Tony0945,

You need water from the Mendip Hills. Its so hard you have a slice :)
That's one thing I miss about where i grew up. It has a lovely taste too.
Kettles don't last very long.

Compare that to London tap water. On average, its been filtered through seven sets of human kidneys on its way to the tap. :)

[NeddySeagoon]

Anon-E-moose,

I used

Code: Select all

acpi_enforce_resources=lax

Now I have lots of numbers to look at and the warning.
Thank you.

[pjp]

@Tony0945
I hope you'll get better soon. (You did not drink water?)

Thank you. I hate water. Never have voluntarily drank it (srunk it?). Coffee, milk, juice. Yes

A long time ago a co-worker told me his doctor recommended drinking water to help avoid getting kidney stones again. I didn't adopt the practice for a very long time, but I eventually did because I've heard too many stories about the pain (only a handful, which is more than enough).

Anyway, I suggest trying cold water in smallish quantities. I tried "large" bottles you see people carrying around, but that never worked for me. I'd get through some of it, but the water would warm up too much before I'd get through it. I can tolerate a little bit warmer water now, but I still start with it refrigerated. I recommend a 12oz bottle, or no more water than that if using a larger bottle. I start the day with water, then alternate during the day when I want something else. Then its a matter of making the choice that you'd rather "take the medicine" than experience the pain.

[Goverp]

I've just got an "ASUS System Product Name/ROG CROSSHAIR VIII DARK HERO."
...

I've an older ASUS "Gaming" MB. FWIW, I keep an eye on the ASUS BIOS downloads, and pick up updates after they've been around for a month or so, though I may stop now the MB is a couple of years old.. There seems to be quite a lot of activity in their BIOSen, presumably of some relevance to newer boards. AFAIR there have been ACPI updates recently.

Also, check your memory speed. I found my 3200 Crucial stuff was being handled as 2400 or something similar; Crucial say it's 'cos a lot of BIOSes mishandle the config data. It's an easy tweak to use the relevant bit of overclocking support to put it back to the right value. I didn't do any benchmarks, so of course the result may be negligible,
(I don't do other overclocking above the default setting in ASUS's BIOS. I know AMD "support" overclocking these days, but I assume there's a reason for the default speeds.)