NicoD

The current status last I read seemed to me that people are currently testing and looking for a solution.  I think it's a regression introduced by newer kernel or something like that.  You can find more info in this other thread which is about desktop however there seems to be a lot of RK3399 specific discussion starting at the post I linked.
 
Best thing you could do at this point is familiarize yourself with the discussion / issue, perhaps try and modify dtb and other things if you are capable, if not just follow along and give additional testing when more advanced users eventually post their solutions.  Because the evidence becomes much stronger if testing has been done by multiple people to confirm results (instead of jut one person).
 
Also, if you don't own a UART yet, you probably should to get one (or more) on their way to you in the mail.  They are only couple bucks apiece, and IMO anyone who play with SBC should own at least one!
 
EDIT: NicoD advice a few posts up (use legacy kernel) or Pedro Lamas' may be best in this case.  I did not read it until after posting.  Understand that as a Mod I read almost everything that is posted, so I end up with shallow (therefore sometimes wrong) understanding on a wide variety of topics.  lol  Don't mind me, carry on.  Some of general ideas in my post still apply, however, so I leave those.  Cheers.

I only now see this post. 
Indeed as @TRS-80 said my favorite for desktop tasks is the NanoPi M4V2 with Armbian Bionic legacy and @JMCC his media script. Now also possible in Buster.
For me watching video, mostly Youtube is very important. And I've got a 4k display, so I rather have a higher display resolution than 1080p.
The RK3399 from the NanoPi M4V2 does 1440p without a problem. And it then plays 1080p video perfect with VPU acceleration. 

Its I/O is just amazing. 2x fast USB3 controllers for each 2 ports, left and right. (every 1 controller is faster/better than the only 1 controller on N2+)
Has PCIe GPIO's what fits an NVMe hat/SATA hat, USB3 hat.
I've got a 256GB NVMe on it. Doing initial boot from eMMC, and full boot from NVMe. I must say that the RockPi4 has a faster NVMe drive(4x PCIe vs 2x PCIe on M4V2), but I like the metal case from the M4V2 a lot more. And not the bandwith is most important using NVMe, but latency. And that's the same.
Also a big swap file of 8GB on NVMe so I never get out of memory. Works great, but does decrease the lifespan of an NVMe drive. I replace it every year just to be safe and then use the used NVMe as external USB3 device.

I also have an sd-card with a Armbian mainline focal image for playing games on it. I just need to push that sd-card in and reboot to get to my 2nd image. 

For a few months google account didn't work on the VPU accelerated Chromium on the RK3399. So then I used Vivaldi browser for watching Youtube. But that could only do 1080p video with 1080p display resolution.
So I switched my M4V2 with the Odroid N2+ for a while. That one is able to play 1080p video at 1440p display resolution. Tho not perfectly as the RK3399. Some dropped frames, some screen tearing.

I do like the extra CPU performance of the N2+. But in desktop tasks I rarely need a lot of CPU power. 
All I do is browsing, answering on this forum and on others, watching youtube, writing textfiles, downloading images and writing them to media, record audio, ...

All tasks that do not need much CPU. So RK3399 is more than powerful enough. 

If not for the media script from JMCC I'd take the Odroid N2+ before my M4V2. But having VPU driver is so nice that my N2+ is playing 2nd fidel.
Future wise the N2+ might become the better one if GPU and VPU drivers are availabe for it. It can do a lot with its CPU alone. 

Only for video editing and rendering I use my PC. And a few games that don't work on my M4V2. But these days even gaming on it is just awesome.
 
Good choice. Do know that the RockPi4 is a bit fidly to put together with the NVMe hat, and its heatsink is a little less potent. 
The NVMe then can go upwards of 1GB/s vs 750MB/s on the M4V2. 
Greetings.
 

You know, I take a lot of notes, but not always.  So I am not 100% sure of following, however if I am recalling correctly, in one of NicoD videos where he goes through all his boards, the Odroid N2+ he says is very powerful (maybe even the most powerful?). but limited on I/O.  And maybe that's what you were hinting to about USB, @lanefu?
 
And this is what I mean by "little gotchas."  Also I want to make the point that there probably is no clear "best" as it depends a lot on your application, etc.
 
