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
23 hours ago, Werner said:

Push to Armbian repo?

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution. :)

sound.sh

Link to comment
Share on other sites

Donate and support the project!

  • 0
On 4/25/2020 at 7:13 AM, balbes150 said:

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution. :)

sound.sh 3.86 kB · 6 downloads

Latest image works great. Is there any chance to have boot/rootfs  on SD card installed to emmc/nvme via Armbian-config?

Link to comment
Share on other sites

  • 0

Strange and obscure problem. With the latest patches, I have audio output working through the codec rt5651. But only with a 5.2.8 core.
I used these fixes in core 5.4.35. But no sound device rt5651 is created. At the same time, everything is normal in the log. The codec driver is connecting successfully.

 

 

Good news. There was an error in dts file patch. You must use the name "realtek" instead of "rockchip" in the node rt5651: rt5651@1a. In this case, the codec driver module will be used successfully. Otherwise, the module will not load automatically.

 

 &i2c1 {
	clock-frequency = <200000>;
 	i2c-scl-rising-time-ns = <150>;
 	i2c-scl-falling-time-ns = <30>;
 	status = "okay";
 
 	rt5651: rt5651@1a {
		#sound-dai-cells = <0>;
 		compatible = "realtek,rt5651";
 		reg = <0x1a>;
 		clocks = <&cru SCLK_I2S_8CH_OUT>;
 		clock-names = "mclk";
		pinctrl-names = "default";
		pinctrl-0 = <&i2s_8ch_mclk>;
 	};
 };

 

Link to comment
Share on other sites

  • 0
On 4/28/2020 at 1:27 PM, RussianNeuroMancer said:

 

Did you get Type-C port working on 5.4 too?

 

I managed to make Type-C port working on 5.* kernels by forcing its mode to "host":

&usbdrd_dwc3_0 {
 dr_mode = "host";
 status = "okay";
};
 

Link to comment
Share on other sites

  • 0

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

 

On 5/4/2020 at 10:48 PM, Oleksii said:

I managed to make Type-C port working on 5.* kernels by forcing its mode to "host"

Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?

Link to comment
Share on other sites

  • 0
2 hours ago, RussianNeuroMancer said:

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

 

Manually compiled dtb will be overwritten during linux-dtb-current-rockchip64 package updates, I guess?

Yep, most probably file names will collide :) I use custom 5.* kernels all the time with optimized configuration + some DT tweaks, so I don't usually care about linux-dtb-current-rockchip64 updates.

And if you want to overcome this, you may simply give your customized *.dtb a new name (make sure it is also correctly specified in the armbianEnv.txt). As another option, TD overlay might be handy too.

However, I would admit with every mainline kernel version increment I keep less and less of my custom patches :) For the moment, I have only one important that fixes Type-C on NanoPC T4 (and still, no 100% confidence it is right way to fix) and one small patch to enable ES400 mode on emmc for NanoPi M4.

Link to comment
Share on other sites

  • 0
5 hours ago, RussianNeuroMancer said:

I briefly tested 5.6.10 kernel  and found that Samsung 970 EVO doesn't work again, same PCIe link training gen1 timeout. Rollback to 5.4.32, and it works again.

Hm. I have a Nanopc T4 with evo 970 and kernel 5.7 performs LE build (compilation with full load within 5-7 hours), I did not find any problems with stability.

Link to comment
Share on other sites

  • 0
36 minutes ago, balbes150 said:

Hm. I have a Nanopc T4 with evo 970 and kernel 5.7 performs LE build (compilation with full load within 5-7 hours), I did not find any problems with stability.

Great to hear!
So you compiled this from mainline and didn't need to apply any further patches to fix e.g. wifi? 

Link to comment
Share on other sites

  • 0
22 hours ago, Oleksii said:

And if you want to overcome this, you may simply give your customized *.dtb a new name (make sure it is also correctly specified in the armbianEnv.txt).

I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.

Link to comment
Share on other sites

  • 0
2 hours ago, RussianNeuroMancer said:

I could, but this solution does not scale (specifically "things that don’t scale ... fix a problem for myself" and "things that scale ... fix the problem in way that will just work for most people, most of the time"). I there reason why you can't submit patch for type-c port to Armbian? You have better understanding of Armbian internals than I do, for sure.

 

1. I still have quite shallow understanding of Armbian's internals

2. I use most up-to-date kernel revisions all the time in experimental mode and those are always several month ahead of Armbian's I suppose

3. I'm not sure that forcing controller to host mode purposely is a right fix - I miss experience and knowledge for such decisions. I did it for my personal sake and my own risk and clearly admitted this in the message above :)

4. Submitting the code to community project - is about 100% confidence and responsibility for me

