* Re: PWM fan control not working with Rock5B and upstream kernel
@ 2025-07-15 8:44 ` Qu Wenruo
0 siblings, 0 replies; 10+ messages in thread
From: Qu Wenruo @ 2025-07-15 8:44 UTC (permalink / raw)
To: Nicolas Frattaroli; +Cc: linux-arm-kernel, linux-rockchip
在 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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>
>
>
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PWM fan control not working with Rock5B and upstream kernel
2025-07-15 8:44 ` Qu Wenruo
@ 2025-07-15 9:01 ` Qu Wenruo
-1 siblings, 0 replies; 10+ messages in thread
From: Qu Wenruo @ 2025-07-15 9:01 UTC (permalink / raw)
To: Nicolas Frattaroli; +Cc: linux-arm-kernel, linux-rockchip
在 2025/7/15 18:14, Qu Wenruo 写道:
>
>
> 在 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?
I'm a total idiot, the timing when the PWM doesn't work is not the
change from ACPI to device-tree boot mode, but the timing I switched
from fanless case to the PWM fan again.
And I plugged the 2pin fan connector to the WRONG PORT!
It's connected to the RTC battery port, I didn't notice until I recheck
the name of the connector minutes ago.
Really sorry for wasting your time on such a stupid error...
Now it's working again without anything problem.
>
> 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@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PWM fan control not working with Rock5B and upstream kernel
@ 2025-07-15 9:01 ` Qu Wenruo
0 siblings, 0 replies; 10+ messages in thread
From: Qu Wenruo @ 2025-07-15 9:01 UTC (permalink / raw)
To: Nicolas Frattaroli; +Cc: linux-arm-kernel, linux-rockchip
在 2025/7/15 18:14, Qu Wenruo 写道:
>
>
> 在 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?
I'm a total idiot, the timing when the PWM doesn't work is not the
change from ACPI to device-tree boot mode, but the timing I switched
from fanless case to the PWM fan again.
And I plugged the 2pin fan connector to the WRONG PORT!
It's connected to the RTC battery port, I didn't notice until I recheck
the name of the connector minutes ago.
Really sorry for wasting your time on such a stupid error...
Now it's working again without anything problem.
>
> 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@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>
>>
>>
>>
>>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PWM fan control not working with Rock5B and upstream kernel
2025-07-15 8:44 ` Qu Wenruo
@ 2025-07-15 9:13 ` Nicolas Frattaroli
-1 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2025-07-15 9:13 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-arm-kernel, linux-rockchip
Hi,
I've seen you've already solved your problem, but I feel I should
reply to some points anyway.
On Tuesday, 15 July 2025 10:44:21 Central European Summer Time Qu Wenruo wrote:
>
> 在 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.
U-Boot standard boot flow works just fine for this. Broken UEFI
services and ACPI interfaces nothing implements do not achieve this.
You can flash a mainline u-boot to your ROCK 5B's SPI flash and it
will boot aarch64 UEFI distro installers off USB thumb drives, or
do PXE boot, or load your GRUB on NVMe and such just fine.
>
> >
> > 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.
Collabora has been providing full mainline based ROCK 5B images for a
long time: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/debian-image-recipes
This includes gitlab pipelines for the mainline-based u-boot we ship
in our images: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/jobs
I'm not sure why you're on the Linux kernel mailing list complaining of
a lack of pre-compiled binaries though, it's not like kernel.org
distributes any binaries either. Compiling u-boot is fairly easy, see
https://docs.u-boot.org/en/latest/build/gcc.html for a general overview
including build dependencies.
1. fetch tf-a https://review.trustedfirmware.org/TF-A/trusted-firmware-a.git
2. compile it with make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- E=0 PLAT=rk3588
3. fetch rkbin https://github.com/rockchip-linux/rkbin/
4. fetch u-boot https://source.denx.de/u-boot/u-boot/-/tree/master
5. export BL31=path/to/tf-a/build/release/rk3588/bl31.elf
6. export ROCKCHIP_TPL=path/to/rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin
7. in the u-boot dir, run make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- rock5b-rk3588_defconfig
8. then again in the u-boot dir, run make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
9. flash the resulting `u-boot-rockchip-spi.bin` to offset 0 of your device's SPI flash,
or alternatively, flash `u-boot-rockchip.bin` to byte offset 32768 of an eMMC flash or SD card.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: PWM fan control not working with Rock5B and upstream kernel
@ 2025-07-15 9:13 ` Nicolas Frattaroli
0 siblings, 0 replies; 10+ messages in thread
From: Nicolas Frattaroli @ 2025-07-15 9:13 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-arm-kernel, linux-rockchip
Hi,
I've seen you've already solved your problem, but I feel I should
reply to some points anyway.
On Tuesday, 15 July 2025 10:44:21 Central European Summer Time Qu Wenruo wrote:
>
> 在 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.
U-Boot standard boot flow works just fine for this. Broken UEFI
services and ACPI interfaces nothing implements do not achieve this.
You can flash a mainline u-boot to your ROCK 5B's SPI flash and it
will boot aarch64 UEFI distro installers off USB thumb drives, or
do PXE boot, or load your GRUB on NVMe and such just fine.
>
> >
> > 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.
Collabora has been providing full mainline based ROCK 5B images for a
long time: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/debian-image-recipes
This includes gitlab pipelines for the mainline-based u-boot we ship
in our images: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/jobs
I'm not sure why you're on the Linux kernel mailing list complaining of
a lack of pre-compiled binaries though, it's not like kernel.org
distributes any binaries either. Compiling u-boot is fairly easy, see
https://docs.u-boot.org/en/latest/build/gcc.html for a general overview
including build dependencies.
1. fetch tf-a https://review.trustedfirmware.org/TF-A/trusted-firmware-a.git
2. compile it with make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- E=0 PLAT=rk3588
3. fetch rkbin https://github.com/rockchip-linux/rkbin/
4. fetch u-boot https://source.denx.de/u-boot/u-boot/-/tree/master
5. export BL31=path/to/tf-a/build/release/rk3588/bl31.elf
6. export ROCKCHIP_TPL=path/to/rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin
7. in the u-boot dir, run make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- rock5b-rk3588_defconfig
8. then again in the u-boot dir, run make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
9. flash the resulting `u-boot-rockchip-spi.bin` to offset 0 of your device's SPI flash,
or alternatively, flash `u-boot-rockchip.bin` to byte offset 32768 of an eMMC flash or SD card.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 10+ messages in thread