PWM fan control not working with Rock5B and upstream kernel

[Nicolas Frattaroli]

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.