5. Just have a look on the DT overlays capabilities - this was designed to provide some decent scalability potential and could be good compromise for you ;)

Link to comment
Share on other sites

  • 0
On 5/6/2020 at 12:31 PM, balbes150 said:

No, I'm using a different kernel (from LE) with additional patches.

Ah, I got that wrong. Didn't know you were talking about Libre Elec. Just had a look at all your great work in the LE forums. Seems like you have a good understanding of our device. Any chance your work on the kernel in LE can be committed to Armbian, so we can all profit from it?

Link to comment
Share on other sites

  • 0
29 minutes ago, DerDave said:

Any chance your work in LE can be committed to Armbian, so we can all profit from it?

I wrote about Armbian. It all works (WiFi BT HDMI analog sound) and uses a common kernel with LE.

Including installation on eMMC and installation on NVMe, and run system in USB

Link to comment
Share on other sites

  • 0

Ah great! Thank you all, so much for all the hard work! Seems like it's time to try out the latest kernels again!

EDIT: @balbes150 I tried both Buster and Bionic with the latest available Kernels (5.6.10-rockchip64) but the wifi adapter still doesn't show up in my interfaces...
Is there anything I can do? I could really use the newer kernels, because I have a lot of problems on the legacy kernels, but I wifi is crucial for my setup. I don't care about HDMI or the 3.5mm Jack. Just a modern kernel and wifi.
Bluetooth also works by the way

EDIT2: I got it working with the hint, Martin gave in this post: 

Is there a way to implement this, so all devices can have wifi with a normal install?

Link to comment
Share on other sites

  • 0
15 hours ago, Oleksii said:

I'm not sure that forcing controller to host mode purposely is a right fix

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

Link to comment
Share on other sites

  • 0
19 hours ago, DerDave said:

Is there a way to implement this, so all devices can have wifi with a normal install?

This is already done for the ArmbianTV version. Everything works in it at once, without manual operations and with the kernel 5.7

 

 

Link to comment
Share on other sites

  • 0
10 hours ago, RussianNeuroMancer said:

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

 

It is not so obvious :( I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).

Link to comment
Share on other sites

  • 0
On 5/8/2020 at 9:33 AM, balbes150 said:

This is already done for the ArmbianTV version. Everything works in it at once, without manual operations and with the kernel 5.7

 

 

Great! Looking forward to see this trickle down to standard Armbian in the future!

Link to comment
Share on other sites

  • 0
On 4/25/2020 at 12:13 PM, balbes150 said:

Script for automatically enabling audio on all known ARM models (in my images, it runs automatically when the system is first started and includes all known audio devices for the model being used).

 

By the way, today, T4 has almost full support for all hardware (WiFi BT NVMe sound etc) and copes well with any tasks. It remains only to solve the issue with 4K resolution. :)

sound.shUnavailable

 

I was able to fix 4k resolution issue editing dtb to make hdmi use vopb as in rk3399 4k dtb fix

 

Hope it helps.

Link to comment
Share on other sites

  • 0
8 hours ago, mmendeza said:

I was able to fix 4k resolution issue editing dtb to make hdmi use vopb as in rk3399 4k dtb fix

 

Hope it helps.

Unfortunately, this is for the old core 4. as far as I understand, these parameters are already used on the new core.

 

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L1601

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399.dtsi#L1765

https://github.com/150balbes/Amlogic_s905-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi#L889

 

 

By the way, the latest version of Libreelec (20200512) has support for 4K decoding. I checked it on T4 - it works.

Link to comment
Share on other sites

  • 0
On 5/8/2020 at 2:08 AM, RussianNeuroMancer said:

Ok, I get why you won't to submit this change. Just want to notice that it looks like Type-C port is in host mode in case legacy 4.4 kernel and in FriendlyDesktop (I don't remember kernel version, probably 4.4 too). So it looks like Type-C is intended to run in host mode after all.

 

If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs :)

Link to comment
Share on other sites

  • 0
2 hours ago, RussianNeuroMancer said:

I briefly tested 5.7.6 kernel and found that Samsung 970 EVO still doesn't work with same PCIe link training gen1 timeout error.

 

Rollback to 5.4.49, and it works again.

 

My Transcend 110S SSD stoped working due to some driver changes in v5.4. But started to work again since next 5.5 :)

Link to comment
Share on other sites

  • 0
On 3/4/2020 at 12:55 AM, RussianNeuroMancer said:

While WD SSD, such as WDS200T3X0C, works just fine on both of Linux 4.4 and 5.3, SSD from Samsung, such as 970 EVO, works only with 4.4, but not with 5.3. Pci driver just fail to detect it, while on 4.4 same SSD works for half year without issues.

Issue with Samsung 970 EVO is no longer reproducible for me on uboot 2020.10 and Linux 5.10.

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...