NanoPI NEO / AIR

[usboot]

Both possible, FriendlyARM's H3 boards can be powered through the 4-pin header or through Micro-USB (if power through header exceeds the one available from Micro USB then devices can even be charged connected to the Micro USB port -- FriendlyARM unlike most other Chinese SBC vendors provides excellect documentation so simply look through their wiki)

USB port too

[trewq]

They have finally arrived. Sent via the wrong shipping method but they got to me in the end. Just going through and checking them all now.

[vlad59]

They have finally arrived. Sent via the wrong shipping method but they got to me in the end. Just going through and checking them all now.

 

I hope they'll arrive soon then

[aliceander]

@trewq please share anything that might help others who plan on getting their own neo (mine is on the way ;-))

[Wazou]

Any idea when we can hope for a release of NanoPi NEO Armbian distro ?

 

I'll be happy to do some stress testing with the board I've received today !

[tkaiser]

http://www.cnx-software.com/2016/07/20/getting-started-with-nanopi-neo-development-board/#comment-529150

 

The most notable difference in the fex file is the way lower DRAM clockspeed and some disabled components (HDMI for example since not useable due to missing connector). I would suppose the main reason for lower DRAM clock is just energy savings so when I receive my boards this will be one of the areas to test. For the basic ideas please see: http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/

[arox]

They propose to ship it with unsoldered USB-A and ETH connector : good, it will be the smaller and lighter card on the market !

[Wazou]

Got my NEO's this morning ! So far so good, the form factor is excellent and there is still some place to screw in M3 spacers without shorts on SMDs (was afraid of this being an issue when reviewing the dxf schematic) 

I'm currently running the version of Snappy Ubuntu while waiting for the ARMbian to come out

 

I'll be happy to run some test if you guys need anything; I have currently 10 of them running on my desk.

 

Bonus : picture of the NEO hooked up with my proto POE module (PCB hat on it's way !)

[trewq]

@tkaiser are we better off waiting for you to get your demo boards so the config can be done properly or should I do some testing now and post the results?

[aliceander]

Simply download the Armbian test image (containing a statically linkes lima-memtester version and a modified kernel to not reclock DRAM) and follow the steps (installation of RPi-Monitor first, then starting lima-memtester), let it run for a few minutes and check temperatures using RPi-Monitor (or in a separate terminal window using 'sudo armbianmonitor -m'). If temperatures get pretty high then everything should be ok and testing works correctly. If temperatures are rather low something's wrong.

 

I think this might be an obvious question, but ... where is the armbian test image?  I have a Nano Pi NEO in hand, and I really want to get armbian on it (especially after spending a few hours running the Friendly ARM Ubuntu release).

[tkaiser]

where is the armbian test image?

 

Please see a few posts above: http://www.cnx-software.com/2016/07/20/getting-started-with-nanopi-neo-development-board/#comment-529150

 

All H3 devices are more or less identical, they show only differences regarding type of voltage regulator, thermal behaviour, count of USB ports, WiFi used and Fast vs. GBit Ethernet. Since we're currently dealing only with legacy kernel on these boards and no WiFi is available here, simply replacing script.bin contents is enough for a test.

 

AFAIK none of the Armbian devs already received NanoPi NEO so why/how should we provide 'test images'? The whole thing is currently based on assumptions (I looked into FriendlyARM's Github repo, checked out their fex file for NanoPi NEO and tried to adopt the changes for Armbian -- the last time I did that for M1 I introduced a silly bug also affecting Orange Pi One and Lite) and without hardware in our hands we're simply not able to provide any 'official' image even just for tests.

 

You can try to follow the simple steps outlined a few posts above, feedback is also welcomed but at least my aim with an own OS image for NanoPi NEO is to make this board an IoT device with lowest consumption possible. I'm currently preparing a test setup to measure efficiency of different tries to reduce consumption: http://forum.armbian.com/index.php/topic/1665-rfc-using-a20-board-with-armbian-as-powermeter/

[aliceander]

I'd misunderstood about the state of development for the neo (that's my own fault of course).  Thank you for the pointers and the explanation. I'll read through the posts to get a better feel for the overall situation. The Ubuntu image provided by Friendly ARM works okay and can be used until there are other options.

[tkaiser]

I'll read through the posts to get a better feel for the overall situation. The Ubuntu image provided by Friendly ARM works okay and can be used until there are other options.

 

Well, there is not that much of an 'overall situation'

 

It's still as easy as pointed out multiple times. Take Armbian for NanoPi M1, exchange script.bin and correct a minor mistake I made a while ago. So when you download and boot NanoPi NEO with our image for M1, you do everything as usual and then just as first step after user creation as root:

sed -i 's/240/480/' /etc/default/cpufrequtils
wget -q -O /tmp/nanopineo.fex https://raw.githubusercontent.com/igorpecovnik/lib/master/config/fex/nanopineo.fex
fex2bin /tmp/nanopineo.fex /boot/bin/nanopineo.bin
cd /boot && ln -sf bin/nanopineo.bin script.bin
reboot

BTW: I'm running FriendlyARM's Ubuntu image for the NEO on an Orange Pi PC since days to get a feeling for what's missing there. And IMO it's a lot, not even cron is installed and so much stuff that 'just works' with Armbian needs too much time. Eg. installing RPi-Monitor: http://www.cnx-software.com/2016/07/22/friendlyarm-nanopi-neo-board-benchmarks/#comments(if you want to continue working with FA's Ubuntu image -- with Armbian it's the usual 'sudo armbianmonitor -r')

 

BTW: Anyone trying out Armbian on NEO now with the method above should be aware that he might run in upgrade troubles later when we release an own OS image for the NEO (recommendation will then most likely be: don't upgrade but start with the NEO image from scratch). But this is stuff we have to discuss internally and maybe nothing relevant will change (at least I want a different u-boot config for NEO to be able to boot the board running at just 480 MHz so that we can ensure consumption does not exceed 1W during boot)

[aliceander]

Thank you for spelling it out again.  I now have armbian 5.16 running on a NanoPI NEO.  Smiles all around ....

[pezi]

FriendlyArm released a NanoPI NEO specific heat sink:

http://www.friendlyarm.com/index.php?route=product/product&path=82&product_id=134

 

I am the owner of NanoPI NEO using the modified NanoPI M1 Armbian image of this thread.

 

I am not a expert of  SBC design. But this board gets very hot. The sink has the same size like the SBC! Has the SBC a design problem, e.g. power supply? Or the CPU is so powerful and you must fix the heat problem by a approbiate heat sink or by software. 

[trewq]

While the heat of them seems bad it's a non issue. I'll have to look it up but I believe the max operating temperature is 125°C. I've only been able to make it reach 100°C at full load.

[tkaiser]

I am the owner of NanoPI NEO using the modified NanoPI M1 Armbian image of this thread.

 

Can you please provide the output from a few lines by 'sudo armbianmonitor -m'. I'm currently in the process of preparing IoT friendly H3 settings and since NEO is still on its way I'm testing with the rather similar OPi Lite:

root@orangepilite:/# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
09:39:35:  312MHz  0.00   0%   0%   0%   0%   0%   0%   30°C
09:39:40:  312MHz  0.00   0%   0%   0%   0%   0%   0%   29°C
09:39:45:  312MHz  0.00   0%   0%   0%   0%   0%   0%   28°C
09:39:51:  312MHz  0.00   0%   0%   0%   0%   0%   0%   28°C
09:39:56:  312MHz  0.00   0%   0%   0%   0%   0%   0%   29°C
09:40:01:  312MHz  0.00   0%   0%   0%   0%   0%   0%   28°C
09:40:06:  312MHz  0.00   0%   0%   0%   0%   0%   0%   29°C
09:40:12:  312MHz  0.00   0%   0%   0%   0%   0%   0%   29°C^C

The Orange Pis all have a rather thick copper layer inside the PCB that helps spreading the heat away from the SoC and also I attached an el cheapo $0.50 heatsink. It's the one in these pictures: http://linux-sunxi.org/Orange_Pi_Lite#Orange_Pi_Lite

 

Please keep in mind that our OS image for NanoPi M1 currently has a thermal issue (mismatch between cpufreq settings and fex contents) therefore without adjusting /etc/defaults/cpufrequtils you end up with a NanoPi most probably always clocking at the upper limit. If that's the case, dmesg should also show 'ARISC errors' (fix/workaround see above).

 

Anyway: H3 is specified to operate at up to 125°C (ambient temperature of up to 70°C) and Armbian throttling settings are rather conservative. The only real issue is us users having to accept that times are over where we thought ARM devices stay always cool. All more recent SoCs need attention when it's about heat. We try to address that when we release our specific Armbian release for the NEO soon (still no dev samples arrived)

[trewq]

still no dev samples arrived

If yours don't arrive by end of next week I'll express ship you one. I've gone 10 on hand and another shipment already on it's way to me.

[arox]

pezi said ! "The sink has the same size like the SBC!"

 

I hate noise. 12 years ago, I assembled an AMD Athlon with (almost) passive cooling. The heat sink costed me more than a powerfull arm card : a copper block with large fan-shape wings, the size of one of our favorite cards, and 5 centimeters high. It was assembled with silver paste and tithlty pressed on the proc ... There is no miracle : if you want to reach high frequencies without a noisy fan wich increase air pressure on the heatsink, you need a costly (copper) and big (air contact surface) heatsink.

 

But I think I nevertheless I will buy a small aluminium heatsink to improve things for my desktop device.

[tkaiser]

There is no miracle : if you want to reach high frequencies without a noisy fan wich increase air pressure on the heatsink, you need a costly (copper) and big (air contact surface) heatsink.

 

Well, let's see how good FA's heatsink performs (makes use of a rather thick thermal pad and the heatsink fins aren't that high). For the stuff NanoPI NEO is designed (IoT) I doubt a heatsink is necessary (see this thread and that thread) but for situations where one might need a heatsink (constant high load) I think it's important that it can be mounted reliably.

 

I think the concept to use mounting holes defined the size of the heatsink and not necessarily the amount of heat H3 will produce. This way a heatsink can even be used in environments where heavy vibrations occur (then goodbye adhesive heatsinks) while the height of the fins allows reducing the size. If FA's package arrives I'll have a few new H3 boards to test with, will then also 'review' this heatsink if they included it.

 

BTW: Any of the NanoPi NEO owners can already help us estimate overheating problems with this device. Simply take and adopt Armbian for NanoPi M1 as outlined in posting #73 above and then

sudo armbianmonitor -r
cd /tmp
git clone https://github.com/ssvb/cpuburn-arm
cd cpuburn-arm
gcc cpuburn-a7.S
sudo mv a.out /usr/local/bin/cpuburn-a7
cpuburn-a7

This will install RPi-Monitor (for some explanations see here please) and then gets cpuburn-a7. This is maybe the most heavy workload we currently have for H3's CPU cores (with Armbian where we clock Mali400 GPU with 600 MHz only GPU bound tasks can heat up the SoC even more) and within 5 minutes heavy throttling should occur without a heatsink.

 

We have already some graphs to compare with -- look at this issue comment or below: https://github.com/igorpecovnik/lib/issues/298#issuecomment-223031359 (with Orange Pis the larger the board the less throttling -- most likely caused by the copper layers inside the PCB, all three graphs were made with H3 devices without heatsink).

 

And it's really like you said: With high-end CPUs and now also with more recent ARM SoCs improved heat dissipation is needed to get full performance over longer periods of time. In case full performance isn't needed or the user in question isn't fearful good performance can also be achieved without a heatsink (our throttling settings can be adjusted, we can easily allow H3 to get way more hot but we don't do so with our default since reliable operation has precedence and also thermal readouts with mainline u-boot show lower values so we leave some extra safety headroom to not operate H3 in a thermal range where permanent damage might occur)

[rm-rfstar]

FA also mentioned that there was a case coming so i'm interested in how that will interface with the board and heatsink!

[Johhny Blue]

Hi.

I have been trying to get audio out working on the NEO.

With a fresh install of the Armbian M1, I can see using aplay -l

card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 []

  Subdevices: 1/1

  Subdevice #0: subdevice #0

card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 []

  Subdevices: 1/1

  Subdevice #0: subdevice #0

 

When I follow the extra instructions in post #73, the on board sound disappears. Is there an easy way to get it back going again?

 

I am sure it will all work in the proper release, but I am keen to keep testing right now.

 

Thanks.

[eperie]

I installed Armbian_5.14_Nanopim1_Debian_jessie_3.4.112, and followed the steps described at #73 and #80, but did not start cpuburn-a7 - I am discussing cpuburn-a7 further.
That is, I had only armbianmonitor web server (three processes) and armbianmonitor command-line running.
 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
06:36:51: 1008MHz  0.03   0%   0%   0%   0%   0%   0%   40 C
...
06:51:03:  480MHz  0.03   0%   0%   0%   0%   0%   0%   58 C
06:51:08:  480MHz  0.03   1%   0%   0%   0%   0%   0%   58 C
06:51:13:  480MHz  0.03   1%   0%   0%   0%   0%   0%   59 C
06:51:18:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:23:  480MHz  0.02   0%   0%   0%   0%   0%   0%   59 C
06:51:28:  480MHz  0.02   0%   0%   0%   0%   0%   0%   58 C
06:51:33:  480MHz  0.02   0%   0%   0%   0%   0%   0%   59 C
06:51:39:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:44:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:49:  480MHz  0.01   1%   1%   0%   0%   0%   0%   58 C
06:51:54:  480MHz  0.01   0%   0%   0%   0%   0%   0%   58 C
06:51:59:  480MHz  0.01   0%   0%   0%   0%   0%   0%   58 C

Starting cpuburn-a7 hangs my nanopi-neo immediatly, leaving both power (green) and heart-beat (blue) LEDs solid.

I got the same behaviour a couple of times - rebooted, kept armbianmonitor -m running until temperature reached 58 C, then started cpuburn-a7 again.

 

Did you experiment this with any other H3-based SBC ?

I can perform other tests and provide feedback upon request - my time zone is Eastern Time/UTC-05:00.

 

Thanks.

[tkaiser]

I am sure it will all work in the proper release

 

Everything that's not necessary will be disabled for sure since NanoPi NEO is not about cheap price but minimal consumption. Also: There is no Audio connector on this board and we learned just recently that by disabling every engine in the SoC we can save energy and minimize consumption. That means you have to enable audio in the fex file for yourself if you want to use it for whatever reasons (what's the use case? Soldering cables to the header?)

root@armbian:/var/git/Armbian/lib/config/fex# diff nano* | grep -i audio
< audio_pa_ctrl = port:PA16<1><default><default><0>
> ;audio_pa_ctrl = port:PA16<1><default><default><0>

Seems the only difference now is audio_pa_ctrl being commented out in NEO's fex file. So please give this a try and report back.

 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
06:36:51: 1008MHz  0.03   0%   0%   0%   0%   0%   0%   40 C
...
06:51:03:  480MHz  0.03   0%   0%   0%   0%   0%   0%   58 C
06:51:08:  480MHz  0.03   1%   0%   0%   0%   0%   0%   58 C
06:51:13:  480MHz  0.03   1%   0%   0%   0%   0%   0%   59 C
06:51:18:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:23:  480MHz  0.02   0%   0%   0%   0%   0%   0%   59 C
06:51:28:  480MHz  0.02   0%   0%   0%   0%   0%   0%   58 C
06:51:33:  480MHz  0.02   0%   0%   0%   0%   0%   0%   59 C
06:51:39:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:44:  480MHz  0.02   1%   1%   0%   0%   0%   0%   58 C
06:51:49:  480MHz  0.01   1%   1%   0%   0%   0%   0%   58 C
06:51:54:  480MHz  0.01   0%   0%   0%   0%   0%   0%   58 C
06:51:59:  480MHz  0.01   0%   0%   0%   0%   0%   0%   58 C

Starting cpuburn-a7 hangs my nanopi-neo immediatly

 

Easy: Insufficient power. In case you use Micro USB you ran into the usual problem: Tiny wires/connectors --> increasing load --> dropped voltage --> freeze.

 

TL;DR: Micro USB to power anything that needs more than a few mA is crap. Always. Reasons are crappy connector (tiny contants) and crappy cables (most USB cables have a resistance way to high), symptoms are that with increasing load the voltage drops (Ohm's law) and if the voltage falls below a critical value then the board either freezes (when you're lucky!) or all sorts of strange symptoms occur the average user blames the software for ('Armbian is instable').

 

Apart from that it's already obvious that NanoPi NEO has an overheating problem if your ambient temperature is below 30°C.

[Johhny Blue]

Thanks you tkaiser - the fex files fixed and now can see the audio.

My use case is that I need a small sound output when plug in USB disk (like a notify beep).

Do you know if I can just connect a tiny speaker directly to the board?

Would I just connect spk+ to lineout (either L or R) and spk- to GND? 

 

One last question, I was using a piezo buzzer and wiring pi on a PiZero, but since found Armbian and the Friendly Arm, I would like to change.

The bash code I use for the PiZero to address the piezo was

gpio -g mode 18 pwm.

Can you tell me how I can translate this for the NanoPi Neo? What pin would I connect it to and what value would I use in the script?

Thanks again.

[trewq]

BTW: Any of the NanoPi NEO owners can already help us estimate overheating problems with this device. Simply take and adopt Armbian for NanoPi M1 as outlined in posting #73 above and then

sudo armbianmonitor -r
cd /tmp
git clone https://github.com/ssvb/cpuburn-arm
cd cpuburn-arm
gcc cpuburn-a7.S
sudo mv a.out /usr/local/bin/cpuburn-a7
cpuburn-a7

 

I ran the test and the following are my results. It became completely unresponsive and I had to do a hard restart.

 

This test was conducted at ~10°C ambient temperature.

 

[tkaiser]

Thanks you tkaiser - the fex files fixed and now can see the audio.

 

Thx for the confirmation. So the commented out definition simply makes no sense (I simply used NanoPi NEO fex directly from FriendlyARM a few weeks ago and adjusted a few Armbian specific stuff). Now the audio definition looks like this

[audio0]
audio_used = 1
lineout_vol = 31
cap_vol = 5
audio_hp_ldo = "none"
adcagc_used = 0
adcdrc_used = 0
dacdrc_used = 0
adchpf_used = 0
dachpf_used = 0
;audio_pa_ctrl = port:PA16<1><default><default><0>

But later it will look like this

[audio0]
audio_used = 0
lineout_vol = 31
cap_vol = 5
audio_hp_ldo = "none"
adcagc_used = 0
adcdrc_used = 0
dacdrc_used = 0
adchpf_used = 0
dachpf_used = 0
audio_pa_ctrl = port:PA16<1><default><default><0>

Then 'audio_used = 0' might lead to same energy savings and in case anyone wants to enable audio it will work after settings this to 1 since PA16 is then enabled too.

 

Regarding the other questions: No idea at all (no electronics skills and I hate audio on Linux since it's such a PITA to deal with)

[tkaiser]

I ran the test and the following are my results. It became completely unresponsive and I had to do a hard restart.

 

Well, at least it's obvious from the graphs that cpuburn-a7 was not running at all (or to be more precise: it ran few milliseconds and then it crashed) so you ran into the same problem as @eperie above: Increasing load --> dropping voltage --> board freezing or starting to behave totally weird.

 

Ok, lesson learned. I shouldn't encourage users to run heavy stuff on boards with an inappropriate DC-IN connector. Since you either need ultra short USB cables that are rated 20AWG or 22AWG or power the board reliably with Dupont jumper wires through the 4 pin header next to the upright USB jack.

[trewq]

Well, at least it's obvious from the graphs that cpuburn-a7 was not running at all (or to be more precise: it ran few milliseconds and then it crashed) so you ran into the same problem as @eperie above: Increasing load --> dropping voltage --> board freezing or starting to behave totally weird.

 

Ok, lesson learned. I shouldn't encourage users to run heavy stuff on boards with an inappropriate DC-IN connector. Since you either need ultra short USB cables that are rated 20AWG or 22AWG or power the board reliably with Dupont jumper wires through the 4 pin header next to the upright USB jack.

 

Yep, you're right. Started doing the testing before I read the above mention of voltage drop after running the test. The power source and everything up the the micro usb connection is more than sufficient it just seems like it's the connection jack. I'll get my connection going straight into the headers and report back.

[trewq]

Well, at least it's obvious from the graphs that cpuburn-a7 was not running at all (or to be more precise: it ran few milliseconds and then it crashed) so you ran into the same problem as @eperie above: Increasing load --> dropping voltage --> board freezing or starting to behave totally weird.

 

Ok, lesson learned. I shouldn't encourage users to run heavy stuff on boards with an inappropriate DC-IN connector. Since you either need ultra short USB cables that are rated 20AWG or 22AWG or power the board reliably with Dupont jumper wires through the 4 pin header next to the upright USB jack.

 

Lets try this again.

 

 

Voltage stayed at 1.1v once cpuburn started.