pask

If you join as a maintainer, we could afford to provide yet another optimized desktop, but until then ... one optimised desktop is already hard to maintain. For a generic MATE install proceed this way:

https://www.google.com/?q=MATE+desktop+debian+install
 
Most if not all recipes should work, but there will be no HW acceleration or other "lousy" optimizations. I agree it's not the most beautiful and advanced, but a choice within necessary compromise due to limited resources. Beauty is subjective so it's pretty pointless to discuss which is nicer. IMO both are lousy.

Great job, @piter75!
 
"current" buster desktop works well for me. The debug ttl console too.
Performance are much better than default friendlyelec 4.4.y kernel's ones, although not overall better than those of the ddr3 version 1 nanopi m4 (see https://www.cnx-software.com/2019/10/28/nanopi-m4v2-kit-review-part-2-friendlycore-desktop/):
Memory performance (big.LITTLE cores measured individually):
memcpy: 1880.5 MB/s (0.6%)
memset: 8430.7 MB/s (0.6%)
memcpy: 3729.4 MB/s
memset: 8492.3 MB/s (1.0%)
Complete sbc-bech results here: http://ix.io/23eC
 
Both sd card read and write speeds are good: 70MB/s with a sandisk 32GB extreme pro card
 
Stability also looks good, but requires more time to be tested.
As soon I'll be able to run some panfrost benchmarks, I'll update. By the way, desktop experience is smooth and stable and sound works too, but lack of acceleration is limiting when watching videos, although the 5.4 kernel improved speed over the 4.4.y is evident.
 
The only "small" issue I have found so far, is that boot is a bit slow. And for about 30 seconds I do not see any activity, neither on the serial console, nor on hdmi. Perhaps because of  "printk: bootconsole [uart8250] disabled" ?
 
I'm going to do some usb storage tests, before considering this board ready for replacing the raspberry pi4 I use at the moment as my home nextcloud server.

No, you do NOT know when you're finished firing up your next round of passive benchmarking tests spitting out some numbers. You need to know what's going on to generate answers to the question 'why is A faster than B' and also 'what is the limiter on A and why can't A not be twice as fast'? You missed this change and attributed faster RockPi scores to DDR4 vs. DDR3 memory while in reality you compared old Armbian kernel config with newer one. This whole passive benchmarking approach (and IMO 'technical' Youtube videos in general) always only contributes to confusion and generates zero insights.
 
The general rule of passive benchmarking and what in fact happened here is: you benchmark A, but actually measure B, and conclude you've measured C (what's needed instead is Active Benchmarking)
 
What matters are insights, settings and software. And this not only applies to RK3399 but to N2/S922X too of course. So with your use case that utilizes all CPU cores in parallel you surely should go with S922X (since being definitely faster than RK3399 with everything that's multi-threaded), then use a kernel with CONFIG_HZ=100 and an optimized software stack. With Gentoo for example, most recent GCC, optimal/aggressive compiler flags for the A53/A73 combo and a CONFIG_HZ=100 kernel on the N2 your Blender job might finish in less than 40 minutes (maybe just 20 or even less if a programmer equipped with knowledge starts to look into Blender code and adds NEON optimizations to the performance critical code parts -- see here for a great example of Active Benchmarking and adding NEON optimizations on ARM to a software that utilizes SIMD Extensions only on x86 so far just like SSE2 optimized Blender does)
 
The price you'll pay is a few weeks of your life needed to become a Linux expert since there's nothing ready. Choosing Armbian is usually a matter of convenience but if you want software that performs as fast as possible it's a problematic choice since the software stack is not meant to be performant but to be compatible and stable (funny joke since Armbian's own approach with kernel/bootloader updates is the opposite). The two distro variants Armbian provides are
Ubuntu also known as 'everything outdated' Debian also known as 'everything outdated as hell' (there are areas where Armbian is in fact faster than other Ubuntu/Debian based images or distros using a more modern software stack like Gentoo or Fedora but this is due to what separates Armbian from the stock Debian/Ubuntu stuff: settings like CPU/IRQ affinity, thermal/DVFS tuning, zram, log2ram and such stuff. But two guys who mostly took care of this contributed nothing to Armbian for a longer time now and no idea how Armbian evolves here in the future. On EoL platforms like Allwinner H5 IRQ affinity is already broken but nobody cares)
 

There is one thing that comes to my mind... I have some features disabled in my config-minimal.conf.
I have AUFS disabled for sure, which is irrelevant. Will let you know about the rest later.
 
Dev kernel should have a sound card working by now 😉

