NanoPI M4

[TonyMac32]

8 hours ago, chwe said:

Without fact checking, I would guess that cheap plastics (e.g. HDPE) are more eco, but as said I never made an 'overall benchmark' of resources. Steel acts different to aluminum in all stages, recycling, mining and production is IMO easier.

 

How many times can you recycle HDPE, and what is the process?  :-P. Plastics are quite cheap to make, and relatively low energy.  It's the disposal and reuse that becomes the problem.

 

My point was, Aluminum is aluminum forever, unless some of the neutrons decay  Plastic waste is, well, garbage.

 

 

[chwe]

1 hour ago, TonyMac32 said:

My point was, Aluminum is aluminum forever, unless some of the neutrons decay

Aluminum oxidizes to Al2O3 immediately..  What you see as 'alu-look' is in fact oxidized aluminum...  Steel is efficient to reuse whereas aluminum isn't (it's still a way more efficient than start from bauxite). 

 

1 hour ago, TonyMac32 said:

Plastics are quite cheap to make, and relatively low energy.  It's the disposal and reuse that becomes the problem.

hmm not really..  a heretic would call HDPE as 'highly viscous diesel'  Okay.. diesel isn't trendy anymore but burn it,  cook water with it and gain energy out of it. Some plastics can be reused (e.g. I don't think that any of my cheap PETg filament is 'new').  America has a 'famous' history of combine plastics with benzene and gasoline, related to increase the viscosity... 

I prefer mixed cases when the SoC is on the bottom side. I would love to see that boardmakers release CAD-files of the top so that if you need things like a pinheader, you just have to adjust it slightly and print it on your own.. 3D-printers or printservices are cheap as hell as long as you don't need fancy plastics (the reason I print with PETg is cause it's the only one which is at least 'a little bit' chemical stable for the my use-cases and cheap enough, the one I would prefer is ~900$/kg and needs 350-400°C print temperature.. Not that handy for a 300$ printer ). 

 

[CabröX]

Is there is an aproximate release date for this board? I would totally pick one, as I was having a look to the nanopc-T4 but I think is too much of an overkill for my projects and would like to get some raspberry pi cases too for this one!

 

Thanks in advance.

Edited July 11, 2018 by CabröX

[tkaiser]

FriendlyELEC usually updates their wiki prior to official product launch.

 

11 hours ago, CabröX said:

Is there is an aproximate release date for this board?

On 7/1/2018 at 3:08 PM, tkaiser said:

No one here knows. So better monitor http://wiki.friendlyarm.com/wiki/index.php/Special:RecentChanges and wait for the M4 page appearing there

[mindee]

Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).

 

 

 

 

[CabröX]

Waw looks amazing, definitely going to wait for it. The firsts versions of this SBC's usually come with hardware problems?

 

And another question, is the back part (aluminium case) like a heat sink for the SoC? And will the final version come with it? Seems so nice.

[tkaiser]

3 hours ago, mindee said:

Working on NanoPi M4 these days,  almost done

 

Really curious about what you did with PCIe here, how many times SuperSpeed is available at USB receptacles and so on. Can't wait for the wiki page to appear  

[guidol]

4 hours ago, mindee said:

Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).

with this "heatsink-case/body"?

[tkaiser]

4 hours ago, mindee said:

 

Thank you for updating the post with this second picture!

 

So I would assume we have either:

• one USB3 port directly connected to RK3399 and three USB3 ports behind the internal VL817 hub sharing bandwidth or
• all 4 USB3 ports behind the internal VL817 hub sharing bandwidth (then OTG is routed to USB-C but only as Hi-Speed?)

Same Wi-Fi chip as NanoPC-T4, optional eMMC, 2 PCIe lanes available on a header... nice! I really hope NanoPi M4 and NanoPC-T4 will be as compatible as possible so we can support them with a single image

[CabröX]

Any news on this board? Is everything going as expected? Hyped to give it a new home  (mine)

[hjc]

On 7/13/2018 at 4:37 PM, tkaiser said:

I really hope NanoPi M4 and NanoPC-T4 will be as compatible as possible so we can support them with a single image 

It seems that the DT files of NanoPi M4 and NanoPi NEO4 are already published on FriendlyARM GitHub. They share most parts (rk3399-nanopi4-common.dtsi) with NanoPC T4, with minor differences.

[frottier]

I had a script monitoring the wiki. There's movement.

 

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4

[CabröX]

This is coming soon for sure!

[tkaiser]

3 hours ago, frottier said:

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4

Ok, so it's confirmed:

On 7/13/2018 at 10:37 AM, tkaiser said:

all 4 USB3 ports behind the internal VL817 hub sharing bandwidth (then OTG is routed to USB-C but only as Hi-Speed?)

 

Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.

 

If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

[JMCC]

On 8/21/2018 at 4:23 PM, tkaiser said:

do you know about the state of video transcoding with RK3399?

Well, FFmpeg's RKMPP support includes only decoding so far, so not many chances that Plex/Emby will support accelerated encoding for RK3399 anytime soon. Gstreamer should be pretty well supported, in theory just as RK3288, but I haven't tested it. Now I'm returning to SBC's after some weeks, so I'll make sure to test video encoding when I do the RK3399 media script, God willing.

[CabröX]

It is already in the friendlyelec shop to buy!

[hjc]

I've ordered one just now.

 

