Posted on by Jean-Luc Aufranc (CNXSoft) - 17 Comments on NanoPi M4V2 Kit Review – Part 2: FriendlyCore Desktop

NanoPi M4V2 Kit Review – Part 2: FriendlyCore Desktop

NanoPi M4V2 Review
Click to Enlarge

We’ve already seen how to assemble NanoPi M4V2 metal case kit which offers an Arm mini PC solution with support for NVMe SSD. The new NanoPi M4V2 Rockchip RK3399 SBC is an evolution of the M4 board that brings faster LPDDR4 memory and adds power & recovery buttons.

Since we’ve already tested several RK3399 SBC‘s and TV boxes, I planned to focus the review on thermal design evaluation (i.e. see how well the board cools), and see how memory bandwidth evolved from LPDDR3 to LPDDR4.

I wanted to do so both with Linux and Android, since I could compare NanoPC-T4 (LPDDR3) benchmarks in Android. But this requires an eMMC flash module, and I don’t own any. So instead I planned to run Armbian because of support for armbian-monitor for nice temperature chart but it’s not working just yet, so instead I’ve done all tests with FriendlyCore Desktop (rk3399-sd-friendlydesktop-bionic-4.4-arm64-20190926.img) based on Ubuntu 18.04.

System Information

NanoPi M4V2 FriendlyCore

The desktop environment will auto-login, but if you want to login over SSH you can use root username and fa password. Just a few details about the system:


Note I connected my USB 3.0 test hardware as well which explains the four /dev/sda1..4 partitions.

Loaded modules:


GPIOs appear to be properly configured:

SBC Bench

SBC Bench script is great to benchmark Arm SBC’s and check if CPU throttling occurs under various workloads, So let’s install it:


The system reports the CPU temperature is 51.7°C at idle, and I measured around 41°C on the top of the enclosure with an IR thermometer. The ambient temperature was around 28-29°C. Note that I do not have any NVMe SSD, and if you do use one temperature may be slightly higher. There’s a fan which will only rotate when the temperature rises further, and when it does it’s really noisy in a way I can hear in another room (if the door is opened) about 6 meters away from the board.

Time to run the benchmarks. It will take a while.


I also had ./sbc-bench -m running in a separate window to monitor the temperature more often, and the CPU temperature rose up to 71.1°C. The top of the enclosure was only slightly warmer 42°C.

CPU Throttling

No problem for single-core benchmark, but we can see a tiny bit of throttling for 7zip multi-thread benchmark:


but it happens much more frequently with cpuminer:


It looks as if the system will drop the clock speed of the big cores to around 600 MHz when the CPU temperature goes over 70°C.

Memory Bandwidth

NanoPi M4 results for the big cores (2x Arm Cortex-A72) taken from SBC-Bench results database:

  • memcpy: 4080 MB/s
  • memset: 8270 MB/s

So now we have software/configuration issues on our hands as NanoPi M4V2 with the supposedly faster memory is actually much slower:

  • memcpy: 2613.9 MB/s
  • memset: 4758.7 MB/s

M4V2 runs Ubuntu 18.04 64-bit with Linux 4.4 while the M4 board was tested with Debian Stretch 64-bit and Linux 4.19. Here’s the kernel boot log for reference, but I can’t see anything about ddr.

Improving Air Flow

The way the case is designed the fan faces the desktop, and the case is only slightly elevated via rubber pads. One way to potentially improve cooling is to turn the enclosure upside down with the fan facing up, but instead, I elevated the case with four HDMI connector caps.

NanoPi M4V2 HDMI caps

Let’s repeat the test:


Sadly throttling still occurred but there are still some improvements since it did not happen with 7-zip at all (4°C lower), and happened less often with cpuminer:

GPU Acceleration and VPU Hardware Decoding

FriendlyCore Desktop
Click to Enlarge

FriendlyCore comes with a set of programs preinstalled including some that allow us to test whether 3D graphics acceleration and hardware video decoding work.

glmark2-es2 is preinstalled and runs fine…

NanoPi M4V2 glmark2-es2

But the glmark2 score is on the low side at 54 because, as I understand it, vsync is enabled so the maximum score is 60 fps:


I could test 4K video playback in FriendlyELEC Player and I was able to play H.265, H.264 and VP9 videos with hardware video decoding.

NanoPI M4 V2 FriendlyELEC Player
Click to Enlarge

However .ts files won’t play at all, and as such, I could not play any 10-bit H.264 nor 10-bit H.265 4K videos since all my samples are based on TS container format. I was also unable to change the display resolution from 1920×1080 to 4K resolutions such as 3840×2160 or 4196×2160 since those were simply not detected despite being connected to a 4K TV.

Qt Development & Demos

I could not help but also notice the Qt demos on the desktop. There was also an OpenCV demo but it requires a USB or MIPI camera and I could not find my USB webcam.

NanoPi Qt Demos
Click to Enlarge