Also just now looking up the above video to get URL I came across another video (which I don't think I watched yet) called Comparison NanoPi M4 - RockPi4 - Odroid N2 - Khadas VIM3 which is perhaps even more directly applicable to this conversation.

I am guessing you mean for "desktop" usage (many of us, including myself, primarily only use Armbian for "server/headless" usage).
 
@NicoD has some great video reviews on his YouTube channel, I want to say (if I am recalling correctly) his favorite right now for desktop usage is... NanoPi M4 V2(?) but check his channel to be sure (and check it anyway, lots of good info on there).
 
@lanefu was reporting really good results with a PineBook (Pro?) the other night in IRC, but that might be WIP/dev stuff, so not sure it's public/available yet or not.  But in general, a lot of work has been done lately on "desktop" branch and should be getting released Soon(TM).
 
Many of these boards are compelling, however the best advice I can probably give you is to do your homework, as there are potentially little gotchas with any particular board.  The more time you spend up front researching, the less hassle down the line.
 
A good starting point is usually always the Supported Devices List, but for "desktop" you are probably looking for one of the RK3399 based boards these days.  Until you know the board families by heart, the home page of forums makes a handy cross reference (note which boards are listed for which family sub-forums). 
 
Good luck, let us know how the search goes / what you pick, and don't be a stranger. 

Just tried focal nightly. https://minio.k-space.ee/armbian/dl/nanopim4/nightly/Armbian_21.02.0-trunk.8_Nanopim4_focal_current_5.9.12.img.xz
After installing the desktop it also crashed. Always the same crash. Black display, no flashing led. Dim led still on. 
I'll try an older image.

Update. Focal 5.8.6 is the same. Even with governor set to performance. 

I've just done the test with the NanoPi M4 with this image https://redirect.armbian.com/region/EU/nanopim4/Focal_current_desktop
And I can confirm the crashes. Black screen, no more blinking light, only the dim LED still on.
I tried with performance governor and again had it. 

3 x in less than half an hour. 
So this doesn't seem the same issue as before. I do suspect it's a kernel issue.
I did have simular crashes before, and that then was fixed by putting governor to performance. Never again had a crash on that (M4V2 with Armbian Reforged V1)
I'll order a friendlyElec ttl adapter. I blew up mine on another device. That's what happens when they all use a different pinout g.d.  

If anyone has some debug info. Please share. 
I'll try a debian image and see if it's the same. 

Hi all.
I've just finished a new video where I review an Amazon AWS Graviton2 arm64 server.
This is a monster with 64 high-performance N1 cores.
It isn't clocked that high at 2.5Ghz, but it performs amazing for that clockspeed.
Here is my video.

Here all the info I've gathered.
 
AWS Server 32-cores 128GB ------------------------- NEOVERSE N1 64-core AWS Graviton2 ARMv8.2 aarch64 Arm’s Neoverse N1 cores -> based on A76 -> almost identical to Arm’s 64-core reference N1 platform -> CPU cores are clocked a bit lower 2.5GHz and only 32MB instead of 64MB of L3 cache Max speed 2500Mhz 8-channel DDR-3200 128GB ram 64 PCIe4 lanes TSMC’s 7nm process node ~1W per core at the 2.5GHz frequency between 80W as a low estimate to around 110W estimation. This info is not disclosed by AWS 7z single core Ampere 32-core : 2763 AWS 32-core : 3393 Threadripper 3990x : 4545 7z quad core : Raspberry Pi 4 @ 1.5Ghz : 6307 Odroid N2+ 4xA73@2.4Ghz : 9900 Ampere 32-core : 11145 AWS 32-core : 13733 Threadripper 3990x : 18060 7z all cores : Ampere 32-core : 85975 AWS 32-core : 110628 Threadripper 3990x : 391809 433702 OC Blender BMW CPU Odroid N2+ : 30m Ampere 32-core : 8m27s AWS Server 32-core : 2m08s ThreadRipper 3990x : 30s Blender Barber shop CPU AWS Server 32-core : 8m28s Threadripper 3990x : 2m18s79 CPU Miner Odroid N2+ : 14 Ampere 32-core : 87 AWS Server 32-core : 154.20 ThreadRipper 3990x : 1310 SBC bench : http://ix.io/2FrG Internet speed test between 1500 Mbit/s and 2000 Mbit/s both up- and download (up to 250MB/s) I had 32-cores of the 64-cores. It is expected to perform a bit worse per core with 64-cores vs 32-cores since less cache available per core. There's a newer Ampere 80-core N1 at 3Ghz SoC. https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/6 Thank you to @lanefu for giving me access to this.

Hello all, 
This Linux OS is based on Armbian_20.11_Tinkerboard_bullseye_current_5.8.18 image. I have created this OS to be able to watch Netflix via a browser. This OS is compatible with TB & TB/s.
Key features:
    • OS: Debian 11 bullseye
    • Kernel: armv7l Linux 5.8.18-rockchip
    • CPU: ARMv7 rev 1 (v7l) @ 4x 1.8GHz
    • GPU: Mali T760 (Panfrost driver, OpenGL 2.1)
    • Browser: vivaldi-stable_3.4.2066.106-1_armhf (widevine-flash)
This Linux OS image is provided AS IS with NO WARRANTY and NO END USER SUPPORT.
You can now download the VinVin-OS version 20201130, here ...
Share code: ASUSMYFKLUXMY
VinVin-OS default username is “vinvin”, password is “vin=20”
Tips:
Use a fast Micro SD card,  minimum 3 amps power supply and a case which includes a cooling fan to avoid system crashing due to overheating. 
Getting Started:
Write the zip compressed image with Etcher and (TB) insert SD card into a slot or (TB/s) use a USB cable to connect to your computer.
Power the board: 
    • TB
      (First) boot takes up to two to minutes.
      (Second) boot takes up to one minute.
      Login with the user id: vinvin
    • TB/s
      Remove the USB cable connected to your computer.
      (First) boot takes up to one to minute.
      Login with the user id: vinvin.
      Also important: resize your file system with, for example, GParted to the full capacity.
Enjoy :-)

