tkaiser Posted August 1, 2016 Posted August 1, 2016 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? 1
tkaiser Posted August 2, 2016 Author Posted August 2, 2016 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.
arox Posted August 2, 2016 Posted August 2, 2016 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 ?
tkaiser Posted August 2, 2016 Author Posted August 2, 2016 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.
arox Posted August 2, 2016 Posted August 2, 2016 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.
tkaiser Posted August 2, 2016 Author Posted August 2, 2016 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) 1
tkaiser Posted August 12, 2016 Author Posted August 12, 2016 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): (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
arox Posted August 12, 2016 Posted August 12, 2016 "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 ?
tkaiser Posted August 12, 2016 Author Posted August 12, 2016 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?
arox Posted August 12, 2016 Posted August 12, 2016 "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 ?
arox Posted August 12, 2016 Posted August 12, 2016 "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 !)
tkaiser Posted August 12, 2016 Author Posted August 12, 2016 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.
arox Posted August 12, 2016 Posted August 12, 2016 - 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) ?
tkaiser Posted August 13, 2016 Author Posted August 13, 2016 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): (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) 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?
tkaiser Posted August 13, 2016 Author Posted August 13, 2016 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...
tkaiser Posted August 14, 2016 Author Posted August 14, 2016 @Zador, @Igor: what's your opinion on this? Ok, no feedback at all -- I give up 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 change sun8i default cpufreq governor from interactive to userspace or even powersave: http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?view=getlastpost
zador.blood.stained Posted August 15, 2016 Posted August 15, 2016 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.
zador.blood.stained Posted August 15, 2016 Posted August 15, 2016 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?
tkaiser Posted August 15, 2016 Author Posted August 15, 2016 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 1
zador.blood.stained Posted August 15, 2016 Posted August 15, 2016 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.
tkaiser Posted August 16, 2016 Author Posted August 16, 2016 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: 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: 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 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. 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... 2
tkaiser Posted August 16, 2016 Author Posted August 16, 2016 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!
zador.blood.stained Posted August 16, 2016 Posted August 16, 2016 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?
tkaiser Posted August 16, 2016 Author Posted August 16, 2016 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) 2
Recommended Posts