Archive

Posts Tagged ‘how-to’

NanoPi Duo Quick Start Guide – Ubuntu, Breadboard, Mini Shield & mSATA SSD

October 30th, 2017 12 comments

As far as I know NanoPi Duo is the only quad core ARM Linux development board that can fit on a breadboard. We’ve already seen it’s much smaller than Raspberry Pi Zero, and the company offer a mini shield exposing USB ports, Ethernet, a few I/Os, and an mSATA slot in in NanoPi Duo Starter Kit Review – Part 1: Unboxing and Assembly.

I’ve finally played with it this week-end, and will report what I had to do to blink a LED when connected to breadboard, and my experience using the mini shield with  an mSATA SSD, WiFi connectivity, and cooling under load.

Flashing Ubuntu 16.04.2 firmware image to NanoPi Duo

As with many other Allwinner development boards, you should first check if Armbian is available for the board. NanoPi Duo is not supported, but it’s said to work with Orange Pi Zero image minus support for WiFi. Since the latter is rather important if you’re going to use the board standalone, I instead went with FriendlyELEC’s Ubuntu Xenial image (nanopi-duo_ubuntu-core-xenial_4.11.2_20170908.img.zip) shared on the company’s Wiki.

I flashed the (compressed) image with Etcher – available for Windows, Linux, Mac OS, on a 8GB micro SD card (Sandisk Ultra).

Using NanoPi Duo as a Breadboard-friendly Development Board

Once this is done, insert the micro SD into the board, insert it into a breadboard, and connect your circuit (in my case a 5V LED connected to GPIOG11 via a transistor). Most other breadboard-friendly WiFi boards include either a USB to TLL chip allowing to access the board’ serial console over USB (e.g. ESP32 boards), or firmware that setups the board as an access point for initial configuration (e.g. LinkIt Smart 7688 Duo). So you just need to connect power and you’re good to go.

Click to Enlarge

But NanoPi Duo’s board has no serial to USB chip, and the current firmware does not setup an access point by default, so I’ll need to connect a USB to TLL debug board too, as shown above. I then started minicom with 115200 8N1 configuration, and connected the board to one of the USB port of my computer for power, and the boot worked just fine.  See complete boot log for reference:

The system will autologin, and show a welcome boot message similar to what is found in Armbian build.

Let’s check some of the relevant info:

The image is based on Ubuntu 16.04.2 with a recent Linux 4.11.2 although apparently not updated with the latest patchsets found in Linux 4.11.12. The rootfs has been automatically resized at boot time so I have 5.9GB free on the partition, and 497MB RAM is accessible from Linux.

There are some useful pre-loaded modules for WiFi, USB mass storage, and IPv6:

Most people will want to use WiFi in this configuration (breadboard use), and nmtui text user interface is normally recommended, but the UI was really messy in the serial console, so I reverted to use nmcli instead as explained in the Wiki. First let’s list the network devices:

WiFi is disabled, so we’ll enable it and scan nearby routers:

I repeated the last command three times, but my main (2.4 GHz) router was not listed. So let’s attach a u.FL antenna…

Click to Enlarge

… to see if I can get a stronger signal for the already detected access points, and find my main router (CNX-TRANSLATION):

Success! I can now see CNX-TRANSLATION SSID, and CNX-SOFTWARE SSID signal is much stronger. However, I lost sonoff-office (which I did not plan to use).  We can connect to the access point of your choice as follows:

Oops. I did not work out as expected. Listing the access points again:

That’s crazy… All my APs are gone! But after persevering a few more times, I was finally able to connect and get an IP address:

We can now update the system to make sure it has the latest packages:

The board could download all the ~150 packages without issues, so once the connection is up it looks fairly stable. The update will take a while, so you may want to try a few other features of the firmware. For example, the company pre-installed NanoPi-Monitor, a fork of RPi-monitor, which allows you to monitor CPU and memory usage, temperature, up time, etc.. directly from a web browser via http://board_IP:8888.

Click to Enlarge

I was also be able to connect via SSH using either pi/pi or root/fa username and password.

The last step of this section of our tutorial is to control GPIOs. Since the board runs Linux 4.11, we may have hoped the new GPIO subsystem might be implemented, but lsgpio is not installed, and instead the company recommends to use WiringNP, a fork a WiringPi. It’s pre-installed, so we can use it right away to list GPIOs:

I’ve connected the LED to GPIOG11 (mapped to pin 16 in WiringNP), and it’s on by default, so let’s pull it down:

The LED turns off, and we can turn it back on with:

Let’s write blink.c to blink our LED every 500 ms:

We can now build and run it, and the LED will blink as expected:

You need to run blink as root as it is required by wiringPiSetup() function: “wiringPiSetup: Must be root. (Did you forget sudo?)”, but there are workarounds roughly explained in the Wiki. The user key/switch on NanoPi Duo board is connected to “GPIOL3/K1” pin, but is not listed by gpio readall command, so this would have to be looked into.

Other modes such as PWM,  I2C, SPI, UART, PWM should also be supported, but out of the scope of this quick start guide.

Beside “GPIOs”, Ethernet, USB, composite video, and various audio signal are also exposed, so it can make for some very interesting DIY projects.

NanoPi Duo with mini Shield and SSD

I took out the micro SD card, and inserted in my other NanoPi Duo board connected to the mini shield with an mSATA SSD. This time I connected the board through a 5V/2A power supply, and added an Ethernet cable.

Getting started is much easier since we are using Ethernet here. Just find your board IP address in your router’s DHCP client list, or via tools like arp-scan, and connect over SSH with pi user:

We can see the SSD is detected (sda – 59GB):

but not mounted:

So I formatted the drive with EXT-4…

and mounted it in a temporary directory to check it out:

In theory the SSD should have much better performance than the micro SD card, even though it’;s connected through a USB to SATA chip. But let’s no assume anything, and first run iozone on the 8GB micro SD provided by FriendlyELEC:

and repeat the same test on the SSD:

We can see that both sequential performance, and especially random I/O are much better on the SSD drive, so it would make perfect sense to move the rootfs from the micro SD card to the SSD.

But before going there, I’ve been asked to check run smartctl on the drive:

There are many parameters reported, and one of them is the drive temperature which apparently went up to 52°C, and as low as 19°C. The latter could not have happened my location, since temperature never went below 24°C.

Time to move the rootfs to the SSD, and to do so I’ll adapt the instructions for CubieTruck, another Allwinner development board.

As we’ve seen above, the roofs is mounted to /dev/mmbblk0p2, so let’s mount it in another directory, and copy the content to the SSD:

We need to let the boot partition know our rootfs has moved. Let’s go to /boot directory, and edit boot.cmd text file (used to be uEnv.txt in CubieTruck) by changing root from /dev/mmcblk0p2 to /dev/sda in the bootargs with all other parameters unchanged:

The final step to create boot.scr binary file using the command below, and reboot.

After a few seconds, we should be able to use login and verify the rootfs has now moved to sda.

Success! The boot partition is still in the micro SD card since Allwinner platform can’t boot from USB. You can reclaim mmcblk0p2 partition on the SD card to do something else. Eventually we should be able to do away completely with the micro SD card by booting from the SPI flash in the board, but I think this is still work in progress (TBC).

Stress Testing & WiFi Performance

Such small board is not designed for heavy load, as even with an heatsink, heat dissipation does not work as well as on larger boards (with a large ground plane). To demonstrate that I ran stress on all 4 cores, and monitored temperature and CPU with NanoPi-Monitor.

Click to Enlarge

Stress was started at 19:32, on based on the chart above the CPU cores ran at 1008 MHz for about two minutes with the CPU temperature quickly increasing from around 50 to 70°C, and after the CPU frequency oscillates between 624 MHz and 1008 MHz to keep the temperature in check. Ticking “active CPUs” would show 4 cores are used at all times during stress. Performance does not completely collapses but the system cannot run at 1008 MHz at all times without additional cooling. Whether this is an issue or not depends on your specific load/use case.

NanoPi Duo relies on Allwinner XR819 WiFi module, and while it’s working decently on my Orange Pi Zero, I had reports of poor peformance and issues in the past, and as we’ve seen above I had some troubles finding and accessing my access points with NanoPi Duo. So it might be good to have a look at WiFi performance too.

As a side note, nmtui is usable while connecting via SSH instead of minicom / serial connection, so if you prefer a user interface you may want to use this tool instead of nmcli when using the mini shield.

That time I could also list all my local access points even with no external antenna attached:

But I could not ssh to the board via the WiFi interface (192.168.0.115) from my computer:

So I rebooted the board, and could login again. All good, so I ran iperf with chip antenna (only):

  • upload:

  • download:

The board was located in my usual (TV box, development board) test location about 4 meters from the router (+ wall), and results are rather poor, so I tried again with an external antenna:

  • upload:

  • download:

Not fantastic, but still about twice as fast, and with much better signal strength so loss of connection should be less likely improving reliability.

MeLE PCG35 Apo Apollo Lake Mini PC Review – Part 3: Ubuntu 17.10

October 26th, 2017 4 comments

I completed the review of MeLE PCG35 Apo with Windows 10 Home a few days ago, and as promised, I’ve now installed the freshly released Ubuntu 17.10 in the Intel Celeron J3455 “Apollo Lake” mini PC.

I’ll start by shortly explaining the step to install Ubuntu 17.10 in the M.2 slot, although you could also install it to the internal eMMC flash replacing Windows 10, then show what works and what does, and finally include a video reproducing the tests I usually do in Windows 10.

How to Install Linux in MeLE PCG35 Apo

This partially follows the procedure I used to run (not install) Ubuntu 16.04 on MeLE PCG03 Apo mini PC. First you’ll need to download the ISO of your choice (ubuntu-17.10-desktop-am64.iso in my case), and prepare a bootable USB flash drive with the software of your choice be it Rufus, Startup Disk Creator or others. I did mine with Startup Disk Creator in my Ubuntu 16.04 computer

We can now plug the USB flash drive with Ubuntu 17.10 into one of the USB port of the mini PC, start it up and press ‘Esc’ key to enter Apio Setup Utility (aka “The BIOS”). By default, the system will use the “Windows boot method”, but we can change that by going to Chipset->South Bridge, then OS Selection and select Intel Linux.

Now go to the Boot menu and select our USB flash drive (I had to select “Partition 1”) to start Ubuntu installation. I did not want to remove Windows 10 (installed in the eMMC flash), nor wipe out the Program Files directory in the M.2 SSD, but still install Ubuntu 17.10 in the faster M.2 SSD, so I used a custom installation type.

Click to Enlarge

The eMMC flash, the M.2 SSD (/dev/sdc), SATA hard drive, and USB hard drive were all recognized by the system. I only modified the SSD partition by resizing the Windows’ “Program Files” partition to 64000 MB, and creating new partitions for the root file system (167913 MB) and swap (~8GB). Once the changes were all applied I clicked on Install Now to complete the installation, and a few minutes later reboot with Grub giving the option between Ubuntu (default) or Windows Boot Manager.

So we have a dual boot Windows 10 / Ubuntu 17.10 systems here, I selected Ubuntu and within a few seconds I could login to Ubuntu 17.10 and access the GNOME desktop environment.

Click to Enlarge

Canonical did a good job of making their GNOME implementation feels like Unity, but there are some obvious changes like the login prompt, different dash search location, and redesigned Settings menu.

Ubuntu 17.10 on MeLE PCG35 Apo – System Info and Hardware Features

Let’s run some command to check what we have:

Ubuntu 17.10 with Linux 4.13, around 4GB RAM, and 153 GB rootfs. The SATA drive (NTFS) was not mounted by default, but I could mount it manually later on. However the three of four partitions on the USB drive were mounted automatically (exFAT not supported?), and the Windows partitions was mounted too:

Good news if you don’t plan to use an SSD, but want to install Ubuntu or other Linux distribution in the computer.

CPU information returned by lshw:

as well as BIOS, cache, & memory info:

Ethernet & WiFi were also detected:

I also tested all ports and networking options of the device, and everything worked just fine.

Features Results
HDMI video OK
HDMI audio OK
VGA OK
Ethernet OK
WiFi OK
Bluetooth OK. Tested with Bluetooth headset
USB 2.0 port OK
USB 3.0 ports OK
USB 3.0 type C port OK. Mouse connected via adapters
SD slot OK
eMMC flash OK

Ubuntu 17.10 User Experience on Apollo Lake

Finally I played with various apps, mirroring what I normally do on Windows 10, except I had to replace Asphalt 8 Airborne by Jet Racing Extreme which I installed from Steam:

  • Multi-tasking – Launching and using Firefox, Thunderbird, LibreOffice, and Gimp at the same time
  • Web Browsing with Firefox
    • Loading multiple tabs with CNX Software blog, Facebook, YouTube
    • Playing Candy Crush Saga
    • Playing a 4K YouTube Videos (also tested with Chrome)
  • Gaming with Steam (Jet Racing Extreme Demo)
  • Kodi 4K videos and audio pass-through

The video is fairly long, and I did not edit it to show how some parts are rather slow to load, especially Jet Racing Extreme, and to a lesser extent Candy Crush Saga.

The Multi-tasking part is really fast, everything starts about as fast as on my much more powerful main computer (AMD FX8350 with 128 GB SSD + 16 GB RAM), ans for simple desktop tasks, even with multiple program, the system is really fast enough.

Multitab browsing goes well too, but Candy Crush Saga takes quite a while to start, so much that I decided to play YouTube videos will the game started. 1080p YouTube video playback works OK, but once we switch to 4K, it’s really sluggish. By default VP9 is used, so I installed h264ify, but in that case (AVC1), YouTube limits video to 1440p, and 2160p is not accessible. I switched to Chrome, and VP9 decoding was again incredibly slow.

Jet Racing Extreme Demo is playable – if we ignore the awful controls -, but it’s really slow to load. Once the reason could be that it requires a lot of RAM, and 4GB is not enough. Running htop while running the game showed that the RAM was fully utilized, and part of the swap was needed too (1GB+).

Kodi 17.3 (installed with apt) was also a disappointment with H.264, H.265 and VP9 all relying on software decoding despite VAAPI hardware video decoding being enabled in the settings. That means the systems is usable with 1080p videos, but not 4K videos. Automatic frame rate switching did not work either. Audio pass-through with PulseAudio worked fine as I could play videos with Dolby Digital 5.1 (AC3) and DTS 5.1.

Getting Started with MicroPython on ESP32 – Hello World, GPIO, and WiFi

October 16th, 2017 13 comments

I’ve been playing with several ESP32 boards over the months, and tried several firmware images. I started with a tutorial for Arduino Core on ESP32, a few month later I tested ESP32 JavaScript programming with Espruino on ESPino32 board, and recently Espressif Systems sent me ESP32 PICO core development board powered by their ESP32-PICO-D4 SiP, and while I took some pretty photos, I had not used it so far.

So I decided to go with yet another firmware, and this time, I played with MicroPython on ESP32, and will report my experience with basic commands, controlling GPIOs, and WiFi in this getting started post.

Flashing Micropython Firmware to ESP32 Board

Source code is available on Github, as a fork of MicroPython repo as ESP32 support has not been upstreamed yet. We could built the firmware from source, but there’s also a pre-built binary which you can download on MicroPython website.

I’ll be using Ubuntu 16.04 for the instructions, which should be pretty similar for other Linux distributions, especially the ones based on Debian, and if you’re using Windows 10, you should be able to follow the same instructions after installing Windows Subsystem for Linux with Ubuntu on your computer.

Let’s open a terminal, to download the firmware (October 14):

If you have not done so already, install the latest version of esptool:

Now connect the board via a micro USB to USB cable to your computer. The log should like like:

In my case, the device is ttyUSB0, but it may vary depending on the board used. We can now erase the flash, and copy the firmware to the board:

If the last step is successfull,  the output should be similar to the one below:

As a side note, version 2.1 of esptool does not know about ESP32-PICO-D4, but it can still detect an ESP32 device, and the update went through normally.

Hello World Sample / Boot Log with MicroPython

We can test the firmware, by connecting to the board using minicom, screen, putty, or whatever software you feel most comfortable with. I went with minicom, setup a connection to /dev/ttyUSB0 device with 115200 bps baudrate. I immediately tested the print function, and made an hard reset to check out the boot log:

The reset command will first generate some errors message, before rebooting the board:

We can type help function to get some more help: