Posts Tagged ‘nanopi’

NanoPi K2 Board Gets Ubuntu Core Firmware Image

July 19th, 2017 3 comments

FriendlyELEC NanoPi K2 is a board powered by Amlogic S905 processor, just like ODROID-C2 board, so while only the Android image was available at launch, it was expected to also support Ubuntu or other Linux distribution shortly after. This was put in doubt by comments on the company’s forums claiming the board would not get Debian images, and only Android was supported.

One alternative would be Armbian, but right now they only have ODROID-C2 images for download, no other Amlogic S905 hardware platform is supported either through stable or experimental builds. One user did manage to run Armbian on K2 with balbes150 help, but I’m not sure what’s the status of those firmware. Balbes150 also have a list of image for Amlogic platform in Github, which may be adapted to most hardware by using your board’s device tree binary (DTB) file.

The good news today is that FriendyELEC did not give up on Linux support for the board, as they’ve just released Ubuntu Core with Qt Embedded for NanoPi K2 (, which you’ll find on mediafire with some changelog (currently in Chinese only) in the Wiki with translates to:

NanoPi-K2 Ubuntu Core system, including Qt-Embedded graphical interface library, the system features are as follows:

Supports HDMI output
Support WiFi connection
Supports Gigabit Ethernet
Support for Bluetooth transmission
Built-in Qt-Embedded

Thanks to the powerful performance of the A53 architecture processor, 2GB memory and Gigabit Ethernet, the NanoPi-K2 is ideal for use as an IoT server or DIY lightweight servers such as Nas.

That probably means they’ve not worked on 3D GPU acceleration, nor hardware video decoding support, or this would be proudly listed in the changelog… So if you’re interested in media playback in Linux this won’t be an option, and LibreELEC should work without too many modifications, maybe with just the right DTB file.

Thanks to boudyka for the tip.

ModBerry Industrial Automation Controllers Leverage Raspberry Pi, FriendlyELEC, and AAEON Boards and Modules

July 19th, 2017 No comments

TECHBASE’s ModBerry Linux based industrial controllers have been around since 2014 with their first model being ModBerry 500 powered by a Raspberry Pi compute module. Over the years, the company has kept adding new ModBerry controllers with now an interesting choice of Raspberry Pi 3 board or compute module, FriendlyELEC’s NanoPi M1 Plus board, or Intel Atom x5 based AAEON’s UP board.

Click to Enlarge

All programmable automation controllers (PAC) runs Linux 4.0 or greater, with Debian or Ubuntu Core rootfs including ready tools and pre-compiled packs including C/C++, JAVA, SQL, PHP, SSH, and VPN support. The firmware is upgradeable over the air, and the controllers can run the company’s iMod control software and interface with iModCloud cloud computing service for telemetry, remote control and data sharing. Typical uses include C-L-V functions with conversion to collect and transmit data over communication interfaces, logging via iModCloud or a SCADA, and visualization via a web browser.

Click to Enlarge

All models share many of the same features, with some models having more I/Os beside the different board, but to get a better idea of the systems, I’ll have a look at ModBerry M700 specifications:

  • SoC – Allwinner H3 quad core Cortex A7 @ 1.2 GHz with an ARM Mali-400MP2 GPU
  • System Memory – 1GB DDR3
  • Storage – 8GB eMMC flash + micro SD card slot
  • Video & Audio Output – HDMI 1.4 and 3.5mm jack for CVBS (composite + stereo audio)
  • Connectivity

    ModBerry M700 – Click to Enlarge

    • Gigabit Ethernet
    • 802.11 b/g/n WiFi and Bluetooth 4.0 LE
    • Optional Zigbee, LTE/3G, GPS, WiFi, and Bluetooth cards
  • USB – 2x USB 2.0 host ports, 1x 4-pin USB 2.0 host header, 1x micro USB port (OTG/power)
  • Expansion I/Os
    • 4x digital inputs, 4x digital outputs up to 30V DC
    • 1x RS-232/RS-485
    • 1x PCIe slot
    • Optional 1-wire
    • Optional ExCard I/O modules for more RS-232/485 ports, Ethernet ports, PCIe slots, analog input and output, digital I/Os, relays, M-Bus interface, and more
  • Misc – RTC with battery, watchdog timer,
  • Power Supply – 7~30V DC up to 20-35W
  • Dimensions – 106 x 91 x 61 mm (ABS casing with DIN railin enclosure)
  • Weight – 300 grams
  • Operating Conditions – Temperature: -30 ~ 80°C; humidity: 5 ~ 95% RH (non-condensing)

The ExCard are DIN rail module that plugs into the ModBerry like LEGO’s, and up to 3 ExCard is supported per ModBerry.

Click to Enlarge

Applications for such systems include PLC, telemetry module with data logger, serial port server, protocol and interface converter, programmable controller, MODBUS Gateway/Router, SNMP Agent, Web server with PHP and SQL database support, SMS Gateway, LTE/3G/GPRS router and more.

TECHBase has not released pricing for the controllers, but you can find more details, including detailed PDF product briefs and links to purchase the controllers and expansions (you’ll still have to ask for the price), on the products page.

Via LinuxGizmos

NetBSD is Now Running on Allwinner H3 Boards

July 11th, 2017 7 comments

Most people will run Linux kernel on development boards because it does the job, and that’s usually the only option. But others have been working on NetBSD kernel for Allwinner H3 boards, and it’s now running on various H3 boards with serial console, USB, Ethernet, SD card, and eMMC flash working.

Jared McNeill explains they first had to deal with low-level code to initialize the CPU and MMU, before using a U-boot layer to disguise NetBSD as the Linux kernel in order to load kernel and device tree file. The code then jumps to the generic ARM FDT implementation of initarm to relocate DTB data and perform other steps, and finally they can enumerated devices. This is explained in greater details in the aforelinked blog post on NetBSD website.

Jared tested the implementation on NanoPi NEO and Orange Pi Plus 2E, but others have reported success on various hardware based on Allwinner H3 processor. Other ARM development boards have been supported since 2015 by NetBSD 7.0 and greater with Raspberry Pi 2, ODROID-C2, BegleBone Black. Allwinner A20/A31, and others, but the work done on Allwinner H3 is different, as it’s the first implementation to use device tree, and eventually it should be possible to ship a single GENERIC evbarm kernel for all boards.

Thanks to Geokon for the tip.

Linux 4.12 Release – Main Changes, ARM & MIPS Architectures

July 3rd, 2017 6 comments

Linus Torvalds has just released Linux 4.12:

Things were quite calm this week, so I really didn’t have any real reason to delay the 4.12 release.

As mentioned over the various rc announcements, 4.12 is one of the bigger releases historically, and I think only 4.9 ends up having had more commits. And 4.9 was big at least partly because Greg announced it was an LTS kernel. But 4.12 is just plain big.

There’s also nothing particularly odd going on in the tree – it’s all just normal development, just more of it that usual. The shortlog below is obviously just the minor changes since rc7 – the whole 4.12 shortlog is much too large to post.

In the diff department, 4.12 is also very big, although the reason there isn’t just that there’s a lot of development, we have the added bulk of a lot of new  header files for the AMD Vega support. That’s almost exactly half the bulk of the patch, in fact, and partly as a result of that the driver side dominates  everything else at 85+% of the release patch (it’s not all the AMD Vega headers – the Intel IPU driver in staging is big too, for example).

But aside from just being large, and a blip in size around rc5, the rc’s stabilized pretty nicely, so I think we’re all good to go.

Go out and use it.

Oh, and obviously this means that the merge window for 4.13 is thus open. You know the drill.


Linux 4.11 provided various improvements for Intel Bay Trail and Cherry Trail targets, OPAL drive support, pluggable IO schedulers framework, and plenty of ARM and MIPS changes.

Some of the most notable changes in Linux 4.12 include:

  • Initial AMD Radeon RX Vega GPU support
  • BFQ (Budget Fair Queuing) and Kyber block I/O schedulers have been merged, meaning the kernel now has two multiqueue I/O schedulers suitable for various use cases that should improve the responsiveness of systems.
  • Added AnalyzeBoot tool to create a timeline of the kernel’s bootstrap process in HTML format.
  • Implemented “hybrid consistency model” for live kernel patching in order to enable the applications patchsets that change function or data semantics. See here for details.
  • Build of Open Sound System (OSS) audio drivers has been disabled, and will likely be removed in future Linux releases
  • AVR32 support has been removed

Some of the bug fixes and improvements for the ARM architecture include:

  • Allwinner:
    • Allwinner H3 –  USB OTG support
    • Allwinner H5 – pinctrl driver, CCU (sunxi-ng) driver, USB OTG support
    • Allwinner A31/H3 SPI driver – Support transfers larger than 64 bytes
    • AXP PMICs – AXP803 basic support, ACIN Power Supply driver, ADC IIO driver, Battery Power Supply driver
    • Added support for: FriendlyARM NanoPi NEO Air, Xunlong Orange Pi PC 2
  • Rockchip:
    • Updates to Rockchip clock drivers
    • Modification for Rockchip PCI driver
    • RK3328 pinctrl driver
    • Sound support for Radxa Rock2
    • USB 3.0 controllers for RK3399
    • Various changes for RK3368 (dma, i2s, disable mailbox per default, mmc-resets)
    • Added Samsung Chromebook Plus (Kevin) and the other RK3399 “Gru family” of ChromeOS devices.
    • Added Rockchip RK3288 support for ASUS Tinker board, Phytec phyCORE-RK3288 SoM and RDK; added Rockchip RK3328 evaluation board
  • Amlogic
    • New clock drivers for I2S and SPDIF audio, and Mali GPU
    • DRM/HDMI support for Amlogic GX SoC
    • Add GPIO reset to Ethernet driver
    • Enable PWM LEDs and LEDs default-on trigger
    • New boards: Khadas VIM, HwaCom AmazeTV
  • Samsung
    • Split building of the PMU driver between ARMv7 and ARMv8
    • Various Samsung pincrl drivers updates
    • ARM DT updates:
      • Enhancements to PCIe nodes on Exynos5440.
      • Fix thermal values on some of Exynos5420 boards like Odroid XU3.
      • Add proper clock frequency properties to DSI nodes.
      • Fix watchdog reset on Exynos4412.
      • Fix watchdog infinite interrupt in soft mode on Exynos4210, Exynos5440, S3C64xx and S5Pv210.
      • Enable watchdog on Exynos4 and S3C SoCs.
      • Enable DYNAMIC_DEBUG because it is useful for debugging
      • Increase CMA memory region to allow handling H.264 1080p videos.
    • ARM64 DT updates:
      • Exynos power management drivers support now ARMv8 SoC – Exynos5433 – so select them in ARCH_EXYNOS
      • Enable few Exynos drivers (video, DRM and LPASS drivers) for supported ARMv8 SoCs (Exynos5433 and Exynos7)
      • Add IR, touchscreen and panel to TM2/TM2E boards
      • Add proper clock frequency properties to DSI nodes
  • Qualcomm
    • Enable options needed for QCom DB410c board in defconfig
    • Added new PHY driver for Qualcomm’s QMP PHY (used by PCIe, UFS and USB), and Qualcomm’s QUSB2 PHY
    • Qualcomm Device Tree Changes
      • Add Coresight components for MSM8974
      • Fixup MSM8974 ADSP XO clk and add RPMCC node
      • Fix typo in APQ8060
      • Add SDCs on MSM8660
      • Revert MSM8974 USB gadget change due to issues
      • Add SCM APIs for restore_sec_cfg and iommu secure page table
      • Enable QCOM remoteproc and related drivers
    • Qualcomm ARM64 Updates for v4.12
      • Fixup MSM8996 SMP2P and add ADSP PIL / SLPI SMP2P node
      • Replace PMU compatible w/ A53 specific one
      • Add APQ8016 ramoops
      • Update MSM8916 hexagon node
      • Add PM8994 RTC
  • Mediatek
    • New clock drivers for MT6797, and hi655x PMIC
    • Fix Mediatek SPI (flash) controller driver
    • Add DRM driver and thermal driver for Mediatek MT2701 SoC
    • Add support for MT8176 and MT817x to the Mediatek cpufreq driver
    • Add driver for hardware random generator on MT7623 SoC
    • Add DSA support to Mediatek MT7530 7-port GbE switch
    • Add v4l2 driver for Mediatek JPEG Decoder
  • Misc
    • Added ARM TEE framework to support trusted execution environments on processors with that capability (e.g. ARM CPUs with TrustZone)
    • ARM64 architecture now has kernel crash-dump functionality.
  • Other new ARM hardware platforms and SoCs:
    • NXP – NXP/Freescale LS2088A and LKS1088A SoC, I2SE’s i.MX28 Duckbill-2 boards, Gateworks Ventana i.MX6 GW5903/GW5904, Zodiac Inflight Innovations RDU2 board, Engicam i.CoreM6 Quad/Dual OpenFrame modules, Boundary Device i.MX6 Quad Plus SoM.
    • Nvidia – Expanded support for Tegra186 and Jetson TX2
    • Spreadtrum – Device tree for SP9860G
    • Marvell – Crypto engine for Armada 8040/7040
    • Hisilicon – Device tree bindings for Hi3798CV200 and Poplar board
    • Texas Instruments – Motorola Droid4 (OMAP processor)
    • ST Micro – STM32H743 Cortex-M7 MCU support
    • Various Linksys platforms,  Synology DS116

The MIPS architecture also had its share of changes:

  • Fix misordered instructions in assembly code making kenel startup via UHB unreliable.
  • Fix special case of MADDF and MADDF emulation.
  • Fix alignment issue in address calculation in pm-cps on 64 bit.
  • Fix IRQ tracing & lockdep when rescheduling
  • Systems with MAARs require post-DMA cache flushes.
  • Fix build with KVM, DYNAMIC_DEBUG and JUMP_LABEL
  • Three highmem fixes:
    • Fixed mapping initialization
    • Adjust the pkmap location
    • Ensure we use at most one page for PTEs
  • Fix makefile dependencies for .its targets to depend on vmlinux
  • Fix reversed condition in BNEZC and JIALC software branch emulation
  • Only flush initialized flush_insn_slot to avoid NULL pointer dereference
  • perf: Remove incorrect odd/even counter handling for I6400
  • ftrace: Fix init functions tracing
  • math-emu – Add missing clearing of BLTZALL and BGEZALL emulation counters; Fix BC1EQZ and BC1NEZ condition handling; Fix BLEZL and BGTZL identification
  • BPF – Add JIT support for SKF_AD_HATYPE;  use unsigned access for unsigned SKB fields; quit clobbering callee saved registers in JIT code; fix multiple problems in JIT skb access helpers
  • Loongson 3 – Select MIPS_L1_CACHE_SHIFT_6
  • Octeon – Remove vestiges of CONFIG_CAVIUM_OCTEON_2ND_KERNEL, as well as PCIERCX, L2C  & SLI types and macros;  Fix compile error when USB is not enabled; Clean up platform code.
  • SNI – Remove recursive include of cpu-feature-overrides.h
  • Sibyte – Export symbol periph_rev to sb1250-mac network driver; fix Kconfig warning.
  • Generic platform – Enable Root FS on NFS in generic_defconfig
  • SMP-MT – Use CPU interrupt controller IPI IRQ domain support
  • UASM – Add support for LHU for uasm; remove needless ISA abstraction
  • mm – Add 48-bit VA space and 4-level page tables for 4K pages.
  • PCI – Add controllers before the specified head
  • irqchip driver for MIPS CPU – Replace magic 0x100 with IE_SW0; prepare for non-legacy IRQ domains;  introduce IPI IRQ domain support
  • NET – sb1250-mac: Add missing MODULE_LICENSE()
  • CPUFREQ – Loongson2: drop set_cpus_allowed_ptr()
  • Other misc changes, and code cleanups…

For further details, you could read the full Linux 4.12 changelog – with comments only – generated using git log v4.11..v4.12 --stat. You may also want to ead kernelnewsbies’s Linux 4.12 changelog once it is up.

H3Droid Android Firmware is Designed for Allwinner H3 Boards & Devices

June 30th, 2017 3 comments

Allwinner H3 boards such as Orange Pi PC and NanoPi NEO are mostly interesting due to their ability to run Linux and control I/Os, and while they also support Android, most people wanting to run Android are better served with TV boxes instead, as they come with enclosure, power supply, HDMI cable, and an IR remote control. That does not mean there’s no use case for Android on development boards, and that’s why probably KotCzarny, and other developers, have decided to work on H3Droid project to provide better Android images for Allwinner H3 boards and devices than the firmware released by manufacturers.

Some of the improvements include “sane DRAM/CPU settings”, support for Custom recovery system, Google Play Store and more USB network adapters, as well as the removal of apps and feature unusable for people outside out China. You’ll also be able to access the board via SSH if you add your public key to the image. You’ll need a Linux computer (or board) to install the image, as it relies on an installer and there are a few steps to complete the installation on the SD card:

  1. Download image from one of the mirrors
  2. Extract the tar file (tar -xf filename.tar) in a folder with enough space to hold the contents (~450MB)
  3. Update 00_conf file to set OUTDEV variable. It should contain either device or plain file path (ex: OUTDEV=/dev/mmcblkX or OUTDEV=/dev/sdX or OUTDEV=/some/path/to/somefile.img)
  4. Copy your PUBLIC SSH key(s) to the install folder (Optional, but required to have root access via SSH) (ex: cp /root/.ssh/ ./)
  5. Execute to write image to your SDCard or somefile.img (in case of a file, you can use it later with dd/etcher/winimager to write to real device)
  6. Note: run only 10.. script, other files are meant to be called from it in order. (for example 20.. prepares partitions.dat used in 30..)

[Update: A Windows installer called H3ii is now available]

The FAQ indicates that the image has been tested on Orange Pi PC, Orange Pi Plus 2E, Orange Pi PC Plus, and Orange Pi Lite, but it should also work on other Allwinner H3 boards as long as you change the FEX file (script.bin). Also note that the first boot may take a while, and H3droid is still considered beta with for example Bluetooth, and power off not working yet, and a few other bugs still lingering. If you try the image on your board, you can provided feedback on #H3droid IRC channel on Freenode, or via the website. There’s also a forum thread on Orange Pi forums.

NanoPi NEO NAS Kit Review – Assembly, OpenMediaVault Installation & Setup, and Benchmarks

June 18th, 2017 67 comments

NAS Dock v1.2 for Nano Pi NEO / NEO 2 is, as the name implies, a complete mini NAS kit for 2.5″ drive for NanoPi NEO or NEO 2 board. The NEO 2 board is strongly recommended, since it’s not much more expensive, but should deliver much better results due to its Gigabit Ethernet interface. I’ve received two of those kits together with several other boards & accessories from FriendlyELEC, and today I’ll show how to assemble the kit, configure OpenMediaVault, and run some benchmarks.

NAS Kit V1.2 Assembly with NanoPi NEO 2 Board

The only extra tool you’ll need is a screwdriver, and potentially a soldering iron as we’ll see further below.
The metal box is stuff wih accessories so the first thing is to open one or two sides to take out the content. We have the mainboard, NanoPi NEO back plate, NanoPi NEO 2 back plater, a heatsink and thermal set, and a set of 5 screws to tighten the hard drive which mean there’s one extra screw. FriendlyELEC always adds extra screws, and I find it’s a nice touch, as it can be a real pain if you happen to lose one.

Click to Enlarge

Let’s have a closer look at the “1-bay NAS Dock v1.2 for NanoPi NEO/NEO2” board. We have a UAS capable USB 3.0 to SATA brige chip between the two header for NanoPi NEO board (note that the USB connection will be limited to USB 2.0 since the board only supports that), an LED, a USB 2.0 host port for a printer, WiFi dongle, or webcam, the power switch, the power jack, a 3-pin serial header, an I2C connector for Grove modules, and of course the SATA connector.

Click to Enlarge

There’s not much on the other side of the board, except a CR2032 battery slot for the RTC.

Before going further, you’ll need to go to the Wiki, and get the latest OpenMediaVault firmware, in my case, which I then flashed with Ether program to a micro SD card..

Once this is done, install the heatsink and thermal to your NanoPi NEO 2 board, and insert the micro SD card into the board.

Notice that I also soldered the headers. While it would be obvious to people would have looked at the pinout diagram, I’ve read some people have justed connect the board using the (pre-soldered) 4-pin header, as they may have believed it was a USB header, but it’s just the serial console instead, and obviously the hard drive was not detected. If you don’t feel like soldering the headers to the board yourself, make sure you tick the option “with pin headers soldered” when ordering. It just costs $1 extra.

Now we can insert our board into the “1-bay NAS Dock” board, instead the hard drive, and optionally an I2C module. I connected an I2C OLED display i the picture below for illustrate, as using the display would require cutting out the case. Some people may want to connect an I2C temperature sensor instead.

Click to Enlarge

I used four screws to tighen the hard drive on the other side of the board, and install a CR2032 battery for the real-time clock.

Finally, you’ll need a 12V power supply with at least 1A, but I could not find any (safe) spare ones so I used Maxoak K2 power bank instead, since it can output 12V @ 2.5 A max.

OpenMediaVault Setup on NanoPi NEO 2 Board

So I connected everything, and applied power, but the board would not boot with the Ethernet Link LED blinking in a regular fashion, meaning something was very wrong. So I took out the board, and connected a serial debug board, connect to the console via minicom using 115200 8N1, and that’s what I got:

The boot was just stuck there. I re-inserted the micro SD in my PC, and I could see both boot and rootfs partitions, so everything looked good.
Then I powered the NanoPi NEO 2 board with a 5V/2A power supply only, and the boot succeeded:

Then I went back to the 12V power input on NAS Kit with the power bank and the boot succeeded. Very strange. It turns out the board would not boot most of the time, but the symptoms are not reproducible 100% of the time. This kind of random behavior is usually a timing or distorted signal issue. So I thought the micro SD card might not play well with the board, and the power bank signal might not be so clean. So I first flashed another micro SD card, but same results. I used another 12V/5A power supply, and it did not really help either. Finally, I used another NanoPi NEO 2 board and it appears to be stable.

You can find the board using FriendlyELEC.local if bonjour services are running in your computer:

Alternatively, you could check out the IP address in other ways. In my case, I just type friendlyelec.local in Firefox to access the web interface. The default username and password are admin and openmediavault.

Click to Enlarge

After login, you can access the dashboard showing system information, and which services are running. You may want to disable the services you don’t need.

Click to Enlarge

You can go to Storage->Physical Disks to check if your hard drive has been detected. No problem for me here with a 931.51 GiB drive detected.

Click to Enlarge

You may then want to setup a fix IP address. There are various ways to do this but I went to Network->Interfaces and set eth0 to a fixed IP address. You’ll be asked to apply the changes once it’s done.

Click to Enlarge

I also changed the hostname to CNX-NEO2-NAS in the General tab.

After that I decided to address some security issues. First by changing the administrator password in General Settings->Web Administrator Password.

I then went to Access Rights Management->User to find out there were two pre-configured users: pi and fa. I deleted fa user, changed pi’s user password, and added it to ssh group. It’s actually even probably better to just delete both user, and create your own.

The root user is not shown, but you’ll want to login as root through ssh first and change the password, as the default password is fa. Once it’s done, you’ll have better security, and your system should not be easily accessible via basic “hacks”. For more security, you’ll still want to install an RSA certificate. A self-signed one should do if you plan to use it only in the local network, but you may also consider a free Let’s Encrypt certificate instead.

We can now take care of the hard drive. I went to Storage->File Systems, and clicked on +Create file system which will let you choose between BTRFS, EXT3, EXT4, XFS, and JFS. I’ve gone with EXT4 first.

Click to Enlarge

After a few minutes you drive should be formatted, so we can configure network shares. I want to use SAMBA and SFTP to transfer files for the purpose of this review, so I went to Access Rights Management->Shared Folders to add a new share called HDD for the root of of hard drive. You may want to add multiple share if you plan to split videos, documents, music and so on.

Click to Enlarge

I clicked Save, and selected ACL to add permissions to pi and admin users. You can add whatever users you plan to use to access the share.

Click to Enlarge

That share3d folder can now be assigned to the services you plan to use. SFTP is enabled by default when SSH is running, so I create a SAMA/CIFS share by going to Services->SMB/CIFS->Shares to add the share.

Click to Enlarge

Browsing the Network with Nautilus would show both cnx-neo2-NAS – SMB.CIFS and cnx-neo2-nas – SSH (SFTP) shares.

Configuration is now complete. I have not find a clean way to power off the system, so I normally open a terminal session via ssh and run the shutdown now command. A software button to turn of the NAS would have been a nice features on the kit.

I also often encountered the error “Software Failure. Press left mouse button to continue. Session not authenticated.” before the session timeout is set to 5 minutes. If you prefer a longer timeout, you can change it in General Settings->Web Administration.

In case you want to use the RTC, you may first want to set the timezone:

Check the date is correct, and write it to the hardware clock:

before reading it back.

You can test it by rebooting the board without the Ethernet cable:

Perfect! You’d just have to make sure the “set” command is run automatically at boot time if the time in the RTC is set. It would be good if FriendlyELEC updated their image to do that automatically at boot time.

NAS Dock V1.2 + NanoPi NEO 2 Benchmarks

Since I can now copy files and folders over SAMBA and SFTP, we can start running some benchmarks to evaluate performance. I’ll use EXT-4, BTRFS, and XFS file systems on the hard drive, and run iozone to specicially test storage performance, following by copying large and small files over SAMBA or SFTP to test real-life NAS performance. For large file copy, I’ll use a folder with 7 large files totaling 6.5 GB, and for small files, I’ve done a fresh checkout of the Linux kernel in my computer:

and removed symlinks since they may cause issues during copy, as well as .git directory with a huge 1.8GB file:

The end result is a directory with 64,013 files totaling 748.6 MB.

Iozone results




I’ve taken results with 16384kB reclen for read, write, random read and random write values to draw a chart, since most people are likely going to store large files in their NAS. The smaller reclen could be interesting if you plan to handle smaller files.

All three file systems have a very good read speed of around 40 MB/s, but BTRFS write appear to be the fastest among the three, with EXT-4 being the weakest at around 25 MB/s. But for some reasons, those results are useless in practice, as we’ll see below. Finding out the exact reason would possibly require studying and profiling iozone and the kernel source code which would be outside of the scope of this review.

File copy over SAMBA and SFTP

Results for large files in minutes and seconds.

File Copy  Large Files SMB SFTP
Write Read Write Read
EXT4 02:49.00 02:40.00 03:54.00 04:15.00
BTRFS 03:20.00 02:40.00 03:48.00 04:32.00
XFS 02:45.00 02:38.00 03:36.00 04:23.00

Chart converted to MB/s.

Read and Write Speeds in MB/s

First, we can see very good read performance from the NAS (NAS to my PC)  with 41 to 42 MB/s close to the theorethical limit of a USB 2.0 connection. Write speed is a a little different as the files were transferred more slowly with BTRS, and around 40MB/s with EXT-4 and XFS.  Since SFTP is encrypted the transfer speed is roughly the same for all three file systems. Overall the file system you choose does not really impact performance with large files.

Results for small files in minutes and seconds.

File Copy  Small Files SMB SFTP
Write Read Write Read
EXT4 15:26.00 18:34.00 09:02.00 12:48.00
BTRFS 18:48.00 18:02.00 10:30.00 11:30.00
XFS 17:33.00 18:22.00 09:18.00 12:35.00

Chart converted to MB/s.

Transferring a large number of small files over SAMBA is really slow, and barely faster over SFTP. Again,there aren’t any significant differences between file systems here.  If you are going to transfer a large number of small file over the network, you may want to either compress the files before transfer, or compress the files on the fly using the command line:

It took just 1 minute and 49 seconds to transfer all 64,013 files, or over five times faster than SFTP write to XFS, at around an effective 6.86 MB/s. So knowing your tools may matter as much as having the right hardware.

I was going to run a last part after enabling optimizations provided by tkaiser, but it turns out FriendELEC has already done that in their firmware image.

If you want to reproduce the setup above, you’ll need to purchase NAS Kit v1.2 for $12.99, and a NanoPi NEO 2 with soldered headers for $15.99. If you don’t have a 2.5″ hard drive, you’ll need to add this, as well as a 12V power supply which you could purchase locally, or on FriendlyELEC website for under $10. All in all that’s cheaper than a similar kit with a Raspberry Pi 3 board, and you’ll get close to four times the SAMBA performance for large files since RPi 3 will be limited to 10 to 12 MB/s due to the Fast Ethernet connection.

Using GPIOs on NanoPi NEO 2 Board with BakeBit Starter Kit

May 21st, 2017 10 comments

NanoPi NEO 2 is a tiny 64-bit ARM development board powered by Allwinner H5 processor. FriendlyELEC sent me a couple of NEO 2 samples together with their BakeBit Start Kit with a NanoHat and various modules via GPIOs, analog input or I2C. I’ve already tested both Armbian with Linux 4.11 and Ubuntu Core Qt with Linux 3.10, and ran a few benchmarks on NanoPi NEO 2. You would normally prefer to use the Armbian image with Linux mainline since it provided better performance, but at the time I was told GPIO support was not there.

Configuring NanoPi NEO 2 board with BakeBit library

So this week-end, when I decided to test GPIO support and BakeBit Starter Kit, I decided to follow this advice, especially image is still the recommended one in the Wiki. So I went with that image.

I’ll use Python examples from Bakebit library, but if you prefer something similar to WiringPi, you may consider using WiringNP library directly instead of using Bakebit. Since NanoHat Hub comes with header with digital I/O (including 2 PWM), analog input, I2C and UART interfaces, I’ll make sure I try samples for all interfaces I have hardware for. FriendlyELEC did not include a module with a UART interface, so I’ll skip that one.

I followed instructions in BakeBit wiki from a terminal which you can access from the serial console or SSH. First, we need to retrieve the source code:

Then we can start the installation:

The last line will install the following dependencies:

  • python2.7           python2.7
  • python-pip         alternative Python package installer
  • git                        fast, scalable, distributed revision control system
  • libi2c-dev           userspace I2C programming library development files
  • python-serial     pyserial – module encapsulating access for the serial port
  • i2c-tools              This Python module allows SMBus access through the I2C /dv
  • python-smbus   Python bindings for Linux SMBus access through i2c-dev
  • minicom             friendly menu driven serial communication program
  • psutil                   a cross-platform process and system utilities module for n
  • WiringNP           a GPIO access library for NanoPi NEO

This will take a while, and after it’s done, the board will automatically reboot.

We can check if everything is properly running, but try out one of the Python scripts:

hmm, python-smbus was supposed to be installed via the installation script. Let’s try to install it manually:

Running the command again with verbose option shows the download URL is not valid:

So I went to looking for another python-smbus library in case the name has changed, and I finally installed the pysmbus:

I could go further, but the I2C bus was not detected:

So maybe the driver needs to be loaded. But running sudo modprobe i2c_sunxi it does nothing, and I could notice the .ko file is missing from the image…

So let’s try to build the source code for the board following the Wiki intructions:

We also need to install required build packages…

… download gcc-linaro-aarch64.tar.xz toolchain, and copy it to lichee/brandy/toolchain directory (do not extract it, it will be done by the build script).

Now we can try to build the kernel for NanoPi NEO 2 (and other Allwinner H5 boards).

and it failed with more errors possible related to CROSS_COMPILE flag. There must be a better solution… FriendlyELEC guys might not work on Saturday afternoon, and while I did contact them, I decided to try one of their more recent images with Linux 4.11 available here.

Let’s pick since it has a similar name, and is much newer (released 3 days ago). I repeated the installation procedure above, and …

Success! Albeit after 4 to 5 hours of work… Let’s connect hardware to ind out whether it actually works, and not just runs.

Analog Input and Digital Output – Sound Sensor Demo

The simplest demo would be to use the LED module, but let’s do something more fun with the Sound Sensor demo I found in BakerBit Starter Kit printed user’s manual, and which will allow us to use both digital output with the LED module connected to D5 header, and analog input with the Sound sensor module connected to A0 header. Just remember the long LED pin is the positive one.

You can run the code as follows:

I changed the source a bit including the detection threshold, and timing to make it more responsive:

The LED will turn on each time the the sound level (actually analog voltage) is above 1.46V.

PWM and Analog Input – Servo and Rotary Angle Sensor Demo

We can test PWM output using the Servo module connected to D5 header, and control it using the rotary angle sensor module connected the A0 analog input header .

Click to Enlarge

The sample for the demo runs fine, and use the potentiometer is detected:

However, the servo is not moving at all. Raspberry Pi relies on rpi-config to enable things like I2C and other I/Os, and I noticed npi-config in the Wiki for NEO 2. So I ran it, and sure enough PWM was disabled.

So I enabled it, and answered Yes when I was asked to reboot. The only problem is that it would not boot anymore, with the system blocked at:

So maybe something went wrong during the process, so I re-flashed the Ubuntu image, reinstalled BakeBit, and re-enabled PWM0. But before rebooting, I checked the boot directory, and noticed boot.cmd, boot.scr, and the device tree file (sun50i-h5-nanopi-neo2.dtb) had been modified. The DTB looks fine, as I could decode it, and find the pwm section:

Let’s reboot the board. Exact same problem with the boot stuck at “Starting kernel…”. So there’s something wrong with the way npi-config modifies one or more of the files. With hindsight, I should have made a backup of those three files before enabling PWM the second time… I’ll give up on PWM for now, and ask FriendlyELEC to look into it.

I2C and Analog Input – OLED UI controlled with Joystick

The final test I’ll use the I2C OLED display module connected to one of the I2C headers, together with the analog joystick module connected to A0 header.

Click to Enlarge

Let’s run the sample for the demo:

It works, but there’s a bit of a lag, and the sample may have to be improved to better detect various states. I’ll show what I mean in the video below.

The bad parts are that documentation is not up-to-date, enabling PWM will crash the image, and while the Python sample do demonstrate IO capabilities, they should probably be improved to be more responsive. The good part is that we’re getting there, the hardware kit is a really nice, and I think the documentation and software should become much better in June, as FriendlyELEC has shown to be responsive to the community issues.

What? Python sucks? You can use C language with GPIOs too

If Python is not your favorite language, FriendlyELEC also provided some C languages samples in the C directory:

As we’ve seen above, Bakebit library appears to rely on WiringNP, and you’d normally be able to list the GPIOs as follows:

The utility is not too happy about seeing an Allwinner H5 board. But maybe the library in the board is not up-to-date, so I have built it from source:

and run the gpio sample again:

Excellent! It’s not quite a work-out-of-box experience, but NanoPi NEO 2 can be used with (most) GPIOs.

My adventures with NanoPi NEO 2 board are not quite done, as I still have to play with NanoHat PCM5102A audio add-on board, which I may end up combining with a USB microphone to play with Google Assistant SDK, and I’m expecting NanoPi NAS Kit v1.2 shortly. I’ll also update this post once PWM is working.

NAS Kit v1.2 Gets Support for NanoPi NEO 2, an UAS Capable USB to SATA Bridge, and an RTC Battery

May 12th, 2017 39 comments

Last month, FriendlyELEC launched a NAS Dock kit for NanoPi NEO board, but they’ll already removed it from their store. That’s because they have a new version NAS Dock v1.2 that also supports NanoPi NEO 2 with Gigabit Ethernet, replaces JMicron JM20329 by UAS capable JMicron JMS567 USB 3.0 to SATA bridge, and adds an RTC battery.

The rest of NAS Dock Kit v1.2 specifications remain the same:

  • 1-bay NAS Dock expansion board with
    • JMicron JMS567 USB 3.0 to SATA bridge
    • SATA connector for 2.5″ HDD drive
    • Extra USB host port
    • On/off switch, and dual color status LED
    • Header to connect NanoPi NEO / NEO 2 board
    • 12V DC power input
    • Dimensions – 151 x 89.7 mm
  • NS-120 aluminum enclosure (154 x 100 x 47.5 mm, 414 grams)
  • Heatsink set for NanoPi NEO / NEO 2
  • 4x M3 6mm screws, 8x M2.5 6 mm screws
  • Four rubber pads
  • Front and back covers

Since NEO 2 has a low profile Ethernet jack, the company provides both NEO and NEO 2 back covers in the kit. It’s probably less hassle than providing two kits.

Software has also improved, as while the company still provides an OpenMediaVault image, it’s now based on Linux 4.11 + Debian 8. You’ll find the download links and instructions in the Wiki. FriendlyELEC also added the better iozone benchmark to the quick hdparm test to compare the “SATA” performance to Raspberry Pi 3, NanoPi NEO, and NanoPi NEO 2 boards.

They should really have done a file copy test over Gigabit Ethernet, as NanoPi NEO 2 should be about 2 to 3 times faster while copying a large file. Raspberry Pi 3 shared Ethernet and USB bandwidth may also affect the performance badly in some specific use cases, while NanoPi NEO 2 won’t have this type of problem since Ethernet and USB are two separate interfaces in Allwinner H5 processor.

The other good news is that despite the improvements, FriendlyELEC NAS Dock Kit price has not changed, and it is still sold for $12.99 + shipping. You’ll also need a  $14.99 NanoPi NEO 2, a micro SD card, a 12V/2A power supply to complete the setup. In other news, the company has also introduced a kit with NanoPi NEO 2 board, and a cute metal case with OLED display going for $34 in total (board included).