NanoPC T4 from FriendlyArm

I’ve been itching to say SOMETHING about this new SBC board from FriendlyArm. This  clearly is not meant to compete with the Raspberry Pi – not at the price –it is meant to blow it away. The NanoPC-T4 is “by far the smallest RK3399 based high performance ARM board with popular ports and interfaces” according to FriendlyArm.

At 100mm x 64mm the board is comparable to other SBCs out there but comes complete with 4GB RAM, 16GB eMMC, 4K video, 2 camera inputs, USB3, Gigabit Ethernet and so much more, at a correspondingly premium price.

NanoPC T4 SBC

Dual band WIFI and a full standard PCIe interface which supports an VNME SSD high-speed hard drive.

The T4 unit supports GPU and VPU acceleration with Android 7.1 and Ubuntu Desktop. Dual camera interface, mini-DSI and eDP display interfaces along with HDMI 2.0

Type-C-DP, USB 3.0, UDB 2.0, MicroSD, 3.5mm audio jack, IR receiver, AD input, serial debug and 40 pin “RPI-compatible” interface… the list goes on.

T4 board

Let’s see: Bluetooth  4.1 (I could go on forever but this WIKI covers all the spec so here it is – lots and lots of info): the T4 WIKI has enough info to keep you reading for some time. Note the power jack is 12v, not (as you might expect) 5v. In the WIKI you will also find images for e-flashing. I’m assuming that Armbian will have something available before too long (but check in case I’m wrong). I’m happy in this instance with Android 7.1

I have no doubt the T4 will make an excellent (if somewhat more up-range than usual) addition to the FriendlyArm range of boards and to test that I took their installer software which installed Android 7.1 on the board. Everything worked first time and blazingly fast at that. With 16GB of eMMC and 4GB RAM, the board will also handle USB3 and PCIe so if I decide I need somewhere to store movies, I don’t expect any problems.

Infra-red receiver is built-in. What a great start and according to the manufacturer, 4K should be no problem.

I've fitted the "case" which comprises nothing more than top and bottom Perspex panels, bolts and spacers but still protects the board and my new media centre is almost ready to test on my new 4K TV.

Update August 4, 2018 - Android seems to have screen overscan issues, is not rooted and at first I could not access the screen settings to fix. At this point not impressed.  Software will make or break this expensive board... eventually I used ADB on my PC to resolve the problem but many users will not know how to do this.  The PC ADB software comprises a single ZIP file from xda-developers.com - https://www.xda-developers.com/install-adb-windows-macos-linux/

Once installed on the PC, if you have turned on USB debugging on Android, and connected the PC and Android boxes by USB, then for example from the PC command line:

adb shell wm overscan 30,20,30,20

The 4 values will depend on the level of issue you have with your monitor - the values are x1,y1, x2,y2. Positive values pull in more info from the edges, negative values hide more info, 0 resets the offset to 0.

Once you get started it is easy and does NOT need any kind of Android rooting. There are other commands you can use but this solved my problem and the changes survive power cycling.

Facebooktwittergoogle_pluspinterestlinkedin

39 thoughts on “NanoPC T4 from FriendlyArm

  1. as said by email, i don't see the point of such pricey devices... 129$ is MADNESS...

    https://www.cnx-software.com/2018/05/23/rockchip-rk3399-sbc-nanopc-t4/

    i can buy a windows pc with equivalent ram+emmc for less than that, and get rid of it and place ubuntu with all the bells&whistles... no gpio, but who cares? I can attach an arduino nano via usb and have whatever i want externally, or even get data via mqtt from devices on the network...

    https://www.amazon.co.uk/Desktop-x5-Z8350-Graphics-Support-Windows/dp/B079BSX22F/

    video at 4k? Who cares... i can buy an android box dedicated to media playing, or even use whatever media enabled NAS to do the same...

    1. I must agree. At something around <$50 this would be a killer SBC (even having half the RAM and a blobbed legacy kernel). At $129 (+ import expenses) - who cares?

    2. Joining the RK3399 experience starts at 60 bucks currently with RockPro64 2GB variant (though this is just the board and not already a kit as sold by FriendlyELEC). My 4GB dev sample arrived yesterday and now software work begins (though first OS images already available for testers).

      But even at this price point it's still searching for use cases 😉

      1. Mr. Kaiser, I'd be happy to be a tester for the armbian for this board. Any pointers where it is, and what I need to do for you to help?
        thanks
        Jim

        1. You can build Armbian yourself by checking out hjc's repo. Links in https://forum.armbian.com/topic/7498-nanopc-t4/

          Currently it's way too early to 'test' anything Armbian on any RK3399 board since hjc's work is just a demonstration how easy it has become to add a new board to Armbian's build system.

          The hard work is to decide which kernel to use and how to maintain/improve sources (everything important happens below the distro layer). But if you read through the referenced thread at least Rockchip is now aware of the issues external open source communities face and hopefully situation will improve.

          Anyway, the 2 images (Debian Stretch and not Ubuntu) I built you'll find at http://kaiser-edv.de/tmp/VRy83B/ in 15 minutes. But it's too early for feedback as explained. This is just an early PoC to identify in which areas more work is needed.

    3. What you can buy and what you can fit in a fixed space and power budget are two different things.

      I can buy a used HP server with a pair of 10 core chips and 128G if RAM and 20 of the 15K RPM drives and 10G Ethernet. It will take 2500 Watts and make a hell of a noise. So I shouldn't get a NanoPC for a server in my diving seacopter?

  2. I've been using the 8 core Nano-PC T3 Plus (2GB RAM) for a commercial project running a custom Android build and it has been super reliable. I've added GSM support so I have full wireless connectivity with it and using either the 4.3" or the 7.0" LCD's I have a couple of display options too, and it is half the price of the T4.

    1. Yeah, there exist definitely use cases for RK3399 devices and in some areas something like the NanoPC-T4 above is even unique.

      It's just not another 'Android TV box' or KODI thingy (as many SBC are used) and you clearly don't want to blink a led with it since too expensive.

      RK3399 allows for 2 camera inputs with up to 13 Mpixel each (and contains IP blocks to deal with this -- hardware encoding). For example up to 4 different displays are possible (USB-C here supports an alternate mode carrying DisplayPort).

      And one of the most interesting features of the SoC that is fully exposed here, Pete didn't even mention. RK3399 contains a PCIe implementation (x4/Gen2) that is exposed as M.2 key M slot which allows for insanely fast storage access with a NVMe SSD.

      We have numbers already: Up to 1600 MB/s (or 45 times faster than a Raspberry Pi) and random IOPS as high as you like (or want to pay for a premium NVMe SSD): https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350

      You can't do the same with a cheap Z8350 Intel box since the Intel SoC is limited to a single Gen2 PCIe lane (same with cameras).

      So it's all about use cases and for sure they exist. Most probably this board will be used as part of commercial projects (and in most cases not relying on Linux but running with Android even though Rockchip actively upstreams RK3399 Linux support. Almost every day mainline kernel patches appear dealing with the many aspects of this SoC)

      1. I am going to use it for a small footprint and small power simh and hercules server, (I hope).

        Also hopefully a capable general use Ubuntu as well

      2. I didn't mention lots of things as I wasn't aiming that particular blog t folk with nothing better to do than rip apart operating systems but more at people who are focussed on using applications on ready to go Android.

      1. Be careful with Orange Pi designs that do not receive 3rd party / community support (as it's the case with their 2G/3G/4G 'IoT' boards). I wouldn't be surprised if only one display with a specific resolution works and nothing else (without you needing to recompile the kernel with settings you would need to discover on your own before).

        FriendlyELEC on the other hand provides full software support for all their various LCDs. They even invented an own (and proprietary) 'onewire' protocol that allows the display to tell its features to the connected board. Their u-boot releases then recognize the display at boot then automagically setting up the appropriate kernel cmdline and both Android and Linux that get then started come up with fully working LCD display (touch included!).

        Just tested this with my freshly arrived NanoPi Fire3 (greatest bang for the buck currently!) and a FriendlyELEC LCD that was lying around. Burned their Ubuntu image, connected the display, booted and able to use LCD with touchscreen without any hassles.

        This is one of the areas where FriendlyELEC really shines 🙂

          1. Something that's also missing in the description above: NanoPC-T4 as all the other RK3399 with Wi-Fi features non-crappy wireless network connectivity.

            It's not just dual-band but also dual-antenna so in combination with a good 802.11n or better 802.11ac (with beamforming) in 5 GHz band with 2x2 MIMO really high throughput numbers with low latency are possible using Wi-Fi.

            In my experiments 2x2 MIMO again makes a real difference compared to single antenna implementations as soon as distances between AP and board increase or some network congestion occurs. Leaving the overcrowded 2.4 GHz band is of course the other prerequisit to get decent wireless performance.

        1. After using Armbian and lots of other operating systems and losing the lot because backups took too much thought in some cases, I've kind of settled into using Raspberry Pi 3B+ with Raspbian but not for TV. As for pre built boxes with Android TV, the so called Play Store is utter crap. The T4 and a Roku box with a €20 VPN router together give me all possible UK TV here on Spain. Mind you the T4 occasionally forgets where to send the sound. Unplugging and reinserting the HDMI lead sorts that. FA need to fix that.

  3. What about the uSD corruption problem?
    Every SBC is doomed for this, no solutions are incorporated into design.

    I don't see any reliable use for commercial real-life applications with this serious problem.

    1. In that case I'd take up woodwork, we're doomed.

      The "problem" is people ignoring SD write limitations, not the SD itself. I have been running "real life" installations for years now without major SD issues... There are many reliable commercial installations using RPI and other such boards.

      For my part I scrapped mySQL in favour of SQLITE and reduced logging to bare essentials. Power stability and reliability to me is a bigger issue but not insurmountable.

      1. For those that need syslog, they can use the remote option which sends logs to another server. I've also I've used nfs and cfs for things like compiling and adding commands and libraries that I can share amongst many similar devices. If I need a lot of db support accessing a remote db is not hard. Web services and REST, again remote. And, of course, I'm sharing data and heartbeats and other useful stuff via MQTT.

        What we really need is a Linux distribution that doesn't have all the bells and whistled turned on unless you request it.

    2. Not every SBC is doomed for this, it's just users ignoring the two most common problems with SD cards:

      1) counterfeit cards (that's the majority of 'reports' about SD cards being unrealiable)

      2) Write Amplification. Some OS images do care about this and some don't. The difference when running an OS on the same card will be the card wearing out at least 1000 times faster on those OS images not giving a sh*t.

      First problem can only be solved by immediately testing for counterfeit cards after purchase (no one does this of course while it's very easy with f3 or h2wtest) and the second problem as well as countermeasures (increasing the filesystem's commit interval, logging to RAM and stuff like that) is explained somewhere here: https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/ (search for 'write amplification' there)

      Asides that on 1st generation Raspberry Pis there was a possible relationship between under-voltage and SD card corruption. Fixed with 2nd generation RPi half a decade ago so nowadays it's using cards with faked capacity (that die at least 1000 times earlier than normal cards) or using OS images with inappropriate settings (like e.g. Raspbian) that are responsible for 'SD cards being unreliable'

    3. Besides that there's 16 GB (most probably fast) eMMC on this board so at least you can't run into the counterfeit card situation with SD cards faking higher capacities.

      But of course with the wrong access patterns (high write amplification) this eMMC will also die eventually and then you would need a BGA soldering station to replace it.

      It prefer A1 rated (!!!) SD cards in the meantime since they show great performance and if chosen wisely (as large as possible, using the more expensive variants and not buying as cheap as possible) and with the right software countermeasures (log2ram, increasing fs commit interval, keeping caches/profiles in RAM and so on) they will last forever anyway.

      https://forum.armbian.com/topic/954-sd-card-performance/?page=3&tab=comments#comment-49811

      1. I take it you're writing the blog for me.. well, that's fine - keep going. I thought I'd made it abundantly clear that I don't have the hardware yet, it is on its way at which point I'll fill in the (many) blanks. I see other blogs doing write-ups based on guesswork and specs.. I don't do that, I work from actual samples and often do follow up write-ups months after initially checking out products. In this case I just wanted to give folk a quick heads up on the new board while waiting for it to arrive.

    4. What about scheduled maintenance. Say you know the board has however many writes that it can do before the SD card fails. You can backup the SD card with ease to another card and then put it back into service within a half hour. Not only that but you can have a redundancy put in by have a second board take the place of the first if it's mission critical. It's not like this stuff is in the price range of PLC controllers. Backups and redundancy is cheap

  4. As usual some very interesting stuff about SD cards but I see very little comment about SSD cards or hard drives with the SBC's. I know that a while back Peter mentioned an SSD but I haven't seen any subsequent comment. I have also seen WD hard drive kits for the Raspi. My question is; are there issues using these devices for data storage / logging? Revolving iron HD's are, after all, the basis of many NAS devices and one assumes they work reliably!

    1. No problems and I use both SSDs and hard drives. The latter however are slow and of course all of these add-ons kind of defeat the idea of a small, cheap processor board. Also since I got to grips with using hard drives last year I've been too busy having a stroke, rescuing a house from the tenants from hell and preparing for this year's exodus to Spain not to mention keeping the blog fresh, to do much experimenting with SSDs... maybe in the summer.

    2. The WD PiDrives are only good companions for ultra slow Raspberry Pis (that suffer from their 'one single USB2 port' limitation).

      USB storage and especially USB3 with type A receptacles has some downsides compared to native or PCIe attached SATA. But if you got an USB3 SuperSpeed cable that fits tightly (no disconnects) and ensure that the USB-to-SATA bridge chipset is a good one then you're fine. With those RK3399 boards we see up to 400 MB/s with fast SSDs via USB3 SuperSpeed.

      I did some first tests yesterday with NanoPC T4 focussing on storage: https://forum.armbian.com/topic/7498-nanopc-t4/ (check the links at the bottom of first post).

      BTW: FriendlyELEC revealed 3 hours ago that there's another very nice RK3399 board to come: https://forum.armbian.com/topic/7511-nanopi-m4/

  5. I just had a good read of the wiki and see that there is a severe lack of UARTs available to the user with only 1 being available with 2 if you disable the debug PORT. I think for the timing being the T3 Plus is a better option when it comes to UART availability. It has been super stable running Android with UART and GSM upgrades.

  6. Hello Peter, what is the easiest way to simply switch over from my Raspberry Pi to the NanoPC-T4? I now need USB3 speed, and more ram, which is why I want to try the NanoPC-T4.

  7. Well, the T4 arrived and I installed LUbuntu on it, using the ISO file from their wiki page. It was an easy install, and seemed fine, until I tried to change the Time and Date and tried to use the Users and Groups system tools. They both ended in an error as soon as their window opened.

    The configuration could not be loaded
    And unknown error has occurred

    I hadn't yet installed anything else. So I tried to use the Update options, and they too failed. I upgraded and updated from the command line hoping that would solve the two first issues, but no. Those still fail. So I am unable to access Users and Groups - which shows there's a bug somewhere. I contacted FriendlyArm, and are aware and said an update may be out sometime in the future - pretty vague.

  8. Up to now I've only tied Android on the T4 but already I'm seeing issues, the screen has overscan and as this is a non-root Android, FA advised going to settings, display - HDMI - screen zoom. Settings bombs at "display" = I can't get any further in. I have to say this is not an inexpensive board - I expect much more than an iffy version of Android even if it is v7+

  9. I was having a lot of problems with the Lubuntu build on the T4 - until I discovered an error in DBUS. I reinstalled it and the things works well now!

    sudo apt-get install aptitude
    sudo aptitude reinstall dbus

    PK

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.