Orange Pi 5 Max (Rockchip 3588) Support?

Hey I am just wondering if the Orange Pi 5 Max is currently supported in FreeBSD yet? It seems like it has been a while.
I have read some older posts about the Rockchip 3588 issues that people were having so I just wanted to ask what the current status of this SBC is at right now?
I have seen alot of workarounds and patches you can do but I was hoping most things might be resolved since it has been a while since these 3588 rockchip versions have been available.
I would like to know what works and what does not work yet.

Sound
WiFi
Bluetooth
OpenGL
Ethernet
USB Ports
eMMC Card Support
M2 Support
MicroSD Support
4k HDMI Support

ETC..
 
I know this post is old, but since its first hit on google asking for opi5-max support I wanted to quick share my experience. By using edk2 port for Orange Pi 5 Max FreeBSD boots up, including HDMI console, Serial Console. M.2 detected with pcie3.0 4x. Onboard RTL8125BG is not detected. Even using realtek-re-kmod. pciconf -lv doesn't show anything expect the nvme so my best guess is that pcie2 controller is not supported (yet). Also tried very latest 15.0-BETA5 just to be sure not to miss latest changes. Situation reminds me to Pi5.
 
Hello everyone!
I'm new here.

Good news: I'm currently porting FreeBSD 14.3 to a NanoPC-T6 (RK3588), so the situation should be similar for the Orange Pi 5 Max. Here's the latest status of my current private branch (incomplete):

U-Boot and Rootfs login: Perfectly working.

CPU and temperature: DVFS frequency tuning and TSADC temperature monitoring are both working well.

eMMC and MicroSD: Work, but still need some performance optimization.

PCIe 3.0 x4 / 2.1: On! I've spent a lot of time studying public documentation—Rockchip register manuals, third-party hardware/software development guides, and finding the right reference commits in Linux code repositories—and using that knowledge to guide AI in helping me implement the code, finally figuring out the intricate relationships between PCIe, SMMU, GICv3 ITS, and the headache-inducing non-consistent DMA.

Intel i350 network card (tested via M.2 to PCIe adapter): This enterprise-class network card was tested using iperf3. UDP (-u -b1G -P2) speed remained stable at 957-960 Mbps with a 0% packet loss rate. TCP (-t10 -b1G -P2) speed reached 942 Mbps with 0 retransmissions. htop showed that the overall CPU utilization was well below 20%, and multi-queue interrupts were perfectly distributed across multiple cores. The bottleneck issue of core 0 has been completely resolved! (Note: This solution runs on the completely original IGB driver, without any modifications for the AArch64 architecture!)

Onboard Realtek RTL8125: Works via the realtek-re-kmod (v1.100+) driver, but due to the significant software cache synchronization overhead of the Realtek driver, core 0 utilization reaches 100%, thus limiting the speed to 600-700 Mbps. (Note: This solution also uses the original kmod driver, completely unoptimized for the AArch64 architecture.)

USB: This is my next goal, currently under development.

HDMI, WiFi, Bluetooth, Audio, GPU/NPU: No plans at the moment. My goal is to build a stable, reliable, high-throughput headless board, so these components are completely skipped.

Current Status/Shortcomings: I'm doing this work alone. Although my prototype runs at full line speed without crashing, the code is still a mess due to the intense debugging phase. I cannot yet guarantee a perfect balance between SMMU/ITS/DMA.

Currently, I'm connecting all my enterprise-grade network cards (Intel igb/ix, Broadcom bxe, Mellanox mlx4/mlx5, up to 100G) to the motherboard via M.2 adapters. I know PCIe 3.0 x4 connections will limit physical throughput to approximately 32 Gbps, but I'm doing this purely to test the multi-queue compatibility of the SMMU driver and the stability of inconsistent cache synchronization between different vendor drivers.

Frankly, I used AI as an architecture aid during the refactoring process to brainstorm ideas and find operating system interfaces. If you don't mind this kind of implementation assistance, I will share a prototype image after the USB protocol stack is finalized and the vendor network cards have undergone stress testing.
 
Back
Top