BTW is there any recommended enclosure for both M4 and NanoPC T4? I'm not to expose these expensive boards in the air any more. Air quality around here is really poor, (for my Firefly RK3399) half year's exposure = lots of dust gathering on the PCB  

[tkaiser]

6 minutes ago, hjc said:

I've ordered one just now

 

I hope you added the heatsink?

 

My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962

[hjc]

Just now, tkaiser said:

I hope you added the heatsink?

Yes I did, of course. Heatsinks are essential for RK3399 boards.

 

12 minutes ago, tkaiser said:

My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962

It's a nice approach, I'll consider that. Although modifying the drawer seems to take a lot of time.

[guidol]

from today:
AUGUST 24, 2018 BY CNXSOFT

NanoPi M4 Raspberry Pi Inspired RK3399 Board Launched for $65 and Up

https://www.cnx-software.com/2018/08/24/nanopi-m4-raspberry-pi-rk3399-board/

[hjc]

Looks like my M4 will arrive next Thursday. One thing that I still concern about is that, I ordered the 2GB RAM model, which uses DDR3 instead of LPDDR3 that the 4GB ones use, so I doubt if there's any RAM initialization differences to take care about when creating images for the board. At least in u-boot, LPDDR3 and DDR3 are using different timing parameters, specified in device tree.

[mindee]

On 8/21/2018 at 10:23 PM, tkaiser said:

Ok, so it's confirmed:

 

Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.

 

If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

 

Thanks for your suggestion, we’ll check that.

[hjc]

M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP

Ambient temperature is ~29℃

I'll write a full review this weekend.

[tkaiser]

4 minutes ago, hjc said:

M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP

 

Hmm... that's a bit underwhelming. I had hoped for better results (even taking into account the 29°C ambient temperature). Do FE guys again use the blue thermal pad that is 1mm thick?

 

And as already reported: throttling needs some tuning since we currently jump between 2.0 and 1.4 GHz and skip the OPP in between:

1992 MHz: 3949.34 sec
1800 MHz:       0 sec
1608 MHz:       0 sec
1416 MHz:   35.42 sec
1200 MHz:       0 sec

Had no time to look into yet (too busy with a boring VoIP project these days)

[hjc]

1 minute ago, tkaiser said:

Do FE guys again use the blue thermal pad that is 1mm thick? 

Yes they do, same as the one that came with NanoPC T4.

[tkaiser]

1 minute ago, hjc said:

same as the one that came with NanoPC T4.

 

Good. Already prepared a bunch of copper shims of varying height and thermal paste since I would believe a lot of the poor thermal performance is due to heat not efficiently transferred into the heatsink. Curious when my M4 will arrive...

[TonyMac32]

Oof, I did not check the heat sink on the T4.  I also have some copper shims lying about...

[hjc]

22 hours ago, hjc said:

M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP

There's something wrong (DRAM related) when running Rockchip 4.4 kernel, which causes the latency to be twice as much as other RK3399 boards. This causes very poor 7-zip performance, and it takes a long time to run the tinymembench. (~20 minutes both on big and little cores)

However the DRAM is performing normally on mainline kernel (4.19-rc1), and the benchmark numbers are identical to other boards.

 

Mainline kernel benchmark details: http://ix.io/1lzx. I didn't modify the opp table and thermal trip point, and it's limited to 70℃ and 1.8/1.4GHz, so thermal throttling occurs very frequently. Though it's still very powerful running under 1.6/1.4GHz and keeps cool.

 

Edit: Re-run with opp/trip point modified: http://ix.io/1lzP

[tkaiser]

30 minutes ago, hjc said:

There's something wrong (DRAM related) when running Rockchip 4.4 kernel, which causes the latency to be twice as much as other RK3399 boards. This causes very poor 7-zip performance, and it takes a long time to run the tinymembench. (~20 minutes both on big and little cores)

 

Yes, you're right. By looking at dmc stats we might get the culprit:

root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat trans_stat 
   From  :   To
         :200000000300000000400000000528000000600000000800000000   time(ms)
*200000000:       0       0       0       0       0      14 224442114
 300000000:       8       0       0       0       0       0      2062
 400000000:       0       6       0       0       0       1     11499
 528000000:       1       1       5       0       0       0     25918
 600000000:       0       0       0       0       0       0         0
 800000000:       5       1       2       7       0       0    136407
Total transition : 51

This is NanoPC T4 running tinymembench:

root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat cur_freq 
200000000

Now repeating the test after:

root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# echo performance >governor 
root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat cur_freq 
800000000

 

[tkaiser]

55 minutes ago, tkaiser said:

Now repeating the test after:

root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# echo performance >governor 
root@nanopct4:/sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc# cat cur_freq 
800000000

 

Results: http://ix.io/1lzW -- comparing with my previous run without modifying dmc policy: http://ix.io/1lkG

 

So looking at dmc memory governor with dmc_ondemand we have 5870 7-zip MIPS and with performance it's above 6500 (I need to retest with fan). Individual results:

A53            dmc_ondemand    performance
        memset     1417.3        1413.7
        memcpy     4784.5        4786.8
single latency     381.0         207.5
  dual latency     451.9         240.6
  7-zip single      837           1037

A72            dmc_ondemand    performance
        memset     2809.3        2821.2
        memcpy     4893.0        4895.7
single latency     381.7         217.8
  dual latency     483.8         260.5
  7-zip single      1336          1712

While memory bandwidth doesn't differ between both governors latency is highly affected. Same with single threaded 7-zip runs and also multi-threaded to a lesser extent.