Hi all.
I've just finished a new video where I review an Amazon AWS Graviton2 arm64 server.
This is a monster with 64 high-performance N1 cores.
It isn't clocked that high at 2.5Ghz, but it performs amazing for that clockspeed.
Here is my video.

Here all the info I've gathered.
 
AWS Server 32-cores 128GB ------------------------- NEOVERSE N1 64-core AWS Graviton2 ARMv8.2 aarch64 Arm’s Neoverse N1 cores -> based on A76 -> almost identical to Arm’s 64-core reference N1 platform -> CPU cores are clocked a bit lower 2.5GHz and only 32MB instead of 64MB of L3 cache Max speed 2500Mhz 8-channel DDR-3200 128GB ram 64 PCIe4 lanes TSMC’s 7nm process node ~1W per core at the 2.5GHz frequency between 80W as a low estimate to around 110W estimation. This info is not disclosed by AWS 7z single core Ampere 32-core : 2763 AWS 32-core : 3393 Threadripper 3990x : 4545 7z quad core : Raspberry Pi 4 @ 1.5Ghz : 6307 Odroid N2+ 4xA73@2.4Ghz : 9900 Ampere 32-core : 11145 AWS 32-core : 13733 Threadripper 3990x : 18060 7z all cores : Ampere 32-core : 85975 AWS 32-core : 110628 Threadripper 3990x : 391809 433702 OC Blender BMW CPU Odroid N2+ : 30m Ampere 32-core : 8m27s AWS Server 32-core : 2m08s ThreadRipper 3990x : 30s Blender Barber shop CPU AWS Server 32-core : 8m28s Threadripper 3990x : 2m18s79 CPU Miner Odroid N2+ : 14 Ampere 32-core : 87 AWS Server 32-core : 154.20 ThreadRipper 3990x : 1310 SBC bench : http://ix.io/2FrG Internet speed test between 1500 Mbit/s and 2000 Mbit/s both up- and download (up to 250MB/s) I had 32-cores of the 64-cores. It is expected to perform a bit worse per core with 64-cores vs 32-cores since less cache available per core. There's a newer Ampere 80-core N1 at 3Ghz SoC. https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/6 Thank you to @lanefu for giving me access to this.

Changing the x11 driver from fb to modesetting will let xrandr deal with resolutions easily.
 
1440p is technically missing from the DRM kernel driver

Release info:
https://www.armbian.com/newsflash/armbian-20-11-tamandua/
 
Downloads:
https://www.armbian.com/download/
 

It most of the times means a replacement has been installed and this package isn't needed anymore. You'll often have that on a fresh install after doing update/upgrade, or from installing and removing many programs.
So you get packages that aren't used by anything. So it gives you the message it may be removed with autoremove.
If everything works, don't care about it.

Donations reached the goal. 
To everybody who helped. Big thank you. This will be well used. I've seen the server and it's a monster.

Next goal maybe different desktop implementations, with GPU and maybe VPU if possible. Who could we hire? What cost?
 
But before that there's already enough new things coming soon. And the server will be in good use or that.

From the whole team. Thank you.
NicoD

It's mainline Focal 5.8 with panfrost. @Salvador Liébana did build the image. I'm just a messenger spreading the word.
His team is behind TwisterOS for the Raspberry Pi. They've got tons of portable apps to make life easy for noobs to experienced user. Will be an amzazig addition to armbian.
This is a preview of what's to come for more SBCs. Certainly when panfrost is ready for Odroid N2/N2+

They've got a whole club on Discord for every project of the group. A lot happens there. 
@Salvador Liébana Is it possible to write a build script for your image that makes use of ours.(write down all yours steps) Then it will take a big load of your back in the long time.
You then always are along with armbian changes. And maybe later we can merge this to te desktop project. Then you can build it all without having to set up something manually. I hate to see too much forks. People better work all together to improve that what we build. Cheers.

I am also very happy that we manage to cover this purchase together in so little no time. This was also a live test of our crowdfunding system. It works surprisingly well and we will certainly use it for our other projects in the future.
 
As you already noticed, server was already purchased and is currently under evaluation. This upcoming release will already be build on it. We already built few nightly builds and speed bump from aging dual xeon is hard to describe  
 
Thank you all for showing us support!
 

Paypal donations and forum donations are not synchronised even paypal user would be the same  Sorting those things is yet another project, but at the project location it will remain at sight who supported server purchase. 

Donations reached the goal. 
To everybody who helped. Big thank you. This will be well used. I've seen the server and it's a monster.

Next goal maybe different desktop implementations, with GPU and maybe VPU if possible. Who could we hire? What cost?
 
But before that there's already enough new things coming soon. And the server will be in good use or that.

From the whole team. Thank you.
NicoD

Here my instruction video on how to install Armbian Reforged and set it up. 
 

Armbian Reforged has been released. Here my video on how to install it and set it up on your RK3399 device.

Here again the download link : https://drive.google.com/file/d/1gQtgWz2pH2TX9Qs_bcDU9zn7w4edfcVf/view?fbclid=IwAR0SRSC8M_1_qm825n4Bd7bqjLmO30qTpFo73qQQga-TC_LRuc2BVFcGzKU
Enjoy

thanks for the post nico! well, with rk3399 across all.my team we will.make some severe changes on this armbian build. we will move to xfce abd rebrand the build as TwisterOS armbian. the idea would be to start with RK3399, then S922x, not only N2 bc they are competitors arising and also bc you know I don't like N2. cheers! 

They probably don't have the knowledge on how to keep their build up to date and improve on it.
Building a basic image that boots vs a well working image with most features working. That's a big difference.

They've always been the worst student in the class when it comes to software support. While selling like 2nd most I believe after Raspberry.
 
Having such bad reputation software wise did bring Armbian to a higher level.
So you might say we need them as much as they need us.

I don't know what that is with Xunlong and Sinovoip. They seem to have good board designer. But the worst sales and software teams.
http://www.orangepi.org/
Orange Pi™ is a trademark of the Shenzhen Xunlong Software CO They protect their trademarks. Now wouldn't you think a sofware company could write, hmm, maybe software... for their own products???

I do like that BPi/Sinovoip now has found its own niche in the marked.
But no other company has spammed my YT channel and mail boxes as much. While wanting to make free advertisement on my channel, but not wanting to support me with one of their products. I'll never review BPi again. Ungrateful.
http://www.banana-pi.org/
Our engineering team is comprised of both experienced and innovative engineers to design and produce the best PCB possible. Our parent company SinoVoip and Foxconn has extensive connections with various large SoC and chipset manufactures to bring you the best technologies available. Our warm and professional service team will communicate with you and offer help and assistance throughout your project with us. Those first 2 lines I could agree upon. The last one....

Hi all.
I wanted to put some light on the fact that you now can run some x86 Windows and Linux programs and games on the RK3399 with Box86.

I have a topic about it in my lonely "Gaming on ARM club"
I've made a preview video about it last week.
I've done some further tests. It is just amazing. Plays way better than the RPi4. Tho not yet as many things work.
@Salvador Liébana made prebuild images with Box86 preinstalled, and with many other emulators.

You can download it here : https://drive.google.com/file/d/1gQtgWz2pH2TX9Qs_bcDU9zn7w4edfcVf/view?fbclid=IwAR0SRSC8M_1_qm825n4Bd7bqjLmO30qTpFo73qQQga-TC_LRuc2BVFcGzKU

Has been tested on many RK3399 devices.

After burning on the SD-card/eMMC. Set /boot/armbianEnv.txt to point to the correct .dtb file.
On first boot change the user password and the root password. Default password is 123456
 
passwd Type default password 123456 and 2x your new password sudo passwd Type user password and 2x new root password Update and upgrade
sudo apt update sudo apt upgrade Then update Box86
Applications -> Emulators -> Update Box86

For HDMI sound you might need to disable the other audio device since it always defaults to it on reboot.
Volume control -> Configuration -> disable the one that's not HDMI audio

With M4/M4V2 you might need to set the governor to performance. Otherwise it is unstable. Be sure to use heatsink + fan to keep it cool. Or clock it lower with big cores for lower temperatures.
Best to use "sudo armbian-config", you can also set your locales with it.
Or set manually by changing /etc/default/cpufrequtils

To start a windows program or game
wine program.exe For Linux x86 something like
wine start.sh
You can switch Windows versions if something doesn't work. For older games/programs for example Windows 98, newer XP...
To do this go to Applications -> Emulators -> Wine Configuration

You can also mount virtual drives there.

Not only is this amazing to be able to play your favorite old games n an RK3399.
It can also be a way to replace old x86 machines running legacy x86 software.
So this really is "a game changer" for ARM.

Now this works I can't wait to see this working on the Odroid N2/N2+. But for that we'll have to be a bit more patient.

Cheers.

Thanks so much for posting your videos.  I recently picked up a number of Rock64 1-GB SBCs off Amazon for $8-$15 (they were used as part of a security monitoring platform that seems to be dumping inventory).  I'm just getting started building simple home sensor and monitoring projects.  Your Armbian tutorials and insights have been extremely helpful.  

Hi all.
@Werner and I have been working on an instruction video on how to install Armbian headless on your SBC.
Here it is.
Greetings,
NicoD

I got my hands on a "Set 9" Orange Pi Lite + GC2035 camera a while back and I've finally been able to put together a self-contained object detection device using Tensorflow, without sending any image data outside for processing.

Basically, its a python Flask application that captures frames from the camera using a GStreamer pipeline. It runs them through a Tensorflow object detection model and spits out the same frame with extra metadata about objects it found, and renders a box around them. Using all four cores of the H2 it can do about 2-3 fps. The app keeps track of the count of all object types it has seen and exposes the metrics in prometheus format, for easy creation of graphs of what it sees over time with Grafana
 


I'll explain some of the more interesting aspects of how I got this to work here in case anyone else wants to try to get some use out of this very inexpensive hardware, and I am grateful to the many posts on this forum that helped me along the way!

Use a 3.4 kernel with custom GC2035 driver

Don't bother with anything new - the GC2035 was hopeless on any newer builds of Armbian I tried. The driver available at https://github.com/avafinger/gc2035.git provided far better image quality. After installing the updated GC2035, I run the following to get the camera up and running:
 
sudo sunxi-pio -m "PG11<1><0><1><1>" sudo modprobe gc2035 hres=1 sudo modprobe vfe_v4l2  
Install Tensorflow lite runtime
 
