NanoPC T4

[tkaiser]

 

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

[chwe]

15 minutes ago, tkaiser said:

Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here)

there's a link missing..  

 

15 minutes ago, tkaiser said:

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?

Question here, does a dev has all those RK3399 boards at hand to test them with a single kernelsource? I would prefer a 'not boardmaker related' kernelsource, therefore ayufan's or RKs own kernelsource might be the best way to go (hope that the missing bits can be added properly by patching the kernel). But I think it's time to discuss/decide it now, before all those boards get added into the buildsystem. 

 

21 minutes ago, tkaiser said:

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

Your turn @JMCC..  For whatever reason RockChip decided to remove all closed issues (and disabled it on github) on all their GPU/VPU userspace stuff. I really don't understand why they decided to act this way but it makes it harder to get a clue what problems are common for people who played with this stuff.  

[zador.blood.stained]

My 2 cents (thx to FriendlyArm and Igor for the sample)

 

Subjective pros:

• Lots of fast interfaces (PCIe, USB3 and Type C) with a pretty fast CPU
• Good software support (for the SoC), both BSP and mainline, we'll have to see if the audio chip and PMIC have good support too

Subjective cons / nitpicks:

• Type C can't be used for powering the board
• Finding an appropriate connector for the fan may be tricky, though it is understandable given the component density on the PCB
• Serial console baud rate (1500000) may not work with some USB-UART adapters (applies to all Rockchip SoCs and devices AFAIK), it was a bit disappointing that the default kit does not include a USB-UART adapter
• M.2 connector has a standoff for only one card form factor, though again it is understandable given the component density on the PCB 

Details to keep in mind:

• Some I/O interfaces are 1.8V only according to specifications

46 minutes ago, tkaiser said:

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?

I'm in favor of having a single kernel source(s) too (default - 4.4 BSP, next - kernel.org mainline, dev - maybe ayufan's mainline?)

I think (and hope) that the mainline kernel should be suitable for server and lightweight desktop usage scenarios, and hope that this device along with Odroid N1 and RockPro64 will get upstream DTs soon enough 

 

53 minutes ago, tkaiser said:

• heatsink too small for continous loads

... without active cooling, which is IMO a not a bad idea for this board, especially if you install a M.2 SSD on it.

[hjc]

56 minutes ago, zador.blood.stained said:

I'm in favor of having a single kernel source(s) too (default - 4.4 BSP, next - kernel.org mainline, dev - maybe ayufan's mainline?)

I think (and hope) that the mainline kernel should be suitable for server and lightweight desktop usage scenarios, and hope that this device along with Odroid N1 and RockPro64 will get upstream DTs soon enough 

It's too early to use the mainline kernel as "next". In fact, RK3399's situation is more or less similar to RK3328's 4.17 kernel right now, so a single mainline branch should be used as "dev".

 

1 hour ago, chwe said:

 

2 hours ago, tkaiser said:

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?

Question here, does a dev has all those RK3399 boards at hand to test them with a single kernelsource? I would prefer a 'not boardmaker related' kernelsource, therefore ayufan's or RKs own kernelsource might be the best way to go (hope that the missing bits can be added properly by patching the kernel). But I think it's time to discuss/decide it now, before all those boards get added into the buildsystem. 

I'd prefer ayufan's kernel, too. Rockchip's kernel development seems to be focusing on their newer low-end SoCs right now, and they usually break things (and maybe fix them in a few weeks after they found older SoCs are broken). Actually I don't understand why they're doing all active development in a branch called release-4.4. What Armbian needs right now is a solid branch optimized specifically for RK3328/3399.

[zador.blood.stained]

2 minutes ago, hjc said:

It's too early to use the mainline kernel as "next".

Is it? RK3399 .dtsi and the status matrix show a lot of supported HW features. But I didn't pay much attention to Rockchip development, so can you please name some roadblocks for getting at least server images with the mainline stack working? I'm not saying that we should immediately release mainline based images, I just indicated my opinion on next and dev kernel branch mapping.

[hjc]

2 minutes ago, zador.blood.stained said:

Is it? RK3399 .dtsi and the status matrix show a lot of supported HW features. But I didn't pay much attention to Rockchip development, so can you please name some roadblocks for getting at least server images with the mainline stack working? I'm not saying that we should immediately release mainline based images, I just indicated my opinion on next and dev kernel branch mapping.

Headless images already works, except big.LITTLE scheduling. AFAIK, there isn't a good solution for this in vanilla kernel.

For lightweight desktop, HDMI is a major problem (incomplete in status matrix, at least my monitor is not working well with RK3399 mainline).

 

 

