OrangePi 5 – Testing with sbc_gpio

After a lot of success with the Radxa Rock 5B, I saw that Orange Pi was offering several different boards using the same Rockchip RK3588 or RK3588S chips. I decided to pick up the Orange Pi 5 that uses the RK3588S so I could check out the differences between the RK3588 and RK3588S. Also, since both platforms are quite similar, I wanted to see how support and usability differed between the different vendors. This is my first OrangePi board, so I was looking forward to it!

Orange Pi 5 Specs

The specs for the OrangePi 5 are similar to the Radxa Rock 5B, but there are a few variances. The OrangePi 5 is a smaller board that uses the RK3588S chip (as opposed to the RK3588). The RK3588S is essentially a cut down version of the RK3588. The PCIe 3.0 has been removed which means that an NVMe SSD will need to use the PCIe 2.0 that the Rock 5B has for the wireless module. This also means that if you want to use an NVMe SSD, you’ll need to use USB for your WiFi.

NOTE: My testing was all performed using the Orange Pi 5. There are two similar boards available that have some slightly different options:

• OrangePi 5B – Removes the PCIe port and replaces it with built-in WiFi and Bluetooth. Same RK3588S with a 26 pin header (rather than the standard 40)/
• OrangePi 5 Plus – This is more similar to the Radxa Rock 5B. Uses the RK3588, has dual PCIe (1x M-Key and 1x E-key), dual HDMI out, eMMC interface, 40pin GPIO

I intentionally chose to skip the OrangePi 5 Plus since it is nearly identical to the Raxda Rock 5B. The OrangePi 5 has less GPIO ports and less PCIe, but it is also smaller and costs less. Based on what I’ve seen I would expect the OrangePi 5 Plus to perform nearly identical to the Radxa Rock 5B.

	OrangePi 5 (and 5B)
CPU	Rockchip RK3588S 4x ARM Cortex-A76 (408Mhz – 2.4Ghz) 4x ARM Cortex-A55 (408Mhz – 1.8Ghz)
NPU	6 TOPS INT4/INT8/INT16/FP16 TensorFlow/MXNet/PyTorch/Caffe can be easily converted 300Mhz – 1Ghz (per /sys/class/devfreq/fdab0000.npu/available_frequencies
Memory	4/8/16/32GB LPDDR4
GPU	ARM Mali-G610 MP4 3D GPU 4 cores (300Mhz – 1Ghz)
Video Decoding	H.264, H.265 HEVC (8/10bit), VP8, VP9, VC-1, AVC, JPEG
Video Encoding	H.264, H.265 HEVC (8/10bit), VP8, VP9, VC-1, AVC, JPEG
GPU FP16/FP32/FP64	? / 610 / ? GFLOPS
Video Out	1x HDMI + 1x DisplayPort 1.4 (via USB-C) + 2x MIPI D-PHY TX 4 Lane
Video In	MIPI CSI 4Lane + 2x MIPI D-PHY RX 4 Lane
Storage	MicroSD 16MB QSPI bootflash M.2 M-Key (supports 2242 only) ** 5B includes 32/64/128GB eMMC
USB	1x USB 3.0 Type-A 2x UsB 2.0 Type-A 1x USB 3.1 Type-C
PCIe	PCIe 2.0 M.2 M key (up to 2242 SSD only!) ** 5B has NO PCIe slot (builtin WiFi/BT instead)
Networking	YT8531C Gigabit Ethernet ** 5B includes Dual-band WiFi6
Bluetooth	None ** 5B includes 5.0 with BLE support
I2C	up to 3x
SPI	up to 1x
UART	up to 4x
PWM	up to 5x
ADC (analog to digital)	N/A
CAN Bus	up to 2x
General GPIO / Other	up to 17x
Power	USB-C 5v 4A
Kernel Support	5.10 (Orange Pi fork)
Purchase Links	OrangePi 5 8GB (Amazon) OrangePi 5 8GB (AliExpress) OrangePi 5B 8GB WiFi (Amazon) OrangePi 5B 8GB WiFi (AliExpress)

SBC Scoring Results

GPIO’s (0/1)

Before you cry foul, I didn’t knock off points for the fewer number of GPIO’s (uses a 26 pin header instead of a 40 pin). I bought this board knowing that there were fewer GPIO pins. I knocked off the GPIO point because I was unable to get internal pull-up or pull-down resistors to work AT ALL. Using libgpiod tools, I tested setting the pull-up and pull-down on multiple different pins and was unable to see any change.

The lack of pull-up and pull-down made me go back and re-test this on multiple other systems including:

• Radxa Rock 5B (RK3588) – ALSO wouldn’t apply internal pull-up or pull-down
• Raspberry Pi 4B (Broadcom BCM2711) – Works perfectly!
• Visionfive Starfive 2 (RISC-V JH7110) – Works perfectly! (Happened to be sitting on my desk, stay tuned for an article for this device)
• BIGTREETECH CB1 (Allwinner H616) – Works perfectly (within the confines of the pull-up/down resistors being a different value on some pins, see my CB1 article for more)

I did find reference to the pull-up/down in the Rockchip datasheets for the RK3588/RK3588S but can’t seem to get it to work on either the OrangePi 5 or Radxa Rock 5B. For now, external pull-up/down resistors are required.

NOTE: I did post a question in the Radxa (for the Rock 5B) forum but haven’t had a single response as of yet.

IR (1/1)

Just like the Rock 5B, the OrangePi 5 handled all the IR tests with no problem at all. The only downside is that you need to create the overlays yourself since OrangePi doesn’t include them in the built-in overlays. However, all the necessary drivers are already compiled into the kernel, and the orangepi-config tool had a section to install LIRC daemon and tools:

I’ll get into the orangepi-config tool more in the Ease of Use section. A copy of the overlay files can be found on our GitHub files share. OrangePi uses UBOOT startup with boot.scr that already incorporates a mechanism to add your own custom overlays. Simply copy the compiled overlay files (dbto) to the /boot/overlay-user directory, then add the following line to the /boot/orangepiEnv.txt file:

user_overlays=gpio-ir-recv-1d2 gpio-ir-tx-1d3

After a reboot, both LIRC devices are initialized and ready to go! Not quite as easy as a Raspberry Pi, but pretty close.

I2C (1/1)

Not a lot to say here. Unlike the BIGTREETECH CB1 which used a software I2C driver, there are 3x I2C devices exposed from the RK3588S SOC. I was impressed that they managed to configure 3x as optional on the 26 pin header. The orangepi-config tool has the option to enable the I2C:

Alternatively, you can add i2c5-m3 to the overlays line in the /boot/orangepiEnv.txt file.

Everything with the I2C display worked perfectly.

SPI (1/2)

For the SPI test, I used both a BME280 and DHT22 connected to SPI. (I created a Python library for reading DHT from the SPI bus since bit-banging has become too unreliable). Both worked, but I couldn’t run them both at the same time since OrangePi only exposed one SPI bus on the 26 pin header. We can’t connect the DHT22 to the same SPI bus as another device due to pull-up issues on the MISO port. I docked a point due to the fact that only one SPI bus was available. (I am working on a way to make the DHT SPI Python setup work alongside other SPI devices, more to come.)

Enabling the SPI bus is again a breeze using the orangepi-config tool.

Alternatively, you can add spi4-m0-cs1-spidev to the overlays line in the /boot/orangepiEnv.txt file.

The only confusing part is making sure you select the right one. Only spi4-m0 is exposed on the 26 pin header. It would be nice if OrangePi would just list the available overlays.

UART (1/1)

The UART tests passed without a hitch on the OrangePi 5 just like with the Radxa Rock 5B. I had essentially 100% success except for 1 test out of 15,000 always seems to fail. The Raspberry Pi 4B and 3B always seemed to end up in the 90-93% success rate that struck me as a buffering issue. The OrangePi 5 and Rock 5B based on the Rockchip 3588(S) worked flawlessly.

The only minor irritation here is that separate from the 26 pin header is a 3 pin serial header that is used for debugging. I have not yet found a way to re-purpose this UART port for use in the OS. If this could be converted to a standard UART interface that would free up additional ports on the limited 26 pin header.

Enabling the UART is again a breeze using the orangepi-config tool.

Alternatively, you can add uart0-m2 to the overlays line in the /boot/orangepiEnv.txt file.

Subjective Performance (2/2)

The RK3588S in the OrangePi 5 is essentially the same as the RK3588 in the Rock 5B when it comes to CPU. Both have 4x A76 (up to 2.4Ghz) and 4x A55 (up to 1.8Ghz). My main bottleneck was the SD card I was booting from. I have an NVMe SSD to install, I just haven’t set it up yet. As far as I’m concerned, the RK3588(S) is good enough to use as a normal desktop.

OrangePi also has ZRAM pre-configured in their image (virtual swap space using compressed RAM, see my article on ZRAM for more info). I’ve found that swap setup isn’t configured by all vendors, so I was pleased to see this. I also saw that ZRAM was used to create a compressed mount point for /var/log. This is something I haven’t seen on other images from board vendors. Moving logging into RAM loses persistence, but for devices running on SD cards it will boost performance by eliminating a lot of background writes, and extend the life of your SD card.

Ease of Use (1/2)

I really want to give OrangePi props for their orangepi-config tool. This is the ONLY vendor I’ve found so far with a tool that can come close to matching the raspi-config tool. The orangepi-config tool even has several features that raspi-config doesn’t have.

I showed some parts of the orangepi-config tool above while configuring the I2C, SPI and UART overlays.

As you can see, we have a range of options available:

• Programming the bootloader to different devices
• Editing the orangepiEnv.txt file
• Selecting overlays
• Configuring network settings
• Installing / uninstalling LIRC
• Time zone
• SSH options (including OTP)
• Even some 3rd Party software

I really would give this a 2/2 if not for a few oddities:

• Overlay page lists overlays that are not applicable (i.e. SPI overlays that use pins not exposed on the OrangePi 5, although they may work on the OrangePi 5 Pro)
• Change some setting aren’t reflected until you close the app and re-open it (i.e. the time zone)
• It isn’t always clear what selecting something will do. For example, selecting “Avahi” from the system settings menu will kick off downloading and installing packages, as well as configuring them without any clear message as to what was about to happen.
• Crashed several times

The orangepi-config tool is excellent but has some rough edges. I would certainly start here to configure your SBC.

Software Updates (1/2)

Kernel

Just like with every SBC I’ve worked with that ISN’T a Raspberry Pi, the kernel doesn’t seem to be getting any updates. The OrangePi 5 uses the same 5.10.110 kernel that is used by the Radxa Rock 5B (not entirely surprising since they are almost the same chip). They both appear to use the same Rockchip kernel as their base, and I don’t see any security updates being applied.

It seems safe to assume that Rockchip selected 5.10 since it is an LTS release that is slated for support through December 2026. However, they forked at 5.10.110 and the kernel has continued on to 5.10.192 (as of August 2023). This seems to defeat the purpose of using an LTS kernel if you aren’t ever going to update it.

System

Here is where things get a bit strange. The image I downloaded was the official OrangePi 5 Ubuntu 22.04 (jammy) release. For some reason rather than using Ubuntu mirrors, the system is configured to use Huawei servers for Ubuntu and aliyun.com for Docker. Here are the apt sources (from /etc/apt/sources.list and /etc/apt/sources.list.d/docker.list):

deb http://repo.huaweicloud.com/ubuntu-ports/ jammy main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-security main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-updates main restricted universe multiverse
deb http://repo.huaweicloud.com/ubuntu-ports/ jammy-backports main restricted universe multiverse
deb [arch=arm64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu jammy stable

The aliyun.com mirror for docker seems to be a Docker supported mirror (based on its presence in the Docker install script). The Huawei mirror also seems legit based on https://launchpad.net/ubuntu/+mirror/repo.huaweicloud.com-archive. I get that OrangePi is a Chinese company, and these mirrors may make the most sense for them, but it would be nice to see an image for those of us not in China. Using a wired connection on my Gigabit internet, I was seeing up to 200ms latency to the Huawei mirrors (NOTE: repo.huaweicloud.com resolved to a CDN, so milage here may vary).

Unusual APT sources aside, they do appear to mirror the official Ubuntu release, so we are getting updates. It was also nice to see a 22.04 image rather than the 20.04 that some other vendors provide.

Community (1/2)

There is an OrangePi forum (http://www.orangepi.org/orangepibbsen/), however it seems relatively small. The forum also covers a wide range of SBC boards that OrangePi offers which can be good and bad. On the plus side, the OrangePi 5 is not their first board, so the setup seems well thought out. The downside is it has been difficult to find much for this specific board. Searching the forum for “OrangePi 5” only found 31 matches and quite a few of those weren’t for the OrangePi 5.

This also brings me to another issue, the name. OrangePi is the company, the model is “5”. There is also a “5B” (which is basically the same board with WiFi and BT in place of the PCIe slot) and a “5 Pro” which is a different chip (RK3588 instead of the RK3588S). The “5 Pro” has quite a few different features including two PCIe slots and a 40 pin GPIO header. Searching for the OrangePi 5 has actually been a bit of a struggle. I keep getting results for the “5 Pro” that don’t apply, or just end up with OrangePi articles that have the number “5” somewhere in them. More characters in the name would make searching a bit easier. Even making it a “5A” and “5B” would help.

Issues

In the GPIO section I covered the issue with the internal pull-up and pull-down. I was not able to get either to work on any of the pins I tested using multiple version of libgpiod. This isn’t a total show-stopper, it just means that external pull-up or pull-down resistors are required until I can figure out if they are just not supported on the RK3588/RK3588S or if it is a bug that needs fixing.

The other issues are pretty minor. I only have 1 SPI bus available which meant I couldn’t test the BME280 and DHT22 at the same time (this is a limitation of how I am reading the DHT22 sensor and not a limitation of the SPI bus itself). I was also a bit surprised by the APT repos, but that should be configurable.

Overall (9/14)

All in all, this is a very solid system. The orangepi-config utility gives a level of usability that my Radxa Rock 5B was missing. You can tell that OrangePi has been building SBC’s for some time now based of the effort put into the software.

The only real caution here is the limited number of GPIO’s and the issue with internal pull-up/pull-down resistors. If you think you’ll need 2x SPI or just more GPIO’s in general then I would suggest looking at the OrangePi 5 Pro instead (where the full 40 pin header is available). This board only scored lower than the Radxa Rock 5B due to the single SPI bus.

One last note on a performance perspective. the RK3588S appears to drop the PCIe 3.0 x4 bus that is present on the RK3588. That means that the NVMe slot is connected to the PCIe 2.0 x1 bus. The theoretical throughput limit is 500MB/sec which will still outperform eMMC or SD cards by a healthy margin.

I would highly recommend the OrangePi 5 (or one of the variants)!