Bug #601
opensuperio/nuvoton/npcd378:379 FAN issue sandy/ivy-bridge & haswell on HP
0%
Description
The NPCD378 HWM FAN control is limited to the PSU FAN only but should work for the "compaq_8200_elite_sff" according to its commit and instruction, which states "... the SuperIO has to be notified that a write is ongoing. After clearing the write-lock bit all changes are applied...".
Is there a special command that I missed that "clears the write-lock" or is there a bug and is its current implementation broken?
Since adjusting the nvram parameter sudo nvramtool -w psu_fan_lvl=1-7and doing a reboot or cold powerup does show that the nvram parameter changes (can be confirmed by coreboot log or reading the nvram parameter after boot again) it never changes the actual PSU FAN speed! Tried multiple coreboot/seabios/edk2 versions the last 3 months on 5 different HP machines and came to the following conclusion.
The following nvramtool psu_fan_lvl=values reflect the following PWM feedback from the coreboot log:
=1
[INFO ] NPCD378: PSU fan PWM 0x37
=2
[INFO ] NPCD378: PSU fan PWM 0x57
=3
[INFO ] NPCD378: PSU fan PWM 0x77
=4
[INFO ] NPCD378: PSU fan PWM 0x97
=5
[INFO ] NPCD378: PSU fan PWM 0xb7
=6
[INFO ] NPCD378: PSU fan PWM 0xd7
=7
[INFO ] NPCD378: PSU fan PWM 0xf8
The following 3 supported sandy/ivy bridge HP variants share the same issue that nvram parameters and coreboot log show the requested manual psu_fan_lvl values but its PSU FAN speed won't change according to these values, atleast its FANs keep spinning after post/boot on these machines:
VALUE FAN SPEED
compaq_8200_elite_sff NPCD378 adjusts remains same
compaq_8300_elite_sff NPCD379 adjusts remains same
compaq_pro_6300_sff NPCD379 adjusts remains same
The following 2 yet uncommited HP Haswell coreboot variants, "HP 260 G1 DM (Desktop Mini) Business PC" and "HP Prodesk 600 G1 SFF" both come with a NPCD379 and both share the same issue with the former 3 variants that the psu_fan_lvl value's can be adjusted by nvramtool(if cmos backend is added to the code) and verified during boot or nvramtool that these values have changed with affecting the PSU FAN speed in a undesired way:
VALUE FAN SPEED
260_g1_dm NPCD379 adjusts stops spinning
prodesk_600_g1_sff NPCD379 adjusts stops spinning
These 2 Haswell machines will halt "and stop spinning" the PSU FAN as soon as during post the "PSU fan PWM" value kicks in!!! A side note is needed for the HP 260 G1 DM since it only has a single FAN, so I'm not sure if its CPU or its PSU FAN technically and its OEM BIOS misses a option the adjust FAN speed compared to the other 4 HP models! Another side note for the Prodesk 600 G1 SFF is that I'm forced to use a aftermarket non HP CPU FAN(old Intel CPU FAN), but it keeps spinning after coreboot post.
Removing the FAN/HWM code from the superio NPCD378 source, leads to the opposite it will force the PSU FAN to its MAXIMUM speed after poweron but atleast keeps the FAN spinning. This maximum forced full speed FAN behaviour can also be replicated by removing one of the 4 FAN wires, red or white cable not sure anymore.
Interesting FAN notes:
In case of the "Prodesk 600 G1", swapping its PSU with the PSU from the "compaq_8300_elite_sff" keeps the PSU fan spinning during and after coreboot post but it will still not adjust its PSU FAN speed to its requested values! Also the other way around, putting the PSU of the "Prodesk 600 G1" inside the "compaq_8300_elite_sff" stops the PSU FAN during coreboot post, but running the OEM firmware, keeps the fan spinning and let it adjust to all requested values on its donor FAN. So it seems there is a certain PWM compatibility to control these FAN's in similar ways between these boards. It seems the the newer PSU FAN from the Haswell generation can actually disable / stop spinning on a certain PWM value while older FAN keep spinning on these lower/ same PWM values.
Compared to the initial support commit by Patrick Rudolph, around April 2021 there were some code fixes but after that the last time this psu_fan_lvl code was verified functional was between 2023-05-02 and 2023-07-03 noted in the boardsupport commit of the variant compaq_8300_elite_sff_usdt by Riku Viitanen.
History for "coreboot/src/superio/nuvoton/npcd378" shows 6 patches from november 2023 till today.
Any tips hints welcome.
Files
Updated by Patrick Rudolph 26 days ago
The initial commit was tested on compaq_8200_elite_sff and definitely worked as expected.
I've never tested the code on other boards.
The code was introduced as the default fan speed (MAXIMUM speed) was too noisy.
You should check the original HP firmware how it does PWM fan control.
It might be that NPCD379 has a different firmware or is connected in a different fashion or uses different registers in the HWM I/O space.
Updated by Walter Sonius 23 days ago
- File compaq_8200_elite_sff.config compaq_8200_elite_sff.config added
- File cblogs-psu_fan_lvl-PWM-compaq_8200_elite_sff.txt cblogs-psu_fan_lvl-PWM-compaq_8200_elite_sff.txt added
You are correct indeed a "default" FAN speed does work, that's part of the active code behavior I forgot to mention (I took for granted) that part is still valid and works for 3 tested models including the sandy/ivy-bridge 379 variants. Like you mentioned it will go to a MAXIMUM speed which is to noisy and undesired if there is no NPCD378 FAN HWM code active, which I still can confirm for all 5 models.
Maybe that part is something which Riku confirmed with "...FAN levels stay in control..."?
This bug report, however is about setting a manual psu_fan_lvl which currently does not work on the "compaq_8200_elite_sff". The supplied coreboot logs show 7 reboots for all psu_fan_lvl with their respective "PWM" values for the "compaq_8200_elite_sff". My guess is that part of the code is broken that activates a custom value set by nvramtool -w psu_fan_lvl=value, therefor always a default quite silent speed is active or overrides?
Any hint in the code to just force a certain hex value without using or depending on the more complex psu_fan_lvl nvram/cmos values in npcd378/superio.c?
Did I read/remember correctly that a compaq 8200/8300 used in coreboot CI / jenkins project / build farm which auto builds and boots coreboot roms to check for errors, maybe I confused it with something else but if someone has access to those machines can they check if the PSU FAN level changes still work on current code?