Google provides a tensorflow runtime as a binary wheel built for python 3.5 armv7. When pip installing, expect it to take 20 minutes or so as it will need to compile numpy (the apt repo version isn't recent enough)
 
wget https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl sudo -H pip3 install tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl  

Build opencv for python 3.5 bindings

This was something I tried everything I could to avoid, but I just could not get the colour conversion from the YUV format of the GC2035 to an RGB image using anything else I found online, so I was dependent on a single color-conversion utility function.
 
To build the 3.4.12 version for use with python (grab lunch - takes about 1.5 hours :-O )

 
cmake -DCMAKE_INSTALL_PREFIX=/home/atomic/local -DSOFTFP=ON \ -DBUILD_TESTS=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_opencv_python2=0 \ -D BUILD_opencv_python3=1 -D WITH_GSTREAMER=ON \ -D PYTHON3_INCLUDE_PATH=/usr/include/python3.5 .. make -j 4 make install # Check that ~/local/lib/python3.5/dist-packages should now have the cv2 shlib export PYTHONPATH=/home/atomic/local/lib/python3.5/dist-packages  
 
Build gstreamer plugin for Cedar H264 encoder
 
This is required to get a working gstreamer pipeline for the video feed:
git clone https://github.com/gtalusan/gst-plugin-cedar ./autogen.sh sudo make install # When trying against a pipc I had to copy into .local to get gstreamer to recognise it cp /usr/local/lib/gstreamer-1.0/libgst* ~/.local/share/gstreamer-1.0/plugins/ # Confirm that plugin is installed: gst-inspect-1.0 cedar_h264enc  
Processing images
 
The full app source is on github, but the more interesting parts that took me some time to figure out were about getting python to cooperate with gstreamer:
 
Frames from the camera arrive to python at the end of the pipeline as an appsink. The Gstreamer pipeline I configured via python was:
 
src = Gst.ElementFactory.make("v4l2src") src.set_property("device", "/dev/video0") src.set_property("do-timestamp", 1) filt = Gst.ElementFactory.make("capsfilter") filt.set_property("caps", Gst.caps_from_string("video/x-raw,format=NV12,width=800,height=600,framerate=12/1")) p1 = Gst.ElementFactory.make("cedar_h264enc") p2 = Gst.ElementFactory.make("h264parse") p3 = Gst.ElementFactory.make("rtph264pay") p3.set_property("config-interval", 1) p3.set_property("pt", 96) p4 = Gst.ElementFactory.make("rtph264depay") p5 = Gst.ElementFactory.make("avdec_h264") sink = Gst.ElementFactory.make("appsink", "sink") pipeline_elements = [src, filt, p1, p2, p3, p4, p5, sink] sink.set_property("max-buffers", 10) sink.set_property('emit-signals', True) sink.set_property('sync', False) sink.connect("new-sample", on_buffer, sink)
This pipeline definition causes a callback on_buffer to be called every time a frame is emitted from the camera:

 
def on_buffer(sink: GstApp.AppSink, data: typing.Any) -> Gst.FlowReturn: # Sample will be a 800x900 byte array in a very frustrating YUV420 format sample = sink.emit("pull-sample") # Gst.Sample ... conversion to numpy array # rgb is now in a format that Pillow can easily work with # These two calls are what you compiled opencv for 1.5 hours for :-D rgb = cv2.cvtColor(img_arr, cv2.COLOR_YUV2BGR_I420) rgb = cv2.cvtColor(rgb, cv2.COLOR_BGR2RGB)
Once you have a nice pillow RGB image, it's easy to pass this into a Tensorflow model, and there is tons of material on the web for how you can do things like that. For fast but not so accurate detection, I used the ssdlite_mobilenet_v2_coco pretrained model, which can handle about 0.5 frames per second per core of the H2 Allwinner CPU.
 
There are some problems I still have to work out. Occasionally the video stream stalls and I haven't figured out how to recover from this without restarting the app completely. The way frame data is passed around tensorflow worker processes is probably not ideal and needs to be cleaned up, but it does allow me to get much better throughput using all four cores.
 
For more details, including a detailed build script, the full source is here:
https://github.com/atomic77/opilite-object-detect

Okay, another use case. This one will bring some surprises.
 
Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
 
In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
 
First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
$ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
 
Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
$ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
 
Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.