PWM fan control not working with Rock5B and upstream kernel

Qu Wenruo wqu at suse.com
Tue Jul 15 01:44:21 PDT 2025



在 2025/7/15 17:19, Nicolas Frattaroli 写道:
> On Tuesday, 15 July 2025 06:10:45 Central European Summer Time Qu Wenruo wrote:
>> Hi,
>>
>> My Rock5B board is running edk-rk3588 firmware and (almost) upstream
>> kernel (6.14.6 kernel from ArchlinuxARM), using upstream dtbs (the
>> firmware is also switched to device-tree boot mode)
> 
> Consider using mainline u-boot instead. I think the only ones who
> insist on edk2 forks are the BSD people, as they don't want to
> write device drivers. Linux has drivers, so inventing UEFI abstractions
> for things probably only makes your experience worse.

Well, having something more user-friendly and more similar to a 
traditional PC setup is definitely more attractive to end users.

> 
> Kernel 6.14 is also quite a bit behind and not supported by upstream,
> you'll likely have a better experience compiling a kernel yourself
> using defconfig as the base. ALARM likes to roll dice when it comes to
> their kernel config and then not update their kernels for half a year.

Thankfully the latest one is 6.15.6, and unfortunately it doesn't make a 
difference.

I'm fine compiling kernels for my VMs to run tests, but for the host I'd 
leave this as the last resort method.

I'll try the Uboot if required, but no pre-compiled upstream one is not 
really inviting end users.

> 
>>
>> Before that I'm using ACPI mode thus no PMW support, but the firmware's
>> fan control is working properly although running at a fixed rpm setting.
>>
>> But after switching to the upstream kernel and device-tree mode, the pwm
>> fan control never works.
> 
> Check /sys/class/pwm, export the pwm associated with the fan in the DT,
> then manually set a period and duty cycle that corresponds to a period
> the fan supports. If it doesn't spin, then the problem is likely that
> there is a disconnect between what Linux thinks the PWM signal is and
> what it actually is.

Mind to explain it a little more?

Not an expert on device-tree, I normally use the board just as a 
headless VM host.

> 
> I'm guessing the problem here is that your firmware of choice leaves
> the clock tree in a bit of a state, and the PWM is clocked from
> something that's incorrect. If it's not the right clock period for
> the fan, it won't spin.

But my bootloader (systemd-boot) is explicitly loading the dtb, not 
really relying on the one provided by the firmware.

Or that is not really enough for this case?

Thanks,
Qu

> 
> A logic analyzer would be able to tell you definitively whether that's
> the case.
> 
>>
>> `sensors` command detects the fan, and the pwm seems to properly
>> following the temperature, but the physical fan just do not spin at all:
>>
>> center_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +80.4°C
>>
>> bigcore2_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +84.1°C
>>
>> package_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +81.3°C
>>
>> pwmfan-isa-0000
>> Adapter: ISA adapter
>> pwm1:            128%  MANUAL CONTROL <<<
>>
>> gpu_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +79.5°C
>>
>> littlecore_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +82.2°C
>>
>> bigcore0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +83.2°C
>>
>>
>> I'm wondering is this a bug in the upstream PWM code or something else
>> is missing preventing the fan from working properly.
> 
> The upstream PWM code definitely works, and has worked for every
> Rockchip device so far. The PWM fan on my ROCK 5B (mainline u-boot,
> mainline kernel, mainline TF-A) works just fine.
> 
>>
>> Thanks,
>> Qu
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>
> 
> 
> 
> 




More information about the Linux-rockchip mailing list