NicoD

I noticed problems with zram but then it would need to wait few more days. It is strange why zram doesn't work oob while it does work on other boards by using the same build system. I checked kernel config, which seems fine and I will check and try to fix this next time, perhaps someone else will. It will be good to add a mainline kernel, no matter how good or bad support is there.
 
Advertisement + change log is WIP. Many more things has been changed/improved.
 
... but family duties cut them short  I hope to catch this up tomorrow.

5.1.y images are out, but untested.
https://dl.armbian.com/orangepi3/nightly/

Good!
https://github.com/armbian/build/commit/2bd7f8efbd165e9e3a0db1cfb9d18dad1432cc4d

Download: https://www.armbian.com/odroid-n2/

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

Official build is coming later on http://ix.io/1Ivj

Added test images 5.84 to the server with the Buster and Disco.
 
 
For vim1 VIM2 x96max Vega s95 etc models, there is remote support in all 5.84 images.

Thanks to @NicoD my sound problems are fixed, still have issues with bluetooth but that is for next weekend!

Hats off to Amazon I told them the board had died ( via their online chat ) and they refunded me in full and presumably dealt with the seller

Drivers are in development but it won't be fast.
 
 

I prepared (last weekend? - don't remember anymore) a first step towards a merge of rk3399 (currently nanopi boards) with rockchip64 (more or less all the rest) so that both can be covered fully under one boardfamily (rockchip64). Patches are adjusted and dts support for nanopis in ayufans kernel is done as well.
 
https://github.com/chwe17/build/tree/rk3399merge
 
I would happily give it into 'someone others' hands cause time in the next month might be really rare.
 
Basically it needs testing on the boards which got newly merged into rockchip64 (don't own any nanopi *4 board so I can't test it). And probably a small helper script to adjust the 'living' boards config so that they'll get updates in the future from their new boardfamily (this might be tricky and needs for sure a lot of testing, to ensure we don't break them)
 
Would be nice if someone can review it and test it on the nanopis

Anyways - would be fun to see a cage match between Nano Pi M4 vs. Odroid N2 vs nVidia Jetson Nano...
 
Traditional benchmarks as well as some VPU/GPU work - as RK3399 has Mali T864 vs. Amlogic with G52 vs. nVidia with Maxwell
 
Since all are supported in some way with Ubuntu 18.04LTS with Vendor supplied BSP's...

Thanks everyone. Bummer about having to remove it each time to change eMMC... And, am left with 4 nuts that I don't know what to do with but it is all put together, thanks @pkfox for the instructions and pictures @Da Alchemist for pictures and more ideas and of course as always for @NicoD without which I would not be moving forward very quickly with my SBC adventures!
 

Would be interesting to see how it competes with Jetson Nano with a good power supply...
 
Jetson has a fairly large heatsink, but it's generally cool to the touch right now with 2.5A over MicroUSB - 5 amp Power Supply is scheduled to arrive tomorrow, and then we can turn up the Jetson clocks and see what it can really do...
 
(Jetson Nano under full load can easily consume 20w when doing GPU compute tasks - not too much different than Google Coral)

FriendlyElec will release a new ROM, it can use dual/single MIPI camera, or USB UVC camera on Ubuntu Desktop, about 1-2 weeek.

I can get in touch with the odroid guys to change this situation if you want.

Hi all.
I've made a new review video about the Odroid N2.
It an amzaing beast of an SBC. But it ain't perfect for everyone.
Geetings, NicoD.
https://www.youtube.com/watch?v=dylc0GjeyM8

@balbes150 Tanks for the great image.
 

Via hackaday

Sent from my Pixel using Tapatalk

@NicoD; Thanks for all the info. I think I made the decision to go for the M4. 

Hi. You seem to have done your homework well. Those are indeed all the most powerful boards.
But other needs are important too. Like how much ram do you need, is power efficiency an issue? Does your task scale well over multiple cores? What voltage do you want it to use?
 
For example when ram isn't that important you could go for the smaller NanoPi NEO4 with the same Soc as the M4, but only 1GB ram. But good cooling is needed with that.
The NEO3 is even a bit more powerful with 8 cores of 1.4Ghz. But single core performance is a lot worse. Power consumption is then again better than the RK3399's. There's also the NanoPC T3+ with that SoC, but a bigger footprint and 2GB ram.
The Odroid N2 is the most powerful of all in CPU power. It does need a higher voltage than the others. It's very new and not super stable yet. But I've tried a new Armbian image today on it and it seems to be better than anything else for it. Too early to know.

The H6's are pretty powerful for a quad-core sbc. Also very new and software isn't ready. It needs sufficient cooling to get the most out of it, but it's doable. I see the PineH64 model b becomming a good board. but that has 2.4Ghz wifi vs 5Ghz wifi of the Orange Pi3.

I've got most of those boards. And the overall best board is the NanoPi M4 for me. Very fast, stable, good Armbian software, great connectivity. It does consume the most of all when maxed out.
Or the Odroid XU4 is also a very powerful board, octa-core. But hard to cool.
I hope that helps.

For some tasks the T3+ is faster. But only tasks that scale well over multiple cores like Blender. Most applications don't do that well and prefere a better single core performance. I indeed menth the Fire3. Too many names. That should be the most powerful for a low price, but indeed not much usb ports.

You mentioned the Atomic Pi. Could be a valible option. It's cheap, x86 and very fast for that price.

I once made a list of benchmarks of most of my sbc's. It is confusing since there ain't no perfect benchmark tools(and I wanted to show discrepencies). But it gives an idea of what you can expect.
7 zip, single core scores are important(small core-big core). Multi-core doesn't give exact results(not 100% se). Igrnore gtkperf, gimp and sysbench. I only used that to show it was useless.
The H3 performs a bit worse than the Rock64 at 1.3Ghz. I should have added one, I've got enough of them but don't like them much except for light data server.

You can  perform the 7-zip tests yourself on the H3. Install p7zip-full, then
7z b   (multicore test)
sudo taskset c 0 7z b (single core)
I only use decompression numbers since I do not want to mix compression with decompression and get a number of nothing.

I also still think the M4 is the best choice. The only sbc that never had issues, and I use it daily.
 

The output now shows that gl4es wrapper and mali drivers are being used. Now, since it is just a wrapper, it's possible that some functions are not implemented, or do not exist at all in the GLES 2 API.
 
Another option to play that game could be using this fork for GLES: https://github.com/meveric/extremetuxracer

I thought this was fixed(haven't checked in a while). You can add the resolution manually.
Here an example for 1080p. Change what's needed for your monitor.
sudo cvt 1920 1080 60 Then you get something like : # 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync Everything after modeline you need to copy and past it behind : sudo xrandr -- newmod e Example : sudo xrandr -- newmod e "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync Then : sudo xrandr --addmode HDMI-1 1920x10 80_60.00 sudo xrandr --output HDMI-1 --mode 1920x1080_60.00  

That's the reason. It updates to new libEGL and breaks the symlink to libmali. If for some reason the new lib is installed you have to manually re-create the symlinks, or just don't update.

@JMCC  Hi. I'm trying to make some Linux games to work well on the NanoPi M4. 
I've tried that tool `glrun`. But I'm not having the best results. I get the message OpenGL: OpenGL version is too old!
So I'm trying supertuxkart. Here's the output without glrun
[verbose ] translation: Env var LANGUAGE = 'en_US.UTF-8'. [verbose ] translation: Language 'English (United States)'. Adding language fallback en Irrlicht Engine version 1.8.0 Linux 4.4.178-rk3399 #2 SMP Tue Apr 9 22:41:35 CEST 2019 aarch64 libGL error: unable to load driver: rockchip_dri.so libGL error: driver pointer missing libGL error: failed to load driver: rockchip [info ] IrrDriver: OpenGL version: 3.3 [info ] IrrDriver: OpenGL vendor: VMware, Inc. [info ] IrrDriver: OpenGL renderer: llvmpipe (LLVM 7.0, 128 bits) [info ] IrrDriver: OpenGL version string: 3.3 (Core Profile) Mesa 18.2.8 [info ] GLDriver: AMD Vertex Shader Layer Present [info ] GLDriver: ARB Buffer Storage Present [info ] GLDriver: ARB Base Instance Present [info ] GLDriver: ARB Draw Indirect Present [info ] GLDriver: ARB Arrays of Arrays Present [info ] GLDriver: ARB Texture Storage Present [info ] GLDriver: ARB Texture View Present [info ] GLDriver: ARB Multi Draw Indirect Present [info ] GLDriver: EXT Texture Compression S3TC Present [info ] GLDriver: ARB Texture Compression RGTC Present [info ] GLDriver: ARB Uniform Buffer Object Present [info ] GLDriver: ARB Explicit Attrib Location Present [info ] GLDriver: Geometry Shaders Present [info ] GLDriver: ARB Texture Swizzle Present [info ] GLDriver: ARB Pixel Buffer Object Present [info ] GLDriver: ARB framebuffer sRGB Present [info ] ShaderBasedRenderer: Preloading shaders... [info ] SharedGPUObjects: Hardware Skinning enabled, method: TBO, max bones: 1024 Most important will be : libGL error: unable to load driver: rockchip_dri.so

Here's the output when using glrun supertuxkart
[verbose ] translation: Env var LANGUAGE = 'en_US.UTF-8'. [verbose ] translation: Language 'English (United States)'. Adding language fallback en Irrlicht Engine version 1.8.0 Linux 4.4.178-rk3399 #2 SMP Tue Apr 9 22:41:35 CEST 2019 aarch64 [info ] IrrDriver: OpenGL version: 2.0 [info ] IrrDriver: OpenGL vendor: ptitSeb [info ] IrrDriver: OpenGL renderer: GL4ES wrapper [info ] IrrDriver: OpenGL version string: 2.0 gl4es wrapper 1.1.1 [warn ] Graphics: Can not find version for '2.0 gl4es wrapper 1.1.1' 'GL4ES wrapper' - ignored. [warn ] irr_driver: Using the fixed pipeline (old GPU, or shaders disabled in options) [info ] HTTPRequest: Downloading http://addons.supertuxkart.net/dl/xml/news.xml [info ] addons: Using cached addons.xml. [info ] HTTPRequest: Downloading http://addons.supertuxkart.net/dl/images/32999604857af930517f49.png [info ] GrandPrixManager: Loading Grand Prix files from /usr/share/games/supertuxkart/data/grandprix/ [info ] GrandPrixManager: Loading Grand Prix files from /home/nicod/.local/share/supertuxkart/grandprix/ [warn ] OpenGL: OpenGL version is too old! Here's what it looks like with glrun, everything's scrabled.
 


Next month I'll make a video about the RK3399's with desktop use with your media script. And I'd like to be able to play extremetuxracer and supertuxkart if possible. 
Cheers.

Right, I forgot to mention that one With the RK3399's the most powerful one.