Jump to content
  • 0

NanoPC T4


tkaiser
 Share

Question

NanoPC-T4-A01.jpg

 

This is something hopefully suitable to become a 'Board Bring up' thread.

 

The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.

 

Pros:

  • Another RK3399 board so software support is already pretty mature
  • Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on)
  • No powering hassles due to 12V (2A) PSU requirement
  • 16GB superfast eMMC 5.1 
  • Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here)
  • All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)

 

Cons:

  • A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price)
  • High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time
  • heatsink too small for continous loads

 

I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).

 

Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).

 

Internal 16 GB eMMC performance:

eMMC / ext4 / iozone                                          random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    23400    28554    26356    26143    27061    29546
          102400      16    48364    48810    85421    85847    84017    47607
          102400     512    48789    49075   273380   275699   258495    47858
          102400    1024    48939    49053   290198   291462   270699    48099
          102400   16384    48673    49050   295690   295705   294706    48966
         1024000   16384    49243    49238   298010   298443   299018    49255

That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)

 

Quick USB3 performance test via the USB-3A port:

Rockchip 4.4.132                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    24818    29815    33896    34016    24308    28656
          102400      16    79104    90640   107607   108892    80643    89896
          102400     512   286583   288045   285021   293431   285016   298604
          102400    1024   315033   322207   320545   330923   320888   327650
          102400   16384   358314   353818   371869   384292   383404   354743
         1024000   16384   378748   381709   383865   384704   384113   381574
         
mmind 4.17.0-rc6-firefly                                     random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    37532    42871    22224    21533    21483    39841
          102400      16    86016   104508    87895    87253    84424   102194
          102400     512   274257   294262   287394   296589   287757   304003
          102400    1024   294051   312527   317703   323938   323353   325371
          102400   16384   296354   340272   336480   352221   339591   340985
         1024000   16384   367949   189404   328094   330342   328136   139675

This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.

 

This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:

13:57:31: 1008/1416MHz  8.44 100%   0%  99%   0%   0%   0% 91.1°C  0/5
13:57:40: 1008/1416MHz  8.52 100%   0%  99%   0%   0%   0% 91.1°C  0/5
13:57:48: 1008/1416MHz  8.51 100%   0%  99%   0%   0%   0% 91.1°C  0/5
13:57:57: 1200/1416MHz  8.47 100%   0%  99%   0%   0%   0% 90.6°C  0/5
13:58:05: 1200/1416MHz  8.47 100%   0%  99%   0%   0%   0% 91.1°C  0/5

So with heavy workloads you most probably need a fan to prevent throttling. 

 

Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?

 

Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.

 

Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).

Link to comment
Share on other sites

Recommended Posts

  • 0

I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.

One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).

 

Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.

 

I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too :)

 

Link to comment
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

Hey guys, since I've recently got a couple of RK3399 boards (FriendlyARM NanoPC-T4, Firefly RK3399 and OrangePi RK3399),  I'm trying to get the best option for my use cases that is server workloads in a Kubernetes cluster lab to test new technologies. There are a couple of articles on https://medium.com/@carlosedp.

 

The Linux distributions the manufacturers create are usually bloated (with desktop software) and with missing Kernel options and modules so I've been in a crusade to build the kernels suited to these boards.

 

The first thing I've found is that each board have it's own kernel tree and lots of DTSs and DTSIs differ from each other. I've built the base Rockchip kernel for both but had to fiddle and replace files to build the DTBs for each board.

 

Do you guys have any news on integrating all this mess maybe into Rockchip or the Mainline kernel trees? Is there anything that I can help?

 

Thanks!

Link to comment
Share on other sites

  • 0

I have to boot it and I have one NvME SAMSUNG MZVKW512HMJP (960 PRO OEM 512GB) drive lying around so I did some tests with:

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

CPU settings were the same.

 

FriendlyARM Bionic image:   

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    41338    78901    99988   100857    45198    78653
          102400      16   139298   214581   231273   233098   104223   208826
          102400     512   484706   533139   479387   489203   430695   533633
          102400    1024   528153   570248   501469   511199   477028   567310
          102400   16384   566544   586036   563672   576738   573686   582514

Armbian from here https://github.com/hjc4869/armbian-build/issues/1 (could not build my own - have to try again later) 

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    49152    74567    92929    93279    41268    69268
          102400      16   156724   234831   294344   254141   101716   236869
          102400     512   958208  1027143   952072   983620   582711  1044034
          102400    1024  1064030  1127356  1007844  1036058   743726  1123484
          102400   16384  1127636  1189732  1097192  1139916  1107548  1071900

Why is Armbian I/O so much faster?

Link to comment
Share on other sites

  • 0
11 hours ago, Igor said:

Why is Armbian I/O so much faster?

 

Since https://forum.armbian.com/topic/7310-rockpro64/?do=findComment&comment=56184

 

There's PCIe link training but if DT defines a conservative link speed then no higher speeds will be negotiated. Checking lspci output is mandatory in such cases (and that's the reason why I added this to our hardware logging. But I don't remember whether lspci is present on Armbian images by default or not)

 

Edit: the kernel version and settings matter too of course. With RK's 4.4 there's /sys/module/pcie_aspm/parameters/policy which defaults to powersave.

 

Link to comment
Share on other sites

  • 0
18 hours ago, Igor said:

Why is Armbian I/O so much faster?

 

BTW: in case you re-test can you please test also with a much larger test data size?

iozone -e -I -a -s 1000M -r 1024k -r 16384k -i 0 -i 1

 

See https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350 -- with your SSD combined with RK3399 and mainline kernel when using the 'right' benchmark even 1.6GB/s can be measured.

 

Here ayufan's scores from RockPro64 also using the same Samsung SSD: https://gist.github.com/ayufan/30c46381c5e4e5c5264a834a752946db

 

Link to comment
Share on other sites

  • 0
11 hours ago, tkaiser said:

Did you prefix the iozone call with 'taskset -c 4-5 '?


Now I did.  K4.4 until mainline is not sorted out. Better!

 

Spoiler

                                                            
              kB  reclen    write  rewrite    read    reread
         1024000    1024  1279569  1307621  1243836  1252293
         1024000   16384  1292840  1322563  1267157  1272861

 

 

 

Link to comment
Share on other sites

  • 0
15 hours ago, tkaiser said:

decided to use another kernel

 

We'll, there's very little difference in them fundamentally, it should take very little work to say Ayufan instead of Rockchip.  I can try it and we can just swap.  Same for RK3288

Link to comment
Share on other sites

  • 0

I know this is irrelevant, but it's too cool for me not share:  (Rockchip kernel 4.4 via HJC's work, Samsung 256 GB

 

Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
	Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    63148    98717   117726   103704    32253    74841                                                          
          102400      16   200588   282047   286796   312951    89631   242632                                                          
          102400     512   472102   577041   458541   430672   540748   557106                                                          
          102400    1024   506514   560837   485540   455210   498891   576875                                                          
          102400   16384   951626   994023   920260   996905   973086   994344  
	Command line used: iozone -e -I -a -s 1000M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         1024000       4    72776    85094   109072   121242    34017    98562                                                          
         1024000      16   221422   302439   331772   333805    88144   290576                                                          
         1024000     512   565209   639164   465860   473754   602073   599450                                                          
         1024000    1024   759673   793099   669950   684237   721181   748267                                                          
         1024000   16384  1045977  1095899  1070003  1079163  1075869  1066718  

 

Link to comment
Share on other sites

  • 0

Hello.

 

I tried Armbian build based on Ubuntu. Feels better than official friendlyelec's builds, interface is much much more responcive, but I have two problems with Armbian:

 

If I start fullscreen video from youtube (checking on this video) it stucks approximately at 2.5 minute. Picture freezes and repeated sound sample, not responding to anything. Tried it on Chromium, on Firefox and even with Smtube, everytime stucks at approximately same place. What is the problem? Video memory leaking and filling all the place? or what? On official builds I didn't have this problem (but there was plenty others).

 