[zador.blood.stained]

1 hour ago, hjc said:

For lightweight desktop, HDMI is a major problem (incomplete in status matrix, at least my monitor is not working well with RK3399 mainline).

And what about the

Quote

DP on Type-C: DisplayPort 1.2 Alt Mode on USB Type-C

Do you know if it needs additional software support on top of the base USB-C and whether it should be working already?

[JMCC]

5 hours ago, chwe said:

For whatever reason RockChip decided to remove all closed issues (and disabled it on github) on all their GPU/VPU userspace stuff. I really don't understand why they decided to act this way but it makes it harder to get a clue what problems are common for people who played with this stuff. 

Yes, It is a long and sad story, but boils down to RK not seeming to be very receptive to community comments/bug reports. I vote too for unifying Rockchip kernels, and I think that, since all kernels are so similar, we should consider as an important factor the communication with the upstream maintainers. About RK, as I said, I'm a bit disappointed. About Ayufan, I really admire his work, though being a single person I don't know how available he is to read and respond to issues, PR's, etc., but at least it seems like he has good communication with RK. And about Hardkernel, my experience has always been good in this regard (as in almost any other aspect too).

 

When I say unifying RK kernels, I vote for including RK3288 too (I'm talking about sorces, of course not patches and configs). That would save us lots of resources in dealing with upstream changes. For example, most of the enormous work that our maintainers are putting now into bringing the rockchip default kernel "back to life" consists in dealing with an upstream mess. So I think it would be positive if all the devs and contributors are fighting in the same front, instead of spreading our limited resources into two or three different source trees. But, of course, that depends on how comfortable is @TonyMac32 with switching to a slightly different kernel source for 3288.

If we decide to go the way of unifying, HK will focus on 3399, but Ayufan covers also 3328, so probably the latter is a better option.

 

6 hours ago, tkaiser said:

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

I've had a surgery last week, and only had some time today to deal with an old RK3328 bug, but I'll try to give a good look to the board multimedia-wise in the next days, and report.

[hjc]

15 hours ago, zador.blood.stained said:

Do you know if it needs additional software support on top of the base USB-C and whether it should be working already? 

Haven't got that working even on legacy kernel. Maybe it's a kernel configuration issue.

[TonyMac32]

On 6/17/2018 at 11:28 AM, zador.blood.stained said:

(applies to all Rockchip SoCs and devices AFAIK)

Seems to be an RK33xx issue, the RK3288 is 115200 like any sane serial terminal.

 

On 6/17/2018 at 12:39 PM, hjc said:

and they usually break things

tell me about it. 

 

On 6/17/2018 at 12:39 PM, hjc said:

What Armbian needs right now is a solid branch optimized specifically for RK3328/3399

 

Agreed. 

On 6/17/2018 at 4:30 PM, JMCC said:

I think it would be positive if all the devs and contributors are fighting in the same front, instead of spreading our limited resources into two or three different source trees

I agree.  I'm not against "slightly different", I just need to see stable.  I don't want a "commit bomb" destroying my kernel config and making it impossible to repair without major issues.

[hjc]

2 hours ago, TonyMac32 said:

 

On 6/18/2018 at 12:39 AM, hjc said:

and they usually break things

tell me about it. 

See this and this, they just silently broke all RK3399 boards, and then silently fixed it. This change even stops the UART from working so one cannot diagnose what's wrong. This is all done in the release-4.4 branch, and they seldom use tags, so I doubt they're not testing their code on various boards.

Besides, they put both Mali Android and (old, not updated) Linux drivers in the kernel, and their modifications to rk3399.dtsi broke the Linux one, since they switched to the new power model. If you use an old kernel config, it will cause a kernel panic after you update the kernel. They finally completely removed the old Mali Linux drivers recently, and their CONFIG_MALI_MIDGARD_FOR_LINUX/CONFIG_MALI_MIDGARD_FOR_ANDROID disappeared.

[tkaiser]

7 hours ago, hjc said:

See this and this, they just silently broke all RK3399 boards, and then silently fixed it. This change even stops the UART from working so one cannot diagnose what's wrong. This is all done in the release-4.4 branch, and they seldom use tags, so I doubt they're not testing their code on various boards.

 

I don't think this group of Rockchip engineers working in these github repos is aware what's happening outside (various open source communities using their kernel sources for a bunch of RK devices). Yesterday I dropped a quick note to Kever Yang (AFAIK he's in charge of some of RK's open source activitities) but got no answer yet.

 

Edit: got an answer almost immediately, just found it in another inbox now. Let's wait and see  

[TonyMac32]

4 hours ago, hjc said:

Besides, they put both Mali Android and (old, not updated) Linux drivers in the kernel, and their modifications to rk3399.dtsi broke the Linux one, since they switched to the new power model.

Same for RK3288, that's why so many issues around Tinker board have popped up, woke up one morning and the kernel config no longer worked, Mali was trashed, etc.

[chwe]

3 hours ago, tkaiser said:

I don't think this group of Rockchip engineers working in these github repos is aware what's happening outside (various open source communities using their kernel sources for a bunch of RK devices).

https://github.com/rockchip-linux/kernel/issues/98 

 

It's not that they don't get some feedback for their action..   But when you've to pray to god after every module that it still works.. It's not that much fun.. If you go down the whole rabbit hole on weekends and on monday your config from saturday has one or two config issues again it starts to piss you..  I do like the idea of having one branch for all their SoCs. but then this needs extensive testing. Who ever found this here (https://github.com/rockchip-linux/kernel/blob/40e877458b0dd3fedc39afc8c2a8e428adafc858/arch/arm/boot/dts/rk3288-linux.dtsi#L10-L12 btw @TonyMac32 we may need it partly due to dmc nodes are now here.... ) a good idea obviously doesn't think about that there are others may get fooled by this (why not set it as kernel bootarg with the 'overrule by u-boot bootargs - flag'? wouldn't hurt any other project). 

 

The first time I played with the ISP-driver I was quite surprised how fast they react on github, now this is more an AA-group model...

 

Btw, let me know if I should split it to a 'which RK kernel should we use?'-thread. IMO this affects all or at least also other RK based boards. 

 

[TonyMac32]

19 minutes ago, chwe said:

we may need it partly due to dmc nodes are now here.... 

My old patch simply eliminated it, now I'll just have to kill off that section of it.

[tkaiser]

1 hour ago, chwe said:

https://github.com/rockchip-linux/kernel/issues/98

 

Well... by looking at the (closed) pull request it becomes even more obvious that the RK people owning this github repo don't have an idea how to deal with the world outside. They don't care about the state of this kernel tree breaking stuff most probably since their internal work style is totally different from ours.

 

I would continue to discuss this stuff here since i sent Kever Yang only a link to this thread right now...

[TonyMac32]

Good idea.  I should be able to start working on this again once my vehicle repair is finished, the weather has worked against me so far.  

[kevery]

I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.

 

The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.

 

I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.

 

Here is the information about Rockchip source code:

- Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;

- Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 

- Rockchip kernel is now 4.4, and will update to next LTS;    

  We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.

- Rockchip kernel is used for Android and Linux OS;

- Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP

     * that's why we not able to merge the pull request, we have to review all the source code internally;

     * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;

- Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;

- Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.

    We will fix issues really need to fix, people don't want to get a kernel always have the same issue.

- We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.

 

    About the common kernel for community, here is my suggestion:

- Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;

- Developing, apply patches for new board support, switch some of module to upstream driver, and so on;

- Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;

- If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;

- maybe a mailing list is needed for better communication?

[TonyMac32]

Thank you for the reply.

 

My only real issue so far has been the large changes with no documented, it's caused a huge disruption to my use of the BSP, specifically the Mali changes.  Another example was getting rkwifi drivers working, the documentation on how to configure the kernel seemed to only be available in the commit message for the adjustments.

 

With some documentation these large changes wouldn't cause as many issues.

 

As far as specific board support, I understand not supporting everything, this is the sort of decisions we are all familiar with.  I can easily maintain a patchset as long as the underlying BSP stays stable.  For hardware like the miniarm, as an example, there are some workarounds that should not be part of the BSP.

[kevery]

@TonyMac32So I think you want a change log for kernel? We have no experience for it now, is there good reference from other vendor's BSP, and I will try what I can do.

[TonyMac32]

Well, it doesn't necessarily have to be a change log, simply keeping the kernel documentation and the kconfig notes current and accurate would be a huge help, like I said sometimes the only way to figure out a kconfig issue is to dig into the commit history for the feature that is changing, and even then sometimes it is simply luck (building Mali as a module seems to be mandatory, at least at my last check. This was not the case before and it still allowed other options ).  

 

As far as other vendors go, I believe Rockchip has the most open development as far as that goes, others keep it more secretive and release snapshots.  For Amlogic the BSP / buildroot is released periodically with a report detailing the results of a group of tests they perform on the kernel like reboot cycling, drivers, etc, that's the only one I can directly comment on.

[tkaiser]

On 6/21/2018 at 9:42 AM, kevery said:

Github source code is a special 'Linux SDK',

 

Thanks a bunch for this explanation, Kever. I think it pretty much explains a lot of the annoyances developers ran into. Also thank you for your other explanation and suggestions.

 

Though I'm a bit disappointed about lack of other developer responses.

 

Anyway, to get back on (our) topic.

 

We have the following 'BSP' branches for RK3399 boards right now:

• RK's own: https://github.com/rockchip-linux/kernel/tree/release-4.4
• Firefly's repo for their RK boards: https://gitlab.com/TeeFirefly/linux-kernel/ (If I understood @hjc correctly also based on an older RK 4.4 kernel?)
• Hardkernel's for their canceled ODROID N1: https://github.com/hardkernel/linux/tree/odroidn1-4.4.y (AFAIK a fork of RK's 4.4 but rebased on 4.4 kernel.org version)
• ayufan's: https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4 (forked and rebased from RK's 4.4 recently)
• FriendlyELEC's for NanoPC T4/NaniPi M4: https://github.com/friendlyarm/kernel-rockchip/tree/nanopi4-linux-v4.4.y (older fork from RK's 4.4 with some device specific additions for now)
• What else?

With mainline we have:

• true mainline
• Heiko's branch: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
• Heinrich Schuchardt's Firefly RK3399 repo: https://github.com/xypron/kernel-firefly-rk3399

Ayufan said he would be happy to open up his repo for other contributors: http://irc.pine64.uk/?date=2018-06-21 08:03:47 (change the channel to #Rock64 via the menu). TL Lim also added he is for unifying development efforts (stopping developers from wasting their time reinventing the wheel over and over again). Is this addressing your concerns @JMCC?

 

So how to proceed? To me it seems possible to use one single BSP kernel for all three RK 'open source SoCs' but I'm not into any details at all. 

 

[JMCC]

Well, let's take a break from important decision-making, and post some benchmarks about VPU/GPU. I have used the official FriendlyELEC's Ubuntu Xenial image, kernel 4.4.126, 32-bit architecture. That allowed me to easily create a media configuration script, based on the existing RK3288 one. All tests were done with "performance" governor, both in CPU and GPU.

 

The 32-bit script can be downloaded here. It is not yet a release version, so there may be some rough edges. If the community demands it, I might create a 64-bit version in the future.

 

1. VPU 4K Video Decoding capabilities

I'll make a chart comparing NanoPC-T4 (RK3399) with ASUS TinkerBoard (RK3328) and Khadas VIM2 (Amlogic S912). Rockchips acceleration was tested with our well-known MPV, while for Amlogic we used @balbes150's LibreElec:

BOARD		H.264	HEVC	VP9	HEVC-10	VP9-10
------------------------------------------------------
TB (RK3288)	✓	✓	x	x	x
T4 (RK3399)	✓	✓	✓	✓	x
VIM2 (S912)	✓	✓	✓	✓	✓

The first thing to comment here is that VP9 10-bit HDR video playback is not supported by the board, which on the other hand is in accordance with Rockchip's official specs. HDR is only supported for H.264 and H.265 (we didn't test the former, though, but we can assume it works if the latter does). It should not be a software issue, since we tested also in Android with the Rockchip Media Player App, and we only got a messagebox saying "10-bit video is not supported". So, in this aspect, RK3399 is inferior to the competitor's S912, which can play VP9-HDR10 videos.

 

Besides that, all supported videos played with perfect smoothness and vivid colors.

 

2. GPU OpenGL-ES & WebGL

Time for 3D capabilities of the Mali-T860 with 4 cores @800 Mhz. As references for the comparison, we chose this time the TinkerBoard (Mali-T760, 4 cores@600), and the Odroid XU4 (Mali-T628, 6 cores@600). All three malis share the Midgard architecture, though they represent the first, second and third generation. We didn't use this time the S912, because it has no Linux Mali support, plus performance would be much lower with only 3 cores. Kernel for TB is Armbian's 4.4.131-rockchip, while for XU4 is 4.14.30. For the Rockchips we used their custom X server with Glamor enabled, while for XU4 we used Crashoverride's armsoc X driver:

Results are in frames per second:

BOARD		Glmark2-X		Glmark2-offscreen	WebGL Aquarium (Chromium)
-----------------------------------------------------------------------------------------
TB (RK3288)	57			547			30-34
T4 (RK3399)	52			340			33-36
XU4 (S5422)	428			747			39-44

In the first place, Rockchip's X server seems to be better tuned for the RK3288, where we see that FPS almost match the Vsync (60 FPS). In the case of RK3399, we see it is significantly lower, while we also see tearing that does not happen with the other Rockchip SoC. XU4's driver works in a different way, and so it is not limited by Vsync, but nevertheless it doesn't show any tearing.

Offscreen performance is strangely low in RK3399 (probably a matter of a not-so-well tuned Mali binary?). WebGL performs better in 3399 than 3288, but the difference is not as big as one should expect considering the superiority of both CPU and GPU. XU4 clearly sticks from the others.

 

3. GPU OpenCL performance

Now OpenCL performance with GPU miners. That can give us a better idea of the raw processing power of the GPU since there are no X drivers getting in the way. We used cgminer for the skein algo, and sgminer for lyra2rev2. Results are averages from running the miner for two hours, with an intensity as high as possible monitoring that no hardware errors happened.

BOARD		Skein (Mh/s)	Lyra2rev2 (Kh/s)
------------------------------------------------
TB (RK3288)	1.150		42
T4 (RK3399)	1.150		60
XU4 (S5422)	1.440		72

It is shocking that performance in Skein algo is about the same for RK3288 and RK3399, but using CPU miners for the same algorithm the TinkerBoard  also gives surprisingly high numbers (higher than XU4). For that reason, I think there must be something in the TB that makes it specially suited for Skein (maybe the dual-channel RAM?), so results must be taken carefully. On the other hand, Lyra2 numbers are more or less as expected.

 

 

Remember that all these tests are made in a armhf system. Maybe arm64 can give us some surprise in the future. Or maybe Rockchip can make improvements to their binaries/libraries giving better performance.

[JMCC]

23 minutes ago, tkaiser said:

So how to proceed? 

Sorry @tkaiser, you posted while I was typing my benchmark results and I didn't notice it. I didn't mean to "bury" your post 

[TonyMac32]

@JMCC Nice review, I still need to get my system running... :'(  

 

@tkaiser, there is very little "special" with the rk3288 boards we support, the Tinker patches have been carefully (well, as carefully as I can manage) tailored to not harm the operation of other boards (the Tinker Reboot is a nasty one, it's hackish code that I wrapped with a device tree check conditional execution).  The MiQi is basically just a Rockchip development board, nothing strange to get in the way. 

 

I would support a common BSP kernel for all the devices, for Mainline though I would recommend using straight official mainline and grab patches for the important things from the "almost mainline" or "will wind up in mainline" repos (easy for me to say when the RK3288 is almost perfectly supported at this point).

 

 

[JMCC]

25 minutes ago, tkaiser said:

Is this addressing your concerns @JMCC?

Definitely. After your remarks, I think Ayufan's is the best option, for the following reasons:

• After @kevery's clarifications, it seems like RK upstream aims at a purpose that does not fit Armbian's needs.
• Hardkernel's is dead ATM, and we have no clue what N2 will be like (maybe not even Rockchip).
• Firefly's and FriendlyELEC's can end up being similar to ASUS, where they choose to stay with an older version of the kernel/drivers and patch them. Not what Armbian does normally.
• Ayufan's main difficulty is that, being driven by a single person, the project could die if for any reason he cannot take care of it any more. But being open to external contributions somehow prevents that situation, since there would be more people closely familiar with the source tree who could be able to continue the work. And also, since his work and Armbian's is so close (we are already using his kernel for RK3328), transition would be relatively easy.

The only drawback could be that @TonyMac32 would need to check all his patches against that kernel (it currently does not support RK3288), but I think that would be a piece of cake compared to what he is doing now trying to put order in RK's upstream kernel.

[TonyMac32]

2 minutes ago, JMCC said:

would need to check all his patches against that kernel (it currently does not support RK3288)

 

Well, thanks to the current state of the Rockchip kernel I need to check all of my patches anyway, so it's not a huge obstacle.  ;-)

[Myy]

Do you need to flash another U-boot to be able to input something during initialization, when starting from the Android Nougat image ? (´･ω･　`)

I'm able to read the input but not send anything and quite frankly the boot phase is FAST. Less than 1 second to react.

 

Also is minicom the best tool for the job ? It seems recommended on FriendlyArm Wiki but... Even though I've used it a lot with the Tinkerboard and MiQi, it still feels clunky.

[Myy]

It seems that Picocom did a better job for transmitting input. Still, that seems to require an awful lot of tinkering to get it working with a Linux system... I guess I'm missing something.

[Doug Drealer]

Prebuilt image can be found here