Orange Pi Zero 2W

[platima]

Basic information

• Board URL (official): http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2W.html
• Board purchased from: AliExpress
• Board purchase date: 2023-11-04
• Board specs (as tested): 2GB RAM + Expansion Board, 64GB microSD Card (w/ heatsink)
• Board price (as tested): $37.60 AUD + $13.37 AUD shipping, inc any taxes

Linux/system information

# output of `neofetch`
        #####           root@orangepizero2w
       #######          -------------------
       ##O#O##          OS: Orange Pi 1.0.0 Bookworm aarch64
       #######          Host: OrangePi Zero2 W
     ###########        Kernel: 6.1.31-sun50iw9
    #############       Uptime: 2 hours, 27 mins
   ###############      Packages: 1360 (dpkg)
   ################     Shell: bash 5.2.15
  #################     Resolution: 1280x720
#####################   CPU: (4) @ 1.512GHz
#####################   Memory: 155MiB / 1986MiB
  #################
 
#output of `uname -a`
Linux orangepizero2w 6.1.31-sun50iw9 #1.0.0 SMP Thu Sep  7 17:39:46 CST 2023 aarch64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: 155 single / 435 multi (https://browser.geekbench.com/v6/cpu/4265031)
• TODO Gflops (geerlingguy/top500-benchmark HPL result)

Power

• Idle power draw (at wall): 1.12 W (Image), 0.94W (Micro)
• Maximum simulated power draw (stress-ng --matrix 0): 2.40 W
• During Geekbench multicore benchmark: 2.35 W
• During top500 HPL benchmark: TODO W

Disk

microSD (Lexar V30 U3 A1 633X 64GB)

Benchmark	Result
fio 1M sequential read	26.6 MB/s
iozone 1M random read	23.52 MB/s
iozone 1M random write	22.52 MB/s
iozone 4K random read	10.00 MB/s
iozone 4K random write	4.58 MB/s

Network

iperf3 results:

• iperf3 -c $SERVER_IP: TODO Mbps
• iperf3 --reverse -c $SERVER_IP: TODO Mbps
• iperf3 --bidir -c $SERVER_IP: TODO Mbps up, TODO Mbps down

(Be sure to test all interfaces, noting any that are non-functional.)

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 : 1431.9 MB/s (0.5%)
C copy backwards (32 byte blocks) : 1441.3 MB/s (0.3%)
C copy backwards (64 byte blocks) : 1445.9 MB/s (0.2%)
C copy : 1380.5 MB/s (1.4%)
C copy prefetched (32 bytes step) : 1072.5 MB/s
C copy prefetched (64 bytes step) : 1047.3 MB/s
C 2-pass copy : 1260.6 MB/s
C 2-pass copy prefetched (32 bytes step) : 849.5 MB/s
C 2-pass copy prefetched (64 bytes step) : 821.5 MB/s
C fill : 5013.8 MB/s (0.4%)
C fill (shuffle within 16 byte blocks) : 5013.3 MB/s (0.4%)
C fill (shuffle within 32 byte blocks) : 4992.9 MB/s
C fill (shuffle within 64 byte blocks) : 5015.8 MB/s (0.4%)
NEON 64x2 COPY : 1462.5 MB/s
NEON 64x2x4 COPY : 1466.7 MB/s
NEON 64x1x4_x2 COPY : 1440.6 MB/s (0.5%)
NEON 64x2 COPY prefetch x2 : 330.3 MB/s
NEON 64x2x4 COPY prefetch x1 : 1582.1 MB/s
NEON 64x2 COPY prefetch x1 : 1611.0 MB/s (0.2%)
NEON 64x2x4 COPY prefetch x1 : 1582.4 MB/s

standard memcpy : 1456.3 MB/s
standard memset : 5013.3 MB/s (0.3%)

NEON LDP/STP copy : 1439.2 MB/s (0.5%)
NEON LDP/STP copy pldl2strm (32 bytes step) : 922.1 MB/s (0.8%)
NEON LDP/STP copy pldl2strm (64 bytes step) : 1192.0 MB/s (0.3%)
NEON LDP/STP copy pldl1keep (32 bytes step) : 1643.2 MB/s
NEON LDP/STP copy pldl1keep (64 bytes step) : 1651.8 MB/s
NEON LD1/ST1 copy : 1434.3 MB/s (0.7%)
NEON STP fill : 5015.8 MB/s (0.3%)
NEON STNP fill : 3161.0 MB/s (0.9%)
ARM LDP/STP copy : 1439.2 MB/s (0.7%)
ARM STP fill : 5016.2 MB/s (0.4%)
ARM STNP fill : 3230.9 MB/s (1.8%)

==========================================================================
== 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) : 176.0 MB/s
NEON LDP/STP 2-pass copy (from framebuffer) : 171.2 MB/s
NEON LD1/ST1 copy (from framebuffer) : 44.7 MB/s
NEON LD1/ST1 2-pass copy (from framebuffer) : 44.3 MB/s
ARM LDP/STP copy (from framebuffer) : 89.0 MB/s
ARM LDP/STP 2-pass copy (from framebuffer) : 87.7 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, [MADV_NOHUGEPAGE]
      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 :    0.0 ns          /     0.0 ns
     32768 :    0.0 ns          /     0.0 ns
     65536 :    4.3 ns          /     7.2 ns
    131072 :    6.5 ns          /    10.3 ns
    262144 :    7.7 ns          /    11.6 ns
    524288 :    8.3 ns          /    12.2 ns
   1048576 :    9.8 ns          /    14.5 ns
   2097152 :   95.0 ns          /   144.7 ns
   4194304 :  143.0 ns          /   189.3 ns
   8388608 :  167.5 ns          /   204.7 ns
  16777216 :  180.9 ns          /   212.1 ns
  33554432 :  188.1 ns          /   216.2 ns
  67108864 :  191.9 ns          /   218.6 ns
 
block size : single random read / dual random read, [MADV_HUGEPAGE]
      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 :    0.0 ns          /     0.0 ns
     32768 :    0.0 ns          /     0.0 ns
     65536 :    4.3 ns          /     7.2 ns
    131072 :    6.5 ns          /    10.3 ns
    262144 :    7.7 ns          /    11.6 ns
    524288 :    8.3 ns          /    12.2 ns
   1048576 :    9.7 ns          /    13.8 ns
   2097152 :   94.2 ns          /   143.5 ns
   4194304 :  136.6 ns          /   181.5 ns
   8388608 :  157.9 ns          /   193.5 ns
  16777216 :  168.3 ns          /   197.6 ns
  33554432 :  173.3 ns          /   199.2 ns
  67108864 :  175.8 ns          /   199.9 ns

Phoronix Test Suite

Results from pi-general-benchmark.sh:

• pts/encode-mp3: 48.19 sec
• pts/x264 4K: 0.78 fps
• pts/x264 1080p: 3.38 fps
• pts/phpbench: 86536

(https://openbenchmarking.org/result/2401052-NE-TEST6962944)

[leon332157]

Hello, thanks for the review! I have the OrangePi Zero 3 board 4GB, which has the same SOC has this board. I'd love to see how this board compared to the Zero 3. Perhaps I can help with the review process as well. How are you monitoring the power consumption during this review?

[platima]

Hey that would be great! I use this little thing https://amzn.to/3vwyDG6 (afilliate link) and you can see how I connect and monitor it in the video https://youtu.be/4sRz4CKpIdk (being published in 11 hours).

I am about to upgrade to a newer model that supports PD though, like https://www.aliexpress.us/item/1005005863861438.html I think.

[leon332157]

Great, I'll be sure to check out the video.

[leon332157]

@platima I watched your video, and you mentioned that there is no GPU acceleration out-of-the box. According to this reddit post, it is apparenly very easy to enable Panfrost with mesa. I have tested this on my Zero 3 and seems to work pretty well.

In fact, I'm writing this message on the HW-accelerated chromium and I am happy with the performance. Hopefully this helps!

[reticulatingsplines]

Hey @platima, if you're in the market for decent one of these usb passthrough meters with PD support, then I wanted to vouch for the TC66 from Ruideng, AKA "RIDEN", at least that's the name they seem to use when marketing stuff in the US (where I'm at). I've been using one for a while and it's been extremely useful. It's reversible (power can be flowing from the female port to the male port or vice-versa) and it can serve as a PD protocol trigger as well (use with caution folks!). I'm guessing that Fnirsi one does both of those things just fine too though.

The main reason I'd opt for the TC66 is that another youtuber, TheHWCave, has two videos uploaded where they extensively test and essentially reverse-engineering the thing, detailing exactly how to hook it up and what modes to use to get the most accurate logging possible. They've done a really great service, given that a lot of these little USB meters seem to come with several buttons and extra ports on the side, but no actual useful documentation about how they're to be used. It's also encouraging that Ruideng's youtube account has left replies in the comments with additional info (importantly, that powering the device through microUSB port on the side will give the most accurate readings of the usb-c power path, as the device won't be drawing from it to power itself).

Again, I don't doubt that the Fnirsi meter is a solid piece of tech as well, they have definitely proven themselves in the "cheap but surprisingly accurate testing gadgets" market and I've heard good things about the FNB58 (which actually comes in a nice enclosure rather than the DIY-style plastic+standoffs that all the rest of these things seem to ship in). Really, it's TheHWCave's feature-length documentary on the the TC66 that makes it the top choice for me, especially given that I've learned these things are pretty easy to use incorrectly, despite seeming to just be plug-n-play.

---

TC66 on aliexpress: https://www.aliexpress.us/item/2251832781988598.html
You can also find it on Amazon, at least in the US. I'd try to buy it from the company's own Amazon store, which on the US version of Amazon is called "RD". There seem to be a lot of other accounts selling these things and I imagine it'd be pretty easy to make an identical knockoff with a garbage BOM.

TheHWCave's videos:
"Ruideng TC66 / TC66C USB Type-C Tester - Way too good for just USB!"
https://www.youtube.com/watch?v=rOlhibDUJgs

"Everything you always wanted to know about USB Type-C & the TC66/C (but were afraid to ask)"
https://www.youtube.com/watch?v=L70gtJ9hzfQ

[reticulatingsplines]

Oh, I also forgot maybe the most important part, @TheHWcave also has a repository with their own short-and-sweet PDF documentation and a python script you can use to interface with the meter and log data from it into a CSV, which is a great alternative to using the manufacturer's software (which is useless to me given I don't use windows!)

https://github.com/TheHWcave/TC66

[platima]

According to this reddit post, it is apparenly very easy to enable Panfrost with mesa

OH that is excellent, I will definitely have to try this out - thank you kindly! And yeah I was mostly referencing page 31 of the doco, the RaspiOS port doco, and the fact there was epic sheering. Could make for some good "Part 2 Updates" content though! I have no idea why it's not enabled out of the box =/

Again, many thanks!

[platima]

I wanted to vouch for the TC66 from Ruideng, AKA "RIDEN"

Excellent, thank you kindly mate! So we stop spamming poor Jeff, I just started https://www.reddit.com/r/AskElectronics/comments/190e1ky/usb_current_meters_w_pd_support/

[richardhendricks]

Getting two of these soon, one of the 1.5GB and one of the 4GB versions. Can you time how long it takes to from cold boot to idle prompt? Thanks!

[platima]

Yo. Measured it in this video (timestamped link), but long story short first boot was about ~2 mins while it sets itself up, then after that boot was 40s to desktop. Would be about 25s to CLI I reckon.

[WarHawk8080]

Read the temps on the dies

paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/`

OOF....mine is running a bit warm!

root@orangepizero2w:/sys/class/thermal/thermal_zone0# paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/'
cpu_thermal_zone  62.2°C
ddr_thermal_zone  63.4°C
gpu_thermal_zone  62.7°C
ve_thermal_zone   61.5°C

[el-quique]

Hello. Does anyone have a tutorial for connecting a 3.5 LCD RPi. I am missing the configuration and connection of the LCD_RST and LCD_RC pins to the Orange Pi Zero 2W. THX
http://www.lcdwiki.com/3.5inch_RPi_Display

[muandane]

Anyone tested the usb speed on the opi ?

[platima]

Anyone tested the usb speed on the opi ?

Not really the place for it mate, this isn't a forum for the product! I'd recommend a post over at http://www.orangepi.org/orangepibbsen/. Cheers

[platima]

Hello. Does anyone have a tutorial for connecting a 3.5 LCD RPi. I am missing the configuration and connection of the LCD_RST and LCD_RC pins to the Orange Pi Zero 2W. THX http://www.lcdwiki.com/3.5inch_RPi_Display

Hey I'd recommend posting over at http://www.orangepi.org/orangepibbsen/. This isn't a support group / discussion forum sorry! Cheers

[platima]

Read the temps on the dies

paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/`

OOF....mine is running a bit warm!

root@orangepizero2w:/sys/class/thermal/thermal_zone0# paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/'
cpu_thermal_zone  62.2°C
ddr_thermal_zone  63.4°C
gpu_thermal_zone  62.7°C
ve_thermal_zone   61.5°C

Not bad for no heatsink though; I'd say anything up to ~75C is fine. Good info though, thank you!