And second problem - Synaptic. Search in Synaptic is dead slow. It takes about 15 minutes ant uses about 16% of CPU according to the Monitor. When searching and after package installation, when returning to the same search list. Strange thing, but on official builds it works as fast as on desktop. Based on same Ubuntu.

 

Do not know, should I create another topic? As I see all about NanoPC-T4 is happening here for now.

Link to comment
Share on other sites

  • 0
2 hours ago, konstantin said:

And second problem - Synaptic. Search in Synaptic is dead slow.


https://forum.armbian.com/topic/8021-orange-pi-one-synaptic-package-manager-search-very-slow/

 

2 hours ago, konstantin said:

If I start fullscreen video from youtube

 

https://forum.armbian.com/topic/8043-orange-pi-one-general-performance-browser-performance/?do=findComment&comment=60618

 

I have to add here that I don't know how is with video acceleration in general with this board, so "playing outside the browser" might not solve anything ... yet.

 

2 hours ago, konstantin said:

should I create another topic?

 

No, but start to use forum search first. We talked about many times:
https://www.armbian.com/search

 


I found both answers in less than 10seconds.

 

Link to comment
Share on other sites

  • 0
1 hour ago, Igor said:

I have to add here that I don't know how is with video acceleration in general with this board,

Within the web browser, basically quite as good as RK3288 and XU4. That means that it can play up to 1080p@30 youtube smoothly. Outside the browser, MPV and Gstreamer can play 4K@60 with no problem. But, as is the case for RK3288 and XU4, you need to configure it first; that is what my media scripts do.

 

