tkaiser

Please keep two things in mind:
Banana Pi M2 is no Raspberry Pi. On Raspberry Pi /boot/config.txt has a special meaning, with Armbian a file called /boot/config-4.3.3-sunxi is something completely different! (important to note when you rely on tutorials written for RPi) The Ethernet module you try to use is both slow as hell and power hungry. I would check whether it's ok to draw 160mA from the 3.3V pin Any USB-to-Ethernet adapter is a better choice when you have a free USB port.

I didn't touch percentage calculations in a while, especially since it reports directly from a register (we are talking about battery/capacity, right?). Last thing I modified - fixed units for battery/power, it should report consumption directly without having to multiply voltage and amperage.
 
Percentage curve is expected to be linear if system power consumption is constant, but I guess it's calculated based on current/min/max voltage, so it looks OK compared to googled images for "li-ion discharge curve".
 
It may be not worth to display it as a graph, but it still should be displayed as a numerical value and it's still good for implementing any kind of "safe shutdown" logic.
 
Also, I finally managed to connect a battery to my cubietruck, so I'll try to do my own experiments with monitoring.
 
 

Just a small update: This is the result based on this template: http://pastebin.com/75qRgFm7
 
Charging state and display of different data sources done dynamically based on values:
 

FYI: the first discharge cycle just finished at 16:44:
 
I connected the battery yesterday at 18:22, then it has been charged until 21:48 and at 21:53 I removed the DC-IN plug. This little beast provides power for ~19h being idle (with EVO840 SSD connected):
 
 
 
 
And here the read-outs. The last one before the PMU switched the Lime2 off:
 
 
 
And then it started again this way:
 
 
 

So what? https://github.com/ssvb/u-boot-sunxi/commits/20160126-wip-a64-experimental

You must use mainline kernel since nearly all the btrfs code lives in the kernel. Never ever try to use with outdated kernels like 3.4.x or even 3.10 (we had +30TB data loss at a customer relying on a broken btrfs feature and that was with 3.12 or 3.10).
 
And then you've to read through the docs if you want to make use of more advanced features.
 
 
 
You run 'btrfs scrub' regulary and check the output. There's no need to export checksums and store it anywhere above the filesystem layer since they are integral part of the filesystem itself:
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html Important to note: When choosing Debian Wheezy you're a bit in trouble due to horribly outdated btrfs-progs packages (this package contains all the userland stuff for btrfs. Wheezy ships with a v0.19 or v.017 from 1876 or even older ). So either go with jessie, use backports or build btrfs-progs from sources.

The C.H.I.P. people contracted with free-electrons for Mainline kernel support and hired the only US employee formerly working for Allwinner.
 
And Linux (kernel 4.4) runs already on Pine64: http://irclog.whitequark.org/linux-sunxi/2016-01-18-- mainly because the A64 is a H3 with Cortex-A53 cores more or less. That means combining Allwinner's u-boot with Allwinner's 3.10.65 kernel with any Linux rootfs shouldn't be a problem at all (which is some sort of a problem -- see below)
 
Obviously the strategies regarding announcements and OS support are different. We'll see what that means in the long run.
 
I still fear for the Pine64 backers that they get flooded with a bunch of crappy Linux OS images and hope the Pine guys are smart enough to concentrate on one or two OS releases that receive full support (by whom?) to avoid crappyness. Otherwise situation could be like with Banana Pi M3 today: Many OS images all being broken more or less since the vendor fails to provide update mechanisms for the relevant parts (fixes for u-boot, sys_config.fex and kernel)

I'm getting tired of all that crap people believe without thinking just a second.
 
Any 2D/3D game running in Android fully utilises the GPU core(s) therefore you won't see that much CPU activity. But GPU activity can lead to high consumption too (ARM just recently announced Mali-470 as being twice as energy efficient as the outdated Mali400 from 2008 used on the A64!) Any video playback running in Android fully utilises the VPU/CedarX therefore you won't see that much CPU activity. But VPU activity can lead to high consumption too Any marketing person producing a video to proof that while playing a game consumption does not exceed 2.5W, pausing a game and then showing the consumption ONLY while the SoC is totally idle (neither before pausing the game nor after the PSU's display is shown) showcases just the opposite: If consumption is just 2.5W while being idle the consumption MUST be higher while gaming. It's that simple: If consumption would not exceed 2.5W while playing Angry Birds they would've shown it in the video. But they prefered to show idle consumption only so the conclusion is simple Apart from that that's also an interesting statement regarding the target audience BTW: Both A20 and H3 boards I've here idle at 1.5W-1.7W. Therefore either the A64 wastes energy when being idle (unlikely since Cortex-A53's strength compared to A7 is not more performance but just less consumption when using optimised software) or there's something wrong with the board or (cpufreq/dvfs) settings.