That would be pretty interesting to debug, I've always been horrified at the "division of labor" between the two, sometimes U-boot configures some hardware and the kernel just assumes it's there, sometimes not, no standard... 
 
Drive levels are a possibility, perhaps the 4.4 kernel is assuming U-boot configured the I/O levels, or maybe a regulator is being set up in FriendlyElec's u-boot that isn't in mainline.
 
All I know for sure is I want anything with RK3399 in it to behave logically and consistently, which seems too much to ask most of the time...

Hello Nico,
your reviews go so deep and are so well made that I learn something from you everytime I watch one of them.
 
Thanks

Hi all.
I've finished my review video of the NanoPi M4V2. Here is it.

Special thanks to @JMCC @balbes150 @pask and @martinayotte.
Cheers all.

Modern kernel code - when you use armbian-config way of installing kernel sources (on Debian Buster or Ubuntu Bionic based Armbian) - you only need to go to the source directory and run "make zImage|Image" and you are done. In some case some wireless drivers might have issues with compilers ... but don't take this feature as granted yet.

He my video about what's new on the Rock Pi 4, and mainline Armbian + Panfrost
 

Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
 
Prerequisites:
We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
on debian a like systems:
sudo apt-get install picocom from arch community repo:
https://www.archlinux.org/packages/community/x86_64/picocom/
 
on fedora systems:
yum install picocom on Mac OS X:
brew install picocom on Widows we use PuTTY:
 
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
 
UART USB Adapter:
There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
Linux:
[256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
Windows:
for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8)
Something like the picture in USB Gadget Mode part of the tutorial should show up)
 
Armbians default settings are (expect some RK devices):
For Picocom:
picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

 
OS X:
TBD
should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&t=841 as an example with minicom.
 
Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
 
USB Gadget Mode
Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
 
install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
For Windows:
run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&q=find+arduino+port+windows+10&sourceid=opera&ie=UTF-8&oe=UTF-8):
(even the tutorial is for arduinos, it should be similar for every 'COM device')
 
Currently boards with USB gadget mode:
bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
The silly approach
For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
For those loving text more than videos:
SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
 

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

 
 

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

I'm using latest "picocom" which is able to manage 1500000 baud under Linux without issues...

Installer always use u-boot from package. If you haven't update that .... works as expected. 

I had to apply the patch from pask on top of the emmc after using "nand-sata-install" to get it to boot, even after already applying it to the SD, I can only assume the bootloader it copies to the emmc is the unpatched variant.
 
After doing so it happily boots from emmc using nvme as root.
 
Using the minimal buster (4.4) build for the M4 with pask's patch everything seems to work as it should (wifi etc.)

I built Bionic dev 5.3 rc4 for M4 and used @pask his patch. Works great.
But I had to use @martinayotte 's trick to make on board wifi to work. 
So this wifi issue is probably not from the RockPi4 image, but I guess has to do with mainline kernel. 

Very nice. I tried your image and everything seems to work. Wifi works, eMMC works, sound, ... 
I think this is the better way to go forward. A lot less hasstle than converting the RockPi4 image to fit the M4V2. 
Great job.

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

@NicoD
I'm using Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0-rc4_minimal.7z as suggested in a previous post by @martinayotte
 
On top of it, I'm remotely running the mate desktop by means of tightvncserver.  I'm quite impressed by the responsiveness of the desktop, considered that I'm still using the sd card, and accessing the mate desktop over the (wired) network. Things at the moment seem to work quite well, apart from the browsers, both chromium and firefox. Browsing is very slow and after few minutes the whole desktop gets stuck, forcing me to kill the vncserver.
 
I hope I'll be able to do further tests this evening.

https://github.com/armbian/build/issues
https://github.com/armbian/config/issues
https://forum.armbian.com/staffapplications/application/6-we-need-board-maintainers/
https://forum.armbian.com/forum/38-feature-requests
 
 

take a look at
https://www.cnx-software.com/wp-content/uploads/2019/09/NanoPi-M4V2-Large.jpg
from
https://www.cnx-software.com/2019/09/30/nanopi-m4v2-metal-case-kit-review-unboxing-assembly/
 
 

also do 
cp /lib/firmware/brcm/brcmfmac4356-sdio.txt /lib/firmware/brcm/ brcmfmac4356-sdio.friendlyarm,nanopi-m4.txt
then check if  /lib/firmware/brcm/brcmfmac4356-sdio.bin would be loaded?

This means it is not "dev" ...
Try this one instead : https://dl.armbian.com/rockpi-4b/nightly/Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0-rc4_minimal.7z
 

Yes ! It is using a U-Boot compatible with LPDDR4 ...