I already made a media script, but it was 32-bit, based on the RK3288 one (with God's help, I plan to make a 64-bit version, now that the board reached the WIP status). The link for the 32-bit script is a few posts above, together with some test results about the SoC GPU and VPU capabilities: 

 

Link to comment
Share on other sites

  • 0

Hi,

 

I tried Armbian on my NanoPC-T4 and installed it to eMMC using ‚armbian-config‘.

I wanted to try the official FriendlyELEC image, but the ‚eflasher‘ utility doesn’t recognise any eMMC.

Then I tried booting from Armbian from SD and using ‚armbian-config‘ again to check if it recognised, but the option for installing to eMMC isn‘t present anymore.

 

I can still boot Armbian from eMMC but can‘t install anything new to eMMC. Are there any advices for fixing the problem?

Link to comment
Share on other sites

  • 0
1 hour ago, Malz said:

I can still boot Armbian from eMMC but can‘t install anything new to eMMC. Are there any advices for fixing the problem?

 

Boot priority with Rockchip boards is AFAIK always eMMC first then SD card. So once RK3399 finds a bootloader signature on the eMMC it will boot from there even if a bootable SD card is inserted. If you want to reflash eMMC in this situation you 

  • either need to use Maskrom mode (or how it's called exactly) which requires another host and USB
  • delete the bootloader on the eMMC (can be done from the running system: 'dd if=/dev/null of=/dev/mmcblk1 bs=1M count=64 ; sync')

I successfully bricked my NanoPC-T4 while developing with nand-sata-install and now have working bootloader on the eMMC that is not able to boot a kernel so I'm locked out and would need to try variants 2) or 3) here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4#Flash_Image_to_eMMC (which is not that easy since my physical x86 machines all run macOS and my Linux boxes are all ARM based -- I might try a VM with USB pass-thru soon)

 

I asked @mindee for help but his advice to boot an eflasher image from SD card doesn't work since I have a working bootloader on the eMMC (but an otherwise bricked system).

 

Would be great to temporarily disable the eMMC as it can be done on Rock64 and RockPro64 (a jumper allows the eMMC to be grounded or something like that so you can boot with this jumper set from a bootable SD card inserted and if you remove the jumper within 2 seconds after boot you can even access the eMMC afterwards to flash a new image)

Link to comment
Share on other sites

  • 0
1 hour ago, tkaiser said:

either need to use Maskrom mode (or how it's called exactly) which requires another host and USB

did you try https://github.com/rockchip-linux/rkdeveloptool

And then a 'rkdeveloptool ef'  might do it..  As far as I see this is plain c++ without any blobs so you could probably compile it on one of your arm boards as well.. ;) 

chwe@chwe-acer:~$ rkdeveloptool

---------------------Tool Usage ---------------------
Help:			-h or --help
Version:		-v or --version
ListDevice:		ld
DownloadBoot:		db <Loader>
UpgradeLoader:		ul <Loader>
ReadLBA:		rl  <BeginSec> <SectorLen> <File>
WriteLBA:		wl  <BeginSec> <File>
WriteLBA:		wlx  <PartitionName> <File>
WriteGPT:		gpt <gpt partition table>
WriteParameter:		prm <parameter>
PrintPartition:		ppt 
EraseFlash:		ef 
TestDevice:		td
ResetDevice:		rd [subcode]
ReadFlashID:		rid
ReadFlashInfo:		rfi
ReadChipInfo:		rci
ReadCapability:		rcb
PackBootLoader:		pack
UnpackBootLoader:	unpack <boot loader>
TagSPL:			tagspl <tag> <U-Boot SPL>
-------------------------------------------------------

 

Link to comment
Share on other sites

  • 0
1 hour ago, tkaiser said:

Boot priority with Rockchip boards is AFAIK always eMMC first then SD card.

Rockchip boot sequence is typically BOOTROM -> u-boot SPL -> u-boot, AFAIK bootrom tries eMMC first, but u-boot SPL tries loading u-boot from SD card first (reference), so if there's a valid SPL on eMMC, you might still have a chance to boot from SD...

Link to comment
Share on other sites

  • 0
4 hours ago, hjc said:

u-boot SPL tries loading u-boot from SD card first (reference), so if there's a valid SPL on eMMC, you might still have a chance to boot from SD...

 

Doesn't work for me.

 

37 minutes ago, martinayotte said:

Is it not what the "boot" button does by shorting the eMMC-D0 line ?

 

Just tested this too and it also does not work. Quoting the wiki:

Quote

Press BOOT key to prevent the board from eMMC booting, making the board enter MASKROM mode

 

Well, I need to do my homework first. Set up another SBC for serial console access (don't want to install CH340T drivers on my new MacBook), then check for a working USB-C cable and so on...

Link to comment
Share on other sites

  • 0
4 minutes ago, martinayotte said:

It did work for me 2 weeks ago, then I've used nand-sata-install ...

 

And you did not use nand-sata-install prior to this? Since then eMMC would've been empty anyway and booting from SD card would be normal behavior even without pressing boot button?

Link to comment
Share on other sites

  • 0
1 minute ago, tkaiser said:

And you did not use nand-sata-install prior to this? Since then eMMC would've been empty anyway and booting from SD card would be normal behavior even without pressing boot button?

No, first time, it was booting some other unknown image already present if I remember.

Later, I had a build done from @hjc old branch, and when I wanted to use latest Armbian, I had to press "boot" again this time.

Link to comment
Share on other sites

  • 0

Thanks a lot! 

 

I finally fixed my eMMC problem.

Booting into MASKROM and erasing flash by using Chinese Rockchip Tool let me install armbian again to eMMC.

 

I had some problems identifying the device with the Rockchip utility. Switching from Win10 to old Win7 laptop fixed connection issues.

 

Now trying to configure armbian as my new ‚all-in-one‘ livingroom device. Are there experiences with running Kodi on armbian?

Link to comment
Share on other sites

  • 0
On 9/19/2018 at 10:06 AM, tkaiser said:

Just tested this too and it also does not work

@tkaiser, I wished to update my NanoPC-T4 today, and I've faced your issue ...

Although the BOOT button trick worked, since I saw the u-boot build date, it was taking the one from SDCard, but it choose to run scripts/kernel from eMMC.

I had to stop u-boot at prompt, do manual "setenv devnum 1" to avoid eMMC followed by "run mmc_boot", it finally booted from SDCard.

It was definitively not like that with my previous old HJC image, so something wrong in the current u-boot scripts ...

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...