Proper way to move from vendor to mainline kernel?

General Discussion
1

Hey all, I have a 32GB Orange Pi 5 + I use to run a bunch of docker containers. I was reading through the github issue about CVE-2026-31431 (“Copy-Fail”) and saw this:

for RK3588 SBCs, one would need to switch to mainline Linux, which is strongly 
recommended anyway (and includes tons of more closed CVEs since 6.1.115), 
unless certain features are needed, e.g. missing WiFi driver for some of 
the Orange Pi 5 variants.

and figure that given that I am not using anything beyond the ethernet PHY and the CPU, there’s no reason to continue running a very old vendor kernel, I just stuck with what diet pi came with when I switched from Armbian. That said, I am not sure what the “right” way to do this in diet pi land is and want to avoid breaking anything or making upgrades a nightmare later.

Side note: if I hadn’t gotten this board for well under retail a year or so ago, I would be furious at how bad rockchip hardware support is. I am annoyed as it is but given that they are listed at $499 some places… yikes.

Thanks in advance!

2

something @MichaIng can answer I guess.

3

See the edit in the first post: linux-image-vendor-rk35xx was built with the affected driver disabled, hence no action needed there.

But switching to mainline Linux is recommended regardless. Naturally, the ancient Linux 6.1.115 has tons of other (less several) unpatched CVEs. The Orange Pi 5 Plus also does not use an onboard WiFi chip that wouldn’t be supported by mainline Linux (like Orange Pi 5 Max and Ultra).

To switch:

packages=()
dpkg-query -l | grep -q '^ii[[:blank:]]*linux-headers-vendor-rk35xx[[:blank:]:]' && packages+=('linux-headers-current-rockchip64')
dpkg-query -l | grep -q '^ii[[:blank:]]*linux-libc-dev-vendor-rk35xx[[:blank:]:]' && packages+=('linux-libc-dev-current-rockchip64')
G_AGI linux-image-current-rockchip64 "${packages[@]}" linux-u-boot-orangepi5-plus-current
G_AGP linux-{image,dtb,headers,libc-dev}-vendor-rk35xx
[[ -d '/boot/dtb' ]] || sudo dpkg-reconfigure linux-image-current-rockchip64
/boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sudo sed --follow-symlinks -i 's/ttyFIQ0/ttyS2/' /boot/dietpiEnv.txt
if systemctl -q is-enabled serial-getty@ttyFIQ0
then
	/boot/dietpi/func/dietpi-set_hardware serialconsole 0 ttyFIQ0
	/boot/dietpi/func/dietpi-set_hardware serialconsole 1 ttyS2
fi

And if you boot from M.2 or USB, flash U-Boot to SPI storage as well via dietpi-config Advanced Options.

4

I saw that it isn’t impacted but the other CVEs and my lack of dependence on things that still aren’t well supported in the mainline kernel makes me think it’s the right call.

Appreciate the really detailed response, I just wanted to make sure there wasn’t some foot gun waiting around the corner. I know you guys try hard to keep things as close to standard debian as possible to avoid things breaking but I wanted to check just in case™

I wanted to clarify the U-boot, I am not running the vendor supplied bootloader to boot from eMMC now, (I believe I am using the diet pi one but it may be from Armbian and a year or so old) does the vendor U-boot not play nicely with the mainline kernel? My experience with U-boot is limited to routers and chromebooks so I just want to make sure before I go in half-informed and fully confident and nuke my system and stay up until 3am getting it reconfigured.

Thanks again for your help!

5

I just tested it, and my Orange Pi 5 Plus boots fine from eMMC with mainline Linux and the new U-Boot. Interestingly, that bootloader even dynamically loads the correct device tree for different Orange Pi 5 variants: Since I have a single eMMC module with those two connector rows only, attached to the Orange Pi 5 Ultra, I switched to mainline kernel + U-Boot for Orange Pi 5 Plus there. And out of interest, I rebooted, and it did still load the Orange Pi 5 Ultra device tree. Plugging that eMMC module to the Orange Pi 5 Plus, it booted the Orange Pi 5 Plus device tree, without me defining it explicitly anywhere. For mainline U-Boot, such is very uncommon, hence I thought it would be still vendor U-Boot, but:

U-Boot SPL 2026.01_armbian-2026.01-S127a-P9249-He141-V7dfd-B1ec4-R448a (May 01 2026 - 22:27:13 +0000)
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
NOTICE:  BL31: v2.13.0(release):armbian
NOTICE:  BL31: Built : 22:25:59, May  1 2026
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    Maximum SPI INTID supported: 511
INFO:    BL31: Initializing runtime services
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x800000
INFO:    SPSR = 0x3c9


U-Boot 2026.01_armbian-2026.01-S127a-P9249-He141-V7dfd-B1ec4-R448a (May 01 2026 - 22:27:13 +0000)

Model: Xunlong Orange Pi 5 Plus

And Armbian explicitly chooses mainline U-Boot for non-vendor branch: build/config/boards/orangepi5-plus.conf at 3ae63519fd2dffcd7d5654e4b51b8bc666415e76 · armbian/build · GitHub

This is a quite big help for me testing new kernel versions on those two SBCs. Another thing I recognized (with mainline kernel), is that the Ethernet interfaces seem to be assigned consistently now:

[    2.626717] r8169 0003:31:00.0 eth0: RTL8125B, c0:74:2b:ff:5b:f2, XID 641, IRQ 130
[    2.627388] r8169 0003:31:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]
[    2.659883] r8169 0004:41:00.0 eth1: RTL8125B, c0:74:2b:ff:5b:f3, XID 641, IRQ 131
[    2.660553] r8169 0004:41:00.0 eth1: jumbo features [frames: 16362 bytes, tx checksumming: ko]

So the outer port is always eth0, the inner one always eth1, without /etc/udev/rules.d/99-dietpi-orangepi5plus.rules. If you do the switch, it would be great if you could test this as well, that after (re)moving that file, the interface names remain attached to the same Ethernet ports. So we could then remove those udev rules on mainline Linux.

One negative thing, though currently not sure whether this was better with vendor kernel: The blue and green LEDs have no trigger applied by default, i.e. only the red power LED remains lid, and one cannot see when the kernel has been loaded, aside of a single short green LED flash. Can be done with dietpi-led_control, but I want to assign heartbeat as default trigger for one of them: If at all, which one is doing the heartbeat with vendor kernel, the green or the blue one? Or any preference about which of the two should blink?

Another hardware question, out of interest: I am not able to attach the eMMC module a way that it looks fully safely plugged with both connector rows. The one at the FAN connector side always stays a bit higher than the one on the other side. It does work, no errors or so, but I have the impression that the FAN connector is located too close to the eMMC slot, preventing the module from being fully plugged without high pressure. Would probably need to file the either the FAN connector or the eMMC module a bit, so that it fully fits :thinking:. Is this the same for you?