public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org
Subject: Re: PWM fan control not working with Rock5B and upstream kernel
Date: Tue, 15 Jul 2025 11:13:21 +0200	[thread overview]
Message-ID: <9751604.CDJkKcVGEf@workhorse> (raw)
In-Reply-To: <f33da910-7e83-40a0-bfcd-a6131a356358@suse.com>

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.




      parent reply	other threads:[~2025-07-15  9:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  4:10 PWM fan control not working with Rock5B and upstream kernel Qu Wenruo
2025-07-15  7:49 ` Nicolas Frattaroli
2025-07-15  8:44   ` Qu Wenruo
2025-07-15  9:01     ` Qu Wenruo
2025-07-15  9:13     ` Nicolas Frattaroli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9751604.CDJkKcVGEf@workhorse \
    --to=nicolas.frattaroli@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox