NanoPi NEO2 Development Board Powered by Allwinner H5 64-bit ARM Processor Sells for $15

NanoPi NEO is a cool little board, and I’ve been using it with Armbian as a 24/7  MQTT + Domoticz server for several weeks without any issues so far. FriendlyElec has now an update with NanoPi NEO2 featuring Allwinner H5 quad core Cortex A53 processor instead of Allwinner H3 Cortex A7 processor, a faster Gigabit Ethernet connection, and a new audio header.

NanoPi NEO2 specifications:

  • SoC – Allwinner H5 quad core Cortex A53 processor with an ARM Mali-450MP GPU
  • System Memory – 512 MB DDR3
  • Storage – micro SD card slot
  • Connectivity – Gigabit Ethernet (via RTL8211E-VB-CG chip)
  • USB – 1x USB 2.0 host ports, 1x micro USB OTG port, 2x USB via headers
  • Expansion headers
    • 24-pin header with I2C, 2x UART, SPI, PWM, and power signals
    • 12-pin header with 2x USB, IR pin, I2S
    • 5-pin audio header with microphone and LINE out signals
  • Debugging – 4-pin header for serial console
  • Misc – Power and status LEDs
  • Power Supply – 5V via micro USB port or VDD pin on headers.
  • Dimensions – 40 x 40 mm

One of my reader (Willy) also noticed they included a low-profile Ethernet jack that was asked by some. The company provides an image based on U-boot + Ubuntu Core, as well as hardware and software documentation on their Wiki. That’s not the first Allwinner H5 board we’ve seen, as Shenzhen Xunlong introduced Orange Pi PC 2 at the end of last year, but NEO2 is the first H5 board in such as small form factor.

Software support for H5 was not quite that good last November, but now Armbian community has released nightly builds for Orange Pi PC 2 based on Linux 4.10, which do seem to work fine for headless operation, but there’s little hope to have Mali drivers, hardware video decoding, and HDMI audio output support any time soon. None of those should matter for NanoPi NEO2 since it does not come with any video output ports, and I’d expect Armbian images to be released for the board soon.

NanoPi NEO2 is sold for $14.99 + shipping together with 2×12 and 1×12 headers directly on FriendlyARM website. Note that the heatsink is not included by default, and depending on your target application you may want to spend the extra $2.97 to add the heatsink + thermal pad to your order.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX Rockchip RK3588 mini-ITX motherboard

49 Replies to “NanoPi NEO2 Development Board Powered by Allwinner H5 64-bit ARM Processor Sells for $15”

  1. Ah, with GigE, with Armbian, and a good Wiki-page. Nice!
    I checked, and shipping to the Netherlands is 5 USD (China Post-Group 3)

  2. Wonder if it stays pin compatible with the NanoPi Power dock and Uno dock. I know from email with NanoPi they are aware of need to improve software.

  3. Quick comparison with Orange Pi PC2: 1368 MHz cpufreq vs 1008 MHz, less memory bandwidth due to single bank configuration here.

    More details: https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/&do=findComment&comment=27536

    @cnxsoft: ‘hardware video decoding’ shouldn’t be a problem since the video engine in H5 is compatible to the older SoCs. This is just a matter of ‘someone has to spend some time to do the work’. Since H3 and H5 are pin compatible I would assume we see a lot of ‘board upgrades’ soon. Adding software support for these new boards is pretty easy now that awesome linux-sunxi community did all the relevant work already (dealing with early stage boot loaders, ARM trusted firmware and porting H3 drivers to H5).

    BTW: Armbian images for H5 devices currently only support mainline kernel (4.10 at the moment) while vendor OS offerings from both Xunlong or FriendlyELEC are based on Allwinner’s smelly BSP (3.10.65 kernel and broken DVFS, maybe that’s the reason FriendlyELEC decided to forget about any voltage regulation on this board since in Allwinner’s outdated kernel voltage switching doesn’t work anyway — funnily community’s mainline kernel drivers do work here, though only on boards with adjustable voltage regulator like OPi PC2)

  4. @tkaiser
    I used the info on OpI PC2 on Armbian website:

    Features that do not work and will not be fixed anytime soon:

    Hardware accelerated video decoding
    Mali driver
    HDMI audio output

    So I guess than means the first one should be feasible, but the last two are harder ?

  5. @Sander
    Unfortunately they don’t include a Micro USB cable in this set unlike with a few other NanoPi. So it’s strongly recommended to add the $2 for one of FriendlyELEC’s cables since they have a very low resistance and you don’t risk powering/undervoltage problems (though as usual NanoPis can also be powered through the 4 pin ‘debug header’)

    @cnxsoft
    Well, ‘will not be fixed anytime soon’ just means that people shouldn’t ask for it. Unfortunately most of the few active Armbian devs aren’t that interested in display/audio stuff so we need to wait until upstream kernel devs add drivers (eg HDMI audio) to be integrated. But there is some progress eg. OPi PC2 has working HDMI display output (though simplefb and not accelerated by any means). Regarding video decoding with mainline kernel last year Free Electrons’ Florent Revest demonstrated that Cedrus is useable together with kernel 4.8 so I would assume it’s just a matter of time until this will work here too.

    And IIRC situation with Mali seems also to be better since for Mali450 there seem to be useable BLOBs for aarch64 around (but I might remember totally wrong, 3D acceleration is something I normally ignore). Time will tell.

    Regarding Armbian OS images for NEO2: 20 minutes ago I commited a small change limiting max cpufreq here to 1008 MHz and setting CLI_BETA_TARGET=”xenial:dev” — so if everything works correctly in a few hours a directory called nanopineo2 will appear automagically on dl.armbian.com with an Ubuntu Xenial image using kernel 4.10 and u-boot 2017.03 (‘nightly build’ and as such 100% untested 😉 )

  6. @tkaiser
    The difference between H3 & H5 is H5’s VDD-CPUS, VDD-CPUX are marked TBD(To Be Decided), Please refer to the chapter 5.2 in H5 datasheet. We assumed Allwinner H5 dont’ support adjustable voltage.

  7. @Mindee
    Hmm, when looking at pages 682 and 683 we’re talking about same ratings as for H3 (1.5V absolute maximum, 1.4V max recommended). TBD (‘to be done’ in my understanding) appears on page 685 when it’s about ‘Maximum Current Consumption’, something Allwinner obviously not yet measured/provided?

    Anyway with Allwinner’s legacy kernel voltage regulation is broken with H5 (it seems the relevant Github issue has been deleted by the guy doing software for Xunlong) but we as community did some testing with H5 on OPi PC2 using the I2C accessible SY8106A voltage regulator. It obviously works since @ErwinH managed to reach even stable 1368MHz@1.4V with appropriate cooling.

    To be honest: the fixed 1.1V on your NEO2 are IMO not a real disadvantage especially given that you don’t add a Micro USB cable to the NEO2 kit (maybe you should overthink that since undervolting NEO2 due to average/crappy cables could be an issue for many users)

  8. @Mindee
    BTW: github.com/friendlyarm/h5_lichee.git is still empty and I did not manage to download h5-lichee-20170307.7z from your Baidu share. Can you please fix that?

  9. dxin :
    Did you guys noticed that this thing has no HDMI and possibly headless, too?

    Well, CNX wrote “None of those should matter for NanoPi NEO2 since it does not come with any video output ports” … so, yes, I had noticed that… 😉

  10. GPU indeed won’t matter (for this board, but not other H5 boards), but VPU might matter – e.g. if you wanna do a media server with transcoding, or add a webcam (usb or ip) and encode the stream.
    PS: mali drivers are very easy to add, assuming you have a binary blob that works with the board (e.g. the hikey driver from malideveloper website, or if sunxi has a binary driver from the older kernel, it would work here too).

  11. I really find this one interesting for a lot of headless stuff. Based on my observations on Opi-PC2 I expect it not to heat much, and in the end having a very small, inexpensive, low-power 64-bit board with gigabit support is very interesting for a lot of use cases in network monitoring, testing as well as to place single-function devices on a home network (DNS+DHCP server, USB NAS, VPN end point, proxy, reverse proxy, etc). For this price you can have a lot. You can easily connect this to a cheap manageable 5-port switch and have a 4-port gigabit firewall as well once you enable VLANs. So there’s a lot of potential in this tiny board which comes with a nice balance of features, size and cost. I really like it and I think it will soon replace my aging dockstars since it has 4 times the amount of RAM and of cores.

  12. @Willy
    Agree with most of your comments but not regarding thermal expectations. Xunlong’s OPi PC2 is just another great example for a PCB design where the ground plane acts like a gigantic bottom heatsink. Not possible on smaller boards like NanoPi NEO/Air or also OPi Zero. So expect higher temperatures here but fortunately max cpufreq on NEO2 is limited to 1008 MHz anway so heat won’t be that much of an issue even under full load. For headless operations max cpufreq of 1008 MHz vs 1368 MHz doesn’t matter at all (but lower memory bandwidth partially for some use cases).

    BTW: this NEO2 is IMO currently the best companion for Xunlong’s NAS Expansion board even if pin header positions don’t fit and small wires are necessary to combine both designs. The ‘NAS HAT’ uses 2 JMS578 USB-to-SATA bridges that are superiour compared to the average bridge used in USB enclosures since it supports:

    – UAS: http://linux-sunxi.org/USB/UAS
    – SAT/SMART: https://en.wikipedia.org/wiki/SCSI_/_ATA_Translation
    – even TRIM https://en.wikipedia.org/wiki/Trim_(computing)

  13. @Willy
    Quick addendum regarding generated heat since related with consumption. When linux-sunxi community developed sane DVFS settings for H5 (OPi PC 2 in this case) we again used an optimized Linpack benchmark to do stability testing. This version using NEON optimizations was already helpful with A64 and H3 before. It generates a pretty heavy load on the SoC and throws errors when the CPU cores are fed with a voltage too low.

    One Armbian user now measured consumption in this mode walking through all available cpufreq steps: https://forum.armbian.com/index.php?/topic/1748-sbc-consumptionperformance-comparisons/&do=findComment&comment=27583

    So at 1008 MHz it’s ~2.3W above idle consumption while at 1368 MHz it’s already 6.1W above. From this point of view feeding H5 on NEO2 with 1.1V max makes a lot of sense given the limited situation with heat dissipation. And for headless use cases the theoretical performance difference between 1.0 and 1.36 GHz is simply negligible.

  14. If Allwinner is interested in that market they should really start making processors for headless applications without display interfaces, VPU or GPU, and just the processor, USB, and I/Os, and some versions with Ethernet and/or SATA.

  15. @memeka
    In fact in github.com/OrangePiLibra/OrangePi_GPU is Mali450 stuff lying around that could work from a technical point of view with Allwinner’s smelly 3.10 kernel but lacks a proper (any to be more precise) license so you end up with distribution issues and no one right in his mind will touch BSP code base anyway (in mainline kernel Mali integration makes not that much sense today since underlying prerequisits are still WiP, all we have there now are simplefb display drivers).

    @cnxsoft
    IMO kinda useless to speculate about Allwinner’s motivation/goals, especially here 🙂

    But it’s obvious that they simple re-use IP blocks in various SoCs, as @memeka pointed out VPU (video engine) support could be crucial even on headless designs since Cedrus supports both HW accelerated video decoding and encoding and in general being not that innovative is sometimes ‘key to success’. Take the newest ‘Foundation innovation’ RPi Zero W for example: the SoC used on all Raspberries up to RPi 3 (VideoCore IV) is a 2011 design, the specific CPU core (ARM1176JZ) is from 2003. What’s the result? Mature software support in the meantime. Same with Nextthing’s CHIP based on A13 (R8): by choosing an old hardware design they ran in less software issues.

    Anyway: I doubt Allwinner could ship cheaper ‘special purpose’ SoCs when re-designing them (and IMO with Allwinner it’s all about cheap), it also doesn’t hurt that much to ignore/deactivate specific SoC engines and to be honest: the reason why we’re already able to run latest mainline kernel on H5 boards is just that Allwinner fortunately re-used IP blocks from both H3 and A64 here.

  16. @Theguyuk
    Well for people able to browse through the commit history of github repos and lookup config bits here and there… there are no surprises any more since approx 2 hours. From a software point of view (mainline kernel+u-boot) it looks easy now that kind souls from linux-sunxi community also added eMMC support upstream (though for A64 and not H5 — IIRC there’s a difference regarding the 2nd MMC controller on A64, no idea whether that applies to H5 too).

    Anyway: since community did the job already ‘board upgrades’ from H3 to H5 aren’t that much of an issue any more and there’s no need to fiddle around with Allwinner’s BSP (and especially buggy/insecure 3.10.65 kernel)

  17. @cnxsoft

    Headless SOCs

    A smarter way to do that is to leave in the 2D video hardware which costs almost nothing, but then add more peripherals which share the display pins. Most NXP chips do this. If you use them in a headless system you gets another dozen peripherals or you can hook up a LCD panel. Doing it this way makes the SOC support more use cases. I’ve asked AW to do this without any success.

    AW does need to get with current times and start including USB3.

    One neat side effect of sharing the display pins is that you can put a FPC connector on the PCB. Then either plug a display into it, or stack an expansion board with peripherals on it and use an FPC cable to access the expanded peripherals.

  18. @tkaiser
    Hi Tkaiser

    If you like helping others with software and not to only interested in OrangePi . Then maybe, only maybe! a polite email conversation with Friendlyelec might be worthwhile. I cannot comment beyond that , It is not my place or liberty to do so.

  19. @Theguyuk
    LOL, care to remember that it was Thebragger who divulged products he shouldn’t talk about? http://www.cnx-software.com/2017/03/01/friendlyelec-nanopi-m1-plus-allwinner-h3-board-adds-gigabit-ethernet-wifi-bluetooth-and-an-8gb-emmc-flash/#comment-539721

    FriendlyELEC and us (linux-sunxi and Armbian community) are constantly in contact via email and github issues, they send out developer samples and listen to suggestions. The last 4 officially announced FriendlyELEC boards were fully supported by Armbian weeks before dev samples arrived and I hope this will remain the same in the future 🙂

  20. @Jon Smirl
    But isn’t that exactly what LicheePi Zero for example is doing? 40 pin FPC connector you can either attach a display to or various add-on boards?

  21. @tkaiser

    Did they finally do this with the V3S? I don’t work with it. It is a good scheme, it costs almost nothing to implement and they should do it for all of their chips.

    For example it would be nice to take mass produced tablet PCBs and use them without displays. The FPC would then give access to SPI, I2S, I2C, etc.

  22. @tkaiser
    Lol Hi tkaiser

    Your assumption is wrong, the board I spoke of was openly disclose by FriendlyElec in a forum. Hence how I knew of it. No underhand at all. 🙂

  23. Jon Smirl :
    @tkaiser
    Did they finally do this with the V3S?

    I checked data sheet (from Nov 2014 so it’s an old design anyway) and nope, I was wrong. LCD is 24 pins and just a few of them are multiplexed so developer Zepan simply added other signals to the 40 pin connector 🙂

    Anyway: NanoPi NEO2 is now officially latest member in Armbian family: https://www.armbian.com/download/

  24. @tkaiser

    So at 1008 MHz it’s ~2.3W above idle consumption while at 1368 MHz it’s already 6.1W above. From this point of view feeding H5 on NEO2 with 1.1V max makes a lot of sense given the limited situation with heat dissipation. And for headless use cases the theoretical performance difference between 1.0 and 1.36 GHz is simply negligible.

    That’s even more true considering the limited RAM bandwidth 🙂

  25. @myself: the nightly Armbian for this board is 64-bit indeed … wow.

    usr/bin/perl: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=98dedd8770d6a5a002221bd42c0af6aa77c9fa89, stripped

  26. Sander :

    Is that a 64-bit Linux?

    Sure, both Debian Jessie and Ubuntu Xenial fully support arm64 architecture so both kernel+userland for all our supported 64-bit platforms (started with S905, then A64, now H5) are 64-bit. We are not that crazy like eg. SinoVoip advertising crippled Raspbian images with an ARMv6 userland for their ARMv8 M64 Banana to totally ruin performance.

    BTW: On all those 64-bit Armbian images, armhf architecture is already added since we include the armhf Firefox/Iceweasel variants due to the 64-bit versions still being buggy. Useless on NEO2 but just as another rather perfect example: many people love Plex media server and there’s a NEON optimized Synology package flying around made for their NAS boxes containing Annapurna Labs’ Alpine ARMv7 SoCs. All you’ve to do to get this installed on a 64-bit Debian or Ubuntu is:

    With Armbian you can save the ‘dpkg –add-architecture armhf’ entirely since it’s already added by default. And such a small NEO2 is the way better Plex media server than any Raspberry around (magnitudes more IO and network bandwidth though maybe just 2/3 the CPU horsepower of an RPi 3 when limited to 1 GHz cpufreq)

    BTW: 32-bit vs 64-bit isn’t the real issue here. It’s using packages that are built with compiler switches for ARMv8 architecture which is the case with arm64 distros like Jessie or Ubuntu. Raspbian on the other hand relies on packages built with an outdated GCC and ARMv6 switches so all those RPi 3 out there waste a lot CPU cycles running inefficient code 🙂

  27. @tkaiser
    “We are not that crazy like eg. SinoVoip”

    Yes, you are, when you’re mixing armhf with arm64 you know you are downgrading performance, right?

  28. JotaMG :
    when you’re mixing armhf with arm64 you know you are downgrading performance, right?

    Huh? It’s an arm64 userland with the ability to install armhf packages (Debian’s Multiarch feature available since Wheezy). While firefox:arm64 is constantly crashing firefox:armhf runs flawlessly. Which one is performing better? Or do you claim that once I execute ‘dpkg –add-architecture armhf’ the whole arm64 OS installation slows down?!

    Regarding the SinoVoip example that’s totally different: They have a 64-bit ARMv8 board but provide OS images relying on a 32-bit ARMv6+VFP userland (‘armhf lite’ or something like that, compiler switches suitable for an ARM CPU generation from 15 years ago!)

  29. @JotaMG
    Found it: https://forum.armbian.com/index.php?/topic/751-rfc-support-cortex-a53arm64/&do=findComment&comment=12462

    Running stupid sysbench pseudo CPU benchmark with compiler settings for ARMv6+VFP with GCC 4.9 results in 52.2640s execution time while the same hardware with same settings and same benchmark just compiled for ARMv8 with GCC 5.4 results in 3.2562s. That’s just 16 times faster by allowing software to make use of modern CPU features! And you get that for free just by taking care of the userland you provide (now imagine RPi 3 being not limited to Raspbian’s ARMv6 packages: would finish this sysbench stuff in less than 3 seconds).

    BTW: No idea which userland FriendlyELEC uses with their NEO2 Ubuntu images. If it’s their usual rootfs then it’s 32-bit/armhf/ARMv7 ‘optimized’ and will run a bit slower/inefficient on ARMv8 H5 (sysbench is a really bad example since this pseudo CPU benchmark does only prime number calculations and this can be done with ARMv8 compiler switches magnitudes faster)

  30. I am definitely going to have to pick up some of these and the NAS add-on boards for testing. I keep saying 512MB of RAM is an issue but is it really? It’s certainly less than optimal and will need some settings tweaking but will it work and more importantly will it work better than the old x86 server I keep kicking around where the NIC’s the bottleneck?

  31. OK, OK … I’ve ordered one.

    I don’t think I really need one, but ARM64 ánd GigE ánd Linux mainline ánd Armbian … that’s just perfect.

  32. CampGareth :
    I keep saying 512MB of RAM is an issue but is it really?

    Well, if storage is the bottleneck (USB2 Hi-Speed without RAID definitely is) then you get higher ‘client to NAS’ write speeds as long as the amount of data fits into RAM before it gets flushed to disk. With only 512MB DRAM files as large as ~350MB might be saved with ~80MB/s and later it drops down to storage speed (~40MB/s with good USB-to-SATA bridge), with 2GB DRAM you might be able to store up to 1.8GB with 80MB/s.

    As soon as many small files are involved it doesn’t matter that much and read speeds usually aren’t affected since the data has to be fetched from storage anyway so this is always the bottleneck except when the data has been stored moments before and is still present in filesystem buffers/caches (that’s what DRAM is used mostly for on headless systems).

    One exception would be the use of performant RAID modes, H3 is personally tested with +120MB/s using RAID-0 and 3 SSD, with H5 it will be the same and another nice feature of these cheap Allwinner chips is that we’ll soon be able to transform the OTG port into a real USB host port since on these SoC’s USB PHY0 is connected to two different real USB controllers, by default connected to musb (OTG and ‘host emulation’ mode) but by changing a register it can also be routed to an own 4th EHCI/OHCI controller pair (do a google search for ‘Add dual-role OTG support for Allwinner H3’ and ‘Icenowy’ for details).

    USB RAID sounds as stupid as it normally is but we use some small GbE equipped boards at some clients with 3 USB thumb drives each combining mdraid10 with btrfs RAID 0 providing ~110GB storage each at NAS read speeds of ~75MB/s outperforming the big NAS boxes they replaced (syncing graphics stuff to homeworkers or remote studios in a more intelligent way)

  33. @tkaiser
    I’m an idiot, forgot to mention this is for Ceph, you might remember me from my interest in the OPi+2E (and subsequent trouble as redhat dropped armhf support, they provide armv8 packages only). Ultimately I had disappointing performance from my old x86 box (top speed of 30-40MB/s) but couldn’t nail down the cause due to all the layers. I’m hoping multiple simpler boxes will be easier to trouble shoot, like latency’s a killer for Ceph and I had 4 cores trying to handle 8 heavy threads with plenty of IO through a single RAID card. Should be better with 4 cores and 1 controller for 1 drive.

    That x86 box had 48GB of RAM so you’d expect writes to have been better but nope.

  34. @CampGareth
    While I still wouldn’t implement storage clusters on nodes without ECC DRAM (just due to having a lot of servers in our monitoring system and many of them report recoverable single bit errors from time to time — without ECC you get just data corruption you’ll realize way too late or a crash from time to time) your Ceph approach looks like a great way to teach yourself active benchmarking skills (just do a web search for ‘active benchmarking’ and the name of one of my personal heroes: ‘Brendan Gregg’)

  35. Just because i still didnt get a clue how far support for h5 now really is after reading here and over at the armbian forum…

    If id like to buy a board now for generic tinkering and maybe to also play with libreelec (not the main purpose) would you recommend an H3 or an H5 based board?

    Thanks for suggestions!

  36. @itchy n scratchy
    Easy, most H3 mainline patches could be re-used with H5 so support with mainline kernel is advanced (though forget about camera and display stuff — @jernej wrote an HDMI driver for u-boot so now basic display output is there with kernel 4.10 or above but nothing useable together with any sort of video/graphics acceleration). I doubt anyone from community will ever touch Allwinner’s H5 BSP so with H5 you’re stuck with vendor OS images (ask Xunlong or FriendlyELEC or maybe even those crazy Bananas) or mainline kernel with Armbian at the moment.

    In other words: the older the SoC, the better the support and OpenELEC is currently only available for H3 devices thanks to @jernej again.

    Related news: soon there will be a NEO Plus 2 available: https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/#comment-28100

    And there also will be a ‘NanoPi M1 Plus 2’ (H3 exchanged with H5, everything else the same). FriendlyELEC told us today that it’s ok to spread the news in the meantime.

  37. @tkaiser thanks for explanations.
    Maybe i better forget about h3/5 for anything else than electronics tinkering with mainline. Else maybe a CHIP with cedrus for further experimentation 🙂 or ill stay with my lame foundation controlled rpi3.

  38. I’ve received the NanoPi Neo2 today, and … what a beautiful package. And the Neo2 is very, very small.

  39. @cnxsoft
    Result of ‘metal enclosure and OLED display’: 2 USB host ports not useable and none of the GPIO pins can be used. What’s the use case for such an expensive thing?

    Still hoping for a rev 2 NAS board for NEO2 that makes use of the OLED display, the buttons, improved heat dissipation (if the case is made of aluminium then use a copper shim to connect H5 to the case) and a power design that allows the use of 2.5″ and 3.5″ disks (it’s just providing 12V on three pins of the SATA power port)

Leave a Reply

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

Boardcon Rockchip RK3588S SBC with 8K, WiFI 6, 4G LTE, NVME SSD, HDMI 2.1...
Boardcon Rockchip RK3588S SBC with 8K, WiFI 6, 4G LTE, NVME SSD, HDMI 2.1...