Orange Pi 5 Max support for 6.12 and 6.13 kernel

[palachzzz]

Description

Following PR #7537,
I've backported Orange Pi 5 Max device tree from mainline linux kernel 6.14-rc1
Now Orange Pi 5 Max can start and boot on 6.13 edge branch, I also added support for 6.12 current branch, in case someone wants to play with that.
Thanks to @shenmintao who found this solution

Documentation summary for feature / change

Nothing specific, you can use following command to run build
./compile.sh build BOARD=orangepi5-max BRANCH=edge BUILD_DESKTOP=yes BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=noble
I think the main motivation for building it is to get HW support of Vulkan on Orange Pi 5 Max,
To achive that, you need to use following command to build:
./compile.sh build BOARD=orangepi5-max BRANCH=edge BUILD_DESKTOP=yes BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=noble ENABLE_EXTENSIONS="mesa-vpu"
But Mesa driver comes outdated without Vulkan support, to fix that you need:

sudo add-apt-repository ppa:oibaf/graphics-drivers
sudo apt install ppa-purge
sudo apt update
sudo apt upgrade
sudo ppa-purge ppa:kisak/kisak-mesa
sudo apt install mesa-vulkan-drivers vkmark

Then you can run vkmark to test Vulkan

How Has This Been Tested?

It was tested on:

• Ubuntu 24.04 (noble) edge branch (kernel 6.13) server and desktop, current branch (kernel 6.12) desktop
• Debian 12 (bookworm) edge branch (kernel 6.13) server and desktop
  The board is able to boot and run without significant issues, except known lack of HW devices support for RK3588 in mainline kernel:
  USB 3.0 ports are not functioning.
  HDMI 1 works at 1080p only.
  HDMI 2 does not work.
  HDMI audio is not working.
  WiFi is not working.
  Bluetooth is not working.

NOTE: I don't know why, but it is required ./config/boards/orangepi5-max.csc to have SKIP_ARMBIAN_REPO="yes" for building Debian 12, otherwise the board is not booting. Ubuntu 24.04 working in both cases if SKIP_ARMBIAN_REPO="yes" present or not. So for better compatibility I added it by default, but feel free to remove if you need Ubuntu.
If someone knows how to solve this issue with Debian 12, feel free to comment or change it.

[EvilOlaf]

I think having this file in dt folder will overwrite the one shipped with the kernel. Means it won't receive future updates from upstream. This would also probably cause breakage on other boards that build their device tree on top of the opi5 base one.
The dt folder should only be used for complete (no includes/dependencies) device trees for individual boards.
Same goes for 6.13.

[palachzzz]

This file is not in dt folder, it is patch which is only adding one line in dts/rockchip/Makefile:
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-max.dtb
Or I didn't get the point.

[EvilOlaf]

I won't force this in 02 w/o being properly prepared and then tested. Community efforts can be released anytime.

My suggestion is to wait until edge patches are rebased on 6.14-rc, then use kernel-dtb to extract a proper full device tree for the board and put that as single file into archive/rockchip64-6.12/dt for current. If that just works or will need more tweaking is a different story.

[palachzzz]

Currently dt patch consist of three files:

rk3588-orangepi-5-compact.dtsi
rk3588-orangepi-5-max.dts
rk3588-orangepi-5.dtsi

It was taken from 6.14 branch as it is. All these files are new for 6.13.y branch, and not used by any other board, so I can't imaging it may affect any other board.
Currently in 6.13.y there is only rk3588-orangepi-5-plus.dts file, as OPi5-Max board using the same chip (rk3588 without "s"), someone made refactor it in 6.14, and split rk3588-orangepi-5-plus.dts to common rk3588 (without "s") features into rk3588-orangepi-5.dtsi and specific OPi5-plus features in rk3588-orangepi-5-plus.dts
So in 6.14 OPi5-Plus will use rk3588-orangepi-5-plus.dts and rk3588-orangepi-5.dtsi.
OPi5-Max will use rk3588-orangepi-5.dtsi, rk3588-orangepi-5-compact.dtsi and rk3588-orangepi-5-max.dts.
There may be a question about purpose of rk3588-orangepi-5-compact.dtsi being created, but I guess it will be common file for future support of Orange Pi 5 Ultra.
So, rk3588-orangepi-5.dtsi is not affecting any current board, as there are no other rk3588 (without "s") OPi board in 6.13.y except OPi5-Plus which is using only rk3588-orangepi-5-plus.dts until 6.14 will be released.

But, if you are insist to have it in one file, I can refactor PR, and combine all three DT files in one, which will be called rk3588-orangepi-5-max.dts

[EvilOlaf]

I don't insist, otherwise I would have sent a change request ;). I am just sharing my thoughts on what would be a better approach to add back-ported support for this board to current.

[palachzzz]

I don't insist, otherwise I would have sent a change request ;)

I'd explain my motivation to not waiting 6.14 and add support faster by following:
It seems that well supported Orange Pi 5/5B is discontinuating, less shops have it in stock.
And looks OPi5 plus will follow the same way in nearest future, as almost everywhere OPi5 Pro, OPi5 Max and OPi5 Ultra, including official orangepi web-site.
But I see, many people buying new boards, and then they find themselves disappointed that it is very badly supported by third-party projects.. The same for me, just one week ago I was in one step from selling OPi5 Max and byuing used OPi5 Plus.
Occasionally I found PR 7537 and tried it. And now I'm almost happy. Yes, there are still some issues with peripheral devices, but I'm trying to solve it.
So, the more people get initial support, the more people will be involved in further support.

I also understand your motivation to not to brake anything already working, crystal clear :)

Anyway, if you see some way to bring it faster - I'm ready to do and test it.

[EvilOlaf]

that it is very badly supported by third-party projects.

Let's just say this attitude is often reciprocated. I will not go into further detail.

I get your point having this in quickly but there is almost never a proper reason to hurry. That is just an almost certain guarantee for regressions that need attention later on. Seen often enough over the years :). Getting things in good enough shape takes time. Just watch kernel patchwork from time to time which patchsets having to digit versions ;)