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

wasn't there a switch between rk3399 and rockchip64  (sources) for the T4. Rockchip64 uses u-boot from ayufan based on rockchips one whereas rk3399 uses mainline u-boot. They may have a difference in definition of 0/1 for eMMC/SD-Card?

Link to comment
Share on other sites

Check forum guidelines to use maximum potential!

  • 0
On 6/17/2018 at 8:26 AM, tkaiser said:

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)

 

 

Has anyone tried a 2 or 4 port SATA controller in the M.2 slot? Does it work? What is the most streamlined way to run power to 3.5" drives in this setup?

Link to comment
Share on other sites

  • 0
48 minutes ago, Jason Law said:

Has anyone tried a 2 or 4 port SATA controller in the M.2 slot? Does it work?

 

Nope and I don't think so. I wanted to try the same, did some research and ended up with an Amazon review from someone trying this with the Firefly RK3399 saying the Marvell 9235 adapter he had has some components on the bottom that make it impossible to use it on the board without shorting something. These things look like this:

 

201801231409528235.jpg

 

And then on NanoPC-T4 there are only mounting holes for 2280 while the SATA adapters are all 2242. So unless you get a PCIe extender somewhere the M.2 slot is 'SSD only'.

 

Are you aware that FriendlyELEC will provide the below for NanoPi M4 soon (also solving the powering problem):

IMG_1132.jpg

 

 

Link to comment
Share on other sites

  • 0
3 minutes ago, Jason Law said:

how will this connect to the M4?

 

It's a HAT so you simply mount in on top of the NanoPi using 4 spacers so GPIO headers make contact. Since NanoPi M4 is one of the few SBC that have the SoC on the appropriate side of the PCB (the lower one) attaching HATs does not negatively affect heat dissipation.

 

(still hoping that the final version of the HAT will also use a 40 pin male header so the GPIOs on this header can still be used)

Link to comment
Share on other sites

  • 0

New guy here.  Sorry if I'm in the wrong place.  I followed the link from the Armbian.com /nanopc-t4/ page.

 

Issue #1:

 

Lots of this in /var/log/syslog, but otherwise working fine:

 

Sep 28 21:13:18 localhost kernel: [ 2203.794730] _tdata_psh_info_pool_deq 200: Out of tdata_disc_grp
Sep 28 21:13:18 localhost kernel: [ 2203.794745] dhd_tcpdata_info_get 1092: No more free tdata_psh_info!!
Sep 28 21:13:19 localhost kernel: [ 2203.924558] _tdata_psh_info_pool_deq 200: Out of tdata_disc_grp
Sep 28 21:13:19 localhost kernel: [ 2203.924578] dhd_tcpdata_info_get 1092: No more free tdata_psh_info!!
Sep 28 21:13:19 localhost kernel: [ 2204.283677] _tdata_psh_info_pool_deq 200: Out of tdata_disc_grp
Sep 28 21:13:19 localhost kernel: [ 2204.283696] dhd_tcpdata_info_get 1092: No more free tdata_psh_info!!
 

I am on the most recent release:

 

Welcome to ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.4.156-rk3399
System load:   0.14 0.04 0.01   Up time:       1 min
Memory usage:  2 % of 3811MB    IP:            192.168.1.162
CPU temp:      51°C
Usage of /:    10% of 15G

 

Originally installed 5.59 via SD card then moved to eMMC boot using armbian-config.  5.59 had the same syslog messages.  Upgraded to 5.60 using armbian-config

 

Details at:  http://ix.io/1nO0

 

Issue #2

 

Generic Amazon mSATA M.2 2280 60GB doesn't show up.   Let me how/where I can provide any more info.

 

Thanks to the devs for all the great work.

 

 

 

 

Link to comment
Share on other sites

  • 0
3 hours ago, SMburn said:

Generic Amazon mSATA M.2

 

Please be very careful with these wordings. M.2 is not mSATA. M.2 is just a mechanical connector able to transport a bunch of different protocols. In case you have no other device suited for an M.2 SATA SSD you might want to have a look at https://jeyi.aliexpress.com/store/group/USB3-0-USB3-1-Type-C-Series/710516_511630295.html for external USB3 enclosures (to get a bulky but ultra fast 'USB pendrive'). But since a 'generic' 60 GB SSD will perform crappy anyway and you talked about Amazon the best you could do is to return such a thing right now.

Link to comment
Share on other sites

  • 0
19 hours ago, hjc said:

The M.2 connector on T4 does not support SATA, so you should get an NVMe SSD.

 

Thanks for schooling me on this.  My SATA stick is keyed for both M and B connectors.  My clearly wrong ASSumption was that if it fits, it works.

 

19 hours ago, tkaiser said:

In case you have no other device suited for an M.2 SATA SSD you might want to have a look at..

 

Thanks.   With that, my car audio system USB input will now get a music library source that that isn't mobile phone dependent. 

 

Returning to my other issue:

 

23 hours ago, SMburn said:

Sep 28 21:13:18 localhost kernel: [ 2203.794730] _tdata_psh_info_pool_deq 200: Out of tdata_disc_grp
Sep 28 21:13:18 localhost kernel: [ 2203.794745] dhd_tcpdata_info_get 1092: No more free tdata_psh_info!!

 

Is there any more info I can provide, or is this a known thing that's being worked on and I just need to relax?

 

Thanks again for your help.

 

 

Link to comment
Share on other sites

  • 0

currently i'm trying to load a dtbo to 4.19-rc4. attachted dts works and results in loading modul adv7180.

/dts-v1/;
/plugin/;

/ {
        compatible = "friendlyelec,nanopc-t4", "rockchip,rk3399";

        fragment@0 {
//              target = <&i2c1>;
                target-path = "/i2c@ff110000";
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        adv7282-m@20 {
                                status = "okay";
                                compatible = "adi,adv7282-m";
                                reg = <0x20>;
                                device_type = "v4l2-i2c-subdev";

//                              powerdown-gpios = <&gpio2 28 1>;// 92
//                              reset-gpios = <&adv_gpio2 27 1>;        // 91
                        };
                };
        };
};

i need some advices for
- referencing by phandle (like target = <&i2c1>)
- defining gpios (commented out gpios)

 

Link to comment
Share on other sites

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

 

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

  • 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')

 

This worked for me, when using the right device for the zero source

  • 'dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=64 ; sync'
Link to comment
Share on other sites

  • 0
On 10/13/2018 at 3:08 PM, habeIchVergessen said:

  		fragment@0 {
                target = <&i2c1>;
...
  				adv7282-m@20 {
...
                              powerdown-gpios = <&gpio2 28 1>;// 92
                              reset-gpios = <&adv_gpio2 27 1>;        // 91

dtb files included in kernel source tree needs to be build with __symbols__ node (dtc -@ ...). just modified the dtc command in scripts/Makefile.lib.

entries in __symbols__ node are required to be able to resolve existing phandle.

 

 

Link to comment
Share on other sites

  • 0

I see multiple people facing issues with the OS on eMMC. Is it safe to "Etcher" the ROM below to a SD card,  apt update && apt upgrade, followed by a nand-sata-install in the armbina-config utility?

ROM: OMV_4_NanoPC_T4.img.xz (2018-10-09) (source)


Or could I install the ROM directly onto the eMMC by following the proces 'Flash Image under Windows with Type-C Cable' (FriendlyARM wiki)? The wiki mentions "images-for-eflasher" so I'm unsure if the ROM needs to be specifically prepared to enable this flashing method.

 

Link to comment
Share on other sites

  • 0
On 11/2/2018 at 11:51 AM, Alexio said:

I see multiple people facing issues with the OS on eMMC. Is it safe to "Etcher" the ROM below to a SD card,  apt update && apt upgrade, followed by a nand-sata-install in the armbina-config utility?

ROM: OMV_4_NanoPC_T4.img.xz (2018-10-09) (source)


Or could I install the ROM directly onto the eMMC by following the proces 'Flash Image under Windows with Type-C Cable' (FriendlyARM wiki)? The wiki mentions "images-for-eflasher" so I'm unsure if the ROM needs to be specifically prepared to enable this flashing method.

 

I didn't have problems with eMMC-Installation. I booted from SD-Card and used armbian-config to install to eMMC. No need to use other flash methods.

Link to comment
Share on other sites

  • 0
On 11/2/2018 at 11:51 AM, Alexio said:

I see multiple people facing issues with the OS on eMMC. Is it safe to "Etcher" the ROM below to a SD card,  apt update && apt upgrade, followed by a nand-sata-install in the armbina-config utility?

ROM: OMV_4_NanoPC_T4.img.xz (2018-10-09) (source)


Or could I install the ROM directly onto the eMMC by following the proces 'Flash Image under Windows with Type-C Cable' (FriendlyARM wiki)? The wiki mentions "images-for-eflasher" so I'm unsure if the ROM needs to be specifically prepared to enable this flashing method.

 

 

Hello, I'm one of those people I'm not sure which steps to follow to install OMV on emmc.

Could someone kindly explain the steps ?

 

- flash the img on SD card with etcher / or use Linux_Upgrade_Tool_1.27 ?

- insert sd card and boot ? (-> nothing happens on screen.)

- use that nand-sata-install tool / how ?

Link to comment
Share on other sites

  • 0
On 12/13/2018 at 11:25 AM, pudding said:

 

Hello, I'm one of those people I'm not sure which steps to follow to install OMV on emmc.

Could someone kindly explain the steps ?

 

- flash the img on SD card with etcher / or use Linux_Upgrade_Tool_1.27 ?

- insert sd card and boot ? (-> nothing happens on screen.)

- use that nand-sata-install tool / how ?

Out the top of my head, here's how I did it:

1. Flash image provide on ARMbian page using Etcher

2. After successful flash insert SD card and boot

3. Find out what the IP of your system is (you can use for instance Angry IP scanner or login to your router which handles the IP's)

4. Connect via SSH to this IP (first start requires password change)

5. Run the code below

nand-sata-install

6. Select EMMC and (I believe) the preferred filesystem

7. Wait some time

8. Turn of your system, remove SD card and power system back on

Link to comment
Share on other sites

  • 0
On 8/16/2018 at 4:34 AM, s_frit said:

 

Are the heatsink mounting holes compatible with "every Northbridge cooler with a mounting hole distance of 60 mm" as for the RockPro64?

It's around 56mm, and very tight. I stuck a 4-position housing with a couple blank sockets (to hold it in place) on the ADC connector to avoid any possibility of contact with the heat sink bracket (the fifth pin is a ground, and I happened to have the 4p housing). Threaded inserts are 2.5mm for the heat sink (M.2 is 3mm, i.e. standard). I trimmed a couple #4 nylon washers for the back of the board (to clear components).

Photo (2MB JPG): http://www.tailbone.net/p1000325.jpg

I'd cover the GPIO header, too, but I ditched all of my 40p housings years ago (unless I still have some 40p -> 80 wire ATA housings somewhere...).

So the Thermalright HR-05 (non-IFX, old mounting hardware, long discontinued) works with minor modifications. Something like the Enzotech CNB-S1 would likely work if you trimmed the mounting ears (and didn't mind spending $30); I don't believe there are any high/tall components within about 20mm of the CPU center, but that's the limit. The Enzotech R1 is too large (in diameter), for instance; the Zalman Flower would be as well. There's not much of a selection any more, since PC chipsets are simpler devices these days. (I have an old K10 with an nVidia MCP55 Pro chipset with an HR-05 IFX on it that runs a bit hotter than the RK3399.)

As always, YMMV.

Link to comment
Share on other sites

  • 0

Just a side note here : Is there any nightly build NanoPCT4 users who are using 4.19.y builds on eMMC ?

 

I ask that because I've some local patch for months that I never committed related to eMMC, which in my case was required since my T4 have an older eMMC, I had to comment those lines in DT :

 

//mmc-hs400-1_8v;

//mmc-hs400-enhanced-strobe;

Link to comment
Share on other sites

  • 0

FYI 5.0-rc1 works on NanoPi M4 with this DT,  Bluetooth works with this instruction:

 

The missing bits are Wifi and I think for GPU/VPU a new mali userspace is needed.  ops, no mali or VPU ready on linux-next, sorry.

 

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.
The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:

 

Link to comment
Share on other sites

  • 0
11 minutes ago, xauser said:

I've read somewhere that the armbian nanopc t4 kernel is overclocked. Since my t4 is in a metal case without a fan I want to ask if there is an easy way to downclock it or do I have to modify the kernel sources for this?


No need. Just edit /etc/default/cpufrequtils and lower MAX_SPEED following by:

service cpufrequtils restart

 

Link to comment
Share on other sites

  • 0
8 hours ago, Teal said:

Has anyone tried the M2 slot yet?


On T4? Yes, it works on legacy 4.4.y kernel and its (ATM) broken on 4.20.y

 

8 hours ago, Teal said:

I plan to install a riser card, like this one m2 riser card  and install a non-raid SATA Controller to get native SATA Ports. Might this work?


It should.

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