RK3588 | Provide mainline kernel packages and images

[isarrider]

Hi,

I would like to try this out with a mainline kernel...
https://github.com/edk2-porting/edk2-rk3588
Is there an easy way to switch to the latest mainline kernel?
(I guess that would be the latest Debian Mainline Arm64 Kernel)...

Has anyone experimented with it?

BR,
Alex

[MichaIng]

I did not try it yet, but the latest rockchip64 edge kernel should work (the "current" one as well, now that it is Linux 6.12), though with limited features. There is a recent build: https://dietpi.com/downloads/binaries/testing/

You need the image and dtb packages both. And verify that /boot/dietpiEnv.txt defines an existing device trees via fdtfile= line, check in /boot/dtb/rockchip which one matches. They might be named differently between mainline and vendor kernel.

Debian kernel is too old, and too genetic as well.

[isarrider]

By "current" you mean when I freshly download the latest Rock5 Image?

[isarrider]

Maybe I should test that on my current Rock5C quickly...
(The latest current ones from your link)

[isarrider]

I must be doing sth wrong - my Rock5C wont come up again...

[MichaIng]

I mean like that:

cd /tmp
wget https://dietpi.com/downloads/binaries/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb

Then check the name of the correct device tree:

ls -l /boot/dtb/rockchip

and assure it matches the one in dietpiEnv.txt:

nano /boot/dietpiEnv.txt

Since this kernel is a major/LTS version upgrade 6.6 => 6.12, I did not push it to our APT server yet. I want to test it on all my Rockchip SBCs first, as there have almost always been problems the first weeks.

[isarrider]

Thats basically what I did but to be sure I did exactly these steps again...
It wont come up again...
(and happy new year)!

[MichaIng]

Happy New Year to you as well 🙂 🥳 !

Do you have a USB-UART adapter to check serial console logs? The device tree is the same.

One thing I just recognised is that the serial console surely won't be ttyFIQ0 anymore, but likely ttyS2. That would need to be adjusted in /boot/dietpiEnv.txt as well. It may break as well bootloader output, but it should not break boot.

But maybe the vendor bootloader is not compatible with the mainline kernel for some other reason.

I am building an image with mainline kernel and bootloader: https://github.com/MichaIng/DietPi/actions/runs/12581152457
Can be found here, once done: https://dietpi.com/downloads/images/testing/

[isarrider]

Let me give that a try later...
Would you be able to do one for my Rock5c too
(so means a Rock5A build)?
That one is already setup to use...

[isarrider]

and my UART debugging days are long over ;)

[isarrider]

Ok, didnt wanna be lazy, the image you provided comes up nicely on my Rock5B...
Pulls 1 update, the armbian firmware...

[isarrider]

little weird is the constant disk write reported by htop:

[isarrider]

seems the I/O went away now...

[MichaIng]

I guess the disk I/O was the kernel, writing the write buffer to disk.

Okay so far so great, many thanks for testing. Do you still have the old vendor kernel image? I wonder whether really the bootloader was the issue, i.e. whether we can offer a migration for all RK3588 SBCs at some point. Armbian offers images with this kernel for at least most of them already, so major issues should show up soon. Some features will be missing, like NPU and hardware acceleration will be gone, though the latter requires usually panfork/unofficial Mesa libs and software specifically compiled against those, which is easily available on Ubuntu only (there is a PPA). Also overlays are missing, like those to switch the M.2 SSD port from NVMe to SATA and such. An idea would be to do the other way round: offer images with mainline Linux, but keep vendor kernel in repo for those who needs missing hardware features, in case mainline U-Boot does support the vendor kernel.

At least I'll build all mainline kernel and bootloader packages for all RK3588 boards now and push them to the APT repo, to make testing them + the migration easier.

[isarrider]

Well - first of all its more like thank YOU - I did basically nth ;)
I dont have the old image anymore...
Regarding your idea - as mainline will get more and more features and fixes,
I would prefer it that way (Offer mainline images and who needs sth should get the vendor kernel).
Happy to test also on my Rock 5C (I like this board price/perf wise a lot)...

[isarrider]

In the coming days I hope to be able to test the UARTs,
sth that I would need to read out my Smart Meter...

[MichaIng]

You mean ROCK 5C? Since the ROCK 4C has mainline kernel already.

[isarrider]

Yap, fixed - typo...

[MichaIng]

Mainline kernel images for all RK3588 SBCs which have a device tree in mainline kernel, are available here: https://dietpi.com/downloads/images/testing/

[isarrider]

I will test the Rock5C with the Rock5A image later today...

[isarrider]

Seems like the 5C wont come up...

[isarrider]

and regarding the overlay for the Uart (#6989),
adding overlays=uart0-m2 makes the Rock5B not boot anymore...

[MichaIng]

Quite possible that the mainline kernel and/or bootloader is more tailored to the particular board than the vendor kernel/bootloader was. Quite common that a single vendor bootloader supported multiple variants of the same board family, while with mainline U-Boot, a dedicated build was needed for each. Makes anyway sense to properly add ROCK 5C support.

The UART0 overlay does not exist in the mainline kernel package:

Not exactly sure why, or whether it is enabled OOTB. Just note that the default/debug UART device change its name: With vendor kernel it is ttyFIQ0, with mainline kernel it is ttyS2. As there is not UART2 overlay as well, it would be at least consistent if then ttyS0 was available OOTB as well.

Apart of that, it is weird that the system does not boot up at all, when applying a non-existent overlay. It should just skip that and continue. It is loaded in an if condition, which is supposed to be allowed to return false/fail, so not sure why it did not in your case. Again would be interesting to see serial console output of this. Maybe we need to put an [ -e ... ] (file existence) condition first, or find some flag for U-Boot to accept a failing file load.

[isarrider]

Haha - too many things to do at once - with uart1-m1 it comes up fine...
I will take a look later...

[isarrider]

I picked overlays=uart4-m2 - need to attach sth and see....
But that has to wait after the CES is over.

[MichaIng]

Are overlay names and UART device names consistent, i.e. ttyS0 and ttyS2 available OOTB, ttyS1 enabled with uart1-m1 overlay etc?