That's an easy one: I've not seen anyone able to get something out of this camera with more than 640x480 resolution when running Linux (Android seems to be a different story). I've done some research since I thought about using a Banana Pi with this camera module (see here or here for example). But that's not important for the Pine64 since they chose a different module: http://wiki.pine64.org/index.php/Main_Page#Datasheet(we'll see what that means regarding drivers and the ability to use this camera in Linux).
 
Regarding recent Allwinner SoCs. I did some testing with both H3 and A83T (the former designed for OTT boxes, the latter a typical tablet SoC). Allwinner's kernel implements identical cooling strategies for both (throttling CPU/GPU cores and if that doesn't help shutting down CPU cores). By looking into the available A64 material it seems the same strategy applies to the A64. And the A83T for example isn't able to be clocked above 1.2 GHz without active cooling (or using the tablet's backcover as large heatsink). When reviewing the 'Banana Pi M3' I had to learn that using micro USB there is really crap since the board might easily draw 5V/3A current which is simply impossible when powering the board without a real DC-IN solution.
 
Apart from that: There are so many undervoltage/undercurrent problems associated with using micro USB for DC-IN (and the people aren't aware that 'not enough current' isn't the problem but voltage drops occuring under higher load) that I will not buy any device again that uses this crappy connector to be powered with.
 
We'll have to see how A64/AXP803 on the Pine64 behave. I would suspect that under full load with a connected USB disk spinning up the usual symptoms occur when choosing micro USB: Sudden power-off due to undervoltage.

I had a quick look into the operation of the A64 lichee SDK:
 
I let build.sh run with the following config (redirected output here):
export LICHEE_CHIP=sun50iw1p1 export LICHEE_PLATFORM=dragonboard export LICHEE_KERN_VER=linux-3.10 export LICHEE_BOARD=t1 And ended up with a typical Android boot.img, containing both kernel and initrd and being created by Android's mkbootimg:
mkbootimg --kernel output/bImage --ramdisk output/rootfs.cpio.gz --board sun50i --base 0x41000000 --kernel_offset 0x80000 --ramdisk_offset 0x01000000 -o output/boot.img At this point you're able to stick boot.img together with any suitable rootfs but there's still a lot of work to do. Everything users expect at the usual locations doesn't exist and everything that can be adjusted easily everywhere else doesn't work here (no config.txt as known from Raspbian, no uEnv.txt/boot.cmd known from distros using u-boot in a sane way, no easy access to sun50iw1p1-t1.dtb since we're booting from ramdisk with /boot being empty). Same situation again as with every other Allwinner SoC family in the past 
 
I'm really curious whether the Pine guys figure out how to solve this problem without delivering a virtual machine image with an installed Ubuntu and the lichee SDK to every user so they can recompile the whole BSP when they want to switch the HDMI resolution for example 
 
Seems both Allwinner's kernel and u-boot still rely on sys_config.fex (I put an example online, this one containing even lower clockspeeds defined): http://pastebin.com/Vh0P9w8a
 
BTW: build.sh indicates that we're seeing a few other ARMv8 (64-bit) chip families from Allwinner all being called sun5Xi:
if [ -n "`echo ${LICHEE_CHIP} | grep "sun5[0-9]i"`" ]; then export ARCH=arm64 fi

sun50iw1p1.dtsi
sun50iw1p1-clk.dtsi
sun50iw1p1-pinctrl.dtsi
sun50iw1p1-soc.dts
 
4 cores running between 480-1344 MHz (DVFS table containing 1200MHz@1.3V as highest value) and the contents of the cpu_budget_cooling/gpu_cooling/thermal-zones nodes: good luck without a heatsink (throttling) or with micro USB as DC-IN (sudden power-off without throttling) 
 
And OV5640 as camera? Really?

The "SDK" has been leaked. Allwinner uses kernel 3.10.65 and u-boot-2014.07 built with
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.01-3) 4.9.3 20150113 (prerelease) BSP looks horrible as usual...

Latest version being 4.2.x? And do you realize that repackaging the work others have done is quite simple?
 
@Igor: Might be the best idea to close/delete this thread to prevent further misuse.
 
@gerhardw: 'Integrating' a new kernel build including some patches for a switch IC into a distribution that's already prepared for and using mainline u-boot/kernel isn't comparable to the challenges the Pine64 people try to delegate to the community now. All they have is the A64 BSP from Allwinner that's suited for Android device developers. And while this BSP might be a good choice for those sort of people that do not care about sane code, kernel versions or software at all (they just want to sell their tablets using Android Lollipop) the standard SDK/BSP makes it really hard to transform it into a flexible build environment necessary for any SBC.
 
I would suspect mainline kernel/u-boot will be ready maybe sometimes in 2016 so all the Pine64 guys can do is to try to find someone who knows the platform, who knows Linux, who knows Allwinner's horrible BSP and can disassemble the BSP into something flexible and useable (relying on Allwinner's outdated u-boot and 3.10 kernel in the meantime). Currently it seems they search for someone that does that for free 

Thx, in the meantime my battery arrived and I had a look (currently using Zador's latest axp209 mainline sysfs interface patches). Now it's also obvious to me that the consumption calculation I used before is simply crap when using a real battery (and not the 'fix Lamobo R1 power problems' operational mode is used).
 
Will have a look into it the next days...

Since my battery arrived I had the time to try out your latest changes on a Lime2. I tested/monitored a few different situations:
    No battery, 5V through DC-IN:
Obviously wrong values that should be ignored. The only value that matters: "battery/connected: 0"     5V provided through DC-IN, battery starting to charge:
In this mode AXP209 gets quite hot (up to +25°C when charging with high current rating compared to normal idle mode without charging a battery) and internal recorded 'total consumption' in my setup exceeded 6W when starting to charge the battery.   Total consumption is the read-out of DC-IN (V*A). Charging consumption is 'charger/amperage' multiplied with voltage from DC-IN -> ac/voltage (not battery/voltage !). Therefore the board's consumption can be calculated by subtracting the 'charge consumption' from 'total consumption'.   Fully charged:
In this mode battery voltage doesn't matter that much. Consumption solely relies on the values that can be read out from DC-IN. But now 'battery/voltage' can be read out.   Disconnecting DC-IN and running on battery:
Now 'battery/amperage' isn't 0 any more and board's consumption can be measured using battery/amperage * battery/voltage   Conclusion (with mainline it _looks_ simple): if "battery/connected = 1" then a battery is present (and also the need to choose a different template and start a daemon approach to calculate total and charging consumption based on the variables below): if "battery/charging = 1" then state is "charging" (board consumption is total - charging -- see above) if "battery/charging = 0" and "battery/amperage = 0" then state is "charged" (board consumption calculated from battery/amperage * battery/voltage) if "battery/amperage > 0" then state is "discharging" (board consumption is battery/amperage * battery/voltage) TODO:  Adjust RPi-Monitor templates to reflect the aforementioned stuff and to check whether there's more to consider by trying out charging/discharing with active monitoring. Try this out with Lamobo R1 where 5V DC-IN is fed through battery connector. Use powermeter to verify internal measurements Check whether external components (SATA disk, USB peripherals) make a difference when reading out AXP209 internals Unanswered questions: Does logic/read-outs differ when power is provided through USB OTG instead of DC-IN? How does the older driver for kernel 3.4 behaves? In case with 3.4 drivers behaviour is different... better fix the driver or the code to detect 3.4 vs. mainline? How does 'charger/low_power' behaves (and should we take care of)?

Since my battery arrived I had the time to try out your latest changes on a Lime2. I tested/monitored a few different situations:
    No battery, 5V through DC-IN:
Obviously wrong values that should be ignored. The only value that matters: "battery/connected: 0"     5V provided through DC-IN, battery starting to charge:
In this mode AXP209 gets quite hot (up to +25°C when charging with high current rating compared to normal idle mode without charging a battery) and internal recorded 'total consumption' in my setup exceeded 6W when starting to charge the battery.   Total consumption is the read-out of DC-IN (V*A). Charging consumption is 'charger/amperage' multiplied with voltage from DC-IN -> ac/voltage (not battery/voltage !). Therefore the board's consumption can be calculated by subtracting the 'charge consumption' from 'total consumption'.   Fully charged:
In this mode battery voltage doesn't matter that much. Consumption solely relies on the values that can be read out from DC-IN. But now 'battery/voltage' can be read out.   Disconnecting DC-IN and running on battery:
Now 'battery/amperage' isn't 0 any more and board's consumption can be measured using battery/amperage * battery/voltage   Conclusion (with mainline it _looks_ simple): if "battery/connected = 1" then a battery is present (and also the need to choose a different template and start a daemon approach to calculate total and charging consumption based on the variables below): if "battery/charging = 1" then state is "charging" (board consumption is total - charging -- see above) if "battery/charging = 0" and "battery/amperage = 0" then state is "charged" (board consumption calculated from battery/amperage * battery/voltage) if "battery/amperage > 0" then state is "discharging" (board consumption is battery/amperage * battery/voltage) TODO:  Adjust RPi-Monitor templates to reflect the aforementioned stuff and to check whether there's more to consider by trying out charging/discharing with active monitoring. Try this out with Lamobo R1 where 5V DC-IN is fed through battery connector. Use powermeter to verify internal measurements Check whether external components (SATA disk, USB peripherals) make a difference when reading out AXP209 internals Unanswered questions: Does logic/read-outs differ when power is provided through USB OTG instead of DC-IN? How does the older driver for kernel 3.4 behaves? In case with 3.4 drivers behaviour is different... better fix the driver or the code to detect 3.4 vs. mainline? How does 'charger/low_power' behaves (and should we take care of)?

In my eyes it's relatively easy (disclaimer: I used/contributed to Bananian first but switched very fast to Armbian over a year ago). Simply count
boards supported OS 'variants' commits made amount of available documentation active contributors and decide then. Nico (the individual behind Bananian) is focused on one secure headless distribution (keep that in mind if you use insufficient tools like sftp since 'performance' might be influenced massively by the SSH ciphers being negotiated between 'client' and 'server'!) but doesn't spend that much time on further development in the meantime.
 
I wouldn't say Bananian is a bad choice but the 'speed' of development already scares me a bit. As an example: Bananian uses an ugly hack (provided by me) to read out the SoC temperature. In the meantime better alternatives exist and I made suggestions to Nico to improve this. But no interest, they still just try to maintain these ugly hacks. Unfortunately this is true for other areas as well.
 
I would believe we'll see a lot of improvements in and around Armbian this year therefore the choice is easy

This is such a simple exercise: You are a marketing person. You want to show that your device draws just 2.5W while being used. In case that's true you can produce a short video showing the device being in use (playing a game, decoding a video, running a benchmark -- whatever) and at the same time the consumption. It's easy since the equipment is already there and you can show both the PSU's display and the PineA64 being busy.
 
They chose the opposite. The PSU's display can only be seen in the video while the PineA64 is totally idle. Simple question: What does this mean?
 
Apart from that: there was another kickstarter campaign for an A64 based device: https://www.kickstarter.com/projects/jidetech/remix-mini-the-worlds-first-true-android-pc?ref=nav_search
 
They're already shipping. These devices are intended to run Remix OS, that's simply Android optimised for desktop. And they ship with a 5V/3A PSU with barrel plug. For a reason. While the Pine people claim 5V/1A are enough: http://forum.pine64.org/showthread.php?tid=75&pid=407#pid407

The "SDK" has been leaked. Allwinner uses kernel 3.10.65 and u-boot-2014.07 built with
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.01-3) 4.9.3 20150113 (prerelease) BSP looks horrible as usual...

@badrianiulian/@pschasch: Can you please provide a few more pictures where one can see the hardware modifications clearly? And add them to http://linux-sunxi.org/Lamobo_R1#Pictures or allow me to do so?
 
I would then summarize the 'Wi-Fi fix' there...

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
 

 

 

 

The latter. RPi-Monitor showed me values between 1.16W when idle and 1.84W when running iozone or sysbench (both too low). But since this might be my mistake I'll double check later. BTW: I stumbled accross this an hour ago: https://github.com/ssvb/linux-sunxi/commit/c0a2252427800aad66fafc27951579e58d84fbf2

Yes, currently it's wrong when running on battery. I just ordered the large Olimex battery and will then look into it at the end of next week.
 
BTW: My Lime2 didn't survive a switch between DC-IN and USB OTG (no battery connected). Now it doesn't even reboot properly. Will have a look into it tomorrow. Now it's time for a few beers

RTFunnyM . Regarding hddtemp you might need to add an entry to its config file (use smartctl to get the right one).

It's probably related to different device class ("power supply" vs "sensor" or "hwmon"). I'll add multiplier in the next version for the sake of consistency.