Jump to content

NanoPI NEO / AIR

Per-Mattias Nordkvist
 Share

Recommended Posts

tkaiser

tkaiser

Posted
Posted
  On 7/30/2016 at 10:48 AM, trewq said:

Voltage stayed at 1.1v once cpuburn started.

 

Yeah, with Armbian settings we use 1.1V from 0-912 MHz and 1.3V for the upper clockspeeds. So the most interesting graph would be 18:30-20:30 with just SoC temperature and clockspeed. Can you please post that again?

eperie

eperie

Posted
Posted
  On 7/30/2016 at 7:22 AM, tkaiser said:

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.

 

No problem, I happily volunteered, and Armbian saved me a ***lot*** if time while setting-up my nanopi-m1.

I had read about those power supply issues on the forum, but thought I would be fine with a 2A micro-USB power supply - it seems I was wrong: my cable is not short, and I am not sure about its gauge.

 

I powered the board with a MB102 breadboard power supply rated for 5V/1.2A directly on the 4 pins header using Dupond cables as suggested, and cpuburn-a7 hanged the board again. Looking now for a 5V switching power supply: I am not sure the breadboard power supply is doing the job. Thanks for the help.

1
wildcat_paris

wildcat_paris

Posted
Posted
  On 7/30/2016 at 4:52 PM, eperie said:

I powered the board with a MB102 breadboard power supply rated for 5V/1.2A directly on the 4 pins header using Dupond cables as suggested, and cpuburn-a7 hanged the board again. Looking now for a 5V switching power supply: I am not sure the breadboard power supply is doing the job. Thanks for the help.

 

The breadboard power supply is usually designed with AMS1117 regulator. Each regulator (3.3V, 5V) can handle 1A MAX output at best

 

note: it can handle the power of an Arduino Uno (USB) or Arduino minipro, a 1602 LCD, a current sensor but not much more components.

eperie

eperie

Posted
Posted
  On 7/30/2016 at 6:21 PM, wildcat_paris said:

The breadboard power supply is usually designed with AMS1117 regulator. Each regulator (3.3V, 5V) can handle 1A MAX output at best

Yes, this is the case of mine - thanks.

trewq

trewq

Posted
Posted
  On 7/30/2016 at 2:17 PM, tkaiser said:

Yeah, with Armbian settings we use 1.1V from 0-912 MHz and 1.3V for the upper clockspeeds. So the most interesting graph would be 18:30-20:30 with just SoC temperature and clockspeed. Can you please post that again?

fijZ0cN.png

 

There we go. Sorry, wasn't sure what was actually needed so I played it safe and included the same as the ones you linked further above on github.

1
tkaiser

tkaiser

Posted
Posted
  On 7/30/2016 at 9:54 PM, trewq said:

Sorry, wasn't sure what was actually needed so I played it safe and included the same as the ones you linked further above on github.

 

 

Thanks. The problem was that cpufreq shares the same axis with other graphs so that the exact range of throttling clockspeeds was not visible. The graph above is better and we now know that NanoPi NEO with the rather unrealistic heavy cpuburn-a7 workload throttles down to ~480 MHz.

 

Fortunately 'normal' use cases for this board look differently but for tasks that need constant higher CPU utilization a heatsink looks mandatory.

tkaiser

tkaiser

Posted
Posted

3D printable enclosure appeared on the official wiki:

 

NanoPi_NEO_3D_printed_housing.png

 

There's enough room for the official heatsink also and I would suppose that the upcoming NanoPi Air will share the same dimensions so a slightly different enclosure allowing to connect an external antenna might follow soon (or NanoPi Air relies on a PCB antenna only -- we'll see)

rm-rfstar

rm-rfstar

Posted
Posted
  On 8/1/2016 at 11:09 AM, tkaiser said:

3D printable enclosure appeared on the official wiki:

 

NanoPi_NEO_3D_printed_housing.png

 

There's enough room for the official heatsink also and I would suppose that the upcoming NanoPi Air will share the same dimensions so a slightly different enclosure allowing to connect an external antenna might follow soon (or NanoPi Air relies on a PCB antenna only -- we'll see)

 

