Orange Pi Compute Module 4

[geerlingguy]

Basic information

• Board URL (official): http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-CM4-1.html
• Board purchased from: Amazon
• Board purchase date: 2023-11-01
• Board specs (as tested): 4 GB RAM / 32 GB eMMC
• Board price (as tested): $43.99

Linux/system information

# output of `neofetch`
        #####           orangepi@orangepicm4 
       #######          -------------------- 
       ##O#O##          OS: Orange Pi 1.0.0 Bookworm aarch64 
       #######          Host: Rockchip RK3566 Orange Pi CM4 Board 
     ###########        Kernel: 5.10.160-rockchip-rk356x 
    #############       Uptime: 4 mins 
   ###############      Packages: 511 (dpkg) 
   ################     Shell: bash 5.2.15 
  #################     Resolution: 1920x1080 
#####################   Terminal: /dev/pts/0 
#####################   CPU: (4) @ 1.296GHz 
  #################     Memory: 169MiB / 3922MiB 

# output of `uname -a`
Linux orangepicm4 5.10.160-rockchip-rk356x #1.0.0 SMP Mon Aug 28 19:23:33 CST 2023 aarch64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: (144 single / 416 multi - https://browser.geekbench.com/v6/cpu/3381180)
• 5.604 Gflops / 1.401 Gflops/W (geerlingguy/top500-benchmark HPL result: Benchmark Orange Pi Compute Module 4 top500-benchmark#23)

Power

• Idle power draw (at wall): 1.7 W
• Maximum simulated power draw (stress-ng --matrix 0): 2.9 W
• During Geekbench multicore benchmark: 3.7 W
• During top500 HPL benchmark: 4.0 W

Disk

Built-in eMMC (SanDisk/Toshiba DV4032 HS200 eMMC 5.1)

Benchmark	Result
fio 1M sequential read	153 MB/s
iozone 1M random read	132.24 MB/s
iozone 1M random write	131.52 MB/s
iozone 4K random read	10.52 MB/s
iozone 4K random write	16.06 MB/s

curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bash

Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with curl -o disk-benchmark.sh [URL_HERE] and run sudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh (assuming the device is sda).

Also consider running PiBenchmarks.com script.

Network

iperf3 results:

Built-in 1 Gbps Ethernet

• iperf3 -c $SERVER_IP: 942 Mbps
• iperf3 --reverse -c $SERVER_IP: 933 Mbps
• iperf3 --bidir -c $SERVER_IP: 933 Mbps up, 237 Mbps down

Built-in WiFi

• iperf3 -c $SERVER_IP: 159 Mbps
• iperf3 --reverse -c $SERVER_IP: 206 Mbps
• iperf3 --bidir -c $SERVER_IP: 9.86 Mbps up, 164 Mbps down

GPU

• TODO: Haven't determined standardized benchmark yet. See Issue #2.

Memory

tinymembench results:

Click to expand memory benchmark result

tinymembench v0.4.10 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   1567.6 MB/s
 C copy backwards (32 byte blocks)                    :   1560.2 MB/s
 C copy backwards (64 byte blocks)                    :   1545.2 MB/s
 C copy                                               :   2252.8 MB/s
 C copy prefetched (32 bytes step)                    :   1552.6 MB/s (0.1%)
 C copy prefetched (64 bytes step)                    :   2249.0 MB/s
 C 2-pass copy                                        :   1347.0 MB/s
 C 2-pass copy prefetched (32 bytes step)             :   1090.0 MB/s
 C 2-pass copy prefetched (64 bytes step)             :   1149.7 MB/s (0.2%)
 C fill                                               :   4398.3 MB/s (0.2%)
 C fill (shuffle within 16 byte blocks)               :   4395.1 MB/s
 C fill (shuffle within 32 byte blocks)               :   4399.2 MB/s
 C fill (shuffle within 64 byte blocks)               :   4394.9 MB/s
 NEON 64x2 COPY                                       :   2253.4 MB/s
 NEON 64x2x4 COPY                                     :   2255.1 MB/s
 NEON 64x1x4_x2 COPY                                  :   2254.5 MB/s
 NEON 64x2 COPY prefetch x2                           :   2022.0 MB/s
 NEON 64x2x4 COPY prefetch x1                         :   2059.9 MB/s
 NEON 64x2 COPY prefetch x1                           :   2029.3 MB/s (0.1%)
 NEON 64x2x4 COPY prefetch x1                         :   2058.6 MB/s
 ---
 standard memcpy                                      :   2252.5 MB/s
 standard memset                                      :   4397.3 MB/s
 ---
 NEON LDP/STP copy                                    :   2255.9 MB/s
 NEON LDP/STP copy pldl2strm (32 bytes step)          :   1495.6 MB/s
 NEON LDP/STP copy pldl2strm (64 bytes step)          :   1988.3 MB/s
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   1755.5 MB/s
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   2287.6 MB/s
 NEON LD1/ST1 copy                                    :   2254.0 MB/s
 NEON STP fill                                        :   4398.2 MB/s
 NEON STNP fill                                       :   3371.9 MB/s (0.5%)
 ARM LDP/STP copy                                     :   2254.9 MB/s
 ARM STP fill                                         :   4398.8 MB/s (0.1%)
 ARM STNP fill                                        :   3373.7 MB/s (0.5%)

==========================================================================
== Framebuffer read tests.                                              ==
==                                                                      ==
== Many ARM devices use a part of the system memory as the framebuffer, ==
== typically mapped as uncached but with write-combining enabled.       ==
== Writes to such framebuffers are quite fast, but reads are much       ==
== slower and very sensitive to the alignment and the selection of      ==
== CPU instructions which are used for accessing memory.                ==
==                                                                      ==
== Many x86 systems allocate the framebuffer in the GPU memory,         ==
== accessible for the CPU via a relatively slow PCI-E bus. Moreover,    ==
== PCI-E is asymmetric and handles reads a lot worse than writes.       ==
==                                                                      ==
== If uncached framebuffer reads are reasonably fast (at least 100 MB/s ==
== or preferably >300 MB/s), then using the shadow framebuffer layer    ==
== is not necessary in Xorg DDX drivers, resulting in a nice overall    ==
== performance improvement. For example, the xf86-video-fbturbo DDX     ==
== uses this trick.                                                     ==
==========================================================================

 NEON LDP/STP copy (from framebuffer)                 :    194.7 MB/s (0.4%)
 NEON LDP/STP 2-pass copy (from framebuffer)          :    184.5 MB/s
 NEON LD1/ST1 copy (from framebuffer)                 :     51.6 MB/s
 NEON LD1/ST1 2-pass copy (from framebuffer)          :     51.1 MB/s
 ARM LDP/STP copy (from framebuffer)                  :    100.6 MB/s
 ARM LDP/STP 2-pass copy (from framebuffer)           :     98.2 MB/s

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    1.4 ns          /     2.6 ns 
     32768 :    8.5 ns          /    13.6 ns 
     65536 :   19.2 ns          /    27.3 ns 
    131072 :   24.2 ns          /    32.1 ns 
    262144 :   28.8 ns          /    34.4 ns 
    524288 :   36.7 ns          /    41.7 ns 
   1048576 :  108.7 ns          /   152.8 ns 
   2097152 :  148.3 ns          /   187.9 ns 
   4194304 :  168.8 ns          /   199.9 ns 
   8388608 :  191.7 ns          /   224.2 ns 
  16777216 :  205.1 ns          /   241.0 ns 
  33554432 :  214.2 ns          /   254.0 ns 
  67108864 :  219.7 ns          /   262.5 ns 

sbc-bench results

http://ix.io/4KDv

Phoronix Test Suite

Results from pi-general-benchmark.sh:

• pts/encode-mp3: 59.051 sec
• pts/x264 4K: 0.59 fps
• pts/x264 1080p: 2.58 fps
• pts/phpbench: 78381
• pts/build-linux-kernel (defconfig): 14862.769 sec

[geerlingguy]

Supposedly this board is compatible with CM4 IO boards. So far I have tested the PiTray mini and am getting no boot.

Boots just fine on the CM4 IO board, however!

It comes pre-flashed with some sort of Android release, going to see about flashing a different OS on it.

[geerlingguy]

Daaaang, the wiki has about 6 miles of instructions for flashing the eMMC, and all the screenshots are of RockChip's tool in Chinese: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_CM4

I'm going to try How to burn a Linux image to eMMC using the dd command...

[geerlingguy]

Interestingly, you can just flash Orange Pi OS (I have 1.0.0 Bookworm) straight to a microSD card and the device will boot off it, even if the device has eMMC. Looks a lot like Armbian.

I wish the 'boot off microSD even though I have eMMC' trick worked on Raspberry Pi CM4 :P

Default user/pass is orangepi.

[geerlingguy]

Running sudo apt update you wind up grabbing sources off http://repo.huaweicloud.com/debian (just an interesting observation...).

[geerlingguy]

I copied the .img file from my Mac over to the microSD card:

scp Orangepicm4_1.0.0_debian_bookworm_server_linux5.10.160.img orangepi@10.0.100.247:~/

Then I erased the eMMC and wrote the image to it:

sudo dd bs=1M if=/dev/zero of=/dev/mmcblk0 count=1000 status=progress
sudo sync
sudo dd bs=1M if=Orangepicm4_1.0.0_debian_bookworm_server_linux5.10.160.img of=/dev/mmcblk0 status=progress
sudo sync

I shut down, pulled the microSD card, and rebooted, and...

[TheOnion7]

I'm currently doing the exact same process than you . Very happy to see that you worked on that today!
I'm a bit disappointed, I thought it would be as easy as a RaspPi... but it's definitely not. I bought the exact same model than you; OrangePI CM4 Control Module with the CM4 board, for a total of 133$ CAD. But as of now, can't boot on anything I flash except the weird Android OS that it's obviously made for a touch screen. I bought that device hoping to install OpenVoiceOS on it since my Raspberry PI 4 was so slow and that new module has very great hardware.... but nothing impressive yet..

Thanks for you work Jeff.

[geerlingguy]

Today when I tried popping the Orange Pi CM4 into my little 3D printed CM4 board carrier tray, I noticed the PCB is way too thick—it's the thickest of all the clones, maybe this is an 8-layer PCB?

[UnKnoWn-Consortium]

@TheOnion7 Given the inferior core mix in the RK3566 (4x Cortex-A55) I dun think it will be faster than a Pi 4B (4x Cortex-A72), not to mention software maturity and optimization of the latter. If performance is your priority you may have better luck with the Orange Pi 5 series. Its RK3588 is an octa-core part (4x Cortex-A76 + 4x Cortex-A55) with a newer P-core architecture plus a 6-TOPS NPU.

[TheOnion7]

@TheOnion7 Given the inferior core mix in the RK3566 (4x Cortex-A55) I dun think it will be faster than a Pi 4B (4x Cortex-A72), not to mention software maturity and optimization of the latter. If performance is your priority you may have better luck with the Orange Pi 5 series. Its RK3588 is an octa-core part (4x Cortex-A76 + 4x Cortex-A55) with a newer P-core architecture plus a 6-TOPS NPU.

Thank You for your replay and all that information.
I would gladly try it, but for now, I'm very disappointed. It's been several days I'm trying to simply boot from an SD Card on any existing possible OS and... no chance yet.

I tried probably anything I could try , I'm about to return it and see for another alternative for me. I have a RaspPi 4B, but it's not enough for what I'm trying to do. I'm currently looking at simple mini Intel PCs. Will see. haha

Thanks for the info

[RicardoCst]

Hi @geerlingguy ,

Can I ask if you have tried the Orange Pi Compute Module 4 in the Radxa Taco?

[RicardoCst]

@geerlingguy

I tested it with the Radxa Taco and it works, no more buying expensive boards from Radxa...

[toastmanAu]

Running sudo apt update you wind up grabbing sources off http://repo.huaweicloud.com/debian (just an interesting observation...).

This is somewhat related to your "looks like Armbian" observation. Their image builder is an Armbian fork complete with the exact same default config file for building images. Apt mirror can be set to "China" for Great Firewall of China friendly apt sources. Armbian uses two Chinese universities for their mirrors and Opi use a Chinese commercial cloud storage service. I use both image builders and if you pass "" to the apt mirror it uses your default sources. My resultant images update from ports.ubuntu.com by default instead of Huawei (Ubuntu images ofc).