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