Jump to content

[RfC] Default settings for NanoPi NEO/Air


tkaiser

Recommended Posts

Hi devs,

 

I would like to discuss our default settings for the small NanoPi H3 boards that lack HDMI output capabilities (so the use cases are pretty clear: we're talking about headless servers or IoT nodes). Based on some research done the last few weeks I would like to start with these settings:

  • HDMI/Mali400 disabled (for obvious reasons, also this is responsible for some severe energy savings -- can't tell numbers but this is the most efficient measure together with drastically reducing DRAM clockspeed)
  • maximum CPU clockspeed by default 1200 MHz in fex file but 912 MHz in cpufrequtils' settings so that the boards remain at 1.1V by default and also maximum consumption is somewhat limited even in case something goes wrong and all CPU cores are busy
  • DRAM clockspeed in fex file remains at 624 MHz
  • DRAM clockspeed reduced from userspace to probably 264 MHz (this needs reliability testing, at least I have not been able to run into stability problems so far). 
  • corekeeper disabled to allow users to control count of active CPU cores from user space
  • g_serial enabled like with Orange Pi Lite (NanoPi NEO will also be sold without Ethernet and USB jack soldered)
  • All USB ports enabled (only deactivating all 4 helps with consumption, as soon as one is enabled it's not that much more consumption when other USB ports are defined as active but not in use)
  • Downclocking CPU cores (and DRAM) in u-boot to ensure minimal consumption while booting (the goal should be to boot 50 NanoPi NEO with a 5V/12A PSU)
  • csi0/audio0/gmac0 disabled (gmac0 of course not on NanoPi NEO)

Regarding DRAM clockspeed: I recently ordered an RPi Zero and a RPi 3 to test with RPi Zero, B, B+, 2 and 3 (using tinymembench and my AXP209 measurement setup). H3 with default DRAM clockspeed is magnitudes faster than the various RPis (DDR2 vs. DDR3, pretty old memory controller on this old BroadCom SoC) and since downclocking DRAM helps also significantly with consumption this is worth a try (downclocking to just 432 MHz like FA is doing is not that efficient). I will test a few different DRAM clockspeeds above 264 MHz to see at which value energy savings look good while trying to ensure that H3 is still faster than RPi Zero.

 

My goal is a board that operates highly energy efficient with defaults but performance can be unlocked instantly. Idea as follows:

  • Ensure through u-boot settings that board boots with minimal consumption (might take a few seconds longer -- but who cares?): 480 MHz CPU and 264 MHz DRAM clockspeed for example (no idea what the lower limits are :) )
  • Allow switching to the max in fex file (1200 MHz CPU / 624 MHz DRAM)
  • As soon as kernel is running the behaviour can be controlled easily from userspace (cpufreq code is operational, CPU cores can be switched off/on individually, cpufrequtils settings can be adjusted, DRAM clockspeed can be set statically as long as no throttling occurs since then fex settings take over)

So users are free to adjust settings to their needs from eg. /etc/rc.local (disabling CPU cores, downclocking DRAM further since the device is just a minimal data logger and so on). The problem is just: Currently our sun8i legacy kernel contains code to adjust DRAM clockspeed when throttling occurs. This can be considered both bug and feature. Imagine a system that should idle at lowest consumption possible but 'wake up' to full performance after a few moments when needed automatically. Cpufreq scaling will be responsible for increasing CPU clockspeed when needed and by choosing a somewhat low 1st thermal trip point in dvfs settings reducing CPU clockspeed only slightly we could allow DRAM clockspeed to also explode automagically. But limiting cpufreq artificially under load to get DRAM clockspeed increased is a bit moronic and also if the system switches to idle state again DRAM clockspeed is still high and consumption 200mW higher than necessary.

 

That's why I started to think about a cron job that will be executed every minute. This script could check /proc/stat and in case high CPU utilization has happened or system returned to idle state adjust settings as defined (activating more CPU cores, lowering DRAM clockspeed backto minimum settings and so on). This would require that we introduce a config file (eg. /etc/armbian-iot-settings.conf) that might look like

CPU_COUNT_MIN=1
CPU_COUNT_MEDIUM=2
CPU_COUNT_MAX=4
CPU_FREQ_MIN=312
CPU_FREQ_MEDIUM=912
CPU_FREQ_MAX=1200
DRAM_FREQ_MIN=132
DRAM_FREQ_MEDIUM=264
DRAM_FREQ_MAX=624
MEDIUM_TRESHOLD=50
MAXIMUM_TRESHOLD=95

Pretty much self-explanatory I guess? The two TRESHOLD values are determined by comparing /proc/stat contents and using CPU utilization (average load is too misleading since people love to use crappy SD cards and load increases just since the cards suck with IO). I can imagine many situations where these settings lead to switching between MIN and MEDIUM state every minute. But we provide 'armbianmonitor -m' which should enable users to 'tune' their settings to their needs.

 

Any thoughts on this?

Link to comment
Share on other sites

Can anyone please help me to understand this commit in FA's lichee tree: https://github.com/friendlyarm/h3_lichee/commit/d7f658426b06afb907f97ac3facf1acfd10ccc7e

 

FA most recently commented this line out in their fex file for M1, NEO and Air:

;audio_pa_ctrl = port:PA16<1><default><default><0>

With our sun8i legacy kernel it's necessary to uncomment the line to get analog audio working again (see posts #84 and #85)

 

My suspicion is that they need PA16 now to enable BT on NanoPi Air. But I fail to understand what the aforementioned code does and why they commented audio_pa_ctrl in fex file of M1 and NEO.

Link to comment
Share on other sites

From an end user point of view, a command like h3disp (for example h3power) with use case profiles would be usefull. Of course, it should use specific tables for the board and would be complex to define, test and parameter. I am not sure that dynamic handling of number of active cores should be a priority, because that depends itself of use cases and then it seems somewhat complex and needing numerous tests but others may think otherwise. (For me, who use cards for specifc functions, it is easy to know how many cores I can use. Number of servers in network or IO services can be a bottleneck in case of full load, but it principally concerns shared usage and do seldom apply to domestic cases).

 

What is NanoPi Air ? Is there a platform targeted at BT audio server (it would make sense to disable internal DAC because of software complexity or instability in BT/a2dp/alsa/pulseaudio).

 

I am a bit lost with nanopi : multiple sites, old cards that would I would have be interested in but no more to sale (?), payment threw PayPal, lot of accessories, serious support and documentation (compared to Orange Pi) but frantic new products release ?

Link to comment
Share on other sites

What is NanoPi Air ?

 

A rumour spread by me yesterday based on github commits: http://forum.armbian.com/index.php/topic/1726-nanopi-air-around-the-corner/

 

There is no relation between BT and audio other than PA16 pin seems to be used on NanoPi M1 and NEO for audio out but on the upcoming NanoPi Air they use the pin for uart3 to connect AP6212's BT part to the SoC.

Link to comment
Share on other sites

I dont know if it is relevant but I had troubles with BT on BPI m2+ because :

 

- when the driver for AP62xx is not initialized, it seems to bug interface indexing and I cannot use an external BT usb dongle (so I disable internal bt in config)

- the AP62xx driver can function, at least for low level bt protocols, but the bnep module create an unusable bnepX instance, hard to investigate because it is immediately destroyed after failing to associate with the bridge.

Link to comment
Share on other sites

I dont know if it is relevant but I had troubles with BT on BPI m2+

 

Well, unrelated to power/energy savings settings so please let us keep that separate (and at least I will never again look into anything that's labeled BPi and does not come with an A20 -- when we deal with BT on NanoPi Air then it's a different story).

 

I just wanted to elaborate why I think that a tool like 'h3power' is not the route to go. People that want to use SBCs with Armbian as IoT nodes need to understand what's happening to set up things correctly. So they have to deal with consequences of setting a specific clockspeed (and understanding what VDD_CPUX means), limiting count of active CPU cores and measuring afterwards whether that helps or not. Which they clearly won't do when they deal with something like 'profiles' to be chosen by the h3power tool.

 

If for example a board is powered by a battery then the goal is to minimize consumption as much as possible. But if there are periodic tasks that require more performance it can even make sense to allow use of more CPU cores and higher clockspeeds since if the task can be finished in less time the CPU cores can enter low power states more early. So in this situation it might make sense to allow even 1200 MHz clockspeed and all 4 cores since in the long run the board consumes less energy with this specific useage profile.

 

Another example: A bunch of SBCs is powered through PoE using a step-down converter (48V to 5V). This converter is rated for 2A max. Therefore it has to be ensured that all SBC never exceed 10W total consumption and then it's necessary to decide to limit count of CPU cores or clockspeeds (or maybe both).

 

Another one: A SBC is used as data logger all the time therefore minimum consumption is a 'nice to have' but should be used from time to time as a networked backup disk using a connected USB disk. In this case the aforementioned settings could be used but the tresholds will be defined that the board switches between data logger and backup mode within a minute automagically (NAS performance will be painfully slow with low cpufreq and DRAM settings):

MEDIUM_TRESHOLD=39
MAXIMUM_TRESHOLD=40

And so on. Also I think we shouldn't be too H3 specific since while this is the SoC of choice currently for IoT projects with a fully blown Armbian installation that's only due to a few H3 boards being dirt-cheap. This might change in the future and maybe we will support the C.H.I.P. rather sooner than later too (since it's also somewhat cheap, energy efficient, comes already with PMIC support therefore battery ready and has WiFi/BT also -- looked at from a certain perspective this device looks even better to be used as fully blown IoT device)

Link to comment
Share on other sites

I iterated through all DRAM clockspeeds between 132 MHz and 672 MHz. Here are consumption numbers and tinymembech results (also as an archive).

 

Format: Timestamp [tab] DRAM clockspeed [tab] 30 min average consumption [tab] SoC temp [tab] /proc/loadavg:

 

 

Thu Aug 11 12:35:49 CEST 2016	132000	870.75	39	0.00 0.02 0.05 1/62 2181
Thu Aug 11 13:05:51 CEST 2016	144000	873.58	39	0.00 0.02 0.05 1/62 2318
Thu Aug 11 13:20:53 CEST 2016	156000	880.21	39	0.09 0.06 0.05 1/62 2458
Thu Aug 11 13:35:55 CEST 2016	168000	886.09	38	0.00 0.02 0.05 1/62 2555
Thu Aug 11 13:50:57 CEST 2016	180000	896.85	38	0.00 0.01 0.05 1/62 2705
Thu Aug 11 14:05:59 CEST 2016	192000	911.33	39	0.04 0.04 0.05 1/62 2812
Thu Aug 11 14:21:01 CEST 2016	204000	915.06	40	0.00 0.01 0.05 1/62 2902
Thu Aug 11 14:36:03 CEST 2016	216000	914.61	40	0.08 0.03 0.05 1/62 2994
Thu Aug 11 14:51:05 CEST 2016	228000	922.80	39	0.00 0.01 0.05 1/62 3094
Thu Aug 11 15:06:07 CEST 2016	240000	932.60	39	0.00 0.01 0.05 1/62 3184
Thu Aug 11 15:21:09 CEST 2016	252000	936.89	40	0.00 0.01 0.05 1/62 3274
Thu Aug 11 15:36:11 CEST 2016	264000	944.90	40	0.08 0.03 0.05 1/62 3371
Thu Aug 11 15:51:13 CEST 2016	276000	956.25	40	0.12 0.04 0.05 1/62 3451
Thu Aug 11 16:06:15 CEST 2016	288000	967.18	40	0.00 0.01 0.05 1/62 3568
Thu Aug 11 16:21:18 CEST 2016	300000	978.16	41	0.00 0.01 0.05 1/62 3638
Thu Aug 11 16:36:19 CEST 2016	312000	988.81	40	0.00 0.02 0.05 1/62 3725
Thu Aug 11 16:51:21 CEST 2016	324000	1011.81	42	0.00 0.01 0.05 1/61 3813
Thu Aug 11 17:06:23 CEST 2016	336000	1031.49	42	0.00 0.01 0.05 1/62 3891
Thu Aug 11 17:21:25 CEST 2016	348000	1041.48	42	0.00 0.01 0.05 1/62 3981
Thu Aug 11 17:36:27 CEST 2016	360000	1047.42	42	0.00 0.01 0.05 1/62 4058
Thu Aug 11 17:51:29 CEST 2016	372000	1055.59	42	0.00 0.03 0.05 1/62 4118
Thu Aug 11 18:06:31 CEST 2016	384000	1073.87	42	0.01 0.03 0.05 1/62 4225
Thu Aug 11 18:21:33 CEST 2016	408000	1104.27	43	0.12 0.04 0.05 1/62 4358
Thu Aug 11 18:51:35 CEST 2016	432000	1199.73	46	0.10 0.07 0.05 1/62 4577
Thu Aug 11 19:21:37 CEST 2016	456000	1251.62	47	0.05 0.03 0.05 1/62 4756
Thu Aug 11 19:51:38 CEST 2016	480000	1262.26	47	0.13 0.04 0.05 1/62 4921
Thu Aug 11 20:21:40 CEST 2016	504000	1262.17	48	0.00 0.01 0.05 1/62 5086
Thu Aug 11 20:51:43 CEST 2016	528000	1289.00	48	0.05 0.03 0.05 1/62 5241
Thu Aug 11 21:21:45 CEST 2016	552000	1301.73	48	0.08 0.03 0.05 1/62 5416
Thu Aug 11 21:51:47 CEST 2016	576000	1287.35	48	0.00 0.01 0.05 1/62 5617
Thu Aug 11 22:21:49 CEST 2016	600000	1296.38	48	0.00 0.01 0.05 1/62 5752
Thu Aug 11 22:51:51 CEST 2016	624000	1309.94	48	0.00 0.01 0.05 1/62 5924
Thu Aug 11 23:21:52 CEST 2016	648000	1328.71	49	0.00 0.01 0.05 1/64 6204
Thu Aug 11 23:51:55 CEST 2016	672000	1337.94	49	0.00 0.01 0.05 1/64 6370 

 

 

 

These were the results from the day before yesterday made with the other NEO/512 (with heatsink but that shouldn't matter) which match more ore less (I had to learn that there's a 12 MHz step at 372 MHz so most numbers there are corrected manually):

 

 

132	820
156	835
180	875
204	900
228	910
252 920
276	940
300	960
324	975
348	985
360	1005
372	1015
384	1020
408	1035
432	1175
456	1200
480	1195
504	1200
528	1220
552	1235
576	1240
600	1265
624	1270
648	1285
672	1290 

 

 

 

IMO it's obvious that the largest savings can be made by using 408 MHz since both 408-432 and 432-456 show best results when it's about reducing consumption and heat (tests made with a NanoPi NEO/512 w/o heatsink):

 

Bildschirmfoto%202016-08-12%20um%2007.51

 

(please forget about the small fluctuations eg. at 17:30 and 22:30, this measuring approach can not be considered save when it's about changes below 20mW).

 

When comparing with an OPi Lite the same happens between 408 and 456 MHz but OPi Lite is faster (dual bank configuration?) and consumes less (no idea). I started the same measurement round at night with OPi Lite but this time using WiFi since my script tries to get actual consumption numbers from my 'monitoring PSU' but that doesn't seem to work well since idle consumption is twice as much with WiFi enabled and also consumption with different DRAM clockspeeds differs much from previous runs -- too bad I can't test with an OPi One instead any more, seems I have to use g_ether instead but then I fear consumption numbers might be incorrect if OPi Lite might take power from both Micro USB and barrel jack)

 

The enhanced script I now use:

 

 

root@orangepilite:/mnt/sda/usr/local/bin# cat check-dram-ng.sh
#!/bin/bash
#
# For whatever reasons DRAM clockspeed can be increased up to 384 MHz in 12 MHz steps
# and beyond that only in 24 MHz steps (while 408 MHz being the lowest allowed clock-
# speed with unpatched kernel).
# So to get better readability of results we could try to skip every 2nd step below 384
# MHz just to realize that there's one exception: between 372 and 384 MHz there's a
# 12 MHz step anyway
#
# for i in 132000 156000 180000 204000 228000 252000 276000 300000 324000 348000 372000 384000 408000 432000 456000 480000 504000 528000 552000 576000 600000 624000 648000 672000 ; do

i=132000
echo -n 108000 >/tmp/last-dram-clock
while [ $i -le 672000 ]; do
	echo $i >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq 2>/dev/null
	read curfreq </sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
	if [ $i -eq $curfreq ]; then
		echo -e "$(date)\t${i}\t\c" >>/var/log/dram.log
		sync &
		read o </tmp/last-dram-clock
		Difference=$(( $i - $o ))
		SleepTime=$(echo "$Difference / 13.33" | bc)
		sleep $(( ${SleepTime} - 2 ))
		PSUConsumption=$(echo "$(ssh 192.168.83.89 'cat /tmp/consumption') - 1030" | bc)
		echo -e "${PSUConsumption}\t$(cat /sys/class/thermal/thermal_zone1/temp)\t$(cat cat /proc/loadavg )" >>/var/log/dram.log
		echo -n $i >/tmp/last-dram-clock
		sync &
	fi
	i=$(( $i + 1000 ))
done 

 

 

 

(to get more precise graphs/numbers a switch to '60 min average' values would be needed, that means dividing through 6.665 and using 'ssh 192.168.83.89 'cat /tmp/consumption_60m') - 1030"' instead. But then test execution takes twices as long and peaks are less visible. IMO that is stuff for trying to measure the effect of switching on/off leds but for this round of tests the best DRAM clockspeeds are already visible)

 

And also some tinymembench performance numbers (scaling not linearly with clockspeed and showing also weird behaviour around 432 MHz, all details available as archive):

 

 

macbookpro-tk:nano-memspeed tk$ grep 'standard memcpy' * 
nanopineo-memtest-132000.log: standard memcpy                                      :    135.8 MB/s
nanopineo-memtest-144000.log: standard memcpy                                      :    147.8 MB/s
nanopineo-memtest-156000.log: standard memcpy                                      :    156.0 MB/s (0.8%)
nanopineo-memtest-168000.log: standard memcpy                                      :    179.2 MB/s (0.4%)
nanopineo-memtest-180000.log: standard memcpy                                      :    188.5 MB/s (0.8%)
nanopineo-memtest-192000.log: standard memcpy                                      :    194.5 MB/s
nanopineo-memtest-204000.log: standard memcpy                                      :    202.7 MB/s (2.4%)
nanopineo-memtest-216000.log: standard memcpy                                      :    199.7 MB/s
nanopineo-memtest-228000.log: standard memcpy                                      :    196.9 MB/s
nanopineo-memtest-240000.log: standard memcpy                                      :    198.9 MB/s (0.1%)
nanopineo-memtest-252000.log: standard memcpy                                      :    199.3 MB/s
nanopineo-memtest-264000.log: standard memcpy                                      :    216.5 MB/s
nanopineo-memtest-276000.log: standard memcpy                                      :    217.9 MB/s
nanopineo-memtest-288000.log: standard memcpy                                      :    231.7 MB/s
nanopineo-memtest-300000.log: standard memcpy                                      :    235.7 MB/s
nanopineo-memtest-312000.log: standard memcpy                                      :    250.0 MB/s
nanopineo-memtest-324000.log: standard memcpy                                      :    262.4 MB/s
nanopineo-memtest-336000.log: standard memcpy                                      :    271.5 MB/s
nanopineo-memtest-348000.log: standard memcpy                                      :    271.3 MB/s
nanopineo-memtest-360000.log: standard memcpy                                      :    299.3 MB/s
nanopineo-memtest-372000.log: standard memcpy                                      :    339.4 MB/s
nanopineo-memtest-384000.log: standard memcpy                                      :    428.5 MB/s
nanopineo-memtest-408000.log: standard memcpy                                      :    433.5 MB/s
nanopineo-memtest-432000.log: standard memcpy                                      :    436.8 MB/s (0.5%)
nanopineo-memtest-456000.log: standard memcpy                                      :    421.1 MB/s (0.2%)
nanopineo-memtest-480000.log: standard memcpy                                      :    434.4 MB/s
nanopineo-memtest-504000.log: standard memcpy                                      :    431.8 MB/s
nanopineo-memtest-528000.log: standard memcpy                                      :    448.9 MB/s
nanopineo-memtest-552000.log: standard memcpy                                      :    454.3 MB/s
nanopineo-memtest-576000.log: standard memcpy                                      :    458.6 MB/s
nanopineo-memtest-600000.log: standard memcpy                                      :    465.8 MB/s (0.3%)
nanopineo-memtest-624000.log: standard memcpy                                      :    484.8 MB/s (0.2%)
nanopineo-memtest-648000.log: standard memcpy                                      :    506.1 MB/s
nanopineo-memtest-672000.log: standard memcpy                                      :    539.3 MB/s 

 

 

Link to comment
Share on other sites

"the effect of switching on/off leds"

 

With 50 mW (2.5V 20 mA) a LED is mainly pretty blinding. Powered threw GPIO with a 270 ohm resistor (as often recomended), it should consume (3.3 - 2.5) / 270 = 3 mA. You may have difficulty to mesure the consumption of a single LED.

 

But what about the difference between 1 our 2 banks of DDR ?

Link to comment
Share on other sites

But what about the difference between 1 our 2 banks of DDR ?

 

Not able to measure. The only boards with just one bank are the NEOs and their design is rather different from the other boards. At least idle consumption and consumption difference when switching between 132 and 672 MHz DRAM clockspeed is way higher compared to the small Oranges.

 

See starting from post #4 here: http://forum.armbian.com/index.php/topic/1781-debian-vs-ubuntu-on-nanopi-neo/#entry13889 (LDO regulators used that generate lower voltage by transforming energy into heat just like on the first Raspberries).

 

Regarding measuring the difference it makes to turn onboard leds on or off (something that can be read in Raspberry forums that it saves 5mA): I thought about using a bunch of H3 boards together by a special DIY cable but in the meantime I came to two conclusions:

  • It's not worth the efforts since in the meantime we already know what's more important than leds (as usual: settings that are chosen intelligently)
  • I can daisy-chain 2 NEOs on each USB port of my PSU for these sort of tests and by adjusting loads on all 4 boards the effect could be measured

Maybe I will do such a test but only if basic settings are finished. Based on information available (especially stuff like U7 -- I added Zador's findings already to linux-sunxi wiki page) I would go with these basic settings:

  • 408 DRAM clockspeed and 480 MHz cpufreq set in u-boot
  • 408 MHz DRAM clockspeed and 240-1200 MHz in fex file, switching from 1.1V to 1.3V above 912 MHz
  • 240-912 MHz in cpufrequtils settings therefore with our default settings VDD_CPUX will remain at 1.1V all the time and users have to 'unlock' the higher voltage and clockspeeds manually (easy, it's just one entry in a config file)
  • corekeeper disabled to let people adjust count of active CPU cores manually
  • Everything that's not needed or is not physically exposed disabled in fex (HDMI, Mali400, usb1, usb2, audio, CSI)

Further possible improvements (decreasing DRAM clockspeed below 408 and a daemon to adjust stuff based on CPU utilization) postponed since for example the DRAM clocking stuff would be better implemented as part of the budget_cooling mechanisms in kernel and not controlled from a daemon.

 

With the above settings we already save a lot of consumption compared to FA's settings, the consumption peak when booting is lower (and booting time slightly increases), we get an additional 100 mW saved by switching from FA's 432 MHz DRAM clockspeed to 408 MHz, save the board from overheating by remaining on 1.1V by default and still allow users to 'unlock' more performance by adjusting one line in a config file.

 

And we could provide official NEO images now. @Zador, @Igor: what's your opinion on this?

Link to comment
Share on other sites

"the consumption peak when booting is lower"

 

This one seems (almost) mandatory for me. As well as a "failsafe" boot mode and as the possibiility to use cheap and compact PSU (less than 1A). BTW, I wondered if it was easy or impossible for some reason to have a boot menu with failsafe/kernel choice/timeout in u-boot when installing or doing test or upgrading ?

Link to comment
Share on other sites

"Not able to measure"

 

So if I understand well, there is no reason to spare 2$ with the 256M option, the consumption being perhaps balanced by the active state duration ? And the price is nothing compared to problems such having bad designed cards or multiple hardware versions (I think that one must have spares when investing a lot of time in a project !)

Link to comment
Share on other sites

As well as a "failsafe" boot mode and as the possibiility to use cheap and compact PSU (less than 1A). BTW, I wondered if it was easy or impossible for some reason to have a boot menu with failsafe/kernel choice/timeout in u-boot when installing or doing test or upgrading ?

 

Well, I think we should really try to allow these boards be powered with very minimal amperage requirements (also important when doing PoE for example) so I hope the others agree on 480/408 MHz set by u-boot. Regarding boot choices: We know that we could improve here a lot but choices at boot time would require keyboard and display (we disabled USB/keyboard on H3 boards for a reason a while ago to improve boot times and prevent crappy USB peripherals interrupting autoboot and there's no display on the NEO anyway) and historically Armbian was more focused on server stuff.

 

To be honest I don't know of any Armbian release that needed failsafe operation since an update/upgrade destroyed the installation. I would assume this sort of failures is related to crappy PSUs or crappy SD cards all the times.

 

So if I understand well, there is no reason to spare 2$ with the 256M option

 

No idea, I booted the 256MiB variant only once and got countless 'hub 1-0:1.0: connect-debounce failed, port 1 disabled' messages (which happened then on other NEOs and both FA's and our images as well) and thought then: ok, there's a problem, let's focus on the 512MiB models for now. Anyway I don't think 256 MiB vs. 512 MiB makes a big difference in consumption (test scheduled for next week).

 

Another note regarding 'DRAM reliability testing' using lima-memtester with 408 MHz DRAM clockspeed without a fan:

 

This is one NEO/512 wearing FA's heatsink completely powering off after 2:20 min of test duration (board even cooled down):

 

 

root@orangepione:~# ./lima-memtester 100M
This is a simple textured cube demo from the lima driver and
a memtester. Both combined in a single program. The mali400
hardware is only used to stress RAM in the background. But
this happens to significantly increase chances of exposing
memory stability related problems.

Kernel driver is version 14
Detected 1 Mali-400 GP Cores.
Detected 2 Mali-400 PP Cores.
FB: 1280x720@32bpp at 0x56200000 (0x00708000)
Using dual buffered direct rendering to FB.

memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 100MB (104857600 bytes)
got  100MB (104857600 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : testing  48

11:06:19:  240MHz  0.04   1%   1%   0%   0%   0%   0%   39°C
11:06:24: 1200MHz  0.04   1%   1%   0%   0%   0%   0%   41°C
11:06:29: 1200MHz  0.12   9%   4%   4%   0%   0%   0%   46°C
11:06:34: 1200MHz  0.19  35%   6%  28%   0%   0%   0%   47°C
11:06:39: 1200MHz  0.41  35%   6%  28%   0%   0%   0%   49°C
11:06:44: 1200MHz  0.46  35%   8%  27%   0%   0%   0%   48°C
11:06:49: 1200MHz  0.50  35%   8%  27%   0%   0%   0%   49°C
11:06:55: 1200MHz  0.54  35%   8%  27%   0%   0%   0%   49°C
11:07:00: 1200MHz  0.58  37%   7%  29%   0%   0%   0%   49°C
11:07:05: 1200MHz  0.61  35%   6%  28%   0%   0%   0%   50°C
11:07:10: 1200MHz  0.64  34%   5%  28%   0%   0%   0%   51°C
11:07:15: 1200MHz  0.77  34%   5%  28%   0%   0%   0%   52°C
11:07:20: 1200MHz  0.79  34%   5%  28%   0%   0%   0%   51°C
11:07:26: 1200MHz  0.81  34%   6%  28%   0%   0%   0%   51°C
11:07:31: 1200MHz  0.98  34%   6%  28%   0%   0%   0%   51°C
11:07:36: 1200MHz  1.22  35%   6%  28%   0%   0%   0%   52°C
11:07:41: 1200MHz  1.21  36%   7%  27%   0%   0%   1%   53°C
11:07:46: 1200MHz  1.19  36%   7%  27%   0%   0%   1%   53°C
11:07:52: 1200MHz  1.17  36%   7%  27%   0%   0%   1%   53°C
11:07:57: 1200MHz  1.32  35%   7%  27%   0%   0%   0%   54°C
11:08:02: 1200MHz  1.29  35%   7%  27%   0%   0%   0%   54°C
11:08:07: 1200MHz  1.27  34%   6%  27%   0%   0%   0%   54°C
11:08:12: 1200MHz  1.25  35%   6%  28%   0%   0%   0%   54°C
11:08:17: 1200MHz  1.23  35%   6%  28%   0%   0%   0%   55°C
11:08:23: 1200MHz  1.29  35%   6%  28%   0%   0%   0%   55°C
11:08:28: 1200MHz  1.27  35%   6%  28%   0%   0%   0%   55°C
11:08:33: 1200MHz  1.25  35%   6%  28%   0%   0%   0%   55°C
11:08:38: 1200MHz  1.23  34%   6%  28%   0%   0%   0%   56°C
11:08:43: 1200MHz  1.21  35%   6%  28%   0%   0%   0%   56°C 

 

 

 

And this is the other NEO/512 without heatsink, freezing after 25 seconds running lima-memtester (led remained on, H3 SoC pretty warm, but OS frozen, no ping, nada):

 

 

root@orangepione:~# ./lima-memtester 100M
This is a simple textured cube demo from the lima driver and
a memtester. Both combined in a single program. The mali400
hardware is only used to stress RAM in the background. But
this happens to significantly increase chances of exposing
memory stability related problems.

Kernel driver is version 14
Detected 1 Mali-400 GP Cores.
Detected 2 Mali-400 PP Cores.
FB: 1280x720@32bpp at 0x56200000 (0x00708000)
Using dual buffered direct rendering to FB.

memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 100MB (104857600 bytes)
got  100MB (104857600 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : ok         
  Random Value        : \
  
11:16:32:  240MHz  0.18   1%   0%   0%   0%   0%   0%   47°C
11:16:37: 1200MHz  0.25   6%   2%   3%   0%   0%   0%   57°C
11:16:42: 1200MHz  0.31  36%   7%  27%   0%   0%   1%   61°C
11:16:48: 1200MHz  0.36  36%   7%  27%   0%   0%   1%   64°C
11:16:53: 1008MHz  0.41  38%   8%  28%   0%   0%   0%   66°C 

 

 

 

So lets better prevent running any heavy workloads on these boards. They might shine in  IoT projects but that's it.

Link to comment
Share on other sites

- how to be sure of the quality ot the thermal interface between the heatsink with the dram (in the old times of AMD Duron, it was a sure way to burn the proc) ?

- are you sure that some critical xfer are not cabritated by the kernel before the dram speed is changed (increased or lowered) ?

Link to comment
Share on other sites

IMO it's obvious that the largest savings can be made by using 408 MHz since both 408-432 and 432-456 show best results when it's about reducing consumption and heat (tests made with a NanoPi NEO/512 w/o heatsink):

 

Bildschirmfoto%202016-08-12%20um%2007.51

 

(please forget about the small fluctuations eg. at 17:30 and 22:30, this measuring approach can not be considered save when it's about changes below 20mW).

 

When comparing with an OPi Lite the same happens between 408 and 456 MHz but OPi Lite is faster (dual bank configuration?) and consumes less (no idea). I started the same measurement round at night with OPi Lite but this time using WiFi since my script tries to get actual consumption numbers from my 'monitoring PSU'

 

Well, doing this test with enabled WiFi resulted in broken numbers (to be expected) since WiFi related random consumption fluctuations were way higher than the stuff I wanted to measure. Therefore I repeated the test without network. Graph below. OPi Lite idles at 510 mW and consumption increases up to 795 mW at 624 MHz (I didn't tested through 648/672 MHz since we won't use these clockspeeds anyway). Consumption increase when switching from 408 MHz to 432 MHz: a whopping 130 mW (630mW vs. 760mW)

 

Bildschirmfoto%202016-08-13%20um%2000.12

 

As a reference the timestamps and temperature reported (OPi Lite wearing a heatsink and therefore not showing 10°C difference but just 5°C):

 

 

Fri Aug 12 11:47:40 CEST 2016   132000  no network      23      0.00 0.01 0.05 1/61 953
Fri Aug 12 12:17:42 CEST 2016   144000  no network      24      0.00 0.01 0.05 1/61 966
Fri Aug 12 12:32:45 CEST 2016   156000  no network      24      0.00 0.01 0.05 1/61 982
Fri Aug 12 12:47:47 CEST 2016   168000  no network      23      0.00 0.01 0.05 1/61 995
Fri Aug 12 13:02:49 CEST 2016   180000  no network      23      0.00 0.01 0.05 1/61 1021
Fri Aug 12 13:17:51 CEST 2016   192000  no network      24      0.00 0.01 0.05 1/61 1034
Fri Aug 12 13:32:53 CEST 2016   204000  no network      25      0.00 0.01 0.05 1/61 1050
Fri Aug 12 13:47:55 CEST 2016   216000  no network      24      0.00 0.01 0.05 1/61 1063
Fri Aug 12 14:02:58 CEST 2016   228000  no network      24      0.00 0.01 0.05 1/61 1089
Fri Aug 12 14:18:00 CEST 2016   240000  no network      24      0.00 0.01 0.05 1/61 1102
Fri Aug 12 14:33:02 CEST 2016   252000  no network      23      0.00 0.01 0.05 1/61 1118
Fri Aug 12 14:48:04 CEST 2016   264000  no network      25      0.00 0.01 0.05 1/61 1131
Fri Aug 12 15:03:06 CEST 2016   276000  no network      25      0.00 0.01 0.05 1/61 1157
Fri Aug 12 15:18:08 CEST 2016   288000  no network      25      0.00 0.01 0.05 1/61 1170
Fri Aug 12 15:33:10 CEST 2016   300000  no network      25      0.00 0.01 0.05 1/61 1186
Fri Aug 12 15:48:13 CEST 2016   312000  no network      24      0.00 0.01 0.05 1/61 1199
Fri Aug 12 16:03:15 CEST 2016   324000  no network      26      0.00 0.01 0.05 1/61 1225
Fri Aug 12 16:18:17 CEST 2016   336000  no network      24      0.00 0.01 0.05 1/61 1238
Fri Aug 12 16:33:19 CEST 2016   348000  no network      26      0.00 0.01 0.05 1/61 1254
Fri Aug 12 16:48:21 CEST 2016   360000  no network      26      0.00 0.01 0.05 1/61 1267
Fri Aug 12 17:03:23 CEST 2016   372000  no network      27      0.00 0.01 0.05 1/61 1293
Fri Aug 12 17:18:25 CEST 2016   384000  no network      26      0.00 0.01 0.05 1/61 1306
Fri Aug 12 17:33:28 CEST 2016   408000  no network      25      0.00 0.01 0.05 1/61 1325
Fri Aug 12 18:03:30 CEST 2016   432000  no network      28      0.00 0.01 0.05 1/61 1354
Fri Aug 12 18:33:32 CEST 2016   456000  no network      27      0.00 0.01 0.05 1/61 1373
Fri Aug 12 19:03:34 CEST 2016   480000  no network      28      0.00 0.01 0.05 1/61 1402
Fri Aug 12 19:33:36 CEST 2016   504000  no network      28      0.00 0.01 0.05 1/61 1421
Fri Aug 12 20:03:38 CEST 2016   528000  no network      29      0.00 0.01 0.05 1/61 1450
Fri Aug 12 20:33:40 CEST 2016   552000  no network      28      0.00 0.01 0.05 1/61 1469
Fri Aug 12 21:03:43 CEST 2016   576000  no network      29      0.00 0.01 0.05 1/61 1498
Fri Aug 12 21:33:45 CEST 2016   600000  no network      28      0.00 0.01 0.05 1/61 1517
Fri Aug 12 22:03:47 CEST 2016   624000  no network      28      0.00 0.01 0.05 1/61 1546 

 

 

 

- how to be sure of the quality ot the thermal interface between the heatsink with the dram (in the old times of AMD Duron, it was a sure way to burn the proc) ?

- are you sure that some critical xfer are not cabritated by the kernel before the dram speed is changed (increased or lowered) ?

 

Sorry, I don't get either question?

Link to comment
Share on other sites

Jessie image with new settings. Annoying delay while running firstrun due to strange USB errors:

 

 

U-Boot SPL 2016.07-armbian (Aug 13 2016 - 10:16:41)
DRAM: 512 MiB
Trying to boot from MMC1


U-Boot 2016.07-armbian (Aug 13 2016 - 10:16:41 +0200) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
No controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2599 bytes read in 182 ms (13.7 KiB/s)
## Executing script at 43100000
gpio: pin PL10 (gpio 298) value is 1
   Warning: value of pin is still 0
gpio: pin PG11 (gpio 203) value is 1
0 bytes read in 131 ms (0 Bytes/s)
** File not found /boot/.next **
** Unrecognized filesystem type **
** File not found .next **
35556 bytes read in 396 ms (86.9 KiB/s)
2873682 bytes read in 371 ms (7.4 MiB/s)
5005160 bytes read in 558 ms (8.6 MiB/s)
Kernel image @ 0x42000000 [ 0x000000 - 0x4c5f68 ]
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2873618 Bytes = 2.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
Using machid 0x1029 from environment

Starting kernel ...

[sun8i_fixup]: From boot, get meminfo:
        Start:  0x40000000
        Size:   512MB
ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1
ion_reserve_select: ion chipid  [0x2004620!
ion_reserve_common: ion reserve: [0x56000000, 0x60000000]!
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.4.112-sun8i (root@armbian) (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #20 SMP PREEMPT Sat Aug 13 10:20:59 CEST 2016
[    0.000000] cma: CMA: reserved 160 MiB at 56000000
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0fe1000 s11968 r8192 d12608 u32768
[    0.000000] Kernel command line: console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_re
serve=16 panic=10 consoleblank=0 enforcing=0 loglevel=7
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] allocated 1048576 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Memory: 512MB = 512MB total
[    0.000000] Memory: 339248k/339248k available, 185040k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc094fed4   (9504 kB)
[    0.000000]       .init : 0xc0950000 - 0xc09a1ec0   ( 328 kB)
[    0.000000]       .data : 0xc09a2000 - 0xc0a1b5d0   ( 486 kB)
[    0.000000]        .bss : 0xc0a1bd84 - 0xc0b4e9d0   (1228 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:544
[    0.000000] Architected local timer running at 24.00MHz.
[    0.000000] Switching to timer-based delay loop
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] console [tty1] enabled
[    0.002157] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.00 BogoMIPS (lpj=24000000)
[    0.002295] pid_max: default: 32768 minimum: 301
[    0.003013] Mount-cache hash table entries: 512
[    0.004980] Initializing cgroup subsys cpuacct
[    0.005057] Initializing cgroup subsys memory
[    0.005187] Initializing cgroup subsys devices
[    0.005251] Initializing cgroup subsys freezer
[    0.005311] Initializing cgroup subsys blkio
[    0.005397] Initializing cgroup subsys perf_event
[    0.005605] CPU: Testing write buffer coherency: ok
[    0.005750] ftrace: allocating 25569 entries in 75 pages
[    0.060526] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.060610] [sunxi_smp_prepare_cpus] enter
[    0.060705] Setting up static identity map for 0x40688fb8 - 0x40689010
[    0.062579] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.070514] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.070909] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.080339] Brought up 4 CPUs
[    0.080496] SMP: Total of 4 processors activated (19200.00 BogoMIPS).
[    0.081925] devtmpfs: initialized
[    0.095950] wakeup src cnt is : 2. 
[    0.096140] sunxi pm init
[    0.096432] pinctrl core: initialized pinctrl subsystem
[    0.109166] NET: Registered protocol family 16
[    0.113043] DMA: preallocated 2048 KiB pool for atomic coherent allocations
[    0.113230] script_sysfs_init success
[    0.115088] gpiochip_add: registered GPIOs 0 to 383 on device: sunxi-pinctrl
[    0.117528] sunxi-pinctrl sunxi-pinctrl: initialized sunXi PIO driver
[    0.117528] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.117528] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.117528] script config pll_video to 297 Mhz
[    0.117528] script config pll_de to 864 Mhz
[    0.117528] script config pll_ve to 402 Mhz
[    0.130471] bio: create slab <bio-0> at 0
[    0.130657] [ARISC] :sunxi-arisc driver v1.04
[    0.148218] [ARISC] :arisc version: [v0.1.58]
[    0.255114] [ARISC] :sunxi-arisc driver v1.04 startup succeeded
[    0.260893] SCSI subsystem initialized
[    0.261329] usbcore: registered new interface driver usbfs
[    0.261329] usbcore: registered new interface driver hub
[    0.261329] usbcore: registered new device driver usb
[    0.261329] twi_chan_cfg()340 - [twi0] has no twi_regulator.
[    0.261329] twi_chan_cfg()340 - [twi1] has no twi_regulator.
[    0.261329] twi_chan_cfg()340 - [twi2] has no twi_regulator.
[    0.262165] Linux video capture interface: v2.00
[    0.262642] Advanced Linux Sound Architecture Driver Version 1.0.25.
[    0.264138] cfg80211: Calling CRDA to update world regulatory domain
[    0.271018] Switching to clocksource arch_sys_counter
[    0.297973] FS-Cache: Loaded
[    0.298566] CacheFiles: Loaded
[    0.321251] NET: Registered protocol family 2
[    0.344812] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.345947] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    0.346510] TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
[    0.347125] TCP: Hash tables configured (established 16384 bind 16384)
[    0.347180] TCP: reno registered
[    0.347226] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.347309] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.348008] NET: Registered protocol family 1
[    0.348773] RPC: Registered named UNIX socket transport module.
[    0.348834] RPC: Registered udp transport module.
[    0.348878] RPC: Registered tcp transport module.
[    0.348922] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.349315] Trying to unpack rootfs image as initramfs...
[    0.703428] Freeing initrd memory: 2804K
[    0.704536] hw perfevents: enabled with ARMv7 Cortex_A7 PMU driver, 5 counters available
[    0.704834] sunxi_reg_init enter
[    0.706600] audit: initializing netlink socket (disabled)
[    0.706723] type=2000 audit(0.700:1): initialized
[    0.710509] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.712372] NFS: Registering the id_resolver key type
[    0.713163] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.713230] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    0.714762] NTFS driver 2.1.30 [Flags: R/W].
[    0.715403] fuse init (API version 7.18)
[    0.716975] Btrfs loaded
[    0.717041] msgmni has been set to 988
[    0.719918] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.720076] io scheduler noop registered
[    0.720122] io scheduler deadline registered
[    0.720318] io scheduler cfq registered (default)
[    0.721173] [DISP]disp_module_init
[    0.721811] cmdline,init_disp=
[    0.721893] cmdline,disp=
[    0.723102] [DISP]disp_module_init finish
[    0.723545] sw_uart_get_devinfo()1503 - uart0 has no uart_regulator.
[    0.723615] sw_uart_get_devinfo()1503 - uart1 has no uart_regulator.
[    0.723677] sw_uart_get_devinfo()1503 - uart2 has no uart_regulator.
[    0.723739] sw_uart_get_devinfo()1503 - uart3 has no uart_regulator.
[    0.724803] uart0: ttyS0 at MMIO 0x1c28000 (irq = 32) is a SUNXI
[    0.724867] sw_uart_pm()890 - uart0 clk is already enable
[    0.724932] sw_console_setup()1233 - console setup baud 115200 parity n bits 8, flow n
[    0.837789] console [ttyS0] enabled
[    1.033282] uart1: ttyS1 at MMIO 0x1c28400 (irq = 33) is a SUNXI
[    1.151350] uart2: ttyS2 at MMIO 0x1c28800 (irq = 34) is a SUNXI
[    1.325275] uart3: ttyS3 at MMIO 0x1c28c00 (irq = 35) is a SUNXI
[    1.528559] brd: module loaded
[    1.540113] loop: module loaded
[    1.544158] sunxi_spi_chan_cfg()1376 - [spi-0] has no spi_regulator.
[    1.551394] sunxi_spi_chan_cfg()1376 - [spi-1] has no spi_regulator.
[    1.559647] spi spi0: master is unqueued, this is deprecated
[    1.566711] tun: Universal TUN/TAP device driver, 1.6
[    1.572464] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.581322] PPP generic driver version 2.4.2
[    1.586560] PPP BSD Compression module registered
[    1.591937] PPP Deflate Compression module registered
[    1.602568] PPP MPPE Compression module registered
[    1.608018] NET: Registered protocol family 24
[    1.613206] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.640798] sunxi-ehci sunxi-ehci.1: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.649902] sunxi-ehci sunxi-ehci.1: new USB bus registered, assigned bus number 1
[    1.660583] sunxi-ehci sunxi-ehci.1: irq 104, io mem 0xf1c1a000
[    1.680071] sunxi-ehci sunxi-ehci.1: USB 0.0 started, EHCI 1.00
[    1.688106] hub 1-0:1.0: USB hub found
[    1.692436] hub 1-0:1.0: 1 port detected
[    1.717726] sunxi-ehci sunxi-ehci.4: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.726856] sunxi-ehci sunxi-ehci.4: new USB bus registered, assigned bus number 2
[    1.736274] sunxi-ehci sunxi-ehci.4: irq 110, io mem 0xf1c1d000
[    1.760088] sunxi-ehci sunxi-ehci.4: USB 0.0 started, EHCI 1.00
[    1.767893] hub 2-0:1.0: USB hub found
[    1.772213] hub 2-0:1.0: 1 port detected
[    1.777390] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.804540] sunxi-ohci sunxi-ohci.1: SW USB2.0 'Open' Host Controller (OHCI) Driver
[    1.813273] sunxi-ohci sunxi-ohci.1: new USB bus registered, assigned bus number 3
[    1.821920] sunxi-ohci sunxi-ohci.1: irq 105, io mem 0xf1c1a400
[    1.885041] hub 3-0:1.0: USB hub found
[    1.889314] hub 3-0:1.0: 1 port detected
[    1.914581] sunxi-ohci sunxi-ohci.4: SW USB2.0 'Open' Host Controller (OHCI) Driver
[    1.923322] sunxi-ohci sunxi-ohci.4: new USB bus registered, assigned bus number 4
[    1.931963] sunxi-ohci sunxi-ohci.4: irq 111, io mem 0xf1c1d400
[    1.995111] hub 4-0:1.0: USB hub found
[    1.999422] hub 4-0:1.0: 1 port detected
[    2.004711] Initializing USB Mass Storage driver...
[    2.010625] usbcore: registered new interface driver usb-storage
[    2.017454] USB Mass Storage support registered.
[    2.022835] usbcore: registered new interface driver ums-alauda
[    2.029653] usbcore: registered new interface driver ums-cypress
[    2.036593] usbcore: registered new interface driver ums-datafab
[    2.043818] usbcore: registered new interface driver ums_eneub6250
[    2.050940] usbcore: registered new interface driver ums-freecom
[    2.057844] usbcore: registered new interface driver ums-isd200
[    2.064686] usbcore: registered new interface driver ums-jumpshot
[    2.071731] usbcore: registered new interface driver ums-karma
[    2.078465] usbcore: registered new interface driver ums-onetouch
[    2.085547] usbcore: registered new interface driver ums-realtek
[    2.092461] usbcore: registered new interface driver ums-sddr09
[    2.099268] usbcore: registered new interface driver ums-sddr55
[    2.106178] usbcore: registered new interface driver ums-usbat
[    2.114573] mousedev: PS/2 mouse device common for all mice
[    2.121389] sunxikbd_init failed. 
[    2.125308] ls_fetch_sysconfig_para: ls_unused. 
[    2.131207] [RTC] WARNING: Rtc time will be wrong!!
[    2.136765] [RTC] WARNING: use *internal OSC* as clock source
[    2.143881] sunxi-rtc sunxi-rtc: rtc core: registered sunxi-rtc as rtc0
[    2.151513] i2c /dev entries driver
[    2.156615] IR RC5(x) protocol handler initialized
[    2.163203] twi_start()434 - [i2c0] START can't sendout!
[    2.169524] twi_start()434 - [i2c0] START can't sendout!
[    2.175867] twi_start()434 - [i2c0] START can't sendout!
[    2.182215] twi_start()434 - [i2c0] START can't sendout!
[    2.188521] twi_start()434 - [i2c0] START can't sendout!
[    2.194858] twi_start()434 - [i2c0] START can't sendout!
[    2.201200] twi_start()434 - [i2c0] START can't sendout!
[    2.207504] twi_start()434 - [i2c0] START can't sendout!
[    2.213814] twi_start()434 - [i2c0] START can't sendout!
[    2.220127] twi_start()434 - [i2c0] START can't sendout!
[    2.226433] twi_start()434 - [i2c0] START can't sendout!
[    2.232786] twi_start()434 - [i2c0] START can't sendout!
[    2.239098] twi_start()434 - [i2c0] START can't sendout!
[    2.245436] twi_start()434 - [i2c0] START can't sendout!
[    2.251747] twi_start()434 - [i2c0] START can't sendout!
[    2.258058] twi_start()434 - [i2c0] START can't sendout!
[    2.264395] twi_start()434 - [i2c0] START can't sendout!
[    2.270732] twi_start()434 - [i2c0] START can't sendout!
[    2.277042] twi_start()434 - [i2c0] START can't sendout!
[    2.283380] twi_start()434 - [i2c0] START can't sendout!
[    2.289684] twi_start()434 - [i2c0] START can't sendout!
[    2.296021] twi_start()434 - [i2c0] START can't sendout!
[    2.302359] twi_start()434 - [i2c0] START can't sendout!
[    2.308663] twi_start()434 - [i2c0] START can't sendout!
[    2.315005] twi_start()434 - [i2c0] START can't sendout!
[    2.321343] twi_start()434 - [i2c0] START can't sendout!
[    2.327648] twi_start()434 - [i2c0] START can't sendout!
[    2.333967] twi_start()434 - [i2c1] START can't sendout!
[    2.340274] twi_start()434 - [i2c1] START can't sendout!
[    2.346581] twi_start()434 - [i2c1] START can't sendout!
[    2.352923] twi_start()434 - [i2c1] START can't sendout!
[    2.359228] twi_start()434 - [i2c1] START can't sendout!
[    2.365567] twi_start()434 - [i2c1] START can't sendout!
[    2.371888] twi_start()434 - [i2c1] START can't sendout!
[    2.378194] twi_start()434 - [i2c1] START can't sendout!
[    2.384532] twi_start()434 - [i2c1] START can't sendout!
[    2.390877] twi_start()434 - [i2c1] START can't sendout!
[    2.397182] twi_start()434 - [i2c1] START can't sendout!
[    2.403520] twi_start()434 - [i2c1] START can't sendout!
[    2.409831] twi_start()434 - [i2c1] START can't sendout!
[    2.416163] twi_start()434 - [i2c1] START can't sendout!
[    2.422501] twi_start()434 - [i2c1] START can't sendout!
[    2.428811] twi_start()434 - [i2c1] START can't sendout!
[    2.435150] twi_start()434 - [i2c1] START can't sendout!
[    2.441488] twi_start()434 - [i2c1] START can't sendout!
[    2.447798] twi_start()434 - [i2c1] START can't sendout!
[    2.454130] twi_start()434 - [i2c1] START can't sendout!
[    2.460468] twi_start()434 - [i2c1] START can't sendout!
[    2.466779] twi_start()434 - [i2c1] START can't sendout!
[    2.473117] twi_start()434 - [i2c1] START can't sendout!
[    2.479421] twi_start()434 - [i2c1] START can't sendout!
[    2.485764] twi_start()434 - [i2c1] START can't sendout!
[    2.492091] twi_start()434 - [i2c1] START can't sendout!
[    2.498425] twi_start()434 - [i2c1] START can't sendout!
[    2.504775] twi_start()434 - [i2c2] START can't sendout!
[    2.511122] twi_start()434 - [i2c2] START can't sendout!
[    2.517428] twi_start()434 - [i2c2] START can't sendout!
[    2.523771] twi_start()434 - [i2c2] START can't sendout!
[    2.530105] twi_start()434 - [i2c2] START can't sendout!
[    2.536410] twi_start()434 - [i2c2] START can't sendout!
[    2.542753] twi_start()434 - [i2c2] START can't sendout!
[    2.549059] twi_start()434 - [i2c2] START can't sendout!
[    2.555397] twi_start()434 - [i2c2] START can't sendout!
[    2.561740] twi_start()434 - [i2c2] START can't sendout!
[    2.568046] twi_start()434 - [i2c2] START can't sendout!
[    2.574378] twi_start()434 - [i2c2] START can't sendout!
[    2.580721] twi_start()434 - [i2c2] START can't sendout!
[    2.587026] twi_start()434 - [i2c2] START can't sendout!
[    2.593365] twi_start()434 - [i2c2] START can't sendout!
[    2.599676] twi_start()434 - [i2c2] START can't sendout!
[    2.606015] twi_start()434 - [i2c2] START can't sendout!
[    2.612326] twi_start()434 - [i2c2] START can't sendout!
[    2.618638] twi_start()434 - [i2c2] START can't sendout!
[    2.624976] twi_start()434 - [i2c2] START can't sendout!
[    2.631314] twi_start()434 - [i2c2] START can't sendout!
[    2.637625] twi_start()434 - [i2c2] START can't sendout!
[    2.643968] twi_start()434 - [i2c2] START can't sendout!
[    2.650274] twi_start()434 - [i2c2] START can't sendout!
[    2.656586] twi_start()434 - [i2c2] START can't sendout!
[    2.662925] twi_start()434 - [i2c2] START can't sendout!
[    2.669230] twi_start()434 - [i2c2] START can't sendout!
[    2.675405] sunxi_wdt_init_module: sunxi WatchDog Timer Driver v1.0
[    2.682886] sunxi_wdt_probe: devm_ioremap return wdt_reg 0xf1c20ca0, res->start 0x01c20ca0, res->end 0x01c20cbfehci_irq: highspeed device connect
[    2.697998] sunxi_wdt_probe: initialized (g_timeout=16s, g_nowayout=0)
[    2.705466] wdt_enable, write reg 0xf1c20cb8 val 0x00000000
[    2.711835] timeout_to_interv, line 167
[    2.716203] interv_to_timeout, line 189
[    2.720608] wdt_set_tmout, write 0x000000b0 to mode reg 0xf1c20cb8, actual timeout 16 sec
[    2.730746] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
[    2.740585] [cpu_freq] ERR:get cpu extremity frequency from sysconfig failed, use max_freq
[    2.754017] no red_led, ignore it!
[    2.758685] no led_0, ignore it!
[    2.762385] no led_1, ignore it!
[    2.766074] no led_2, ignore it!
[    2.769755] no led_3, ignore it!
[    2.773440] no led_4, ignore it!
[    2.777130] no led_5, ignore it!
[    2.780843] no led_6, ignore it!
[    2.784524] no led_7, ignore it!
[    2.789714] usbcore: registered new interface driver usbhid
[    2.796148] usbhid: USB HID core driver
[    2.801867] [DAUDIO]sunxi-daudio cannot find any using configuration for controllers, return directly!
[    2.812467] [I2S]snddaudio cannot find any using configuration for controllers, return directly!
[    2.822306] [DAUDIO0] driver not init,just return.
[    2.832772] asoc: sndhdmi <-> sunxi-hdmiaudio.0 mapping ok
[    2.840128] oprofile: using arm/armv7-ca7
[    2.844844] u32 classifier
[    2.847858]     Performance counters on
[    2.852190]     input device check on
[    2.856291]     Actions configured
[    2.860301] IPv4 over IPv4 tunneling driver
[    2.865678] TCP: bic registered
[    2.869221] TCP: cubic registered
[    2.872944] TCP: westwood registered
[    2.876946] TCP: highspeed registered
[    2.881056] TCP: hybla registered
[    2.884764] TCP: htcp registered
[    2.888375] TCP: vegas registered
[    2.892085] TCP: veno registered
[    2.895700] TCP: scalable registered
[    2.899696] TCP: lp registered
[    2.899785] mmc0: new high speed SDHC card at address 0007
[    2.909344] TCP: yeah registered
[    2.909413] mmcblk0: mmc0:0007 SD16G 14.4 GiB 
[    2.917930] TCP: illinois registered
[    2.918075]  mmcblk0: p1
[    2.918635] mmcblk mmc0:0007: Card claimed for testing.
[    2.918646] mmc0:0007: SD16G 14.4 GiB 
[    2.918665] *******************sd init ok*******************
[    2.940964] Initializing XFRM netlink socket
[    2.946003] NET: Registered protocol family 10
[    2.952144] NET: Registered protocol family 17
[    2.957136] NET: Registered protocol family 15
[    2.962166] Registering the dns_resolver key type
[    2.967823] VFP support v0.3: ehci_irq: highspeed device disconnect
[    2.974852] ThumbEE CPU extension supported.
[    2.979627] Registering SWP/SWPB emulation handler
[    2.985556] registered taskstats version 1
[    2.990886] ths_fetch_sysconfig_para: type err  device_used = 1. 
[    2.998956] CPU Budget:corekeeper enabled
[    3.003854] CPU Budget:Register notifier
[    3.008222] CPU Budget:register Success
[    3.012525] sunxi-budget-cooling sunxi-budget-cooling: Cooling device registered: thermal-budget-0
[    3.025775] ALSA device list:
[    3.029085]   #0: sndhdmi
[    3.032750] Freeing init memory: 324K
[    3.078155] systemd-udevd[94]: starting version 215
[    4.290253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[    6.690217] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[    9.090296] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   11.490251] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   13.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   16.290205] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   18.690211] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   21.090253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   23.490246] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   25.890250] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   28.290203] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   30.690212] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   33.090254] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   35.490250] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   37.890249] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   40.290202] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   42.690213] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   45.090253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   47.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   49.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   52.290204] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   54.690209] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   57.090252] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   59.490248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   61.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   64.290232] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   66.690211] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   69.090253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   71.490248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   73.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   76.290209] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   78.690214] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   81.090254] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   83.490248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   85.890246] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   88.290218] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   90.690212] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   93.090257] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   95.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[   97.890249] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  100.290226] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  102.690211] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  105.090256] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  107.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  109.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  112.290220] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  114.690211] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  117.090255] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  119.490248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  121.890250] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  124.290221] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  126.690213] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  129.090256] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  131.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  133.890247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  136.290213] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  138.690212] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  141.090255] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  143.490249] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  145.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  148.290245] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  150.690210] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  153.090255] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  155.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  157.890246] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  160.290212] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  162.690215] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  165.090254] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  167.490240] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  169.890245] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  172.290212] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  174.690210] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  177.090256] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  179.490247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  181.890246] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  184.290077] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  186.690253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  189.090288] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  189.782741] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[  191.490253] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  193.890248] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  196.290247] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  198.690245] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  199.921037] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[  199.937379] systemd[1]: Detected architecture 'arm'.
[  199.960751] systemd[1]: Set hostname to <nanopineo>.
[  200.302736] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[  200.321787] systemd[1]: Expecting device dev-ttyS0.device...
[  200.328761] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[  200.337535] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[  200.346059] systemd[1]: Starting Remote File Systems (Pre).
[  200.352549] systemd[1]: Reached target Remote File Systems (Pre).
[  200.359401] systemd[1]: Starting Encrypted Volumes.
[  200.365057] systemd[1]: Reached target Encrypted Volumes.
[  200.371190] systemd[1]: Starting Arbitrary Executable File Formats File System Automount Point.
[  200.381605] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[  200.392189] systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
[  200.401304] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[  200.410173] systemd[1]: Starting Paths.
[  200.414669] systemd[1]: Reached target Paths.
[  200.419557] systemd[1]: Starting Swap.
[  200.423946] systemd[1]: Reached target Swap.
[  200.428742] systemd[1]: Starting Root Slice.
[  200.433801] systemd[1]: Created slice Root Slice.
[  200.439076] systemd[1]: Starting User and Session Slice.
[  200.445336] systemd[1]: Created slice User and Session Slice.
[  200.451788] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[  200.459545] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[  200.467356] systemd[1]: Starting Delayed Shutdown Socket.
[  200.473679] systemd[1]: Listening on Delayed Shutdown Socket.
[  200.480139] systemd[1]: Starting Journal Socket (/dev/log).
[  200.486644] systemd[1]: Listening on Journal Socket (/dev/log).
[  200.493331] systemd[1]: Starting udev Control Socket.
[  200.499223] systemd[1]: Listening on udev Control Socket.
[  200.505308] systemd[1]: Starting udev Kernel Socket.
[  200.511105] systemd[1]: Listening on udev Kernel Socket.
[  200.517086] systemd[1]: Starting Journal Socket.
[  200.522551] systemd[1]: Listening on Journal Socket.
[  200.528188] systemd[1]: Starting System Slice.
[  200.533506] systemd[1]: Created slice System Slice.
[  200.539026] systemd[1]: Starting File System Check on Root Device...
[  200.622135] systemd[1]: Starting system-getty.slice.
[  200.630146] systemd[1]: Created slice system-getty.slice.
[  200.636763] systemd[1]: Starting system-serial\x2dgetty.slice.
[  200.645924] systemd[1]: Created slice system-serial\x2dgetty.slice.
[  200.653920] systemd[1]: Starting Increase datagram queue length...
[  200.722422] systemd[1]: Starting Restore / save the current clock...
[  201.100047] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  201.172761] systemd[1]: Started Set Up Additional Binary Formats.
[  201.180259] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[  201.270931] systemd[1]: Mounting POSIX Message Queue File System...
[  201.320774] systemd[1]: Mounting Debug File System...
[  201.383784] systemd[1]: Starting Load Kernel Modules...
[  201.451811] systemd[1]: Starting udev Coldplug all Devices...
[  201.540954] systemd[1]: Mounted Huge Pages File System.
[  201.546938] systemd[1]: Starting LSB: Set keymap...
[  201.640707] systemd[1]: Starting Slices.
[  201.645659] systemd[1]: Reached target Slices.
[  201.653162] systemd[1]: Mounted Debug File System.
[  201.658886] systemd[1]: Mounted POSIX Message Queue File System.
[  201.760410] systemd[1]: Started File System Check on Root Device.
[  201.810468] systemd[1]: Started Increase datagram queue length.
[  201.861380] systemd[1]: Started Restore / save the current clock.
[  201.961312] systemd[1]: Started Create list of required static device nodes for the current kernel.
[  202.041496] systemd[1]: Started Load Kernel Modules.
[  202.250739] systemd[1]: Started LSB: Set keymap.
[  202.300599] systemd[1]: Started udev Coldplug all Devices.
[  202.311206] systemd[1]: Time has been changed
[  202.316759] systemd[1]: Mounted Configuration File System.
[  202.323035] systemd[1]: Mounting FUSE Control File System...
[  202.430585] systemd[1]: Starting Apply Kernel Variables...
[  202.491156] systemd[1]: Starting Create Static Device Nodes in /dev...
[  202.630911] systemd[1]: Starting Syslog Socket.
[  202.636687] systemd[1]: Listening on Syslog Socket.
[  202.642433] systemd[1]: Starting Journal Service...
[  202.751450] systemd[1]: Started Journal Service.
[  203.025770] systemd-udevd[177]: starting version 215
[  203.510099] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  205.910082] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  208.130331] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
[  208.330118] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  209.358075] systemd-journald[176]: Received request to flush runtime journal from PID 1
[  209.648287] gmac0: probed
[  209.651655] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)
[  210.730108] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  213.130095] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  213.650251] PHY: gmac0-0:00 - Link is Up - 100/Full
[  215.051878] Registered IR keymap rc-empty
[  215.057243] rc0: sunxi-ir as /devices/virtual/rc/rc0
[  215.064318] rc rc0: lirc_dev: driver ir-lirc-codec (sunxi-ir) registered at minor = 0
[  215.530186] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  217.930242] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  220.330219] hub 1-0:1.0: connect-debounce failed, port 1 disabled

Debian GNU/Linux 8 nanopineo ttyS0

nanopineo login: [  222.730283] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  225.130237] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  227.530310] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  229.940070] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  232.340067] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  234.740078] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  237.140071] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  239.540080] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  241.940085] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  244.340118] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  246.740151] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  249.140077] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  251.540189] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  253.940171] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  256.340141] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  256.916837] Adding 131068k swap on /var/swap.  Priority:-1 extents:2 across:163836k SS
[  258.740064] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  261.150119] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  263.550059] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  265.950165] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  268.360232] hub 1-0:1.0: connect-debounce failed, port 1 disabled
[  268.850663] wdt_set_tmout, write 0x00000080 to mode reg 0xf1c20cb8, actual timeout 10 sec
[  268.860251] wdt_enable, write reg 0xf1c20cb8 val 0x00000081
[  268.866917] sunxi_wdt_ioctl err, line 420
[  268.871996] sunxi_wdt_release: unexpected close, not stopping watchdog!
[  268.920247] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[  268.963455] systemd-journald[176]: Received SIGTERM from PID 1 (systemd-shutdow).
[  269.336469] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[  269.398921] wdt_set_tmout, write 0x00000071 to mode reg 0xf1c20cb8, actual timeout 8 sec
[  269.408319] wdt_enable, write reg 0xf1c20cb8 val 0x00000071
[  269.414874] systemd-shutdown[1]: Hardware watchdog 'sunxi_wdt', version 0
[  269.800627] systemd-shutdown[1]: Unmounting file systems.
[  269.809450] systemd-shutdown[1]: Unmounting /tmp.
[  269.870402] systemd-shutdown[1]: Unmounting /sys/fs/fuse/connections.
[  269.930382] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
[  269.937338] systemd-shutdown[1]: Unmounting /dev/mqueue.
[  270.004299] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[  270.019495] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[  270.025618] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[  270.031729] systemd-shutdown[1]: All filesystems unmounted.
[  270.037955] systemd-shutdown[1]: Deactivating swaps.
[  270.043916] systemd-shutdown[1]: All swaps deactivated.
[  270.049754] systemd-shutdown[1]: Detaching loop devices.
[  270.059905] systemd-shutdown[1]: All loop devices detached.
[  270.066172] systemd-shutdown[1]: Detaching DM devices.
[  270.072283] systemd-shutdown[1]: All DM devices detached.
[  270.089240] systemd-shutdown[1]: Rebooting.
[  270.095030] IRQ110 no longer affine to CPU1
[  270.100329] CPU1: shutdown
[  270.103388] [hotplug]: cpu(3) try to kill cpu(1)
[  270.108579] [hotplug]: cpu1 is killed! .
[  270.115486] IRQ105 no longer affine to CPU2
[  270.120819] CPU2: shutdown
[  270.123860] [hotplug]: cpu(3) try to kill cpu(2)
[  270.129051] [hotplug]: cpu2 is killed! .
[  270.136403] CPU3: shutdown
[  270.139602] [hotplug]: cpu(0) try to kill cpu(3)
[  270.144919] [hotplug]: cpu3 is killed! .
[  270.151335] wdt_enable, write reg 0xf1c20cb8 val 0x00000070
[  270.198614] Restarting system.
[  270.202182] Restarting Linux version 3.4.112-sun8i (root@armbian) (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #20 SMP PREEMPT Sat Aug 13 10:20:59 CEST 2016
[  270.202195] 

U-Boot SPL 2016.07-armbian (Aug 13 2016 - 10:16:41)
DRAM: 512 MiB
Trying to boot from MMC1


U-Boot 2016.07-armbian (Aug 13 2016 - 10:16:41 +0200) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
No controllers found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2599 bytes read in 171 ms (14.6 KiB/s)
## Executing script at 43100000
gpio: pin PL10 (gpio 298) value is 1
   Warning: value of pin is still 0
gpio: pin PG11 (gpio 203) value is 1
** File not found /boot/.verbose **
** File not found /boot/.next **
** Unrecognized filesystem type **
** File not found .next **
35556 bytes read in 395 ms (87.9 KiB/s)
2873682 bytes read in 361 ms (7.6 MiB/s)
5005160 bytes read in 550 ms (8.7 MiB/s)
Kernel image @ 0x42000000 [ 0x000000 - 0x4c5f68 ]
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2873618 Bytes = 2.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
Using machid 0x1029 from environment

Starting kernel ...

[sun8i_fixup]: From boot, get meminfo:
        Start:  0x40000000
        Size:   512MB
ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1
ion_reserve_select: ion chipid  [0x2004620!
ion_reserve_common: ion reserve: [0x56000000, 0x60000000]!

Debian GNU/Linux 8 nanopineo ttyS0

nanopineo login: root
Password: 
You are required to change your password immediately (root enforced)
Changing password for root.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
Linux nanopineo 3.4.112-sun8i #20 SMP PREEMPT Sat Aug 13 10:20:59 CEST 2016 armv7l
 _   _                   ____  _   _   _            
| \ | | __ _ _ __   ___ |  _ \(_) | \ | | ___  ___  
|  \| |/ _` | '_ \ / _ \| |_) | | |  \| |/ _ \/ _ \ 
| |\  | (_| | | | | (_) |  __/| | | |\  |  __/ (_) |
|_| \_|\__,_|_| |_|\___/|_|   |_| |_| \_|\___|\___/ 
                                                    

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-sun8i 
System load:   2.41             Up time:       1 min
Memory usage:  7 % of 494Mb     IP:            192.168.83.106 
CPU temp:      46?°C           
Usage of /:    8% of 15G    


New to Armbian? Check the Armbian H3 Mini FAQ first:
 https://github.com/igorpecovnik/lib/blob/master/documentation/H3_mini_faq.md 

Thank you for choosing Armbian! Support: www.armbian.com

Creating new account. Please provide a username (eg. your forename): tk
Adding user `tk' ...
Adding new group `tk' (1000) ...
Adding new user `tk' (1000) with group `tk' ...
Creating home directory `/home/tk' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for tk
Enter the new value, or press ENTER for the default
        Full Name []: Thomas Kaiser
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []: 
Is the information correct? [Y/n] 

Dear Thomas Kaiser, your account tk has been created and is sudo enabled.
Please use this account for your daily work from now on.


Your display settings are currently 720p (1280x720). To change this use the
h3disp utility. Do you want to change display settings now? [nY] nroot@nanopineo:~# armbianmonitor -u
/var/log/armhwinfo.log has been uploaded to http://sprunge.us/IbGC
Please post the URL in the Armbian forum where you've been asked for.
root@nanopineo:~# cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-sunxi
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.00 ms.
  hardware limits: 240 MHz - 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance
  current policy: frequency should be within 240 MHz and 912 MHz.
                  The governor "interactive" may decide which speed to use
                  within this range.
  current CPU frequency is 240 MHz (asserted by call to hardware).
  cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:64.44%, 312 MHz:0.06%, 408 MHz:0.04%, 480 MHz:0.07%, 504 MHz:0.00%, 528 MHz:0.11%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:0.00%, 648 MHz:0.00%, 672 MHz:0.00%, 720 MHz:0.01%, 768 MHz:0
.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:18.45%, 960 MHz:0.00%, 1.01 GHz:3.28%, 1.06 GHz:0.18%, 1.10 GHz:0.34%, 1.15 GHz:0.73%, 1.20 GHz:12.29%, 1.25 GHz:0.00%, 1.30 GHz:0.00%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00%  (96)
analyzing CPU 1:
  driver: cpufreq-sunxi
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.00 ms.
  hardware limits: 240 MHz - 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance
  current policy: frequency should be within 240 MHz and 912 MHz.
                  The governor "interactive" may decide which speed to use
                  within this range.
  current CPU frequency is 240 MHz (asserted by call to hardware).
  cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:64.44%, 312 MHz:0.06%, 408 MHz:0.04%, 480 MHz:0.07%, 504 MHz:0.00%, 528 MHz:0.11%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:0.00%, 648 MHz:0.00%, 672 MHz:0.00%, 720 MHz:0.01%, 768 MHz:0
.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:18.45%, 960 MHz:0.00%, 1.01 GHz:3.28%, 1.06 GHz:0.18%, 1.10 GHz:0.34%, 1.15 GHz:0.73%, 1.20 GHz:12.29%, 1.25 GHz:0.00%, 1.30 GHz:0.00%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00%  (96)
analyzing CPU 2:
  driver: cpufreq-sunxi
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.00 ms.
  hardware limits: 240 MHz - 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance
  current policy: frequency should be within 240 MHz and 912 MHz.
                  The governor "interactive" may decide which speed to use
                  within this range.
  current CPU frequency is 240 MHz (asserted by call to hardware).
  cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:64.45%, 312 MHz:0.06%, 408 MHz:0.04%, 480 MHz:0.07%, 504 MHz:0.00%, 528 MHz:0.11%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:0.00%, 648 MHz:0.00%, 672 MHz:0.00%, 720 MHz:0.01%, 768 MHz:0
.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:18.45%, 960 MHz:0.00%, 1.01 GHz:3.28%, 1.06 GHz:0.18%, 1.10 GHz:0.34%, 1.15 GHz:0.73%, 1.20 GHz:12.29%, 1.25 GHz:0.00%, 1.30 GHz:0.00%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00%  (96)
analyzing CPU 3:
  driver: cpufreq-sunxi
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 2.00 ms.
  hardware limits: 240 MHz - 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance
  current policy: frequency should be within 240 MHz and 912 MHz.
                  The governor "interactive" may decide which speed to use
                  within this range.
  current CPU frequency is 240 MHz (asserted by call to hardware).
  cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:64.45%, 312 MHz:0.06%, 408 MHz:0.04%, 480 MHz:0.07%, 504 MHz:0.00%, 528 MHz:0.11%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:0.00%, 648 MHz:0.00%, 672 MHz:0.00%, 720 MHz:0.01%, 768 MHz:0
.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:18.45%, 960 MHz:0.00%, 1.01 GHz:3.28%, 1.06 GHz:0.18%, 1.10 GHz:0.34%, 1.15 GHz:0.73%, 1.20 GHz:12.29%, 1.25 GHz:0.00%, 1.30 GHz:0.00%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00%  (96)
cur_freqopineo:~# cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/ 
408000
root@nanopineo:~# cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state 
60000 0
120000 0
240000 13395
312000 8
408000 5
480000 9
504000 0
528000 15
576000 0
600000 0
624000 0
648000 0
672000 0
720000 2
768000 0
816000 0
864000 0
912000 2699
960000 0
1008000 453
1056000 25
1104000 47
1152000 101
1200000 1700
1248000 0
1296000 0
1344000 0
1440000 0
1536000 0 

 

 

Some more details: http://sprunge.us/IbGC

 

At least h3disp message should be disabled. And no idea how to deal with these USB errors :(

 

Edit: USB troubles related to powering through Micro USB. As soon as the boards (tested all 4) are powered through USB pins, the symptoms disappear. Interesting. I can not remember that the same happend when I powered Banana Pi M2+ through Micro USB. But IIRC on NanoPis the power scheme is different...

 

Edit 2: Switching usb_detect_type from 0 to 1 'solves' this problem. But then the 'average load always above 1' problem is back and /sys/bus/platform/devices/sunxi_usb_udc/otg_role is switched to 2 (OTG) by default which will using USB gadgets somewhat harder since prior to loading the appropriate module /sys/bus/platform/devices/sunxi_usb_udc/otg_role has to be switched to 0 and back to 2 afterwards.

 

Hmm... how to proceed? BTW: Problem affects NanoPi M1 in exactly the same way. I wonder why we did not get a single report regarding this...

Link to comment
Share on other sites

@Zador, @Igor: what's your opinion on this?

 

Ok, no feedback at all -- I give up  :(

 

Open issues:

Link to comment
Share on other sites

Ok, no feedback at all -- I give up  :(

Sorry, I didn't pay much attention to this thread, I'm not really interested in Neo board (IMO Air is much better suited for IoT). And since I don't have this device, I can't help with issues that require testing the device.

 

After reading the last page my opinion is:

  • I don't see any need to rush with providing prebuilt images for Neo
  • We should focus on stability and try to solve any issues (like usb_detect_type). I don't see any reasons to focus default settings towards minimizing power consumption (for a device not designed to be powered directly from battery)

 I would go with these basic settings:

  • 408 DRAM clockspeed and 480 MHz cpufreq set in u-boot
  • 408 MHz DRAM clockspeed and 240-1200 MHz in fex file, switching from 1.1V to 1.3V above 912 MHz
  • 240-912 MHz in cpufrequtils settings therefore with our default settings VDD_CPUX will remain at 1.1V all the time and users have to 'unlock' the higher voltage and clockspeeds manually (easy, it's just one entry in a config file)
  • corekeeper disabled to let people adjust count of active CPU cores manually
  • Everything that's not needed or is not physically exposed disabled in fex (HDMI, Mali400, usb1, usb2, audio, CSI)

Further possible improvements (decreasing DRAM clockspeed below 408 and a daemon to adjust stuff based on CPU utilization) postponed since for example the DRAM clocking stuff would be better implemented as part of the budget_cooling mechanisms in kernel and not controlled from a daemon.

 

I'm not sure about disabling corekeeper, but we should test that cpuburn doesn't trigger shutdown with it being enabled.

And audio is technically exposed, so it should be enabled by default.

Link to comment
Share on other sites

Open issues:

  • how to deal with USB errors? Switching from usb_detect_type=0 to usb_detect_type=1 solves this but makes it harder to use USB gadget stuff and introduces 'average load always above 1' problem

 

 

hub 1-0:1.0: connect-debounce failed, port 1 disabled
/* Handle physical or logical connection change events.
 * This routine is called when:
 * 	a port connection-change occurs;
 *	a port enable-change occurs (often caused by EMI);
 *	usb_reset_and_verify_device() encounters changed descriptors (as from
 *		a firmware download)
 * caller already locked the hub
 */

So it either picks up EMI noise or voltage from USB hub/charger on DM/DP pins and thinks that this is an USB device. Can you try setting

usb_host_init_state = 0

and checking the same scenario?

Link to comment
Share on other sites

After reading the last page my opinion is:

  • I don't see any need to rush with providing prebuilt images for Neo
  • We should focus on stability and try to solve any issues (like usb_detect_type). I don't see any reasons to focus default settings towards minimizing power consumption (for a device not designed to be powered directly from battery)

I'm not sure about disabling corekeeper, but we should test that cpuburn doesn't trigger shutdown with it being enabled.

And audio is technically exposed, so it should be enabled by default.

 

Well, regarding the rush for images. For whatever reasons there is already one image available and NEO got an own download page (and 'test build' mentioned there is IMO too small)

 

Regarding minimum consumption I still think we should go this route with reasonable defaults since these boards might be powered through PoE or from battery (even if OPi One/Lite would be the better choices since at least OPi Lite is way more energy efficient most probably due to better components and maybe also due to single bank DRAM configuration on NEO being responsible for more heat/consumption?).

 

But IMO we should come up with settings that do not 'hurt'. Eg. lowering DRAM clock from vendor's default 432 MHz to 408 MHz: helps a lot with consumption while not affecting performance at all (to my big surprise). Or reducing maximum cpufreq by cpufrequtils to 912 MHz since this board is prone to overheating and avoiding 1.3V VDD_CPUX seems to be a good idea anyway. Same with switching from interactive to userspace default cpufreq governor in kernel. Avoids consumption peaks with NEO, doesn't hurt with all other H3 devices.

 

We could stay with 1200 MHz max cpufreq by default but why not making a clear disctinction through settings: since NEO is headless disabling HDMI/Mali already reduces consumption and use cases are also pretty limited (unlike with OPi One/Lite no one will try to use NEO as a media center). 'You want low power operation? Choose NEO or Air with Armbian, otherwise use the larger variants like NanoPI M1 or OPi PC'

 

BTW: All the results from this consumption monitoring approach will end up in documentation so owners of other H3 boards that want to lower consumption can also benefit (especially One/Lite are the champions in this area with improved settings). But I wanted to wait a bit since apart from the obvious (disable HDMI/Mali on a headless device, reduce CPU clockspeeds) the biggest win is reducing DRAM clock. This area needs still more testing and maybe someone looks into budget cooling stuff and adds dynamic DRAM clocking there too?

 

So it either picks up EMI noise or voltage from USB hub/charger on DM/DP pins and thinks that this is an USB device. Can you try setting

usb_host_init_state = 0

and checking the same scenario?

 

I tested with 3 different 'PSUs' the last days. With default settings (usb_detect_type = 0 / usb_host_init_state = 1) it's as follows:

  • 'Monitoring PSU' (Banana Pro): dmesg flooded with ehci messages and also the 'hub 1-0:1.0: connect-debounce failed, port 1 disabled' messages appear every few seconds
  • USB PSU I use since almost 2 years for various sunxi board tests: dmesg only reports a few ehci messages at system start [1]
  • Using my MacBook Pro as power source: Not a single occurence of any ehci connect/disconnect message

So it's definitely related to 'noise' (note to myself: get a JHT header and power Banana Pro not any longer through the Micro USB DC-IN jack but use the SATA power connector instead. Maybe voltage fluctuations are gone then or at least minimized) and I made a lot of wrong assumptions the last days blaming software/settings where the 'PSU' in question made the real difference. But this would also explain why we didn't receive complaints regarding NanoPi M1 (or BPi M2+) since my 'monitoring PSU' is obviously providing noisy power.

 

I then tested with the same USB PSU with usb_detect_type = 1 / usb_host_init_state = 1 (symptoms gone as expected) and also usb_detect_type = 0 / usb_host_init_state = 0 (symptoms also gone). But to be sure I went back to my 'Monitoring PSU' the Banana Pro. And guess what: autoboot problem immediately appeared again. So it seems noisy DC-IN provided by Banana Pro is responsible not only for these USB messages/errors but also for u-boot getting stuck at booting (at least good to know to interpret complaints in the future)

 

Connected to Banana Pro with usb_detect_type = 0 / usb_host_init_state = 0 I had not a single USB related error in the logs. Otg_role was set to 0 as expected, loading a gadget driver and changing role to 2 seems to work since then on Banana Pro lsusb also lists 'ID 0525:a4a7 Netchip Technology, Inc. Linux-USB Serial Gadget (CDC ACM mode)'. Then tested again with usb_detect_type = 0 / usb_host_init_state = 1

and again not a single error. Several reboots later (sometimes with UART adapter temporarely disconnected) I've not been able to reproduce the behaviour. Only 'being stuck in u-boot' happened nearly all the time when UART adapter was disconnected.

 

I need more time for tests to get a clue what's going on. What are the downsides of defining usb_host_init_state = 0 in fex file?

 

[1] Only a few ehci messages when using an USB PSU:

 

[   15.201508] ehci_irq: highspeed device connect

[   15.220124] ehci_irq: highspeed device disconnect

[   15.361448] ehci_irq: highspeed device connect

[   15.365806] ehci_irq: highspeed device disconnect

[   15.441436] ehci_irq: highspeed device connect

[   15.445869] ehci_irq: highspeed device disconnect

[   15.521504] ehci_irq: highspeed device connect

[   15.525870] ehci_irq: highspeed device disconnect

[   15.581434] ehci_irq: highspeed device connect

[   15.585792] ehci_irq: highspeed device disconnect

[   15.641502] ehci_irq: highspeed device connect

[   15.645867] ehci_irq: highspeed device disconnect

Link to comment
Share on other sites

Regarding minimum consumption I still think we should go this route with reasonable defaults since these boards might be powered through PoE or from battery (even if OPi One/Lite would be the better choices since at least OPi Lite is way more energy efficient most probably due to better components and maybe also due to single bank DRAM configuration on NEO being responsible for more heat/consumption?).

Yes, but IMO reasonable == balanced, not minimal. For example, changing governor starts affecting performance without improving reliability and disabling devices available on expansion headers will result in more questions like "audio is not working" and "I soldered USB device but it is not detected"

 

But IMO we should come up with settings that do not 'hurt'. Eg. lowering DRAM clock from vendor's default 432 MHz to 408 MHz: helps a lot with consumption while not affecting performance at all (to my big surprise). Or reducing maximum cpufreq by cpufrequtils to 912 MHz since this board is prone to overheating and avoiding 1.3V VDD_CPUX seems to be a good idea anyway. Same with switching from interactive to userspace default cpufreq governor in kernel. Avoids consumption peaks with NEO, doesn't hurt with all other H3 devices.

Agree apart from governor and again targeting consumption. Changing one line in /etc/default/cpufrequtils is easy and obvious enough for users that care about consumption.

 

We could stay with 1200 MHz max cpufreq by default but why not making a clear disctinction through settings: since NEO is headless disabling HDMI/Mali already reduces consumption and use cases are also pretty limited (unlike with OPi One/Lite no one will try to use NEO as a media center). 'You want low power operation? Choose NEO or Air with Armbian, otherwise use the larger variants like NanoPI M1 or OPi PC'

1200MHz implies using 1.3V VDD_CPU, which can cause instability when using shitty power supplies, shitty cables and microUSB for power input, in addition to significantly higher chance of overheating.

 

I need more time for tests to get a clue what's going on. What are the downsides of defining usb_host_init_state = 0 in fex file?

This is exactly what needs to be tested. If I understand it correctly, OTG port should (ideally) initialize as slave device and switch to host mode (and try to detect connected USB device) only after ID pin is pulled to the ground. But how this is implemented in legacy kernel USB driver is a good question.

Link to comment
Share on other sites

To keep things short... (since I go on vacation and this most probably will be my last contribution to NEO stuff prior to release).

 

I did another consumption test: enabling all USB ports, audio and so on 'costs' 30mW --> already enabled. The autoboot and USB issues seem to be related to noisy DC-IN, at least no one else complained about this stuff but people already helped testing (see NEO thread in H3 forums)

 

Then the reason why I'm after lowering consumption is pretty simple: How to dimension PSUs when you power a fleet of devices? Imagine you use a PoE injector panel like this:

poe24_1_z1.jpg

 

Maximum default consumption defines how you have to dimension your PSU and the individual step-down converters used (a real world use case not only I have to deal with). We're talking about three different types of consumption:

  • idle: irrelevant
  • boot peak consumption: important, imagine you power on all 24 boards at the same time then 500mW more or less per board add to +12W peak consumption the PSU has to deal with (can not be controlled from userspace only by changing u-boot and kernel defaults!)
  • 'worst case' consumption: scripts/daemons run amok for whatever reasons, taking sysbench and cpuburn-a7 numbers we get the idea how maximum PSU dimensions have to look like. Sysbench providing more realistic 'worst case' numbers and cpuburn-a7 the absolute maximum (can be controlled from userspace pretty easy through cpufrequtils config and with disabled corekeeper also from /etc/rc.local -- limiting count of active cpu cores)

My goal was to get default maximum consumption (defined by both peak and 'worst case' consumption) as low as possible. With my proposed settings we can provide an OS image for NEO which guarantees that NEO itself does not exceed 2000 mW consumption.

 

The three most important changes:

 

  1. Setting MAX_SPEED=912000 in /etc/default/cpufrequtils: this is responsible to remain at 1.1V VDD_CPUX and limits worst case consumption to around ~2W: I measured 1980 mW when running sysbench @ 912 MHz (vs. 1190 mW when being idle). When we use MAX_SPEED=1200000 instead then we're talking about ~5W (!), currently testing NEO with cpuburn, FA's heatsink and a fan and get 5105 mW, using sysbench it's 2940 mW instead. In reality this is also more or less a peak consumption value since no one will use the NEO with a fan and the budget_cooling stuff will limit consumption after a short period of time. But defaulting to 1200 MHz means that per board 5W instead of 2W maximum consumption have to be taken into account. Given the overheating issues of the board I think it's better to default to 912 MHz and tell users which 'price' they have to pay for unlocking another laughable 33 percent more CPU performance in /etc/default/cpufrequtils
  2. Changing interactive to userspace in kernel config's cpufreq governor settings. This switch is not really performance relevant since it only affects the few seconds between kernel starting and cpufrequtils taking over. The difference in numbers: With userspace as kernel default booting gets delayed by less than 1.3 seconds while reducing peak consumption compared to interactive by 500 mW! On the other H3 boards that are set to 816/1008 MHz in u-boot booting gets delayed by less than 0.5 seconds or even just 0.2x on all boards that are allowed to use the 1.3GHz clockspeed. So this little change only affects the few seconds between u-boot and start of cpufrequtils daemon but saves a whopping 500 mW peak consumption that has to be considered in PoE scenarios or if a few boards should be powered with a single PSU. And changing this parameter would require rebuilding the kernel so I strongly vote for changing the default there since it helps staying below the 2W barrier and costs only 1.3 seconds per boot.
  3. Lowering DRAM clockspeed from FA's 432 MHz to 408 MHz: no performance implications but saves 130 mW (630mW vs. 760mW)

Issue 1) and 2) do really help in real world situations when it's about dimensioning amperage requirements of step-down converters and PSUs (or step-up converters when we're talking about battery usage!).

 

And I also consider the whole approach I've been busy with the last days as a differentiation feature of Armbian. We care about details. And with NEO and Air the use cases are pretty obvious (at least no media center where people prefer performance over consumption) and our settings should help users here. If anyone wants to get the laughable 33 percent speed improvement risking +2W more consumption and overheating, then he's free to adjust the single line in /etc/default/cpufrequtils

 

But please let us stay with the current settings and switch from interactive to userspace as kernel's default cpufreq governor (applies to other kernel branches as well but needs more testing regarding change of boot times so this is stuff for another time).

 

All my assumptions above are backed by the measurements that can be found in the latest posts of this thread.

 

BTW: I did yesterday worst case tests to check corekeeper behaviour (see post #123 in NEO thread). Trying to emulate an 'enclosure from hell' by putting NEO flat on a table with SoC/DRAM/U7 on the lower side w/o heatsink and only the table spreading a little bit of the heat NEO throttled down to 312 MHz, sometimes being at 240 MHz but CPU cores were never killed. So it's save to keep it enabled? Anyway: I burned my fingers later when touching Ethernet and SD card slot -- seems the NEO also uses copper layers since the whole board and every component was simply hot (another good reason to stay at 912MHz / 1.1V by default). Did the same 'test' later with Orange Pi Lite/PC and there SD card slot felt not that hot.

 

Now off for vacation...

Link to comment
Share on other sites

And a final word regarding performance: Since I already had the setup with heatsink and fan up and running I tried something out I wanted to test for weeks. DRAM clockspeed dependency on cpuminer performance. An OPi PC running at 1296 MHz / 624 MHz gets 2.35 khash/s.

 

Now trying NEO with 1200 MHz cpufreq and 132 MHz vs. 408 MHz DRAM clockspeed:

  • sysbench: 152.9355 sec vs. 152.9851 sec (zero dependency on DRAM clockspeed)
  • cpuminer: 1.00 khash/s vs. 1.83 khash/s (132 vs. 408 MHz DRAM -- also consumption varies heavily)

That's just adjusting DRAM clockspeed in another shell from 132 to 408 MHz:

 

 

[2016-08-16 13:19:06] Total: 1.00 khash/s
[2016-08-16 13:19:06] thread 1: 1251 hashes, 0.25 khash/s
[2016-08-16 13:19:06] thread 0: 1257 hashes, 0.25 khash/s
[2016-08-16 13:19:06] thread 2: 1245 hashes, 0.25 khash/s
[2016-08-16 13:19:11] thread 3: 1260 hashes, 0.25 khash/s
[2016-08-16 13:19:11] Total: 1.00 khash/s
[2016-08-16 13:19:11] thread 1: 1254 hashes, 0.25 khash/s
[2016-08-16 13:19:11] thread 0: 1248 hashes, 0.25 khash/s
[2016-08-16 13:19:11] thread 2: 1245 hashes, 0.25 khash/s
[2016-08-16 13:19:14] thread 3: 1260 hashes, 0.36 khash/s
[2016-08-16 13:19:14] Total: 1.11 khash/s
[2016-08-16 13:19:14] thread 1: 1254 hashes, 0.36 khash/s
[2016-08-16 13:19:14] thread 0: 1251 hashes, 0.36 khash/s
[2016-08-16 13:19:14] thread 2: 1248 hashes, 0.36 khash/s
[2016-08-16 13:19:16] thread 3: 723 hashes, 0.46 khash/s
[2016-08-16 13:19:16] Total: 1.55 khash/s
[2016-08-16 13:19:16] thread 1: 726 hashes, 0.46 khash/s
[2016-08-16 13:19:16] thread 0: 726 hashes, 0.46 khash/s
[2016-08-16 13:19:16] thread 2: 729 hashes, 0.46 khash/s
[2016-08-16 13:19:21] thread 3: 2292 hashes, 0.46 khash/s
[2016-08-16 13:19:21] Total: 1.83 khash/s
[2016-08-16 13:19:21] thread 1: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:21] thread 0: 2292 hashes, 0.46 khash/s
[2016-08-16 13:19:21] thread 2: 2292 hashes, 0.46 khash/s
[2016-08-16 13:19:26] thread 3: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:26] Total: 1.83 khash/s
[2016-08-16 13:19:26] thread 0: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:26] thread 1: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:26] thread 2: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:31] thread 3: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:31] Total: 1.83 khash/s
[2016-08-16 13:19:31] thread 1: 2292 hashes, 0.46 khash/s
[2016-08-16 13:19:31] thread 0: 2295 hashes, 0.46 khash/s
[2016-08-16 13:19:31] thread 2: 2292 hashes, 0.45 khash/s
[2016-08-16 13:19:36] thread 3: 2292 hashes, 0.46 khash/s
[2016-08-16 13:19:36] Total: 1.83 khash/s

 

 

 

Therefore NEO is the wrong device anyway when it's about performance ;)

 

Edit: After replacing script.bin with one that allows 672 MHz DRAM clock I got 2.03 khash/s at 624 MHz and 2.05 khash/s with 672 MHz. But since running lima-memtester on this board deadlocks it within 2 minutes we have to stay with vendor's defaults anyway or better use the 408 MHz DRAM clock that save additional 130 mW consumption!

Link to comment
Share on other sites

Just to be clear: are you talking about setting userspace governor as kernel default to lower consumption at boot or about setting userspace in /etc/default/cpufrequtils too?

 

Only switching to userspace in linux-sun8i-default.config -- in /etc/default/cpufrequtils we should stay with interactive since all the heavy stuff happens before cpufrequtils daemon will be loaded. This way the 'less than 2W consumption by default' claim is true and the only drawback is an average delay of 1.3 seconds on every boot.

 

If then a user wants to further tune settings he is free to do so by altering /etc/default/cpufrequtils and/or script.bin together with /etc/rc.local to disable CPU cores. But this way we retain performance behaviour (lowering maximum performance by 25 percent when looking at 1200 vs. 912 MHz maximum cpufreq) but make everything important accessible from userspace (no need to recompile the kernel)

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines