Orange Pi 5 Plus

Vet du om den körde Rockchip eller Allwinner?

Blev lite tvingad till att hitta alternativ till RPi4 i jobbet då de inte gick att köpa. Var inte helt glad över det p.g.a. rätt dåliga erfarenheter av Allwinner baserad Banana Pi samt rk3288 baserade ASUS Tinker board (den var dock långt bättre än Banana Pi:n).

Körde initialt Orange Pi 4 LTS som är rk3399, en krets som redan när vi började använda den hade bra kernel.org stöd.

Orange Pi 4 LTS har 8-16 GB integrerad eMMC, lärdomen från den blev att även om eMMC inte är lika snabb som NVMe är det ändå långt bättre än SD-kort både sett till tillförlitlighet (den är lika bra som "vanlig" SSD) och prestanda (klart snabbare än SD-kort, men en bra bit efter NVMe).

rk3399 har 2 st Cortex A72 + 4 st Cortex A53, på det stora hela något långsammare all-core jämfört med RPi4 med 4 st Cortex A72.

Prismässigt går det hitta Orange Pi 4 LTS (som har också har integrerad Wifi 5) för under 1000-lappen.

Blev så positivt överraskad av hur bra Orange Pi 4 LTS fungerade så Orange Pi 5 kändes som ett självklart val från i somras. Framförallt då så mycket av I/O-stödet var direkt användbart utan att kräva extra kretsar (well, man behöver transivers för saker som CAN, RS485 och liknande men kontroll-delen och drivers är inbyggt).

CAN, RS485, SPI, I²C, UART etc är kanske inte något den typiska PC-användaren kommer i kontakt med, men det är ju de är alla väldigt vanliga protokoll för inbyggda-system och industri-datorer.

CAN kan ge hårda realtidskrav, har historiskt främst används av bilindustrin men börjar nu allt mer vanligt i SBC och mikrokontrollers. OPi5, RPi5, Arduino UNO R4, m.fl. har det integrerat och finns drivers i Linux-kärnan för populära kretsar (t.ex. RPi-HATs eller liknande).

RS485 är en långsam (typiskt 2400-19200 BAUD...), men väldigt populär standard för kommunikation mellan PLC, elmätare, etc inom industrin. Tål miljö med mycket störningar, möjligt att daisy-chain:a enheter (så två trådar från datorn kan styra många enheter). Rätt sällan integrerat direkt på SBC/mikrokontrollers, men finns massor med kretsar som kopplas mot UART.

SPI och I²C är väldigt vanliga protokoll för att lägga till specifika kretsar eller sensorer till ett inbyggt system. SPI är hyfsat snabbt, de flesta enheter/kretsar fixar 1 Mbit/s.

UART är en generell mekanisk för seriell kommunikation. UART:en är normalt synligt från Linux som "/dev/ttyS5" eller liknande. Man kopplar sedan TX/RX-pinnarna till lämplig transiver, t.ex. RS232 (PC-style seriell kabel), RS422, RS485, eller egna kreationer som använder sig av asynkron seriekommunikation (föredrar själv SPI för det senare, synkron serielkommunikation är enklare att begripa sig på och rimligen stabilare...).

Så inom många områden är detta "inga konstigheter". En stor orsak till den stora bristen på RPi 4 är ju att "industrin" fått upp ögonen för hur bra och billig produkt det är. Var just bristen på RPi 4 som gjorde att jag upptäckte Orange Pi 4 och till min glädje upptäckte att den fungerar precis lika bra för dessa saker då det sedan länge är standardfunktioner i Linux-kärnan.

Har gjort korta försök att köra RPi 3 och RPi 4 som desktop-system. I båda fallen tyckte i alla fall jag att det räckte med ett par minuters surfande för att konstatera: det här var ingen vidare upplevelse... Delvis föll de på prestanda (framförallt RPi 3 som forfarande var en in-order CPU-design), men det föll nog främst på dålig disk hastighet.

Körde inte länge med SD-kortet på OPi5:an, men de minuter det tog att starta Ubuntu desktop och köra guiden för att lägga installationen på eMMC eller NVMe räckte för att "känna" hur segt allt kändes att starta. Med NVMe känns allt som en "vanlig" dator ur den aspekten, ska även testa med eMMC. Köpte eMMC specifikt för att kunna testa hur mycket/lite prestandaskillnaden "känns".

En 256 GB eMMC krets kostar någon hundralappar, nu är inte en 512 GB NVMe heller speciellt mycket dyrare, men den senare tar betydligt mer plats och drar mer ström.

Tror många missförstår din kommentar här

"Notera att den kernel-utvecklingen går mot Radxas ROCK5B/5A, vilket är en annan bräda än OrangePi 5 plus, antalet NIC är den uppenbara skillnaden."

Ja, det är helt sant att det är Radxas som primärt jobbar med kernel.org stödet för rk3588. Men det kvittar om det man önskar är kernel.org stöd för just systemkretsen rk3588. Dessa två system skiljer sig ungefär som två PC-datorer där mitt mål är stöd för GPU-krets Xyz, det spelar då ingen roll om den som jobbar på stödet har t.ex. ett Intel NIC medan jag sitter på ett Realtek.

En systemkrets innehåller en rad IP-block, det är möjligt att stödja en systemkrets delvis eller fullt ut. Grejen är att hela kretsen är ett helt paket, eventuella periferienheter som hänger på PCIe eller USB är inte relevant för hur systemkretsen fungerar.

Kort och gott: om/när det finns stöd för Radxas ROCK5B/5A i standardkärnan kommer det även finans stöd för övriga system baserade på rk3588, inklusive Orange Pi 5 Plus (verkar bara vara PCIe stödet som är friserat i rk3588s, så gissningsvis fungerar även dessa).

De saker som hänger på PCIe är redan nu ett icke-problem, de använder redan standard drivrutiner från kernel.org

I Orange Pi 5 handlar det om RTL8125 för de två 2,5 Gbit/s portarna samt RTL8842BE för Wifi-6. De är ju "helt vanliga" PCIe enheter sett från Linux sida.

Sen angående

"Jag är inte lika imponerad som Yoshman av att köra Rockchips "custom kernel". Videon nedan nämner hemliga minnesareor i Rockchip-processorn. Det är oklart för mig vem som står bakom OrangePi, men om det är FriendlyELEC (som säljer dem), så är de kända för att lämna WAN utan brandvägg och ha andra suspekta hyss för sig i sitt OpenWrt-derivat FriendlyWrt."

Hur är ens det sista relevant om man väljer att köra standard Ubuntu 22.04 LTS? I det läger blir det varken mer eller mindre säkert än någon annan plattform körandes samma OS.

Det första är ett potentiell problem dock. Är det något jag tenderar ta bort på något som är en "server" är det hela grafik-stacken.

Dels finns det ingen anledning att ha den med, då den äter resurser + har bitter eftersmak av fall där just GPU-drivern försämrat realtidsegenskaper då de genererat relativt hög frekvens med interrupt bara genom att vara aktiv.

Men framförallt är moderna GPU-stackar stora, d.v.s. de har en stor potentiell attackyta som är helt onödig att ha med på en server som effektivast hanteras via SSH.

Vill gå till kernel.org kärna. Det jag ändå har kunnat konstatera med den custom-kernel som i nuläget finns är att den har hög tillförlitlighet och vad jag kan se perfekt funktionalitet av alla de HW-block jag testat så här långt (använder allt utom GPU och NPU, svårt att se poängen med NPU utanför mobiler då GPU-delen är snabbare men drar lite mer ström + NPU-delen bara verkar stödja inferens för INT4/INT8/INT16/FP16, d.v.s. ingen träning och ingen FP32 som är det jag nästan alltid använt här).

Men stödet finns tydligen om man vill köra NPUn

Vulkan-stödet verkar _inte_ fungera ihop med Ubuntu 22.04 i nuläget, däremot fungerar OpenGL ES och acceleration av "vanlig" desktop är tillräckligt bra för att utan problem driva runt systemet på en 4k skärm (websidor flyter "perfekt" när man scrollar).

Skalning 2:1 fungera också bra, 1:1 med 27" skärm blir väldigt plottrigt medan 2:1 är lite åt det stora hållet men fullt användbart. UI ser helt OK ut, inte MacOS nivå med "retina skärm" vad det gäller fontrendering, men väldigt nära Windows 10/11 på samma skärm (Windows är dock ett snabb bättre i.m.h.o)

Skulle nog gå att använda som daily-driver...

... men att det inte är ingen "M1-killer" märks så fort man drar igång VS Code och kompilerar lite... Att koda i VS Code är dock inga problem alls! Förra årets Advent of Code som jag körde i Go går hur bra som helst att kompilera, debugga och köra. Snart dags för årets AoC!!!

Har beställt en sådan här för att kunna ser vad enheten drar.

Klicka för mer information

Visa mer

Lär oavsett vara mindre än den NUC jag nu kör som "hemma-server", i7-8559U baserad. Den har OK "idle" effekt, 7-10 W, men peak-effekten är 70-80 W 😱

Andra verkar fått idle till 2-3 W, vilket är OK för en SBC, men horribelt ställt mot mikrokontrollers som t.ex. RPi Pico som tar ungefär 1/1000-del i "idle" (bra att tänka på om man köra sin IoT-enhet på batteri)

Tycker priset dragit iväg lite väl på NUCs + effekten blev helt galen. Både pris och effekt var OK så länge de körde med 2C/4T kretsar, senaste NUC:en jag testat är i3-1315U baserad som var helt OK men ändå klart dyrare än en Orange Pi 5 Plus när systemet har alla komponenter.

Ska testa att mäta power från väggen...

Man får ju högre "idle" om man mäter från väggen då PSUn drar en del. Men så här ser det ut i alla fall, första "toppen" är när man spelar YouTube video och den andra är när jag kör min Advent of Code 2022 (som i de tunga fallen använder alla kärnor).

Testade att köra denna disk-benchmark på NVMe, eMMC och SD-kort (SanDisK Ultra 32 GB)

NVMe (väldigt billig no-name på 512 GB)

     Category                  Test                      Result     
HDParm                    Disk Read                 1740.47 MB/s             
HDParm                    Cached Disk Read          1555.47 MB/s             
DD                        Disk Write                511 MB/s                 
FIO                       4k random read            65852 IOPS (263408 KB/s) 
FIO                       4k random write           30889 IOPS (123559 KB/s) 
IOZone                    4k read                   254443 KB/s              
IOZone                    4k write                  109772 KB/s              
IOZone                    4k random read            42075 KB/s               
IOZone                    4k random write           96228 KB/s               

                          Score: 25903

eMMC

     Category                  Test                      Result     
HDParm                    Disk Read                 253.20 MB/s              
HDParm                    Cached Disk Read          250.75 MB/s              
DD                        Disk Write                163 MB/s                 
FIO                       4k random read            9669 IOPS (38677 KB/s)   
FIO                       4k random write           10733 IOPS (42935 KB/s)  
IOZone                    4k read                   27193 KB/s               
IOZone                    4k write                  26437 KB/s               
IOZone                    4k random read            26588 KB/s               
IOZone                    4k random write           32545 KB/s               

                          Score: 7983

SD-card

     Category                  Test                      Result     
HDParm                    Disk Read                 63.06 MB/s               
HDParm                    Cached Disk Read          63.87 MB/s               
DD                        Disk Write                19.8 MB/s                
FIO                       4k random read            3940 IOPS (15762 KB/s)   
FIO                       4k random write           1011 IOPS (4046 KB/s)    
IOZone                    4k read                   11292 KB/s               
IOZone                    4k write                  3526 KB/s                
IOZone                    4k random read            9723 KB/s                
IOZone                    4k random write           3381 KB/s                

                          Score: 1336

Skulle säga att givet den testning jag gjort på de olika diskarna stämmer hyfsat väl med skillnaden i "4k random read/write" resultatet ovan.

D.v.s. SD-kort är "crap" jämfört med båda de andra. eMMC är långsammare, men ändå väsentligt mycket bättre jämfört med SD-kort.

Med NVMe/eMMC är det en riktigt bra strömsnål hemma-server.

Även om det skulle gå att använda denna som desktop i nödfall har den samma problem som alla enheter där prestanda per kärna inte är på en "bra" nivå: spelar ingen roll att det är 8-kärnor, man "känner" att det inte är lika responsivt som en modern desktop/laptop dator. Dessa har trots allt 2-3 gånger bättre enkeltrådprestanda än Cortex A76 @2,4 GHz (en sådan presterar i nivå med Skylake/Zen2 per cykel).

Verkar peak:a på 11-12 W, vilket är OK

Däremot har Orange Pi 5 (samma verkar gälla RPi 5) bedrövlig "idle" förbrukning, verkar som man rätt mycket ignorerat power-management.

Man kan tycka att de 3 W som den drar i "idle" är lite, vilket det är jämfört med t.ex. en stationär PC. Det kommer inte heller påverka elräkningen på ett märkbart sätt om den är på 24/7.

Är mer: det finns potential för något så mycket bättre givet att det trots allt är en plattform för mobiler egentligen. Och kanske ännu mer, den NUC med i3-1315U jag använt i en jobb-projekt låg på ~2 W i "idle", och den är rätt mycket snabbare (dock drog den ~40 W peak).

Testade att köra ett bygge av en privat Rust-projekt. Dels på alla kärnor, dels enbart på de 4 små Cortex A55 kärnorna. Testade också samma projekt på min RPi4 med SD-kort.

Tack vare NVMe-disken är OPi5:an något snabbare även med Cortex A55 kärnorna (dessa är 20-30 % snabbare än CPU i RPi3), tog då 4m29s att kompilera medan det tog 5m1s på RPi4. Användes alla kärnor på OPi5 klarades det hela av på 1m38s.

yt-dlp -f 401 "https://www.youtube.com/watch?v=7x5lqqji9ww" -o sample.mp4
ffmpeg -benchmark -hide_banner -i sample.mp4 -f null -
ffmpeg -version | grep FFmpeg

curl -OJ https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.1.tar....
tar xf linux-6.6.1.tar.xz
time -h tar -c -I 'zstd -4 -T0' -f linux-6.6.1.tar.zst linux-6.6.1
zstd --version

Aldrig använt yt-dlp innan, den version som ligger med i Ubuntu 22.04 fungerade inte, den misslyckades ladda ned videon och "gissade" att versionen var för gammal. Men det var ju bara ett Python-script, så fungerade att köra med versionen på github.

time ffmpeg -benchmark -hide_banner -i sample.mp4 -f null -
<lots of output...>
frame= 4547 fps= 66 q=-0.0 Lsize=N/A time=00:03:01.88 bitrate=N/A speed=2.64x    
video:2380kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=241.527s stime=4.394s rtime=68.795s
bench: maxrss=333848kB

real	1m8.905s
user	4m1.567s
sys	0m4.460s

----

$ ffmpeg -version | grep FFmpeg
ffmpeg version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2000-2021 the FFmpeg developers

orangepi@rock:~/test$ time tar -c -I 'zstd -4 -T0' -f linux-6.6.1.tar.zst linux-6.6.1

real	0m5.349s
user	0m25.315s
sys	0m5.735s
orangepi@rock:~/test$ ls -lh
total 336M
drwxrwxr-x 26 orangepi orangepi 4.0K Nov  8 11:56 linux-6.6.1
-rw-rw-r--  1 orangepi orangepi 134M Nov 18 21:42 linux-6.6.1.tar.xz
-rw-rw-r--  1 orangepi orangepi 202M Nov 18 22:18 linux-6.6.1.tar.zst

Det är ingen raket, men OK prestanda givet att den verkar max:a på runt 12 W (kompilering). I detta fall drog komprimeringen ca 10 W medan ffmpeg bench:en klarade sig på 9 W.

kernel.org stödet för RK3588 börjar nå bra nivå. För den som vill köra Ubuntu på den systemkretsen kan ni kika på detta projekt
https://github.com/Joshua-Riek/ubuntu-rockchip

Finns stöd både för att använda de två custom-kernels som används mest, men finns också stöd för att använda "main line kernels"!

Använder som sagt OPi5B Plus i skarpa projekt som använder nästan alla I/O-block i kretsen. Denna plattform har fungerat riktigt bra!!!

Sedan ett par månader tillbaka finns också vettig tillgång på 32 GB RAM versionen. Tyvärr tycker jag det ser ut som priset gått upp en del på dessa kort, hittar inte 16 GB RAM version med alla tillägg jag skaffade för ~2600 SEK, utan det är väsentligt dyrare