The Qt5 QML demos include an image browser and a smart hone UI. If you want to easily get started with Qt UI development on Arm, FriendlyELEC has a “Develop Qt Applications” section in their wiki so NanoPI M4/M4V2 may be a good starting point. They also have several Qt repositories with demos in their GitHub account.

Final words

NanoPi M4V2 metal case kit does the job at keeping the Rockchip RK3399 board cool enough in most conditions. But you must be aware the fan is really noisy when it kicks off, and I did not test the kit with an NVMe SSD which may further generate heat.

If you plan to use Android, you’ll need to purchase an additional eMMC flash module, but with FriendlyCore Desktop tested above a MicroSD card will suffice. I used a 32GB class A1 MicroSD card and performance was satisfactory. The software appears to be fairly solid and should be a good base for product development. There may be further tweaks needed to extra more performance, as we’ve found out memory bandwidth was about half of boards with DDR3 memory.

If you’d like to purchase the hardware used for this review you can do so  for $98 plus shipping Just make sure to also select “Metal Case w/ Cooling Fan(NVMe SSD Adapter included) (+$28.00)” option.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

17 Replies to “NanoPi M4V2 Kit Review – Part 2: FriendlyCore Desktop”

  1. Great review. I’ve also got one to review. I’m waiting for official Armbian to run on it. I also noticed it’s performing a little worse than the M4 in FriendlyDesktop.
    It’s not to say that lpddr4 should perform better than ddr3. I think the lpddr4 modules are just cheaper than the ddr3 ones. LPDDR4 might have a worse latency than ddr3 what makes it perform worse.
    I like the case. But I’ve removed the plate under the fan. With it on there the fan makes a lot of noise. Even on 5V. Without that plate you almost can’t hear it running.
    Cheers.

    Reply

  2. > as we’ve found out memory bandwidth was about half of boards with DDR3 memory

    This is most probably just a kernel setting. Rockchip’s Android BSP uses CONFIG_HZ=1000 by default while most Linux distros choose CONFIG_HZ=250 for both server and desktop scenarios which will end up with much better memory bandwidth benchmark numbers, see for example: https://github.com/armbian/build/issues/1142

    How fast memory access really is depends on the boot BLOB in question (but maybe Rockchip in the meantime published DRAM initialization code as they promise for years now — no idea since I’m pretty much done with this ARM mess anyway).

    Reply

    2. I’m not sure CONFIG_HZ alone explains such a difference. I already noticed bad memory performance on RK3399. Each A53 alone has 1/3 the read performance of the A72 but higher write performance! However when using two A53 at once for reads I noticed that their total performance more than doubles. Typically (I don’t remember the exact numbers) you’d get 400ns DRAM access time for a single core and only 250ns for two cores! The smaller 64-bit read datapath of the A53 alone cannot explain this, and the CPU supports assigning rotating priorities to access the L2 cache which I’ve long suspected not to be optimal, and to leave idle slots when not enough cores are in use, and to reduce the burst length. Also mixing one A72 with one A53 would further increase the A53 performance. I spent some time reading the data sheet but failed to figure working changes.

      Note that I already noticed this one year ago on the H96 with DDR4 and rockchip’s BSP so it’s not limited to the NanoPI.

      I gave up searching since in my build farm most cores are in use together anyway, but definitely for me there is something totally wrong in the RK3399’s memory controller.
      This chip is getting old now, it’s not worth trying to investigate into this anymore IMHO.

      Reply

      1. > I’m not sure CONFIG_HZ alone explains such a difference.

        It does in this case (looking at numbers generated with one specific benchmark).

        Please see the four RockPro64 entries here: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md — RK3399 running with mainline kernel resulted in twice the memory bandwidth compared to Rockchip’s 4.4 Android BSP. But there’s no magic, just the real difference between Rockchip’s BSP kernel and mainline being simply CONFIG_HZ=1000 vs. CONFIG_HZ=250. Once this is adjusted in RK’s 4.4 kernel memory related benchmark numbers improve.

        > This chip is getting old now, it’s not worth trying to investigate into this anymore IMHO

        Sure, let’s move on to some other ARM adventure where software support becomes mature once the SoC is obsolete 😉

        Seriously: something like exchanging the type of DRAM modules resulting in a board not being able to run any ‘standard images’ without digging into the world of smelly boot blobs or outdated u-boot variants from 5 years ago is pathetic. But pretty much represents the ARM world today if it’s not about some selected ARM based ‘real servers’.

        Reply

        1. > Seriously: something like exchanging the type of DRAM modules resulting in a board not being able to run any ‘standard images’ without digging into the world of smelly boot blobs or outdated u-boot variants from 5 years ago is pathetic. But pretty much represents the ARM world today if it’s not about some selected ARM based ‘real servers’.

          This is inevitable in a world of multiple vendors and least-effort/first-to-market forces at play where a SKU is not meant to see much ram variation. Under such conditions there will always be the SoC vendor who ships something with a barely-running ram support, and the board vendor who takes that and runs away with it. Luckily, non-server arm ‘desktop’ boards (of the mITX variety) where ram is not soldered and thus vendors have no choice but provide a BL1/2 that does robust ram support. And the more SoC vendors aim for u/mITX, the more robust ram support we will get. Marvell and nxp are two examples of vendors who don’t skimp on ram support. E.g. macchiatobin (A8040) runs with DDR4 DIMMs from a plethora of vendors, in both ECC and non-ECC variants, just like any (xeon) desktop.

          Reply

          2. > Not the brightest future according to this rumor
            This one doesn’t even surprize me, I expected it when seeing they acquired Cavium. Far too much overlap between the two, especially when their consumer devices are likely sufficient to pay the bills.

          3. I guess that explains why A8040 has been phased out by some of its notable customers since this summer. Unfortunately, I don’t see Cavium meeting demand for entry-level SoCs where fewer cores, better ST performance is needed. Their TX is lacking in ST, and their TX2 is completely out of the price segment. NXP seem to be picking up with the LX series, but Marvell leaving the segment would be a bummer indeed.

        2. > Please see the four RockPro64 entries
          Impressive difference, indeed. Something’s terribly wrong in this kernel. Maybe they’re flushing the cache on each context switch to work around whatever bug :-/

          > Seriously: …pathetic
          Agreed. Also with DDR training blobs everywhere it’s not possible to even remotely imagine such machines one day becoming almost plug-n-play and extensible with modular components. I was truly impressed when I saw the mcbin take a normal DDR4 stick. Then I realized that it’s been this way for 4 decades in the PC world… In the ARM world, most machines require a full rebuild of some crappy BSP every time you need to adjust whatever minor setting, just as if what they put in them was extremely precious. But I’m still hoping to see such idiocies change, maybe I’m wrong.

          Reply

    1. Only with Armbian bootable from NVMe. But official Armbian does not yet work on it. (soon)
      The fan speed can’t be adjusted to my knowledge. It would be simple to solder a potmeter in between the wires.

      Reply

      1. > Only with Armbian bootable from NVMe.

        Nope since no RK3399 device can ‘boot from NVMe’ since this SoC has no boot support for PCIe at all. The only possibilities are to boot from SD card, eMMC or (non existing) SPI NOR flash. And even then it’s technically still not booting from NVMe but instead loading a patched u-boot from the supported boot media which can then in turn load the kernel from wherever it is. Radxa guys claim to provide this with RockPi 4 starting with V1.4: https://www.cnx-software.com/2019/10/08/ecopi-starter-cute-mini-pc-kit-rockpi-4b-sbc-m2-nvme-ssd/#comment-567004

        The SPI NOR flash then kind of acts like a BIOS on x86 providing driver support to load the OS from unsupported media.

        In Armbian I added NVMe capabilities to ‘nand-sata-install’ last year but this is still booting from either SD card or eMMC on such a NanoPi (in absence of SPI NOR flash) which means both u-boot and kernel have to reside on traditional boot media but just the rootfs is then located on an NVMe attached SSD.

        Reply

        1. What a pity: NVMe and SBC look “made for each other”: both small, low power consumption, not too expensive.

          Reply

          1. See RockPi 4 (V 1.4 or above) with an NVMe capable u-boot in its SPI NOR flash. That’s all it needs.

  4. I run sbc-benc on the NanoPi M4 v2 using an armbian build with “default” kernel (from nanopi-m4v2-u-boot-v2019.10-ddr-miniloader branch which uses updated blobs from rockchip): results are quite simitar to those ones of the review:

    Memory performance (big.LITTLE cores measured individually):
    memcpy: 1351.5 MB/s (0.4%)
    memset: 4803.8 MB/s (0.3%)
    memcpy: 2648.2 MB/s
    memset: 4871.5 MB/s (0.9%)

    While:
    pask@nanopim4v2:~/sbc-bench$ zcat /proc/config.gz |grep HZ
    CONFIG_NO_HZ_COMMON=y
    # CONFIG_HZ_PERIODIC is not set
    CONFIG_NO_HZ_IDLE=y
    # CONFIG_NO_HZ_FULL is not set
    CONFIG_NO_HZ=y
    # CONFIG_HZ_100 is not set
    CONFIG_HZ_250=y
    # CONFIG_HZ_300 is not set
    # CONFIG_HZ_1000 is not set
    CONFIG_HZ=250

    I guess NicoD’s hypothesis is right: sadly lpddr4 chips used fy friendlyelec on the m4v2 are worse then the ddr3 ones used on the previous version of this board.
    Or perhaps the rk3399 doesn’t work well with lpddr4 memory. Would be interesting compare those results with the rockpi4’s ones.

    Full results here: http://ix.io/22Oj

    Reply

    1. > lpddr4 chips used fy friendlyelec on the m4v2 are worse then the ddr3 ones used on the previous version of this board

      Why do you think about hardware differences when you use a closed source piece of software that initializes memory and therefore determines its performance?

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products