NanoPi Neo 2

Peter ScargillFriendlyArm, Nanopi Neo 2109 Comments on NanoPi Neo 2

NEO 2You may well have read my review of the NanoPi NEO back in August 2016 – a nice little H3 unit available in two versions, 256Meg and 512Meg RAM. Well, the new unit has an H5 64-bit processor and comes with 512MB RAM and although there is only one USB connector – there are three USBs available. Size is 40mm square! The NEO 2, however is more expensive than the original at $15 + post etc.

There are lots of add-ons available for it including WIFI, a TTL-RS232 module (just an FTDI but cheap enough), power dock, prototype board etc etc – you can read about it here so I won’t go into too much detail. Personally I wonder about the logic of bringing out add-ons for such a small board – would you not be better off buying more complete board in the first place? Where this board scores is size – it really is small.

So – nice looking – I’m not sure why they chose hardwired Ethernet over WIFI – I’d have gone the other way and kept the height down – but there you are. The existing case for the NEO does not fit the new model incidentally.

The board DOES have fast Ethernet which is a plus – but then if you were going to use it as a NAS the 512Meg RAM might be a limitation?

NEO 2

So you can log into the board via the FTDI or by normal micro-USB serial. At this point I headed off to the WIKI to get the operating system image..

One thing that worried me – and I’ve complained about this before – the requirements are:  A NEO2 (obviously), a micro TFT card, a power supply and “a computer running Ubuntu 14.04 64 bit” –  FRIENDLYARM  – YOU MUST BE JOKING! Most of us in the west have Microsoft Windows PCs. I do have one PC running Linux – it is running MINT and I’ve no intention of changing that just for one new board!!!

I was a little disappointed to find that the website has only Ubuntu Core available – unlike the M3 and M1 both of which have excellent DEBIAN images which work straight out of the box. Again – this fascination with Ubuntu – a bit disappointing to those of us who like Debian and have used it on previous boards – however – the current version is 16.04 which is up to date.

At the time of writing, the ARMBIAN site had only nightly releases available and they refer to WIFI – so not exactly customised to this board which by default does not have WIFI !!

So, despite desire for Debian, I downloaded the Ubuntu Core software from the FriendlyArm WIKI site. I blew the image file with Win32 Disk Imager as usual and plugged it into the NEO 2 board. From what I could read, this would expand on first use and might take some time.

Power on and both the green and blue lights flashed for a moment then the green went full on – and the blue continued to flash. A quick check with Advanced IP Scanner showed the board sitting at 192.168.0.193.

I opened winSCP as usual and I tried logging in as root with password fa.

Having ran the script and that having created a PI user – I went off to log in as user PI – loaded and ran the script again. While all of this was running the processor was running at 53c, so depending on use, the heatsink may not be needed after all.

I cannot tell you how many times I have impressed on various companies – you cannot just put out hardware without software support – and Ubuntu 16.04 (if you have to use Ubuntu) is pretty standard stuff.

And yes the board is fast. Total Time using the nightly built from Armbian to install the script was 46 minutes – as against several hours on the Raspberry Pi Zero WIFI !! Using the default Ubuntu from FriendlyArm, my script took about an hour.

I have however noted some issues with the utility program as I could not get the unit to set up for 3.5mm jack audio. I got an error message.  There were a couple of other minor niggles which I’ve reported and no doubt will be fixed.  I’ve also noted that for the first time, they’ve created a PI user but when I used that for the script, it kept asking me for the password which was marginally annoying so I ran:

sudo visudo

and changed the sudo line to read

%sudo   ALL=(ALL) NOPASSWD: ALL

That sorted that out. Annoying but not that critical.

A brief check of my script and everything worked – so at least there are no negative changes and far less messing about than there was when I started this blog entry.  I tried a typical Chinese WIFI dongle known to work with the M3 and similar boards – although IFCONFIG was aware that something was plugged in, no WLAN messages came up.  GPIO apparently is on the way.

I think a little more time is needed before we can say this is a winner.  I never understand why companies release boards without full GPIO support when the openly available competition such as the Raspberry Pi has support by the shedload.

Where I WAS disappointed was when testing the SERIAL ports – there are 4 of them – with serial port 0 being used for debug. Node-Red recognised all 4 of them and even said it was connected – but ONLY serial port 0 seems to be working. That is a real shame as there simply isn’t enough info out there to figure out how to get the others to work. Whether this is an issue with the operating system or the Node-Red serial port I don’t know but that’s a disappointment.

Update 9 May 2017

I’ve now heard back from FriendlyArm on the subject of GPIO and the issues I had – they have fixed the most trivial – the temperature display – here is the link – https://www.sendspace.com/file/eqh907

But they still have not addressed the almost total lack of information on GPIO, SPI, I2C and serial ports. I decided to go see, because this board uses the H5, if there was a WIRINGPI or WIRINGOP library for it. Well, what a disaster – there are several for the H3 but the only links I could find suggesting an H5 build FAILED until I came across this link – http://www.jianshu.com/p/0ee31099983e

I tried the instructions:

git clone https://github.com/kazukioishi/WiringOP.git -b h5
cd WiringOP
chmod +x ./build
sudo ./build

and sure enough it all compiled. I then went off to my favourite easy-to-use facility GPIO

By trial and error I discovered that setting pins 7 and 10 to outputs worked. That corresponded to FriendlyArm 198 and 67 respectively (goodness knows where they get these numbers from).

Of course – as the numbers were wrong – I could not see how things like serial and I2c could work – it would be up to FriendlyArm to amend the code for their board and I have pointed this out to them – it seems sensible to me that if the market leader i.e. Raspberry Pi -as open source WiringPi with the GPIO utility, then it would make sense for those bringing out products in a similar market space to modify this code for their own use – indeed I believe that Orange Pi do have a version called WIRINGOP to do this and that too is open source. Let’s hope FriendlyArm take notice as their products are good but when you can’t do something as easy as GPIO without having to resort to fumbling around with sys/class etc that’s not very good – but at least that’s an easy way to get to normal IO. The likes of PWM would not work either and I found the i2cdetect command missing. FriendlyArm pointed out that this link takes you to the I2c pins but that still doesn’t help as the likes of GPIO is expecting other pins.

Friendlyarm have recently written to say that they WILL bring out a version of WIRINGPI to go with this board – the sooner the better – if you want this – be sure to write to them to let them know others are interested.  The GPIO utility is really easy to use.

109 thoughts on “NanoPi Neo 2”

  1. I was able to get the NanoHatOLED (I2C) working with the NanoPi Neo2 running DietPi stretch, I had to install WiringNP first and then their NanoHatOLED software.
    But I can’t get it to work with the NanoPi Neo. /dev/i2c doesn’t show up on the Neo when running Dietpi stretch, which is why (I think) wiringNP doesn’t work (complains about it not being a NanoPi board).

    Have you managed to get i2c working on the Neo running DietPi?

    WiringNP:
    http://wiki.friendlyarm.com/wiki/index.php/WiringNP:_NanoPi_NEO/NEO2/Air_GPIO_Programming_with_C

    NanoHatOLED:
    http://wiki.friendlyarm.com/wiki/index.php/NanoHat_OLED

  2. I am trying to understand why my newly booted neo2 using the ubuntu image has the following 2 users shown as logged in..

    root@pip:~# w
    09:58:27 up 1 min, 3 users, load average: 0.25, 0.14, 0.05
    USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
    pi ttyS0 09:56 632days 0.18s 0.04s -bash
    pi tty1 09:56 632days 0.31s 0.05s -bash

    Any ideas folks?

    I’d love to see a Debian image without the openmediavault stuff included – reckon that’s possible too?

      1. Is it easy to uninstall? I wasn’t sure if it was installed from a deb or just manually compiled and integrated. I guess I should investigate that. Still cannot understand why this Ubuntu image has those 2 users always logged in between reboots (and never cleared).

    2. ttyS0 is the 1st serial, are you logged in from serial?
      tty1 is used if you have a graphical environment, usually…
      you 1st say it’s debian, then ubuntu in other comment… what’s that?
      to see if it’s installed via apt:
      dpkg -l | grep -i vault
      copy paste this line, there are lower L and a pipe (|)…
      otherwise, just disable the service… openmediavault is just a web gui to underlying services…

      1. Seems to be confusion… 2 problems…

        1. After creating a new microsd that contains the latest Ubuntu image, upon booting it up you will notice 2 users are logged in. 1 from serial console (ttys0) and one from tty1.

        It’s like these users must of been logged in during creation of that image and thus exist upon booting that image for the first time. Oddly enough they exist across each and every reboot.

        root@pip:~# w
        23:50:34 up 13:17, 3 users, load average: 0.00, 0.00, 0.00
        USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
        pi ttyS0 10:33 633days 0.05s 0.02s -bash
        pi tty1 10:33 633days 0.07s 0.02s -bash

        PS. I am not logged in with either of the above users, these seem to be contained in the image and shown to be logged on upon first (and every reboot).

        2. I want a Debian image, but I don’t want openmediavault and other rubbish in it.

        I wasn’t sure if openmediavault was integrated from source files manually or installed using a deb package – but I will go investigate when time permits. If it’s via deb, its removal will be easy otherwise if the other method it will be very difficult to cleanly remove it.

        Hope this makes sense to my original query..

        1. you can want whatever you want: if it exists, use it, if not, do it yourself or adapt yourself to what’s available… or use boards with more support, like a raspberry pi… and even if openmediavault is installed via source or whatever (you are complaining without even actually testing what i suggested to check this), just disable it and live happy…

          1. It was installed by a package, so it was easy to remove. I just did it now. Good thing to note too, the Debian image upon being imaged and booted doesn’t have those 2 pi users constantly seen to be logged in from tty1 or ttyS0.

            On the Ubuntu image, those users are constantly seen. I cannot see how to disable it either. I can see on the Ubuntu image that the bash processes for those users on those terminals cannot be terminated, as they instantly start again. Looks to be that init starts login -f as root, which in turn is the parent pid for the bash processes for pi user on ttyS0 and tty1. So wasn’t able to work out how to disable this.

            So far so good with Debian image though after removing openmediavault.

            Think I need to buy another neo2, this will suit my purpose well and has a better form factor over the RPi 🙂

            1. Of interest, NEO2…. I am back in the UK now and I’ve left two of them sitting attached to little hard drives in Spain, on solar power with proper batteries (2*100amp deep discharge) – just in case it rains for a week solid in Spain (fat chance)… they’ve been running day and night now for months without a hitch – every now and then I go in remotely (WinSCP) to do update/upgrades – not the fastest boards in the world but cute and reliable.

              I use them for my Node-Red experiments and I have a little script to copy the file system live from one to the other so I can experiment on Node-Red remotely and if I make a complete mess I can just run the script and restore one to the state of the other (everything gets overwritten except the hosts and hostname files).

              Just been in today and I note that Grafana has updated to version 4.6.1

              1. I am thinking I will buy another 2, and remove openmediavault when I install one of them back into the nas dock thing. I don’t need openmediavault. Would prefer to manage it manually and just provide sftp and internal samba access that I will manage.

                Wonder if these things would run BSD sometime 🙂

                1. I wouldn’t hold your breath…. it is hard enough getting support for Debian and Xenial and these seem to be the two favourites.

  3. Hi all, Pete asked me to post my question in this blog, Hope someone can help me out??

    —

    Hi Pete,

    My name is Jeroen Wolf, I’m an audiovisual engineer at the Highschool of Amsterdam and also electronics entiouchiast 🙂 Our team is working on a large project to remotely control AV-equipment in class rooms (independent of Wifi/LAN) through a new LoRaWAN network. Teachers are using a button panel (Extron MLC 104 IP Plus) in these classrooms to localy turn On/turn Off a DLP projector (beamer) and switch between input devices (PC, laptop VGA, laptop HDMI, or laptop DisplayPort).

    There is a fixed serial connection (RS232) between the button panel and the projector (local operations). The button panel is also equipped with a RJ45/Ethernet port to control/monitor the button panel, by simple ASCII commands. This port is currently not being used!

    We want to wireless (via LoRa) connect a IoT (LoPy) unit in combination with a NanoPi NEO2 (for Ethernet functionality) to the Ethernet port of this button panel, thus creating troubleshooting in class rooms on a distance and monitor status values, like projector lamp status (very important for our department), without effecting the local operations of the class rooms.

    The LoPy unit outputs and receives Tx/Rx (ASCII) data on TTL level (UART).

    Do you know if it’s possible that the NanoPi NEO2 can convert these bi-directional signals toEthernet (for the button panel connector) ? Or do you perhaps advice on another unit instead of the NanoPi Neo2 beter suited for this task?

    The button panels acts and response by ASCII commands via a Telnet connection (ip: 192.168.254.254, subnet: 255.255.0.0)

    I Hope you can help me (us) out with this?

    With kind regards
    Jeroen Wolf

    —

    Cheers, Jeroen

  4. It seems odd that such a common driver is missing from a Linux distribution. Did you try loading it manually with “sudo modprobe ftdi_sio” ?

    If that does work then you can add “ftdi_sio” to the end of the /etc/modules file and it will load automatically on the next reboot.

  5. unplug the USB device and type “dmesg” on a console/terminal commandline and look at the last thing there(for reference).

    plug the USB device in and type “dmesg” and look at the result. Copy and past the last 10 lines or any lines which relate to the USB device you just plugged in.

    1. Hi,
      I found out, that the module “ftdi_sio.ko” isn’t available in this Image (Linux Version 4.3.39) So i can’t load it. But now i am working with an “older” Image (Linux3.4.39) and this is ok to me. There the “ftdi_sio.ko” is present and it works fine.

      Here is the “bad” NanoPi:
      pi@NanoPi:~$ dmesg
      usb 8-1: USB disconnect, device number 2
      usb 8-1: new full-speed USB device number 3 using ohci-platform

      pi@NanoPi:~$ lsusb
      Bus 008 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

      pi@NanoPi:~$ lsmod
      Module Size Used by
      g_mass_storage 16384 0
      usb_f_mass_storage 32768 1 g_mass_storage
      libcomposite 40960 2 g_mass_storage,usb_f_mass_storage

      Here the “good” NanoPi 😉
      pi@NanoPi-Neo:~$ dmesg
      ftdi_sio 8-1:1.0: device disconnected
      ehci_irq: highspeed device connect
      ehci_irq: highspeed device disconnect
      ohci_irq: fullspeed or lowspeed device connect
      usb 8-1: new full-speed USB device number 3 using sunxi-ohci
      ftdi_sio 8-1:1.0: FTDI USB Serial Device converter detected
      usb 8-1: Detected FT232RL
      usb 8-1: Number of endpoints 2
      usb 8-1: Endpoint 1 MaxPacketSize 64
      usb 8-1: Endpoint 2 MaxPacketSize 64
      usb 8-1: Setting MaxPacketSize 64
      usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0

      pi@NanoPi-NEO:~$ lsusb
      Bus 008 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

      pi@NanoPi-NEO:~$ lsmod
      Module Size Used by
      ftdi_sio 29102 1

      1. you can take the source kernel package of the updated one and recompile it adding your missing module…. there are tons of good guides online… be prepared to hours of build time, though… or if you’re brave crosscompile on a pc… 😉

        1. Thanks DrFragle and MrShark
          I have almost no experience with kernel compiling and such things.
          Unfortunately, I have little time to learn all this, but I will certainly make up for it. At the moment I have to take care of the application (Node-Red-Project).
          First I could not imagine that a USB2Serial module is missing, so searched in the wrong place.
          Is not that something that all developers need? I thought at least …

          1. If it helps Alexander – I have NO experience with kernel compiling and unless someone makes it work with a large button – I’m unlikely to gain any – I can imagine the heartache if a cryptic error message appears in the middle of several hours of compiling – it’s bad enough when that happens in my own script.

        2. I keep hearing people saying this but I am guessing it implies a lot of knowledge that a Linux fan might consider “common sense” but which would not be to others. Unless of course you can pull up one of your usual magical links – “Complete Compilation guide for dummies” would do with full examples…

          1. if the config file of the shipped kernel is available, the steps are really a few… import the config, add the missing module, run the compile step… but if config file is not available, is a guessing-what game, you really have to know what to include and what not, and what as statically linked and what as a loadable module: imagine to compile the ext4 filesystem as a module, and as such, it will be in the filesystem itself, somewhere… if you can’t access the filesystem, how is it supposed you could access and load it? And this is just the basic example of the HOW-TO-NOT you’ll receive whenever start to dig into kernel compilation stuff 🙂

            1. first comment here gives you the steps to download the kernel source of your actual kernel, when you arrive at the menuconfig section you need to dig into the menus and add the missing module, then go on with the process… you can use as a base the config file from your actual running kernel, you should find it in /boot/config-YOUR-KERNEL-VERSION, you must copy it as .config in the folder in next link and do a make oldconfig to reuse it… but as said, is a LONG process…
              https://askubuntu.com/questions/163298/whats-a-simple-way-to-recompile-the-kernel
              you can compile just the missing module, here how to find it and compile just it:
              http://www.g-loaded.eu/2005/12/20/build-a-single-native-kernel-module/

                1. never said the contrary 🙂
                  but this guide is pretty straight forward…
                  anyway the easiest path is to complain with who did the kernel you’re using, or stick with the old one 🙂

                  1. Yes, complain that the FTDI driver isn’t in the kernel or packaged as a module because it is a VERY common device used by thousands of people all the time. Seriously, if you google for “Ubuntu 16.04 ftdi_sio” you will not find much so it’s probably there but something is preventing it from loading.

                    Did you try loading it yourself? sudo modprobe ftdi_sio

                    1. FYI, I just booted a 16.04.2 system and the ftdi_sio driver is there for the 4.4 kernel:

                      find /lib/modules/. -name “ftdi_sio*”
                      ./4.4.0-58-generic/kernel/drivers/usb/serial/ftdi_sio.ko
                      ./4.4.0-77-generic/kernel/drivers/usb/serial/ftdi_sio.ko
                      ./4.4.0-57-generic/kernel/drivers/usb/serial/ftdi_sio.ko
                      ./4.4.0-79-generic/kernel/drivers/usb/serial/ftdi_sio.ko

                    3. Every so often I did clean them out, I don’t stress over it.

                      You’re going to laugh knowing that I run that system from a LiveDVD ISO image on my HD. I use persistent storage on a 128GB USB 3.0 thumbdrive and my development and work data mounted into the live system from the HD.

                      I started doing it for testing but just kept using it and haven’t upgraded my 14.04 partition yet.

                2. check if the module was compiled in your actual kernel, and if it’s embedded or module… run this:

                  grep FTDI_SIO /boot/config-$(uname -r)

                  in my case, it returns:

                  CONFIG_USB_SERIAL_FTDI_SIO=m

                  so it’s compiled as a module (last “m”)
                  if last char is an “y”, module is integrated in kernel, if it’s a “n” it was not compiled at all, not as integrated nor as a module…

  6. Sorry about my question, but im serching for hours and i am nearly to kill somebody.

    I use a Nanopi wit this Image “nanopi-neo_ubuntu-core-xenial_4.11.2_20170605” from the friendlyarms-Website.

    The Problem is, that i get no /dev/USB0 with i can use in Node-Red.
    I think that the modules are missing, but i am not the linux-guru.

    Can somebody give me a tip what i can do to find a solution?
    Thank you guys!
    Alex.

    1. Ok so first things first…. unless you plug in a USB serial dongle of some description you don’t get that.

      What you SHOULD get is at least one normal serial port…. for Node-Red… like for example /dev/ttyS0, /dev/ttyS1, /dev/ttyS2, /dev/ttyS3… one or more will work – easiest way to test is set the serial to work on 100ms timeout rather than waiting for a char – wire input and output together, send a debug node to the serial in and the serial out to debug…. send some text and it should come out of the output. I think with the current exception of the K2 I have multiple serial working on all of their boards.

      1. Hallo Pete, thank you very much for spending your time!
        The device i have to handle is the controller-board from a heat pump.
        It contains a USB connector with a FTDI-Chip behind. The protocol is a simple string (ex. 140 2050 15300)

        I put the user “PI” to the group “dialout” and so i can connect all “/dev/ttySx” without errors (because the permissions)
        But i get no data from an input (ttyS0 to ttyS7).

        I test some things tomorrow ….

  7. Guys – please note update to the blog – I finally found a version of WIRINGOP which is amended for the H5 (several out there claim to do this but when you actually GIT them – they don’t support H5) – but this is only basic IO – until FriendlyArm or some other knowledgeable person modifies the pin defs etc, we won’t be able to use more exotic stuff like PWM and I2c etc… but it is a start.

    If anyone is up to this…

  8. FriendlyELEC has released a new version ROM based on mainline 4.11.
    Download link: https://www.mediafire.com/file/sudalxmlh1jkdh3/nanopi-neo2_ubuntu-core-xenial_4.11.0_20170428_dev.img.zip

    Main feature:
    – GigE supported
    – USB WiFi supported
    – USB Camera supported
    – Internal audio codec and record supported
    – UART, I2C, SPI, GPIO etc has been tested OK, via NanoHat OLED, Motor, Bakebit, UNO Dock etc.

    A tools “npi-config” for basic configuration is inside it too.

    Enjoy.

    3. Hi there Mindee

      There are some issues with the npi-config tool – I’ve sent you an email directly.

      Pete

    4. I note all sorts of claims here about WIFI etc, nothing in the npi-config about setting up WIFI however, or GPIO – can you point us to the relevant docs to make use of the features you mention above…

  10. TKaiser: Re; Hackish…. the script is the result of lots of hard work by lots of people – if you think it is “hackish”- then by all means improve it and let’s see the result – however – please do not insult the volunteers who work on this stuff!! I for one am not a Linux fanatic and I don’t have time nor desire to become one – I make things that work = the script works and saves people a lot of messing about – and spending my life making elegant scripts is not on the list.

    1. Pete, not ‘spending my life making elegant scripts’ pretty much sums up ‘hackish’ 🙂 But it’s not about elegance at all but portability.

      This wasn’t meant as an insult, please be aware of the context ‘packaging’. And I prefer to decice myself where/what to improve. The suggestion how to deal with arm64 came already and is still valid since memory consumption of arm64 NodeJS variant is insanely high compared to armhf variant: https://github.com/nodesource/distributions/issues/375#issuecomment-290440706

      Also please be aware that some stuff can be fixed better at different locations. For example if the NodeJS installer can deal with arm64 on its own you don’t need special checks for 64-bit boards. Actually I already sent a pull request with reference to discussion: https://github.com/nodesource/distributions/pull/435

    2. As a result of my tests with armhf NodeJS variant today we decided to evaluate a 32-bit Armbian build for those 64-bit boards with low memory like NEO 2: https://github.com/igorpecovnik/lib/issues/645

      Since I don’t want to rely on synthetic benchmarks only and to get a working environment I will transform ‘The script’ into something that accepts the items to be installed as simple command line arguments. It will then be something like ‘install_iot_environment’ accepting the following parameters: mosquitto apache nodejs nodered odroid generich3 webmin screen java mpg123 phpsysinfo upgradenpm addindex habridge

      This approach makes it possible to install all relevant applications already as part of the image creation (will then be magnitudes faster running on a x64 build host) while remaining compatible to ‘The script’. And while the target environment will be the Jessie/Xenial Armbian variants I’ll take care that this should also run on every other Debian based distro Raspbian included (might later even evaluate porting it to FreeNAS/FreeBSD)

      Every installation goes into an own function so Antonio and you can decide later whether you want to use those changes or not (again: it’s not about elegance but portability)

      BTW: ‘installjed’ installation option seems to be orphaned?

      1. I’ll check that JED.. – about to put up new version of script as we have it working reliably with NEO2 now… and with less output etc…

      2. JED works fine – it WORKED but is now clearer (the ** on either wide means anything with JED in it) – script updated with other stuff as well – not doing any more tonight – but no doubt tomorrow – there will be more…. and the next day…. and….

    4. Quick questions (since parsing the script):

      – is there a specific reason for NodeJS v6.10.1 (and not v7.8 already)?
      – same for ‘NODE_OPTIONS=–max-old-space-size=128’ in /lib/systemd/system/nodered.service (why not increasing memory limit on boards with more DRAM)?

      When I start working on the script variant I will test through Jessie, Xenial and Stretch (the latter 64-bit). But this will take some time, FriendlyELEC ran out of NEO Plus 2 samples and other preparations are necessary too.

      1. Good morning

        New updates to the script this morning – just done them.

        Yes, the Node-Red guys say NOT to use v7.8 and as Node-Red is a central part of the script – I abide by their wishes.

        The settings for max-old-space-size are THEIR recommendation.

      2. the same reason why you don’t use ubuntu 16.10 or 17.04 beta: is not STABLE… version 6 is an LTS…

        https://nodered.org/docs/getting-started/installation

        Install node.js

        We recommend the use of node.js LTS 6.x or 6.x . Node-RED no longer supports node.js 0.10.x or 0.12.x.

        Note: Node.js 7.x is under active development and is not recommended for a stable base. Many 3rd party node packages may not yet fully support Node 7.x and later, especially if they contain a binary component. Check with the author of the package if you are not sure.

        1. I see. Unfortunately V8 version the binary packages you currently reyl on is using is rather outdated (it’s 5.1.281.95, while the 7.8 binaries are built with 5.5.x and upstream version is already 5.9.142).

          Since I will use this project also for various performance tests I’ll give it a try to build everything from source or even add some optimized packages to apt.armbian.com

          Anyway, will be silent from now on the next few weeks and ping you both once something starts to grow over here: https://github.com/ThomasKaiser/install-iot-stuff

  11. You might already do this but using “sudo apt-get clean” after installing a few packages cleans up/removes the downloaded packages and provides more root storage space.

    But if your /boot was on its own partition from / then this won’t help.

    1. Thanks for that Doug. I tried everything. Ultimately even EASEUS could not resize things effectively. The upshot is – unless you have other uses for the board, steer clear of that old version of Ubuntu and wait for 16.04 which they say is on the way – OR take a chance on the Armbian nightly – and it is a chance as TKaiser will confirm – but for me it worked and was an opportunity to further improve the script. I don’t think I mentioned it but I checked in Node-Red both serial (I checked serial port 1, there are 4 of them but two will be in use) and MQTT and both work a treat.

      1. I’m running The Script now on the M1+ and I only see apt-get clean called once. I’m only 10 minutes in and already /var/cache/apt/archives is at 141MB so clearly throwing in more calls to apt-get clean will reduce storage usage during script running.

        Interestingly, the M1+ came with Debian Jessie already on EMMC so there was not need for anything but pulling the script down running it with sudo and then remote in as pi and have at it. So far so good.

        I like your use of menu selections and might do some adding on to it. Will let you know in case interested in including as options.

        Oh and I screwed up. I’d read your M1+ review and then the S430 review and thought they were associated so I bought the display with the M1+. Needless to say there’s no display connector but for HDMI. My OrangePi and rPi both have slightly smaller connectors. LOL, so I’ll have to buy and M2 or other to use the display. 🙂

        1. Hi Doug – good luck with the script. I tend to not worry about space – I use 16GB SDs (8GB would do) which leaves loads of room and I do that on the assumption that with wear levelling I will lose space over time and so best to start with plenty – also high speed SDs at LESS than 8GB are a bit thin on the ground. However – no harm in cleaning up – I’ll make suitable changes. We also have a couple of mods to make as right now on the M2 we end up leaving an archive file in the /home/pi directory. Sometime to day that will be updated but of course you can always remove it manually.

          1. if it was for me, when we moved to menu system during christmas holidays, i had collected all the packages we want to install and done a single apt-get install line at the end, and after that, a single apt-get clean and eventually autoremove if something was removed during install… this because i don’t like to do apt-get update every since and then, and this would have reduced a bit the install time… but then we choose the actual path as is more straight, and we do the cleanup only at the end, which is no harm as during install it’s supposed you leave your sbc there to do its stuff, or just open an other ssh session to just check if something is already there, if temperature is right (now it’s directly in script), and the like…

            1. Not sure if I read the explanation correctly regarding doing apt-get clean throughout the install script and the comment about not having to run apt-get update many times. Just in case, apt-get update updates the package list and dependencies and apt-get clean doesn’t effect that. It just removes archived downloaded packages from /var/cache/apt/archives. So apt-get update at the beginning is all that’s needed and incremental cleanup throughout the script would save space.

              If done at the end anyways I don’t think it would add time to the installation. It would only be useful in constrained installations like small EMMC or small uSD. FWIW, I’ve heard EMMC is far more reliable for embedded devices.

              1. as you said, no need to save space if you have a quite normal 8gb microsd, you can do at the end with no real problems… yes, emmc is better, but very few SBC have it…

                and we do apt-get update many times as we add repositories as script goes on, based on user selection… we could have done differently, we did so, not a real problem…

    2. /boot is quite always on its own on these little distros, as it’s a fat32 partition to which you can access from windows directly and do some tuning even before starting the install process… for example you can choose ssh instead of dropbear, put wifi credentials, use fixed ip address, etc…

      1. true and what I see is even EMMC is done that way too. So maybe Pete filled /boot with old kernels as he updated. Maybe running apt-get autoremove would have cleaned up the old kernels. Just guessing since I don’t know what filled his /boot partition.

        1. No, trust me the old /boot was as empty as it could be – nothing could be done to save it – however – right at this very moment I am testing the NEW, AS PROMISED 16.04 release from FriendlyArm including discussed changes – fingers crossed. And yes, I do know it is 6am in the UK 🙂

          1. I was wondering about the time there since previously I saw your post timestamped at 10pm. Good to hear FriendlyARM is stepping up their game on the OS side. The products seem sound.

            1. Since most people seem to not understand what Armbian is… it’s not yet another distro but it’s a fully automatized but easily customizable build system creating OS images from scratch ‘debootstrapping’ either Debian or Ubuntu.

              If you bought a PC within the last 5 years (64-bit) then you’re ready to build your own OS images. Need a 64-bit Debian Jessie for NanoPi NEO 2? Here you go: https://docs.armbian.com/Developer-Guide_Build-Preparation/

              ./compile.sh RELEASE=jessie BRANCH=dev BOARD=nanopineo2

              If you make ‘The script’ non-interactive (no idea whether that’s already the case) and make it distro-agnostic (easy and already explained) then you can call it from within the build system on your PC running magnitudes faster. Here you go: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

              (first run will take some time since kernel build and debootstrapping takes some time but subsequent runs are a lot faster since we cache as much as possible)

              Not that it would be that useful to create OS images with ‘The script’ already integrated. But if you go the extra mile and make that possible (taking care that the script runs on Raspbian and Ubuntu/Jessie in both armhf/arm64 flavour) you enable all your users to use ‘The script’ on every of the +50 SBC Armbian currently supports: https://www.armbian.com/download/

              At least that’s one of the ideas behind Armbian: enabling users to choose the hardware they want without having to take care about (shitty) vendor OS offerings. We all known that FriendlyELEC is a rare exception taking care about good OS images but I still prefer to be able to generate my own since only then I known that no one else has tampered with the software already. I ‘only’ have to trust Linux kernel dev community and upstream Debian/Ubuntu software maintainers. Armbian’s build script is that primitive that everyone can audit it. 🙂

                1. I know you were talking about their release, I just wanted to point out that the thousands of hours that went into Armbian (improving the build system, improving drivers, developing improved settings, making it easy to use sane bootloaders and kernels on hardware where the vendor does not care) are available to anyone. For free.

                  If you want to have an Ubuntu or Debian with good settings… you can generate one. An Armbian user even started to provide ‘Armbian as a service’ https://armbian.builders (AFAIK not ready yet and I wouldn’t use it for exactly the same reason why I don’t use vendor supplied OS images: since security matters and you don’t use stuff you find somewhere on the Internet 😉 )

                  Please also note willy’s and my comments regarding BSP vs. mainline kernel here: http://www.cnx-software.com/2017/03/26/nanopi-neo-2-board-nanohats-and-bakebit-starter-kit-review-part-1-hardware-overview-assembly/#comment-540774

                  The ‘willy’ over there is Willy Tarreau and official 3.10 LTS (long term support) kernel maintainer. 3.10 kernel is at 3.10.105 now but the crap contained in Allwinner’s BSP (board support package) for H5 is still at 3.10.65 and FriendlyELEC now throws OS images based on this crap out. It’s a shame but no one cares 🙁

                  1. as already said in the past, many don’t consider security issues a real issue because they just use these boards in their own home, with no external internet access…

                    about the build process, i was thinking instead to a distro+script, a distro with ALREADY the stuff in it, preinstalled, instead of running at the end…

                    can i add repositories/packages/custom folders to the build? this is quite intriguing…

                    1. It’s not only about security, the ‘careless approach’ relying on shitty vendor BSPs also has a massive impact on performance. Just check Phoronix for H3 board benchmarks, they all totally suck and that’s since the BSP kernel has a weird strategy to deal with heat: kill CPU cores instead of throttling. At linux-sunxi and Armbian we spent a huge amount of time to improve this.

                      Settings matter. And that’s what Armbian is about. Just look at the 3 different results for this random H3 board, the Banana Pi M2+, there: http://openbenchmarking.org/result/1604204-GA-1604082GA37

                      That’s the difference that software/settings make. Same hardware performs totally different. And (not so) surprisingly the vendor’s own OS image sucks the most (but SinoVoip might just be the definition of low-end wrt software/support).

                      And of course you can customize Armbian in any possible way while keeping compatibility to kernel and distro updates.

                      Two starting points:

                      https://forum.armbian.com/index.php?/topic/853-armbian-customization/ (that’s the software guy of a hardware vendor starting to roll out their very own OS images while keeping compatibility to distro and Armbian’s kernel updates)

                      https://github.com/igorpecovnik/lib/issues/638#issuecomment-288443940 (yet another user opening github issues with questions instead of asking/searching in the forum)

                      But IMO the right approach to deal with ‘The script’ would be to re-think the whole logic and transform it to a .deb. All the dependencies will then be handled by the package manager (that’s there for exactly that) and installation will then be as simple as ‘apt install the-script’ on any SBC out there that can run Debian, Ubuntu, Kali or any other distro making use of Debian’s package management)

                      Please see last log entry from just now here: http://sprunge.us/dNEU (all those packages have been installed automatically just by ‘apt install rpimonitor’ since this package declares dependencies correctly — BTW: it took only 25 seconds since OS is running of a pretty fast SD card, on a crappy card this could take minutes)

                    2. oh, i told to Peter a while ago to convert it into a deb, but the problem is the menu system… The approach is to allow anybody to select what he wants/needs… i hate that install hog which is webmin, just saying, but many are not familiar with command line and want it…

                      the idea could be to create a main package (which adds dependencies on prerequisites and not much more), and some subpackages which add specific addons… that will be way easier to install, we can even create a PPA, but is less easier for Peter to make mods to the script, as he should generate packages using the usual debian build process… not nuclear science, once created the structure is all to add stuff to some files and folders…

                      we have to discuss… both of you don’t want me to have a life! 😀

                    4. oh, that’s good, but as for now, the only 64 bit board we had (Peter, really) is just this one… and a couple of virtual machines… well, maybe i’ll try taking a look at deb conversion during Easter, let’s see 🙂

                    5. Well, as already said: it’s rather easy to do things right. Since more and more boards will come with arm64 distros you should be prepared in general and the next ‘major distro switch’ (Debian Stretch) is also just around the corner.

                      And the more hack-ish attempts are removed and replaced with sane ones (dealing with different distros and armhf/arm64 correctly) the less hassles and even more: Not always the need to re-invent the wheel.

                      As soon as this is fixed once ‘The script’ will work on +50 SBC automagically (every board Armbian now or in the future supports. And since ‘Armbian’ is here only a synonym for ‘a random Debian or Ubuntu based on either armhf or arm64’ it will work anywhere.

                      BTW: the check for 64-bit in ‘The script’ is wrong IMO (as already said: don’t check the CPU but the distro architecture, some crazy board makers like those Banana people provide armhf distros for their A64 and soon H5 boards)

          3. So you got a ‘new’ Ubuntu 16.04 from FriendlyELEC? Can you provide output of ‘uname -a’, ‘lsb_release -a’ and ‘dpkg –print-architecture’ please?

            1. Now how did I know you’d be the first to respond, TKaiser 🙂

              Ok, firstly you may wish to comment on why the script took 25% longer (about an hour) on their Debian 16.04 than the Armbian version (about 45 minutes)? Some tweaking needed there? (see update) – and as for your question..

              uname -a
              Linux NanoPi-NEO2 3.10.65 #5 SMP PREEMPT Wed Mar 29 09:50:17 CST 2017 aarch64 aarch64 aarch64 GNU/Linux

              lsb_release -a
              No LSB modules are available.
              Distributor ID: Ubuntu
              Description: Ubuntu 16.04.2 LTS
              Release: 16.04
              Codename: xenial

              dpkg –print-architecture
              arm64

              Comments?

              1. i think the slow install is due to using an old xenial as base… it had 3 different iterations, 16.04 16.04.1 and 16.04.2 (the latter is out from about a month), so if you start from the very first, there are A LOT of packages to update, even in the stock version… stock version which i think has GUI, so you even updated a ton of graphical stuff we never even see when se use “server” editions of xenial and jessie…

                do the “lsb_release -a” after a fresh install, before update, to check the first thing, and please confirm that you have gui on that distro…

              2. Well, users do not care about the most important stuff (kernel and settings) and they’re even encouraged to do so. This is a shitty Android kernel containing loads of security vulnerabilities and countless bugs fixed in the meantime slapped together with an arm64 Ubuntu userland in a hurry. Nothing anyone wants to use who cares about details.

                @Antonio: https://github.com/friendlyarm/h5_lichee/commit/9b639a25a90a7b782678f000d05ffa86af57ff7f

                Something like this https://github.com/friendlyarm/h3_lichee/issues/2 will not happen again since this a move in the wrong direction (folks, please start to care about the important bits! It makes absolutely no sense to use the crappy/insecure/buggy Allwinner kernel on this device since there’s no display output)

                1. Didn’t you say earlier not to trust the nightly builds of Armbian – that’s all there is for the Neo2 right now, yes?

                  1. I was talking about ‘don’t base anything productive’ on nightlies since everything still WiP. That is not related to ‘trust’. The nightly builds are just the result of an unattended ‘compile.sh’ run for a couple of boards.

                    You get the same results in your own mansion/cave when you do the same at the same time. And you don’t have to trust a hardware vendor doing software correctly (or someone from the other end of the world who fiddles around with a vendor OS image and then submits it to DietPi who present this than as a ‘DietPi for device xy’) since Armbian’s build system grabs bootloader and kernel sources from github and Debian/Ubuntu from their respective servers.

        2. no, it’s simply too small in this crappy version that friendlyarms gives… we did way more tests than i expected to just update a distro to the next one… half a day, peter in his mansion and me in mine, chatting all day…

          1. You missed “thousands of Km apart” off the end. Not sure about mansion though – it’s made out of wood.

  12. A suitably renamed version of the script called “the script” – link in the article – will now work perfectly using the Armbian nightly build of Ubuntu from 27/03/2017.

    I’ve not tried a WIFI add-on dongle on the little NEO but on Ethernet it seems to be just fine and definitely fast at around 45 minutes for the script.

    1. this should become the default script soon, as far as we add some more checks… we don’t want to go deep again in all the messing that a failed step brings… several checks were added, more needed, as we learned today…

  13. Mint is a variant of Ubuntu and is the same under the hood, so instructions for Ubuntu should work more or less the same. They probably just specified Ubuntu to have something concrete.

  14. You should wait with ‘board reviews’ a bit in the future if you’re in anger. 🙁

    Sorry, that you failed to understand the mentioning of Wi-Fi on Armbian’s download page for the board (we support more than just a few boards and it really doesn’t matter whether you use onboard Wi-Fi or an USB dongle: getting Wi-Fi up and running is always just a simple ‘nmtui’ call and that’s why it’s mentioned on the shared download page of every of the +40 boards we support). Good luck.

    1. Thanks for the clarification – and I’m not in anger – plenty in politics to get angry about – no… I’m almost there with the Armbian nightly build… got up to NPM in my script and it being 64 bit I’ve hit a snag there – no doubt we’ll fix that in the morning..

      Re: WIFI – anyone looking there for the first time – will see that WIFI reference and wonder why it is there on a board that doesn’t include WIFI…. not everyone has in-depth knowledge of the Armbian site!

      1. Hmm… I appreciate your feedback but also have no clue whether ‘Required condition: a board with onboard or supported 3rd party wireless adapter on USB’ as written on the download page shouldn’t be already sufficient?

        We had a wall of text on download pages months ago, changed that to ‘minimal info’ since people are scared reading more than a few words (and miss the important bits) and now you tell us it’s not OK again…

        Anyway: to clarify ‘nightly’ builds… as soon as we start to support a new device we test it (somewhat in the beginning — once we provide regular images they’re tested extensively).

        Nightly builds are generated automatically every 24h and for that reason are untested. They might just work or fail totally (as a result of updating main components in between). That’s why we maintain different branches: default, next and dev. And currently since H5 SoC here is quite new everything happens in dev branch and it’s just too early to ‘freeze’ anything.

        That’s why you shouldn’t rely on Armbian’s nightly images yet since next update might break things. We (Armbian) aren’t in a hurry, we try to improve H5 support to benefit most from 64-bit support and once it’s ready OS images for H5 boards will be fully supported.

        1. It’s your code – I can only tell you that for me – my first impression was when I saw WIFI – that this was generic.

          However you will be pleased to know that with some caviats – your nightly build DOES work and is better than the FriendlyArm offering – but they have promised to release 16.04. We will have to wait and see.

          We have some mods to the script for 64 bit to go in and I will try the whole thing later today, hopefully successfully.

          1. Glad to hear that you got it working even if I still don’t recommend to base anything productive on our nightly builds 😉

            Anyway: Making your script more and more universal is the right decision. A small hint: the 32-bit vs. 64-bit issues you’re running into are not related to kernel version (so neither rely on ‘uname’ nor ‘arch’ here!) but the architecture the userland is based on. With Debian and Ubuntu this can be either armhf or arm64 and you must always use ‘dpkg –print-architecture’ to test (since you or your users will run in situations where a 64-bit kernel is combined with a 32-bit Debian/Ubuntu userland, the crazy Banana people do this for example to totally ruin performance on their BPi M64).

            So do an ARCH=$(dpkg –print-architecture) in your script and base decisions later on $ARCH then.

            Bonus tip: On both 64-bit Ubuntu and Debian you can simply install 32-bit packages by doing an ‘dpkg –add-architecture armhf’ (already done by Armbian for you but please remember that your script should be able to run on more careless distros too!) and then simply install packages/requirements with eg. ‘apt install npm:armhf’ instead of ‘apt install npm’.

            Of course ‘apt install npm:armhf’ works on any 32-bit Debian/Ubuntu too so if your script should only be able to run on 64-bit Armbian variants later you don’t need to care about anything but simply add the ‘:armhf’ suffix to all package names.

            Regarding Wi-Fi I still don’t get it. What’s wrong mentioning ‘use nmtui to connect to Wi-Fi’ on NEO2’s download page? In case you want to use Wi-Fi with NEO 2 now… you take any of your Wi-Fi dongles, connect it, call ‘sudo nmtui-connect PETES-WIFI’ and are in, aren’t you?

          2. BTW: blue led confirmed to not work (yet — it’s just that Igor had no time to try out the other potential pin mapping yet): https://forum.armbian.com/index.php?/topic/3576-nanopi-neo-2/&do=findComment&comment=27670

            And your ‘first boot’ login issue might be related to Armbian doing an unattended reboot on first boot though we tried to avoid that since it caused a lot of confusion (the reboot is sometimes needed since Armbian does an automatic resize of the SD card, IIRC Mikhail changed that in the meantime and a reboot should only be recommended but as already said: nightly builds and therefore untested). Anyway: on all boards with Ethernet you should be able to simply do the first login through SSH after approximately 2 minutes. And on those boards lacking Ethernet you get a serial console through the Micro USB port to do initial setup (including nmtui for Wi-Fi access 🙂 )

            1. BTW: today a cheap crappy RTL8188EUS USB dongle arrived from China and another one based on RT5572 (2.4/5 GHz, 802.11n, good driver) from a local seller. The RTL8188EUS you get on Aliexpress for $2 while you can pay 10 times more here in EU. All that was needed was… ‘sudo nmtui’ to get both things up and running.

              Performance with the RTL8188 thingie as bad as expected (single mini antenna and 2.4Ghz only) but the other shows pretty good performance especially in ‘noisy’ environments and link is pretty stable over larger distances with 2.4GHz. Only drawback: Looks pretty absurd when connected to something that small like a NEO 2: http://kaiser-edv.de/tmp/lGtv37/NEO_and_Ralink_RT5572.jpg

              IMO that’s a totally valid use case to add el cheapo and even more superiour Wi-Fi to Ethernet only boards. But as usual: YMMV 🙂

        2. One of the things I learned working for Jef Raskin: Never argue with users about their errors. Fix the interface to make the error impossible. Apple has done OK following his rules.

Comments are closed.