tkaiser

The whole idea is crap. The person supplying additional power used the wrong Micro-USB connector (USB OTG and not power-in).
 
You always have to keep in mind that this is not a Raspberry Pi (where you can insert power easily through GPIO pins since its power scheme is totally different) but an A20/AXP209 device. And the PMU (AXP209) decides on its own where to take power from if there is more than one source available.
 
In case you use kernel 3.4 I would suggest installing RPi-Monitor with the sunxi fixes since this immediately shows you thermal values for SoC and PMU and the power used from the three different available sources (power-in, USB-OTG and LiPo -- for the latter not exactly when you connect a PSU to the LiPo connector since the voltage can't be read out and my sunxi fixes then assume 5V).
 
I delivered one R1 recently to a customer. Runs vertical, no heat sinks (one on the SoC but a crappy one that doesn't help at all) but some sort of convection and a small fan that jumps in if the PSU's temperature exceeds 55°C. Uptime while being totally stable for 30+ days. Temperature was a problem a few weeks ago when ambient temperature exceeded 30°C (since inside the enclosure it were 7°-8° above and then the PMU's temperature exceeded 55° -- might be ok if it gets higher but I decided to let then a fan cool down both SoC and PMU since the fan is just a few cm above both)
 

 

I am open for adding new boards ... but the biggest problem is to support boards I don't have around my desk.

Here we have one fresh example  I (we) wasted a day and haven't got anywhere. If I had a board on my desk I would most likely quickly find out what's wrong. Now we are doing ping - pong. Try this, try that ... 
 
Either read manual, learn and try to build your own or send me one such board (or talk to Linksprite to send me one). In this case I can add it to the list of officially supported.

Not in any case. You could also do some redirect/filter magic and let the output of a specific command lead to different triggers that modify blink frequency based on load or something like that.
 
On page 4 of this thread there are many examples using iostat (one line in /etc/rc.local). Also the BananaLEDd project that has been started in the aforementioned thread should be usable starting with v1.2 on Cubietruck using the LED=cubietruck:orange:usr syntax.
 
A simple daemon approach would be something like this (saved as eg. /usr/local/bin/diskblink.sh and started from within /etc/rc.local):
#!/bin/bash export PATH=/usr/local/bin:/usr/bin:/bin MyLed="/sys/class/leds/green:ph24:led1" PartitionUUID=a7747356-feed-432a-81a3-7caea67c8cb8 PartitionDevice=$(ls -l /dev/disk/by-uuid/${PartitionUUID} | awk -F"/" '{print $7}') echo timer >${MyLed}/trigger while true ; do PartitionUseage=$(df -k | awk -F" " "/\/dev\/${PartitionDevice}/ {print \$5}" | tr -d '%') echo ${PartitionUseage} >${MyLed}/delay_on     echo $(( ( 100 - ${PartitionUseage} ) * 100 )) >${MyLed}/delay_off # echo $(( 10000 - ${PartitionUseage} * ${PartitionUseage} ))  >${MyLed}/delay_off sleep 10 done   Since LED blinking is rather annoying I would also adjust brightness in the loop by something like this (value is in the range 0-255, with the following formula you get 2 with 10%, 62 with 50%, 202 with 90% and 245 with 99% -- so you will notice the LED only when it gets critical):    echo $(( ${PartitionUseage} * ${PartitionUseage} / 40 )) >${MyLed}/brightness You've to define $MyLed and of course $PartitionUUID (lookup with blkid). The script uses the timer trigger and adjust on/off cycles based on df's percentage output for the partition in question.
 
@Igor: Request for enhancement: please add BananaLEDd to /usr/local/bin for the A20 boards and ship with a disabled config for all supported boards :-)

Since you want to use a Banana Pro it should read CONFIG_SPI_SUN7I instead? It's not defined in Igor's config and maybe that's the reason: http://will-tm.com/spi-on-the-cubieboard2/
 
Regarding mainline kernel, SPI and device tree have a look at http://linux-sunxi.org/SPIdev

RPi-Monitor can be extended nearly unlimited since version 1.2 or 1.3 regarding custom data sources and various output types and starting with 2.10 also to customize the web pages extensively and include every stuff you like.
 
The focus of my additions was simply to address the different data sources on sunxi devices regarding thermal things and power consumption (and some sort of a daemon to collect data since in my test setups -- torturing the devices under full load -- RPi-Monitor often failed to collect some stuff due to timeouts: ie querying a disk for its internal temperature under full load --> takes often more than a second to respond and in the meantime RPi-Monitor already gave up).
 
If you want add the stuff you mentioned you can start directly. Just become familiar with RRD data collection types (GAUGE vs. COUNTER vs. DERIVE and so on) and how you apply regex to filter raw data and you're done. There are plenty of examples available on the web and you get many ideas by reading the full post including comments/links here: http://rpi-experiences.blogspot.fr/2013/06/rpi-monitor-version-20-advance-usage.html
 
But since it sounds you like to monitor a router I would suggest checking better options first (eg. fully blown monitoring solutions that know alerts and triggers like OpenNMS or OMD -- prebuilt for ARMv7)

The only OpenWRT image recommended can be found here: http://www.bananapi.com/index.php/forum/general/1157-openwrt-chaos-calmer-3rd-test-version-gigabit-and-temp-sensors-10-08-15?limitstart=0
 
If you still want to go the Armbian route (recommended if you want to learn to improve your skills) then start with Tido's tutorial.

FYI: Testing finished / feature freeze. I submitted a second pull request to Xavier to include the current state with the next RPi-Monitor release.
 
In case you've further comments feel free to discuss them here :-)
 
If you want to try it out in the meantime you should follow these steps:
# become root eg. by "sudo su -" cd /tmp && wget http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz md5sum sunxi-monitor.tar.gz | grep -i 6822bcd7fe5cb2403eed9747e7cfff52 || exit 1 service rpimonitor stop cd / && tar -xzf /tmp/sunxi-monitor.tar.gz pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' 2>/dev/null nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & service rpimonitor start If you chose the first installation method (compare with http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html please) then when RPi-Monitor 2.11 will be released all you've to do is a simple 'apt-get update/upgrade' and you're done. You should keep in mind that when you change templates then create them with a new and unique name otherwise conflicts while doing 'apt-get upgrade' will occur.

FYI: Running the very same test (" cd /mnt/sda/ && stress -t 900 -c 2 -m 2 -i 2 -d 2"), first time with the R1 being powered through the LiPo connector and second run through the crappy Micro-USB power-in (consumption peaks and voltage drops down to 4.7V -- the PSU provides 5.0V and with just 20 cm cable and Micro-USB we loose between 0.1-0.3V idle/load)
  Powered through battery connector:       Powered the crappy way through Micro-USB connector:      

yes, now ok

Hi,
 
I started to adjust RPi-Monitor's settings for the Banana Pi a while ago and reworked the whole stuff in the meantime (since it was focused on Banana Pi and some parts were too quick&dirty -- especially temp file handling of the temperature daemon). I also adjusted the consumption measurements for Lamobo R1 since it's the best idea to power the board through the LiPo battery connector -- for this case you need the axp209_cpu_pmu_temp_r1.conf template!
 
Here you find an installation overview for RPi-Monitor (takes you 3 minutes if you are able to copy&paste): http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html
 
Here you find what's different on sunxi: https://github.com/ThomasKaiser/RPi-Monitor/blob/master/README_sunxi.md
 
Here you find the adjustments: http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52. It will take you additional 3 minutes to 'install' -- see below)
 
The archive contains the following:
/etc/rpimonitor/data.conf /etc/rpimonitor/template/sunxi_axp209.conf /etc/rpimonitor/template/axp209_cpu_pmu_temp.conf /etc/rpimonitor/template/axp209_cpu_pmu_temp_r1.conf /usr/share/rpimonitor/scripts/sunxi_tp_temp /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh Contents: data.conf is relinked to template/sunxi_axp209.conf which includes all the basic RPi-Monitor stuff but uses template/axp209_cpu_pmu_temp.conf for all the A10/A20/AXP209 specific stuff since this differs totally from Raspberry Pi. The sunxi_tp_temp binary is able to read out A20's temperature and sunxi-temp-daemon.sh is a script I rewrote from scratch since it's not possible to collect thermal data from disks/SoC under heavy load (RPi-Monitor isn't that patient waiting for external ressources to respond. So I created a daemon that collects thermal data into 3 temporary files and redirect RPi-Monitor to read from there).
 
WARNING: Most of the sunxi stuff works only with kernel 3.4.x since in mainline the I2C/sysfs interface to the AXP209 PMU disappeared.
 
Installation: Install RPi-Monitor as outlined in the link above, then stop it, untar the archive from /, ensure that /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh will be running and start rpimonitor again.
# become root eg. by "sudo su -" service rpimonitor stop cd / && tar -xzf /path/to/sunxi-monitor.tar.gz nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & service rpimonitor start To let the collection of thermal data survive a reboot it's a good idea to add "/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &" prior to "exit 0" to /etc/rc.local
 

 

 

 

This is part LT-1318 from https://www.led-tech.de/de/High-Power-Zubehoer/Kuehlkoerper-c_106_114.html

Just FYI: By simply exchanging U-Boot and the board's .dtb file Armbian is able to run on a Banana Pi M2 which is based on the A31s SoC: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=6 (comprehensive instructions for Arch Linux on the M2 available there)

It's one of the known problems of this board: http://linux-sunxi.org/Lamobo_R1#Available_enclosures_and_thermal_issues
 
Try to operate it vertically since then convection jumps in 
 

I came out with this: 
###################################################################################### # # Battery info # i2cset -y -f 0 0x34 0x82 0xC3 # read power OPERATING MODE register @01h POWER_OP_MODE=$(i2cget -y -f 0 0x34 0x01) BAT_EXIST=$(($(($POWER_OP_MODE&0x20))/32)) # divide by 32 is like shifting rigth 5 times CHARG_IND=$(($(($POWER_OP_MODE&0x40))/64)) # divide by 64 is like shifting rigth 6 times ######################################################################################## #read battery voltage 79h, 78h 0 mV -> 000h, 1.1 mV/bit FFFh -> 4.5045 V BAT_VOLT_LSB=$(i2cget -y -f 0 0x34 0x79) BAT_VOLT_MSB=$(i2cget -y -f 0 0x34 0x78) BAT_BIN=$(( $(($BAT_VOLT_MSB << 4)) | $(($(($BAT_VOLT_LSB & 0xF0)) >> 4)) )) BAT_VOLT=$(echo "($BAT_BIN*1.1)"|bc) # store maximum battery voltage to compare to if [ -f "/etc/default/battery" ]; then source "/etc/default/battery" else echo "MAX=$BAT_VOLT" > /etc/default/battery echo "MIN=3484" >> /etc/default/battery fi # integer is enough, cut down the decimals MAX=${MAX%.*} BAT_VOLT=${BAT_VOLT%.*} # mainline kernel shows battery existence even if not exists. this is walkaround if [ "$BAT_VOLT" -ge "3200" ]; then # if we have new max value, alter defaults if [ "$BAT_VOLT" -gt "$MAX" ]; then MAX=$BAT_VOLT sed -e 's/MAX=.*/MAX='$BAT_VOLT'/g' -i /etc/default/battery fi # if we have new min value, alter defaults if [ "$BAT_VOLT" -lt "$MIN" ]; then MIN=$BAT_VOLT #sed -e 's/MIN=.*/MIN='$BAT_VOLT'/g' -i /etc/default/battery fi # calculate percentage percent=$(echo "($BAT_VOLT-$MIN)*100/($MAX-$MIN)"|bc) # colorize output under certain percentage if [ $percent -le 15 ] then color="31" fi if [ "$BAT_EXIST" == "1" ]; then BATT=" - Batt: " # dispay charging / percentage if [ "$CHARG_IND" == "1" ]; then BATT=$BATT"charging $percent%" else BATT=$BATT"\e["$color"m$percent%\x1B[0m" fi fi fi OUT="${OUT}${BATT}" echo "" echo -e ${OUT} echo "" Load: 1.64, 1.14, 1.00 - Board: 36.2°C - Ambient: 27.0°C - Drive: 43°C / 2.5Tb - Memory: 934Mb - Batt: 7%
 
Working on both kernels.

Yes, but I meant the increment in 48MHz steps. So I just tried it out myself (with kernel 4.0.4 and ready to overclock up to 1.2 GHz):
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 144000 312000 528000 720000 864000 912000 960000 1008000 1056000 1104000 1152000 1200000 root@bananapi:/# echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor root@bananapi:/# echo 1000000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 960000 root@bananapi:/# echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1008000 root@bananapi:/# echo 1009000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1008000 root@bananapi:/# echo 1056000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1056000 Same behaviour as with kernel 3.4. So the operating points available in kernel 4.0 or above are the equivalent to the former dvfs_table entries. They define a relationship between core voltage and clock speed but the actual cpufreq settings are still only possible in steps of 48 MHz. But what's different: Starting with kernel 4.0 thermal throttling is implemented on sun7i (A10/A20). If the temperature that will be read out from the thermal sensor inside the A20's touchpad controller exceeds defined values then the cpufreq driver will start to throttle. The temperature can be read out using the following code starting with 4.0:
awk '{printf ("%0.1f",$1/1000); }' </sys/devices/virtual/thermal/thermal_zone0/temp

Sorry, but both dd as well as hdparm aren't benchmark tools. They're abused in this way but the results are simply crap.
 
When you use dd with filesizes too small and without the appropriate flags ('direct' parameter) it always tests partially caches/buffers and sequential throughput seems to be higher than it is in reality. Same applies to 'hdparm -tT'. One parameter just shows RAM throughput and when used together with the other parameter a so called 'correction factor' will be applied to the results shown. In other words: The results given do NOT show what the disk in question is able to deliver.
 
And both pseudo benchmarks only test sequential throughput. Use bonnie++ or iozone (and use always at least twice as much as RAM available for test filesizes) to get a clue how the SD card or disk in question really performs. And both tools are able to show the performance of random I/O with different block/sector sizes.

All A20 based boards seem to be limited to approx. 16,x MB/s when reading/writing sequentially from/to SD card. What really makes a difference when you're frequently accessing files on the SD card will be random I/O. And there some SD cards outperforman others easily and sequential writes (or class xy) do not count any more.
 
In my eyes it depends whether you use an SSD or a HDD on the SATA port. In case it's a spinning disk there might be many situations where it's better to keep the rootfs on SD card (and using Wheezy and Igor's ramlog configuration to minimize writes to SD card) to let the HDD spin down when idle after longer periods. When you're using an SSD IMO it's a no-brainer to move the rootfs to SSD.
 
On my TODO list are experiments with F2FS on SD card (only possible using a different partition scheme than the one Igor's using now since u-boot can not directly read from F2FS at the moment). That might both decrease wear-out of the SD card and increase (random) performance. But I won't have the time to test this the next weeks/months. But if I'm done I'll report back.

Just as a small addendum: Many things one might attribute to "new kernel" are just side effects of different settings.
 
Given the hardware implementation of the GMAC ethernet (everything has to be done by the CPU) clock speeds and cpufreq settings matter. So you should check what you had when running Igor's image with kernel 3.4 (I would assume interactive governor and max. 912 MHz?) and what you've now.
 
If you didn't change anything then kernel 4.0.x with the new cpufreq stuff comes with these defaults:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 960000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 144000 /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy = 0 /sys/devices/system/cpu/cpufreq/ondemand/up_threshold = 95 /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 1 And while this might be nice on a tablet or on a machine that's mostly idling around it leads to bad throughput especially when it comes down to NAS useage. By tweaking mostly these settings as well as TCP/IP and CPU affinity settings you can double throughput in one direction and let it max out in the other: http://forum.lemaker.org/forum.php?mod=viewthread&tid=15543&fromuid=33332
 
Which results do you get when you try it with the following settings?
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 960000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo 528000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor sysctl -w net/core/rmem_max=8738000 sysctl -w net/core/wmem_max=6553600 sysctl -w net/ipv4/tcp_rmem="8192 873800 8738000" sysctl -w net/ipv4/tcp_wmem="4096 655360 6553600" sysctl -w vm/min_free_kbytes=65536 sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_timestamps=1 sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_no_metrics_save=1 BTW: Solely relying on iperf is wrong judging from my experiences. Real-world performance might differ. So I always double-check with a combined benchmark that checks a couple of different things including disk access (unfortunetaly we have a SATA write limitation where network throughput is faster in this direction and vice versa. When writing from client to Banana Pi disk I/O is the bottleneck and in the other direction it's network when using a SATA disk)