Home > Android, Debian, Hardware, Linux, Linux 4.x, Samsung S5P, Ubuntu > NanoPi Fire2A & Fire3 Boards Released with Samsung/Nexell Quad & Octa Core Processors

NanoPi Fire2A & Fire3 Boards Released with Samsung/Nexell Quad & Octa Core Processors

November 12th, 2017 Leave a comment Go to comments

FriendlyElec previously launched NanoPi 2 Fire board powered by Samsung (Nexell) S5P4418 quad core Cortex A9 SoC, mostly interesting because of its small form factor, camera and LCD interfaces.

The company has now launched two new boards based on S5Pxx18 processors, namely NanoPi Fire2A powered by S5P4418 SoC, and NanoPi Fire3 based on S5P6818 octa-core Cortex-A53 SoC. Both boards share the same form factor, which remains quite similar to the one of NanoPi 2 Fire, except the HDMI connector now makes place for a micro HDMI port, the USB 2.0 has moved into vertical position, and a few other tweaks have been made to positions of buttons and components.

NanoPi Fire2A / Fire3 specifications:

  • SoC
    • Fire2A – Samsung S5P4418 quad core Cortex A9 processor @ up to 1.4GHz, Mali-400MP GPU
    • Fire3 – Samsung S5P6818 octa core Cortex A53 processor @ up to 1.4 GHz, Mali-400MP GPU
  • System Memory
    • Fire2A – 512MB DDR3
    • Fire3 – 1GB DDR3
  • Storage – 1x Micro SD Slot
  • Connectivity – Gigabit Ethernet port
  • Video Output / Display I/F- 1x micro HDMI 1.4a port up to 1080p60, RGB LCD interface
  • Camera – 24-pin DVP interface; 0.5mm pitch
  • USB – 1x USB Host port; 1x micro USB 2.0 OTG port for power and data
  • Expansions Headers – 40-pin Raspberry Pi compatible header with UART, I2C, SPI, GPIOs…
  • Debugging – 4-pin header for serial console
  • Misc – Power and reset buttons, power and system LEDs, RTC battery header
  • Power Supply – 5V/2A via micro USB port; STM32F03 ARM Cortex M0 MCU for power handling (SW power off, sleep , and wakeup function)
  • Dimension: 75 x 40 mm

Other differences with the earlier model: AXP288 PMIC is gone, and replaced by an STM32 Cortex M0 MCU, and the company has now added mounting holes for a heatsink. The company provides FriendlyCore, and Debian firmware images for both hardware, and an extra Android image for Fire3 board. FriendlyCore is based on Ubuntu Core 16.04 with Linux 4.4, Qt 5.9 with OpenGL, and GStreams with VPU acceleration. The good news is the Linux kernel got an upgrade from Linux 3.4 to a more recent Linux 4.4 LTS kernel.

You’ll find download links and instructions to get starting in the Wiki pages here and there. NanoPi Fire2A is sold for $28 plus shipping, while NanoPi Fire3 goes for $35. You may also be interested in compatible accessories and external modules, including S430 4.3″ capacitive touch screen LCD display, X710 7.1″ capacitive touch screen LCD display, HD101 10.1″ touchscreen LCD display, CAM500B 5MP CMOS camera, Matrix GPS module, and others which you can find by browsing in the store.

NanoPi Fire2A/3 Connected to LCD430 Display (Left) and GPS Matrix Module (Right)

  1. willy
    November 12th, 2017 at 16:11 | #1

    I noticed the new board yesterday on their site, it’s really nice. I’ve been waiting for this one last year as an attempt for by build farm and for various other stuff.

    Also their upgrade to kernel 4.4 is much welcome, the 3.4.39 they were providing is totally outdated and contains thousands of bugs causing a lot of stability issues. With 4.4 we’ll at least be able to occasionally rebase on more recent LTS releases to benefit from fixes even if the SoC vendor doesn’t do its job.

    I also noticed that this time they drilled holes to attach the heatsink.

    The NanoPi-Fire form factor is really excellent to embed boards behind a small display as well as to build high density clusters, because it’s possible to build horizontal “bars” with all boards packed against each other, with only one cable in front (power) and another cable behind for power, and nothing in the middle preventing air from flowing.

    I just tried one of the trial images on my NanoPC-T3 and the kernel was 4.4.49 and was limited to 1.2 GHz (no modules on this image, so no cpufreq). Once they release the sources, I’ll see how much effort it is to rebase on the latest 4.4.x.

  2. tkaiser
    November 12th, 2017 at 16:42 | #2

    @willy
    Have you seen linux-4.4.y-g3739ddc.tar.xz at 112.124.9.243/uftp/

  3. theguyuk
    November 12th, 2017 at 16:43 | #3

    Wonder if NanoPi would ever take inspiration from Odroid MC1 and build a NanoPi Neo type device with Samsung Exynos 5422 and pop 2GB ram ?

  4. JotaMG
    November 12th, 2017 at 18:20 | #4

    “AXP288 PMIC is gone, and replaced by a STM32 Cortex M0 MCU”
    – good choice ?

    “NanoPi Fire2A/3 Connected to LCD430 Display (Left)”
    – what is he running, FriendlyCore, Android ?

    And, for that price the heatsink should be included…

  5. memeka
    November 12th, 2017 at 18:23 | #5

    The SoCs look the same as the ones in Samsung Artik 5xx and 7xx.
    You can check the Artik github for 4.4 kernel sources.

  6. tkaiser
    November 12th, 2017 at 18:30 | #6

    @memeka
    These are the same SoCs but IMO a better starting point is github.com/rafaello7/ (mainline u-boot/kernel for the older NanoPi M3 and NanoPC T3 also basing on the same SoC)

  7. willy
    November 13th, 2017 at 00:58 | #7

    @tkaiser
    no I hadn’t, thanks for the link. Will try.

  8. willy
    November 13th, 2017 at 01:02 | #8

    tkaiser :
    IMO a better starting point is github.com/rafaello7/ (mainline u-boot/kernel for the older NanoPi M3 and NanoPC T3 also basing on the same SoC)

    An even better option would be to have a kernel derived from mainline. Rafaello’s kernel started with a huge import, hence it’s not possible/easy to pull updates from LTS. Also sadly it’s based on 4.11.x which is now dead. Hopefully he will rebase it on top of 4.14 once it’s out.

  9. mindee
    November 13th, 2017 at 01:35 | #9

    @JotaMG
    Good suggestion! That would be added.

  10. willy
    November 13th, 2017 at 05:15 | #10

    tkaiser :
    Have you seen linux-4.4.y-g3739ddc.tar.xz at 112.124.9.243/uftp/

    So I’ve just tried that, and it was trivial to rebase on 4.4.97. I just found something like 10 trivial conflicts, it took no more than 10 minutes to do it one branch at a time to keep a fine history. It’s cool because it will finally be possible to maintain up-to-date kernels with all known fixes. BTW, the patch against 4.4.x-mainline is about 88 MB uncompressed and 5.6 MB gzipped, and it covers both the 4418 and the 6818. So it’s not huge.

  11. tkaiser
    November 13th, 2017 at 05:54 | #11

    @willy
    Great news!

    Since I was a bit curious I took one of my NanoPi M3 today and tested quickly through some stuff with 4.11.12 (my understanding is that Raffaelo also started with Samsung’s ARTIK 4.4 kernel, fixed few things and ported everything to then up-to-date mainline kernel which was 4.11 half a year ago). To me it seems that SBC with S5P6818 currently are both the fastest and cheapest octa-core thingies around as long as they’re able to keep running at 1.4 GHz on all cores simultaneously and it’s not about AES encryption (since missing the ARMv8 crypto extensions).

    Tough job, when powering through Micro USB the board simply deadlocked with demanding stuff, even with one 3A rated PSU when powering through the 4 pin header it failed but with another 3A PSU I succeeded with benchmarking. Unfortunately for my use cases the boards are rather useless since only 2 x USB2 and here outperformed by every cheap NanoPi NEO (since faster and UAS capable).

    On the other hand now that we know that there’s a kernel that does not suck [TM], given stuff like HW accelerated video encoding/decoding works, all the nice FriendlyELEC LCDs are supported (I hope the same way as in the past –> simply attach the LCD, let u-boot auto-detect the model, hand it over via kernel cmdline and everything ‘just works’) I could even imagine to use these boards for non server stuff (most probably sending CPUs 4-7 offline to avoid throttling and retain higher single-thread performance).

  12. ahrlad
    November 13th, 2017 at 15:48 | #12

    Cute little board. They don’t seem to respect their own designs a lot though, they seem to already have discontinued the Nanopi M3? Not to mention the original M1 and about a dozen other boards. I wonder what that’s about.

    Anyway the old PMIC could handle lithium cell charging, this cortex MCU doesn’t handle any of that. I guess it would be of limited use in a power-hungry board such as this, but I would have liked the option of turning this into a portable thingy without additional charging circuitry.

  13. theguyuk
    November 13th, 2017 at 18:13 | #13

    @tkaiser
    So is this good news also for andahammer limited run NanoPi2

    https://andahammer.com/nanopi-2

    They have 43 left at $14.99

    S5P4418 1.4GHZ, 1GB ram, WiFi and bluetooth. Free shipping in USA.

  14. November 13th, 2017 at 18:16 | #14

    Pity it has only got 1GB of ram

  15. James
    November 13th, 2017 at 19:05 | #15

    It’s good to see a replacement for the m3, and these boards have great density for clusters. But, to get the performance out of them you need a work load that scales to 8 threads and still fits in 1G of RAM. I find that to be quite limiting, so I really wish they had provided a 2G model with this revision.

    On the plus side, I find the S5P6818 (in my m3) to be relatively easy to cool with heatsink and fan, even when over-clocked to 1.6GHz, and it still holds the performance title in my collection of SBCs.

  16. theguyuk
    November 13th, 2017 at 19:24 | #16

    @James
    If people really want more Ram write to NanoPi sales Director, email for sales on Friendlyelec, and politely make your case for why.
    The more that register a genuine need and interest the better.

    These NXP / Samsung Soc are mostly popular in industrial embedded, that market drives NanoPi design on these.

  17. tkaiser
    November 13th, 2017 at 19:48 | #17

    James :
    I really wish they had provided a 2G model with this revision.

    Well, by looking at the bottom PCB side of ‘NanoPC-T3(2GB)’ it seems 2GB would require 4 DDR3 chips…

  18. James
    November 13th, 2017 at 20:09 | #18

    Wait – there’s a 2G version of the T3?

  19. tkaiser
    November 13th, 2017 at 20:34 | #19

    @James
    Not that long: wiki.friendlyarm.com/wiki/index.php?title=NanoPC-T3(2GB)&action=history (BTW: since they provide a ‘wiki/index.php/Special:RecentChanges’ URL receiving updates in your inbox is fairly easy if you take the additional steps web2feed –> filter –> feed2email)

  20. etatto
    November 14th, 2017 at 01:18 | #20

    willy :

    tkaiser :
    Have you seen linux-4.4.y-g3739ddc.tar.xz at 112.124.9.243/uftp/

    So I’ve just tried that, and it was trivial to rebase on 4.4.97. I just found something like 10 trivial conflicts, it took no more than 10 minutes to do it one branch at a time to keep a fine history. It’s cool because it will finally be possible to maintain up-to-date kernels with all known fixes. BTW, the patch against 4.4.x-mainline is about 88 MB uncompressed and 5.6 MB gzipped, and it covers both the 4418 and the 6818. So it’s not huge.

    Hope your patch will be available to download, so maybe a Armbian dev take the tasks to include these sbcs, even I know the FA images are not so bad after all…

  21. MHSadri
    November 14th, 2017 at 13:49 | #21

    Rafaello7 suggests using 64-bit compiler to cross compile the kernel and also making “64-bit Debian/Ubuntu installer for NanoPi M3”. But due to low amount of RAM as well as the lack of RAM BW to the SoC (32bit * 800MHz) , I think it would be better to compile the kernel using 32-bit ARMv7 crosscompiler and make 32-bit FS. Consider the Cortex A53 can also run in 32-bit ARMv7 mode (as official *absurd* M3 OS images use 32-bit ARMv7 kernel and binaries). Any body has an experience? Dose it need any kernel configuration to be change?

  22. tkaiser
    November 14th, 2017 at 15:04 | #22

    @MHSadri
    You’re thinking about the kernel while you should think about the userland instead. Building a 64-bit kernel is fine (and of course cross-compiling unless you’ve already set up a fast build cluster like @willy did) but on such boards with rather low RAM combining this with a 32-bit userland can make some sense (binaries are somewhat smaller and memory demands are lower).

    Some details why this could also make a lot of sense on servers: https://github.com/armbian/build/issues/645 (but I’ve given up almost entirely on trying to optimize Linux builds on ARM for now)

  23. willy
    November 15th, 2017 at 13:23 | #23

    tkaiser :
    To me it seems that SBC with S5P6818 currently are both the fastest and cheapest octa-core thingies around as long as they’re able to keep running at 1.4 GHz on all cores simultaneously and it’s not about AES encryption (since missing the ARMv8 crypto extensions).

    I agree that it’s one of the fastest boards (others using S912 or RK3368 at 1.5 GHz may be faster, provided they really run at this frequency). However regarding crypto I disagree with you, extensions *are* there :

    [email protected]:~# cat /proc/cpuinfo
    processor : 0
    BogoMIPS : 19.84
    Features : fp asimd aes pmull sha1 sha2 crc32
    CPU implementer : 0x41
    CPU architecture: 8
    CPU variant : 0x0
    CPU part : 0xd03
    CPU revision : 3

    Also, “openssl speed -evp aes-128-gcm -multi 8” gives 226->277MB/s in armv7 mode, and 728->4480MB/s in v8!
    I’ve read some reports about people running them at 1.6 GHz. I remember trying that on the 4418 in the past but it didn’t run stable. I may have to retry with the 6818. The 1.6 GHz entry definitely is present in the kernel (at least it was in the 3.4.39).

  24. willy
    November 15th, 2017 at 13:27 | #24

    etatto :
    Hope your patch will be available to download, so maybe a Armbian dev take the tasks to include these sbcs, even I know the FA images are not so bad after all…

    I’m certainly not going to post an experimental patch I’ve done in 5 minutes in /dev/shm just for a test, based on sources downloaded from an unofficial site, some people would dare redistributing it, considering it good enough. I’d rather help the friendlyarm guys ensure their official kernel is in a good enough shape for anyone to easily follow LTS updates. This will be much more efficient and useful.

  25. tkaiser
    November 15th, 2017 at 16:01 | #25

    willy :
    However regarding crypto I disagree with you, extensions *are* there :

    That’s good to know, I wait for an 4.4 LTS appearing in FriendlyELEC’s github repo and will re-test on my own. Thanks for the heads-up!

  26. etatto
    November 15th, 2017 at 20:07 | #26

    willy :

    etatto :
    Hope your patch will be available to download, so maybe a Armbian dev take the tasks to include these sbcs, even I know the FA images are not so bad after all…

    I’m certainly not going to post an experimental patch I’ve done in 5 minutes in /dev/shm just for a test, based on sources downloaded from an unofficial site, some people would dare redistributing it, considering it good enough. I’d rather help the friendlyarm guys ensure their official kernel is in a good enough shape for anyone to easily follow LTS updates. This will be much more efficient and useful.

    Even better IMHO! Keep up! 😀

  1. No trackbacks yet.