for everyone's interest more information (and pictures!) about this enclosure has been posted to thingiverse here: http://www.thingiverse.com/thing:1698298

cb88

cb88

Posted
Posted

So I installed the Jessie armbian image, grabbed tkaiser's .fex file ...

 

now I get this repeatedly in the kernel log.... ?

[ 7522.234589] [ARISC ERROR] :message process error
[ 7522.234650] [ARISC ERROR] :message addr   : f004b840
[ 7522.234687] [ARISC ERROR] :message state  : 5
[ 7522.234720] [ARISC ERROR] :message attr   : 2
[ 7522.234753] [ARISC ERROR] :message type   : 30
[ 7522.234786] [ARISC ERROR] :message result : ff
[ 7522.234817] [ARISC WARING] :callback not install
[ 7522.234857] [cpu_freq] ERR:set cpu frequency to 240MHz failed!
 

Edit:

the 240Mhz voltage level was missing... also the minimum frequency was still 480Mhz so I fixed that (and just changed 480Mhz level to 240Mhz also I don't think you need to do this though) and now it works fine.

cb88

cb88

Posted
Posted

this is on the naonpim1 image... I did update the nanopine.fex to the one linked to above.

 

If I modprobe sunxi_pwm I get a /dev/sunxi_pwm device and some sysfs interfaces but they don't seem to match up with any documentation I can find.

 

root@nanopi-neo:~# ls
a.out  test.c
root@nanopi-neo:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
01:21:22: 1008MHz  0.16   0%   0%   0%   0%   0%   0%   52°C
01:21:27: 1152MHz  0.14   0%   0%   0%   0%   0%   0%   52°C
01:21:32:  240MHz  0.13   0%   0%   0%   0%   0%   0%   52°C
01:21:37:  240MHz  0.12   4%   1%   0%   0%   1%   0%   53°C
01:21:42:  240MHz  0.19   1%   1%   0%   0%   0%   0%   55°C
01:21:47: 1008MHz  0.31   1%   1%   0%   0%   0%   0%   53°C
01:21:52:  240MHz  0.28   1%   1%   0%   0%   0%   0%   53°C
01:21:58:  240MHz  0.26   4%   2%   1%   0%   0%   0%   53°C
 

Igor

Igor

Posted
Posted
  Quote

this is on the naonpim1 image... I did update the nanopine.fex to the one linked to above.

 

Board configuration / this file is the only difference. PWM - I haven't check this yet and it's possible that it's not properly configured.

pezi

pezi

Posted
Posted

Back from holiday - here are my CPU values with the first offical NanoPI  NEO Armbian image.

 

root@nanopineo:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
06:55:18: 1008MHz  0.49   4%   1%   1%   0%   1%   0%   55°C
06:55:23:  240MHz  0.45   4%   1%   1%   0%   1%   0%   55°C
06:55:29:  240MHz  0.42   4%   1%   1%   0%   1%   0%   54°C
06:55:34:  240MHz  0.38   4%   1%   1%   0%   1%   0%   54°C
06:55:39:  240MHz  0.35   4%   1%   1%   0%   1%   0%   54°C
06:55:44:  240MHz  0.33   4%   1%   1%   0%   1%   0%   54°C
06:55:49:  240MHz  0.30   3%   1%   1%   0%   1%   0%   54°C
06:55:55:  240MHz  0.28   3%   1%   1%   0%   1%   0%   54°C
 

cb88

cb88

Posted
Posted

I was able to get gpio 6 to turn on and off from sysfs but I still haven't figured out pwm.

 

 

The only thing in /sys/sunxi_pwm/sunxi_pwm is...

./dev
./power
./power/control
./power/async
./power/runtime_enabled
./power/runtime_active_kids
./power/runtime_active_time
./power/autosuspend_delay_ms
./power/runtime_status
./power/runtime_usage
./power/runtime_suspended_time
./subsystem
./uevent

 

my .fex file has the follwing..

[pwm0_para]
pwm_used = 1
pwm_positive = port:PA05<3><0><default><default>

[pwm1_para]
pwm_used = 0
pwm_positive = port:PA06<3><0><default><default>



 

cb88

cb88

Posted
Posted
  On 8/8/2016 at 2:47 PM, tkaiser said:

Which might conflict with uart0?

So is it PA06 that is acutually the correct PWM output?

 

I was toggling the correct pin GPIO6 earlier with no effect on UART0. So I presume that is the case...

tkaiser

tkaiser

Posted
Posted
  On 8/8/2016 at 5:21 PM, cb88 said:

So is it PA06 that is acutually the correct PWM output?

 

If have neither an idea nor the hardware here (and since there are some vendors out there that are totally surprised by different pin mappings they find on their own boards checking with real hardware is IMO mandatory -- but FriendlyARM can not be compared to lousy 'Team BPi')

 

I just wanted to point out that both pins that might be used for PWM are defined already as active (PA05 for uart0 and PA06 as GPIO pin -- this definition then has to be removed in case you want to try out pwm1)

cb88

cb88

Posted
Posted
  On 8/8/2016 at 5:28 PM, tkaiser said:

If have neither an idea nor the hardware here (and since there are some vendors out there that are totally surprised by different pin mappings they find on their own boards checking with real hardware is IMO mandatory -- but FriendlyARM can not be compared to lousy 'Team BPi')

 

I just wanted to point out that both pins that might be used for PWM are defined already as active (PA05 for uart0 and PA06 as GPIO pin -- this definition then has to be removed in case you want to try out pwm1)

Ok, I tried disabling the UART in the .fex (and it did end up disabled once I rebooted) but this didn't change anthing else as far as I could tell....

 

Edit:

running cpuburn-a7 ... I only have 1 core enabled and everything I am not using disabled in the .fex file. (this is an automatic AVR 32u4 board flasher so I don't need much ummph) Also the ram is running at 132Mhz.

Stop monitoring using [ctrl]-[c]

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU

22:07:21:  240MHz  0.44  12%   8%   0%   2%   0%   0%   39°C

22:07:27:  240MHz  0.49  76%  11%  61%   1%   0%   0%   40°C

22:07:33:  240MHz  0.53 100%   3%  95%   0%   0%   0%   40°C

22:07:39:  240MHz  0.56 100%   3%  95%   0%   0%   0%   40°C

22:07:45:  240MHz  0.60 100%   3%  95%   0%   0%   0%   40°C

22:07:50:  240MHz  0.71 100%   7%  90%   1%   0%   0%   40°C

22:07:56:  240MHz  0.83 100%   2%  97%   0%   0%   0%   40°C

22:08:01:  240MHz  0.84 100%   5%  91%   2%   0%   0%   40°C

22:08:07:  240MHz  0.94 100%   5%  91%   2%   0%   0%   40°C

1
tkaiser

tkaiser

Posted
Posted

My FriendlyARM package arrived yesterday and they included a bit more stuff than expected (NanoPi M1 too). I immediately started to build a NanoCluster just to realize that this was a very bad idea since I always confused boards and ended up in the meantime disassembling the 'cluster' and using a single board with mounted heatsink for the first round of tests

 

Nano_Cluster.jpg

 

Based on some research how to lower consumption on H3 boards the last weeks I used then our new preliminary Armbian image for the NEO, simply adjusted DRAM clockspeed to the lower limit (needs a patch) and disabled cpu cores 1-3 to end up at 805 mW consumption. I simply added to /etc/rc.local

echo 0 >/sys/devices/system/cpu/cpu3/online
echo 0 >/sys/devices/system/cpu/cpu2/online
echo 0 >/sys/devices/system/cpu/cpu1/online
echo 132000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
dmesg -n1

Then I tried out FA's 'Ubuntu Core + Qt Embedded' image just to realize that there's something wrong since consumption was immediately at a very high level (above 1.5W I would assume) since this image starts '/opt/QtE-Demo/run.sh&' from within /etc/rc.local which might not be that useful on a device lacking display output. After killing these processes FA's image needed 1225 mW so our 805 mW are a nice improvement (two thirds).

 

But since I found 805 mW quite a lot I used the modified NanoPi NEO image with an Orange Pi Lite and there consumption with exactly the same settings was just at 665 mW so switching to a different hardware saved another 140 mW (please take this with a grain of salt since even with identical settings there the hardware differs and there's no Ethernet physically available which might let H3's integrated PHY disable the Ethernet block at all? This test would've to be repeated with an Orange Pi One but I don't have one any more).

 

From left to right:Bildschirmfoto%202016-08-10%20um%2008.18

 

Since I used the heatsink a few first words regarding temperatures. NanoPi NEO with our new settings and heatsink applied reported 27°C while idling at 240 MHz, with FA's Ubuntu Core idling at 480 MHz 41°C were reported. Why such a difference? Since thermal readouts in Armbian are broken. :)

 

To be more precise: When we started supporting H3 boards half a year ago I immediately realized that thermal readouts are wrong as soon as we switch from Allwinner's legacy u-boot (2011.09) to mainline u-boot (2016.01 back at that time). We discussed this in linux-sunxi IRC but still have no idea why the readouts differ (maybe some clocks are set differently and this affects ADC conversion?). But based on a series of measurements I did back then we can assume that temperatures reported in Armbian are 10-15°C lower than when using BSP u-boot (that's why we start with throttling on H3 boards already at 70°C -- H3 is specified to run at up to 125°C so we use a lot of safety headroom).

 

The temperature mismatch can simply be checked with a thumb. 27°C as reported when running Armbian is less than my own temperature but touching the heatsink it feels slightly warmer. BTW: To ensure lowest idle operation possible I refrained from installing RPi-Monitor and did not use 'armbianmonitor -m' but just checked clockspeed and temperature every 2 seconds using

while true ; do echo "$(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq) kHz, $(cat /sys/class/thermal/thermal_zone1/temp)C"; sleep 2; done

That's it for now. Next steps are some consumption measurements with different DRAM clockspeeds (since the 432 MHz FriendlyARM chose do not help that much with regards to energy savings but 264 MHz for example do and 132 MHz even more) and debugging why the boards quite often hang in u-boot.

Chun

Chun

Posted
Posted
26.6°C

91% Humidity

 

  Reveal hidden contents 




Stop monitoring using [ctrl]-[c]

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU

12:56:05: 1152MHz  0.05   0%   0%   0%   0%   0%   0%   36°C

12:56:10:  240MHz  0.05   0%   0%   0%   0%   0%   0%   36°C

12:56:15:  240MHz  0.04   0%   0%   0%   0%   0%   0%   36°C

12:56:21:  240MHz  0.04   0%   0%   0%   0%   0%   0%   35°C

12:56:26:  240MHz  0.04   0%   0%   0%   0%   0%   0%   36°C

12:56:31:  240MHz  0.03   0%   0%   0%   0%   0%   0%   35°C

12:56:36:  240MHz  0.03   0%   0%   0%   0%   0%   0%   36°C

12:56:42:  240MHz  0.03   0%   0%   0%   0%   0%   0%   36°C

12:56:47:  240MHz  0.03   0%   0%   0%   0%   0%   0%   35°C

12:56:52:  240MHz  0.02   0%   0%   0%   0%   0%   0%   36°C

12:56:57:  240MHz  0.02   0%   0%   0%   0%   0%   0%   36°C

12:57:03:  240MHz  0.02   0%   0%   0%   0%   0%   0%   36°C

12:57:08:  240MHz  0.02   0%   0%   0%   0%   0%   0%   36°C

12:57:13:  240MHz  0.02   0%   0%   0%   0%   0%   0%   36°C

12:57:18:  240MHz  0.02   0%   0%   0%   0%   0%   0%   35°C

12:57:23:  240MHz  0.01   0%   0%   0%   0%   0%   0%   36°C

12:57:29:  240MHz  0.01   0%   0%   0%   0%   0%   0%   36°C

12:57:34:  240MHz  0.08   0%   0%   0%   0%   0%   0%   35°C

12:57:39:  240MHz  0.08   0%   0%   0%   0%   0%   0%   36°C

12:57:44:  240MHz  0.07   0%   0%   0%   0%   0%   0%   36°C

12:57:50:  240MHz  0.07   0%   0%   0%   0%   0%   0%   35°C

12:57:55:  240MHz  0.06   0%   0%   0%   0%   0%   0%   36°C

12:58:00:  240MHz  0.06   0%   0%   0%   0%   0%   0%   36°C

12:58:05:  240MHz  0.05   0%   0%   0%   0%   0%   0%   36°C

12:58:10:  240MHz  0.05   0%   0%   0%   0%   0%   0%   36°C

12:58:16:  240MHz  0.04   0%   0%   0%   0%   0%   0%   35°C

12:58:21:  240MHz  0.04   0%   0%   0%   0%   0%   0%   36°C

12:58:26:  240MHz  0.04   0%   0%   0%   0%   0%   0%   36°C

12:58:31:  240MHz  0.03   0%   0%   0%   0%   0%   0%   35°C

12:58:37:  240MHz  0.03   0%   0%   0%   0%   0%   0%   36°C



tkaiser

tkaiser

Posted
Posted
  On 8/10/2016 at 2:41 PM, cb88 said:

I've rebooted my board 20+ times and haven't seen it hang... So, how often are we talking?

 

Pretty often, it must've been some 'noise' that prevented u-boot from doing autoboot (u-boot waits a few seconds for keystrokes and if none happen it resumes with booting. In my case something went wrong -- didn't had the time to check since currently DRAM clockspeed consumption tests do run)

 

BTW: Please don't consider any DRAM clockspeed below 408 MHz to be safe for productive use. It still needs a lot of testing whether we can decrease minimum DRAM clockspeed by patching the kernel :)

 

  On 8/10/2016 at 5:13 PM, multivac61 said:

I am having troubles with getting audio from the sunxi audiocodec on my NanoPi NEO.

 

Please check post #2 here. Sorry, can't help more since I refrain from touching audio on Linux.

tkaiser

tkaiser

Posted
Posted

And again: NanoPi NEO got stuck on u-boot prompt again. I did some unattended testing regarding temperature and consumption figures when switching between 132 MHz and 672 MHz DRAM clockspeed and then the script did a reboot which looks like it would've failed but in reality the NEO is 'just' waiting for input. All I had to do was to connect serial console and then [enter], boot, [enter]:

 

  Reveal hidden contents

 

 

Pretty mean behaviour. Everytime I have serial console connected it did not happen, only in unattended mode :)

 

At least we now know at which consumption the NEO idles in u-boot 2016.07 with NanoPi M1 settings (816 MHz CPU, 624 MHz DRAM): 1100 mW. Good to know since I want to test out settings with greatly reduced consumption (480 MHz, 408 MHz DRAM for example -- the goal is to let NEO boot with less than 1W consumption while bringing up all 4 CPU cores)

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 8/11/2016 at 10:58 AM, tkaiser said:

Pretty mean behaviour. Everytime I have serial console connected it did not happen, only in unattended mode :)

Comparing NanoPi Neo schematics with, for example, Orange Pi Lite, Lite has level shifter and pull-up resistor on UART0 RX line, while RX line on Neo is floating.

So the problem can be very simple - Neo picks up noise on RX during boot if nothing is connected to UART0 RX pin. Solution - solder a resistor (i.e. 10kOhm) from 3.3V to RX. (WARNING: 2nd pin on Neo UART header is 5V, not 3.3V!)

 

Edit: There should be internal pull-ups in SoC, but whether SPL/U-boot activates them or not needs to be checked in source code.

Edit 2: U-boot seems to set pull-up for RX pin, but still there is difference in hardware implementation

1
tkaiser

tkaiser

Posted
Posted
  On 8/11/2016 at 11:12 AM, zador.blood.stained said:

There should be internal pull-ups in SoC, but whether SPL/U-boot activates them or not needs to be checked in source code.

 

Would be interesting whether there was a change between 2016.05 and 2016.07... but I definitely had the same behaviour with FA's OS image which uses u-boot 2011.09.

 

Thanks for the explanation. IIRC I also had not a single problem yesterday when I used FA's PSU-ONECOM module to power the board. Will dig deeper tomorrow. The scheduled test for today will run the next 11 hours and I hope that I'm then not too tired to switch boards after midnight and let the same consumption monitoring test run again on OPi Lite.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 8/11/2016 at 11:28 AM, tkaiser said:

IIRC I also had not a single problem yesterday when I used FA's PSU-ONECOM module to power the board. Will dig deeper tomorrow. The scheduled test for today will run the next 11 hours and I hope that I'm then not too tired to switch boards after midnight and let the same consumption monitoring test run again on OPi Lite.

If you can reproduce this hang at u-boot without connecting anything to serial port and can't with connected (and powered) serial adapter, then it's probably related to simplified schematics, otherwise try connecting only TX line (from board's side) to catch any possible messages without interfering with input.

tkaiser

tkaiser

Posted
Posted

Different debugging approach since it happened only once with FA's OS image but quite frequently with our NEO image. I downloaded our 5.14 image for Orange Pi One, flashed it and started NEO with this. No hang, then downloaded our new fex file as outlined on page 3 of this thread and disabled usb2 and usb3 since I wanted to have a look if then the frequent messages stop (they don't):

hub 1-0:1.0: connect-debounce failed, port 1 disabled

I've seen them on at least two different NEOs (one 512MiB, one 256MiB) and with both FA's Ubuntu as well as ours. NEO/512 running FA's Ubuntu:

 

  Reveal hidden contents

 

 

The very same NEO starting Armbian 5.14 for OPi One the first time:

 

  Reveal hidden contents

 

 

Full debug output (a bit scary regarding ehci_irq): http://sprunge.us/SZaR (on the other NEO with my patched kernel currently doing DRAM consumption tests there is no such message -- strange)

 

I let the board reboot now automatically a few hours (11 reboots without any problem already passed) and wil then replace/update u-boot with 2016.07.

 

Edit: nothing connected to the board except Ethernet while reboot tests are running.

cb88

cb88

Posted
Posted

Yeah I am using the M1 image with modified .fex and a kernel with your patch + built in SPI LCD module.

 

I can't test he LCD module yet though... don't have it yet.

 

The serial converter I am using is a Silicon Labs  CP2102 board.it has LEDs on the TX and RX likes which may be acting as pull downs... I haven't booted it much without the serial console attached.

 

Also, duing my testing I have powered it from both a large USB power pack as well as my laptop's USB port with a short usb cable.

martinayotte

martinayotte

Posted
Posted
  Quote

 

it has LEDs on the TX and RX likes which may be acting as pull downs

 

That is a bit of myth in some people's thinkings. If they were acting like that, it would means that LED is in conducting mode.

Same thing applied when LED is connected in Sink mode, it doesn't act as PullUp, otherwise it will glow ... :rolleyes:

tkaiser

tkaiser

Posted
Posted
  On 8/11/2016 at 1:11 PM, tkaiser said:

I let the board reboot now automatically a few hours

 

Well, reboot is the wrong test (worked 80 times flawlessly with 2016.05 and 2016.07). I switched to issuesing 'poweroff', then waited until the board shut down, cut power and then let the board do a cold boot again.

 

Couldn't reproduce it any more reliably so I gave up and do some other testing now. At least I prepared u-boot settings that start H3 boards with 408 MHz DRAM clock and 480 MHz CPU. They work and I use them now to wait for the next occurence of the 'stalled in u-boot' situation since I can then measure new idle consumption in u-boot :)

 

Changes compared to NEO defaults:

 

  Reveal hidden contents

 

 

Archive with .debs and script.bin here: sun8i-dram-downclocking.tar

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept