tkaiser

Just a note, name Odroid XU4 sounded familiar to me, and I remembered that I saw some notes about it in comments in an article I linked here.
Since it's in Russian, TL;DR translation:
Pros (compared to cubietruck and RPi2):
Small form factor Better performance (subjective) USB3.0 GBit network faster than on cubie Barrel plug DC in (compared to RPi I guess) Cons:
2.0mm GPIO headers with plastic "walls" surrounding them GPIO TTL voltage 1.8v, hard to find compatible periphery Very loud stock cooler, but speed can be lowered in software/by script With stock cooler throttling starts after 2-3 minutes with 2 cores loaded by cpuburn, temperature readings - 97°C With non-stock coolers (one with heat pipes and another without) throttling after 6-8 minutes with 4 cores Feels like SoC "body" plastic material has poor thermal conductivity (note from me - and/or internal temperature sensor readings are not accurate) "Normal" for these devices software/kernel support problems After all experiments and putting stock cooler back board died after ~1 hour, shorted power somewhere

http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks
 
"Always test from bottom to top" means: Use iperf to identify whether it's network related.

Another small update regarding the M3:
 
In SinoVoip's current 'official' forum (time will tell how long it takes until they abandon this and start over with the next one like they did already before) the same question regarding the M3 will be asked again and again "How can i boot from SATA?!". Even via PM again and again. Only by people who aren't willing to accept the only possible answer "You can't. Banana Pi M3 has no SATA".
 
It's that simple: the M3 has no SATA port. Just one single USB port is used to connect all externally available USB ports and a very slow USB-to-SATA bridge through an internal USB hub. It's really that limited. So the question could've be "How can I boot from USB?" instead. And the only valid answer to that is: "Why would you? Are you insane?"
 
Every M3 comes with 8 GB eMMC that is at least twice as fast as the crappy GL830 USB-to-SATA bridge. Storing the rootfs on USB this way means slowing things unnecessarily down. On the M3 your best bet is to boot from eMMC since this is the fastest storage option you have. This is different to other incompatible SBCs that are also called "Banana Pi" that lack eMMC and where you might benefit from the rootfs stored on USB or even SATA (M1). But on the M3 the approach to boot from USB especially using the ultra-slow onboard USB-to-SATA bridge is simply moronic.
 
Next thing: Since it is not SATA but only USB you can never rely on something like 'root=/dev/sda1' since a connected USB thumb drive might be /dev/sda on the next reboot and your rootfs will never be touched since being now /dev/sdb1. To escape from that you've to use partition UUIDs instead. I documented the whole stuff already where it belongs to and won't repeat it here again to prevent uneducated users from doing harm to their installations (again: Booting from USB on the M3 is adopting a strategy suited for different SBCs wrongly).
 
The best strategy to deal with the M3's 'SATA port' is to ignore it. Performance of a connected disk is unnecessarily low (especially writes -- see above) and using the SATA-power connector to power a disk means risking sudden power-offs more often than necessary since the M3 is prone to running in undervoltage/undercurrent situations. It's strongly recommended to turn off every power savings if you try to use a HDD this way since when your M3 is busy and disk spin-up leads to another 1A peak current needed then it's time to pick your solder iron to bypass the crappy micro USB connector unfortunately being used for DC-IN.
 
BTW: I updated my RPi-Monitor template for Banana Pi M3 or let's better say A83T/AXP813 to be able to also monitor the 'cooling states': http://linux-sunxi.org/User:Tkaiser#Preliminary_RPi-Monitor_template_for_A83T
 
If you've installed RPi-Monitor already, it's enough to stop it, then do as root
cd /etc/rpimonitor/ && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-A83T.tgz | tar xzf - restart RPi-Monitor, and you're already done (of course you should do this in a two-step process and check the MD5 checksum ef7220daadad5726b32b0d2270d4bffd first)

LOL, I've not realized that you're already using RPi-Monitor. In case you use my sunxi addons it would be easy to replace the temperature daemon (/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh) with this extended version where you might want to disable some stuff (eg. querying external weather stations via HTTP to also monitor your town's temperature and exact parsing of /proc/stat to get an idea what's really going on -- average load is so misleading): http://pastebin.com/U08kPTxt
 
I start the daemon as such through an init script:
root@lamobo:~# cat /etc/init.d/sunxi-tempd #!/bin/sh ### BEGIN INIT INFO # Provides: sunxi-tempd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: RPi-Monitor sunxi-temp helper # Description: Sunxi-temp helper for daemon for RPi self monitoring daemon ### END INIT INFO # Source function library. . /lib/lsb/init-functions DAEMON="/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh" PIDFILE="/var/run/sunxi-tempd.pid" [ -x $DAEMON ] || exit 0 checkroot(){ if [ "$(id -u)" != "0" ]; then echo "This script must be run as root" exit 1 fi } start() { touch $PIDFILE for pid in $(cat $PIDFILE); do if ( kill -0 $pid > /dev/null 2>&1 ); then echo "Sunxi-temp helper is already running."; status; return 0; fi done; log_daemon_msg "Starting Sunxi-temp helper for RPi-Monitor" "sunxi-tempd" nice -n 19 $DAEMON $PIDFILE & status=$? log_end_msg $status } stop() { touch $PIDFILE log_daemon_msg "Stopping Sunxi-temp helper RPi-Monitor" "sunxi-tempd" for pid in $(cat $PIDFILE); do kill -15 $pid > /dev/null 2>&1 done status=$? log_end_msg $status rm $PIDFILE } restart() { stop sleep 2 start } status(){ echo -n "Sunxi-temp helper RPi-Monitor status: " if [ ! -f $PIDFILE ]; then echo "Not running" exit 0 fi for pid in $(cat $PIDFILE); do kill -0 $pid > /dev/null 2>&1 && echo -n "[ \033[1;32mok\033[0m ]" || echo -n "[\033[31mFAIL\033[0m]"; done; echo } checkroot case "$1" in start) start ;; stop) stop ;; status) status ;; restart) restart ;; *) echo "Usage: $0 {start|stop|restart|status}" ;; esac exit 0 But it should also work if you just start it from /etc/rc.local -- then uncomment the last line. You need the first 2 lines to query the DHT11:
echo 'Humidity = 300 % Temperature = 300 °C' >/var/log/enclosure.log /usr/local/bin/dht11 >>/var/log/enclosure.log & # /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & My /etc/rpimonitor/data.conf looks like on this system:
include=/etc/rpimonitor/template/version.conf include=/etc/rpimonitor/template/uptime.conf include=/etc/rpimonitor/template/pispy.conf include=/etc/rpimonitor/template/memory.conf include=/etc/rpimonitor/template/swap.conf # include=/etc/rpimonitor/template/sdcard.conf include=/etc/rpimonitor/template/lamobo-disks.conf include=/etc/rpimonitor/template/network.conf All that's necessary (including the /usr/local/bin/dht11 binary) you'll find here: http://kaiser-edv.de/downloads/sunxi-temp-daemon-with-dht11.tgz

Three more things to add regarding 1-Wire:
 
It has been recommended to me to buy an I2C-to-1Wire bridge like 1 Wire Pi to protect the board from ESD damage and to have easier access to sensors: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=8312&pid=40322 Worth a look: OWFS Here a user has shown a solution to use 1-Wire reliably over longer distances.

"Enclosure" is a DHT11 and "Ambient" a DS18B20. And you will need to adjust the templates a bit since I monitor a lot of stuff there:
 

 

Hello,
 
Interested in replacing virtualbox as a VM host, "docker" tool seems to be able to run on Debian/Ubuntu/other linux distro/MacOS/Windows (as they claim)
 
 
 
My test:
 
1/
Installing docker on my amd64 4-cores Ubuntu 14.04 (too much tweaking to run "armbian" properly)
see doc here also I have been using "Create a Docker group" and don't forget to run "Hello World" test
 
2/
To create a new container with Ubuntu 14.04 (if you have added docker group to your non-privileged user, if not use "sudo")
 
$ docker run --privileged -i -t ubuntu:14.04 /bin/bash
 
"privileged" is needed for /dev/loop operations, if not the container cannot see the loop device, btw it is less "secure" but not "really" applicable here, I am on my test system.
 
on the host system, the files are stored in "/var/lib/docker", you can move this folder on another HDD/SSD, then you need to (in my example) "cd /var/lib; ln -s /home4/docker docker"
 
3/
once you have the root shell of the VM
 
# mkdir /root/armbian
# cd /root/armbian
 
then feel free to follow the Armbian tool instructions
 
Once all is compiled & package, you can transfer the files with "sftp", "ftp", etc. Or if you want a challenge, grab the files in /var/lib/docker (good luck!)
 
4/
later to come back to the container, list the containers, get the "Container ID" then start the container
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e12d3a2b9263 ubuntu:14.04 "/bin/bash" About an hour ago Up About an hour grave_ardinghelli d1efa716ad64 hello-world "/hello" 8 hours ago Exited (0) 8 hours ago elegant_meitner $ docker start -i e12d3a2b9263 (to be tested more carefully)
 
edit:
you need the "under work" script attached as the ubuntu:14.04 is *not* really a ubuntu server packaged style!
 
edit2:
[ o.k. ] Fixing release custom applications. [ jessie ] [ o.k. ] Install board specific applications. [ lamobo-r1 ] [ o.k. ] Fingerprinting. [ Armbian 4.6 Lamobo-r1 Debian jessie next Linux 4.2.6 ] [ o.k. ] Creating boot scripts [ lamobo-r1 ] [ o.k. ] Possible after install. [ o.k. ] Writing boot loader [ /dev/loop1 ] [ o.k. ] Shrink image last partition to [ minimum ] [ o.k. ] Create and sign [ Armbian_4.6_Lamobo-r1_Debian_jessie_4.2.6.zip ] [ o.k. ] Runtime [ 81 min ] et voilà !
 
more testing needed

Ah, one thing I forgot to mention: The older the disks the more they often consume (applies especially to peak current needed at disk spin-up). And you might also end up with the LCC problem (LCC --> load cycle count): many 'green' 2.5" HDDs suffer from this problem when running with linux: the drive's firmware parks the drive's heads every few seconds in a landing zone just to let the kernel unramp them a few seconds later.
 
Be prepared to install both smartmontools and hdparm and watch/adjust the relevant parameters (preventing increasing LCC counters and sane spin-down timeouts). If your disk doesn't support automatic spindown, it's time to give hdd-spindown.sh a try: https://github.com/lynix?tab=repositories
 
With Armbian it's easy to put the rootfs on a connected SATA disk. But unless it's an SSD I normaly refuse to do so and stay with the rootfs on SD-card with Igor's default settings (check /etc/fstab for details) and put only 'application data' on disk. With this setup I manage high spindown times since the disk only runs when really needed.

Absolutely second that. This is the most time saving approach. Unless the devices mentioned here are ready I would always prefer that solution after spending so many hours with the rubbish R1.

Turris Omnia comes with 1 GB RAM: http://www.cnx-software.com/2015/11/13/turris-omnia-open-source-hardware-routers-crowdfunding-campaign-is-up/ 
 
Campaign started this morning and already reached the $100.000 goal...

I always do it that way: https://www.bananian.org/download#os_x
 
In fact the last step is 
sudo dd if=... of=/dev/rdisk? bs=1m && diskutil eject disk? && say "Whoot, There It Is"

Sorry, but the Guitar is dead. Way too expensive, high performance only possible when combined with an annoying fan and weird design decisions. Since every standard Micro-USB3-OTG cable does NOT work together with the Guitar they need to bundle such a cable with their baseboard otherwise the advertised feature "USB 3" isn't available.
 
It's moronic to inform customers that they have to customize their cables to use the only interesting feature for a board in this price range: USB3. Without useable USB3 both storage and network performance are way too slow.
 
Even if you're not interested in storage/network performance the Guitar is a bad choice: You have to configure the board to either run slow or you get in trouble due to thermal issues. Due to the brain-dead board layout you can not use GPIO-Add-Ons (Raspberry Pi HATs) and a fan at the same time. So it will be either slow or with limited functionality.
 
Add the software problems (no mainline kernel support, just a horribly outdated kernel 3.10.37 lacking essential features) and you have to come to the conclusion that the Guitar isn't worth the price (the reseller's prices here in Germany are rather high: Baseboard and Coreboard add up to over 90,-€ including shipping and ordering directly from lenovator.com with shipping costs of $33 doesn't make a difference).
 
For less than that I get an ODROID-XU4 (8 CPU cores and not just 4, 2 GByte RAM instead of 1, 2 useable USB3 ports instead of 0, GBit Ethernet instead of Fast Ethernet, experimental mainline kernel support instead of an outdated 3.10.37 kernel being 2450 fixes behind 3.10.92) and for the same price I get two comparable ODROID-C1+ which shares some limitations (kernel 3.10 and no USB3) but is way more attractive due to high performance without thermal issues and GBit Ethernet.

I used the cnx-software.com link for a reason because there is not one but three similar boards mentioned (one of them being canceled in the meantime):
 
WiTi Board: https://mqmaker.com(headed by Benn Huang, co-founder of CubieTech)
Turris Omnia: https://omnia.turris.cz/en/(no idea who they are)
 
Unlike Lamobo R1's manufacturer the people behind WiTi board released their stuff very early: http://ftp.mqmaker.com/WiTi/
 
And in the comments on cnx there are other similar MT7621A based designs mentioned: http://www.cnx-software.com/2015/08/12/witi-openwrt-router-board-features-6-ethernet-ports-dual-band-wifi-sata-and-usb-3-0-ports-crowdfunding/#comment-435523
 
If I would need a board with a few GBit ports and SATA I would never ever choose the R1 again :-)
 
Benn already posted performance numbers (and not the usual SBC benchmark stuff where everything is measured wrong but reasonable test setups testing storage and network also individually): https://mqmaker.com/tutorials/making-your-own-nas-with-witi-board/-- looks promising to me. If there will be a board variant with 512 MB or even 1 GB this would be my favourite. 

As far as I understand it's about the order of started services (ramlog has to be the very first and the last daemon started/stopped so that all other daemon's output will be inside the ramdisk). The parallelisms introduced with systemd make this a bit hard to achieve.
 
Anyway: You can run jessie with SysV init instead of systemd. I tried to summarize the way Bananian does it here: https://olimex.wordpress.com/2015/08/26/devuan-jessie-for-olinuxino-images/#comments

I used the cnx-software.com link for a reason because there is not one but three similar boards mentioned (one of them being canceled in the meantime):
 
WiTi Board: https://mqmaker.com(headed by Benn Huang, co-founder of CubieTech)
Turris Omnia: https://omnia.turris.cz/en/(no idea who they are)
 
Unlike Lamobo R1's manufacturer the people behind WiTi board released their stuff very early: http://ftp.mqmaker.com/WiTi/
 
And in the comments on cnx there are other similar MT7621A based designs mentioned: http://www.cnx-software.com/2015/08/12/witi-openwrt-router-board-features-6-ethernet-ports-dual-band-wifi-sata-and-usb-3-0-ports-crowdfunding/#comment-435523
 
If I would need a board with a few GBit ports and SATA I would never ever choose the R1 again :-)
 
Benn already posted performance numbers (and not the usual SBC benchmark stuff where everything is measured wrong but reasonable test setups testing storage and network also individually): https://mqmaker.com/tutorials/making-your-own-nas-with-witi-board/-- looks promising to me. If there will be a board variant with 512 MB or even 1 GB this would be my favourite. 

https://duckduckgo.com/?q=motd+site%3Aforum.armbian.com

https://duckduckgo.com/?q=motd+site%3Aforum.armbian.com

First steps with LeMaker's guitar:
  These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design):   Lemon Pi:     Roseapple Pi:     The Allo SPARKY is also compatible to RPi HATs     LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware:     (yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too)   All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness'   How differs the Guitar from the other boards:   The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable! Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that.   I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds: Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores)     The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet.   Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet    It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes)         Original Thread starting one week ago:   Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar   Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running.   Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors:     /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel     /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0     /sys/devices/virtual/thermal/thermal_zone1/temp: 60000 The PMU can be queried (and maybe its behaviour also modified) using I2C:       root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al     total 0     drwxr-xr-x 29 root root    0 Jan  1  2011 .     drwxr-xr-x  4 root root    0 Jan  1  2011 ..     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-adckeypad.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-audio.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-cap-gauge.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc3.3     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ext-pwm-dcdc1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ext-pwm-dcdc2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-gpio.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-hwmon.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-irkeypad.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo11.11     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo3.3     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo5.5     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo6.6     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo7.7     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo8.8     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-onoff.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-pm.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-power.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-pwm.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-rtc.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-sgpio.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-switch1.1     -r--r--r--  1 root root 4096 Oct  5 14:26 auxadc_dbg     lrwxrwxrwx  1 root root    0 Jan  1  2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c     -r--r--r--  1 root root 4096 Oct  5 14:26 modalias     -r--r--r--  1 root root 4096 Jan  1  2011 name     drwxr-xr-x  2 root root    0 Oct  5 14:11 power     -r--r--r--  1 root root 4096 Oct  5 14:26 pstore_dbg     -rw-r--r--  1 root root 4096 Oct  5 14:26 reg_dbg     lrwxrwxrwx  1 root root    0 Jan  1  2011 subsystem -> ../../../../bus/i2c     -rw-r--r--  1 root root 4096 Jan  1  2011 uevent          root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al     total 0     drwxr-xr-x 3 root root    0 Jan  1  2011 .     drwxr-xr-x 3 root root    0 Jan  1  2011 ..     -r--r--r-- 1 root root 4096 Oct  5 14:27 bypass     lrwxrwxrwx 1 root root    0 Oct  5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0     lrwxrwxrwx 1 root root    0 Oct  5 14:27 device -> ../../../atc2603c-dcdc1.1     -r--r--r-- 1 root root 4096 Oct  5 14:27 max_microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 min_microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 name     -r--r--r-- 1 root root 4096 Oct  5 14:27 num_users     drwxr-xr-x 2 root root    0 Oct  5 14:11 power     -r--r--r-- 1 root root 4096 Oct  5 14:27 state     -r--r--r-- 1 root root 4096 Oct  5 14:27 status     lrwxrwxrwx 1 root root    0 Oct  5 14:27 subsystem -> ../../../../../../../class/regulator     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_disk_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_mem_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_standby_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 type     -rw-r--r-- 1 root root 4096 Jan  1  2011 uevent   Kernel config: http://pastebin.com/9bUSA7Rr   For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below):       root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies     408000 720000 900000 1104000      root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors     conservative ondemand userspace powersave interactive performance      root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq     408000     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq     1104000   Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/   "sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards   Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all.   While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements.    I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong)   http://pastebin.com/ZpMNkbU1   Complete boot log via debug UART: http://pastebin.com/X2ppDEwS   Device tree used: http://pastebin.com/QNb3i9F6   Contents of /boot/uEnv.txt:   uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait   If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that?   UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs: S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500 XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page

Next Update -- some performance measurements.
 
[uPDATE: LeMaker deleted their original forum post with the misleading benchmark results. And I provided a few bar diagrams also containing results from a 5th board a few posts below]
 
Today I did a set of performance tests. There are already tests published (I assume from a LeMaker employee) over there in the LeMaker forums: http://www.lemaker.org/forum.php?mod=viewthread&tid=17277&fromuid=33332
  Unfortunately the results published there are questionable/misleading. For the CPU tests they clocked the Guitar with 1.3 GHz while operating the RPi 2 with just 900 MHz and the Banana Pro obviously with 912 MHz (or maybe the performance sucks cause they used ARMv6 based Raspbian). The numbers are also wrong, especially the Guitar's excellent sysbench result with threads=4 (must be clocked with 1.5 GHz at this time otherwise impossible).   So I repeated the tests and took care of boundary conditions. I added another board:   LeMaker Guitar, Actions Semi S500 quad core SoC, 1.1 GHz, 1 GB RAM, 2 x USB2, 1 x USB3, 1 x Fast Ethernet Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz, 1 GB RAM, 1 x USB2 LeMaker Banana Pi, Allwinner A20 dual core SoC, 0.96 GHz, 1 GB RAM, 3 x USB2, 1 x SATA, 1 x GBit Ethernet Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz, 1 GB RAM, 2 x USB, 1 x GBit Ethernet   (you're reading right, the RPi has just 1 x USB2 and the ODROID only 2 USB2 ports, they use both an internal USB hub to provide their 4 external USB ports that have to share bandwidth this way! The RPi's network interface is also connected using the single USB2 connection between SoC and the outside)   I let the Guitar run with 1.1 GHz since Lemuntu v1509 doesn't give the opportunity to clock it higher. The RPi 2 is clocked with 1.0 GHz since this is a pretty sane/safe setting. The SoC doesn't get hot at all when running benchmarks even without a heatsink. Same applies to the ODROID, can be clocked safely with 1.7 GHz. The Banana Pi was clocked with the default 960 MHz from mainline kernel (it's confirmed that it works with up to 1.2 GHz but I didn't tested that).   Some tests are pretty useless (at least to me: trying to measure/compare GPU performance with gtkperf when the main point is the ability to use hardware acceleration from within Linux for video decoding and encoding... is just a joke) and some doesn't provide valuable results (like trying to measure sequential SD card transfer speed -- to which use case should this apply?)   You should also keep in mind that the tester in the aforementioned thread exchanged some labels by accident (eg. read/write speed when testing the SD card wrongly since in his setup his SD card wasn't fast enough and he tested not card but instead partially RAM speed due to wrong invocation of dd)   To sum it up:    The single thread integer performance of all 4 boards doesn't differ that much especially if they are clocked identical. If the typical workload makes use of many parallel threads then clearly the boards with 4 CPU cores outperform an A20 based device like the Banana Pi that features just 2 CPU cores. GPU performance is about hardware acceleration. As far as I know the best situation is with the RPi's VideoCore GPU (can both encode/decode video stuff on the GPU without the CPU cores being involved) followed by the ODROID-C1+. Since I'm not interested in 'Linux as desktop' I didn't tested this area at all. Memory performance differs a lot but this doesn't influence real-world situations that much. So by looking at numbers or graphs you might not get the real picture. Storage performance can not be measured by looking at sequential read/write speeds of the SD card where the system is installed on. But since every board review contains this useless stuff (most of the times measured wrong) I repeated such tests... and all boards are close together except the ODROID where write performance sucks. To get the real picture random I/O has to be tested (and there large performance differences exist but due to different SD cards and not boards) and disk performance connected via SATA or USB. Comparing network performance is useless since RPi and the Guitar have only Fast Ethernet. The ODROID-C1+ is many times faster and the Banana Pi even more. If it's about network speed then the Guitar should get an USB3-Ethernet adapter to compete with ODROID and Banana. The RPi is a joke since all its peripherals are behind one single USB2 connection between SoC and outside. So parallel storage/network accesses block each other and real-world performance as a NAS is horribly slow.   Testing the Guitar v1.3. Tests made with Lemuntu v1509, kernel 3.10.37, cpufreq settings set to 1104000 Hz (1.1 GHz) and performance governor.   1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 138 seconds, 79°C SoC, 67.5°C PMU 2 Threads: 273 seconds, 68°C SoC, 59°C PMU 1 Thread:  546 seconds, 62°C SoC, 54.5°C PMU   2) Memory bandwidth tests using mbw: -t0 256: 425.823 MiB/s -t1 256: 466.103 MiB/s -t2 256: 551.927 MiB/s   3) Rather useless sequential SD card tests   Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro), unlike LeMaker we try to use dd correctly -- https://romanrm.net/dd-benchmark root@Lemuntu:/mnt# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 225.577 s, 19.0 MB/s root@Lemuntu:/mnt# sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 212.929 s, 20.2 MB/s   Testing the Raspberry Pi 2. Tests made with 2015-09-24-raspbian-jessie, kernel 4.1.10+, cpufreq settings set to 1000000 Hz (1.0 GHz), NO use of force_turbo=1   config.txt reads arm_freq=1000 core_freq=450 sdram_freq=450 over_voltage=2   1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 173 seconds, 56°C SoC 2 Threads: 344 seconds, 49.5°C SoC 1 Thread:  692 seconds, 45°C SoC   2) Memory bandwidth tests using mbw: -t0 256:  447.574 MiB/s -t1 256:  980.893 MiB/s -t2 256: 1645.031 MiB/s   3) Rather useless sequential SD card tests   Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro) root@raspberrypi:/home/pi# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 244.799 s, 17.5 MB/s 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 222.493 s, 19.3 MB/s   Testing the Banana Pi. Tests made with Armbian_4.4 Wheezy, kernel 4.2.2, cpufreq settings set to 960000 Hz (0.96 GHz) and performance governor. The 960 MHz are the default upper limit with mainline kernel. I resigned to let the Banana Pi run at 1.2 GHz (good heatsinks applied and known to work stable at this clock speed).    1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 371 seconds 2 Threads: 371 seconds 1 Thread:  743 seconds   2) Memory bandwidth tests using mbw: -t0 256: 305.042 MiB/s -t1 256: 590.251 MiB/s -t2 256: 586.218 MiB/s   3) Rather useless sequential SD card tests   Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro) root@bananapi:/# dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 198.396 s, 21.6 MB/s 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 187.43 s, 22.9 MB/s   Testing the ODROID-C1+. Tests made with Hardkernel's most recent Ubuntu image, kernel 3.10.80-125, cpufreq settings set to 1728000 Hz (1.7 GHz) and performance governor. The default heatsink is in use.    1) sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=N: 4 Threads: 134 seconds, 62.5°C SoC 2 Threads: 265 seconds, 60.5°C SoC 1 Thread:  539 seconds, 56°C SoC   2) Memory bandwidth tests using mbw: -t0 256:  527.641 MiB/s -t1 256:  999.952 MiB/s -t2 256: 1152.731 MiB/s   3) Rather useless sequential SD card tests   Primitive dd 'test': target is a pretty fast SanDisk SD card (8GB Extreme Pro). I had to reduce the test size since Hardkernel's OS image wastes space on the 8 GB SD card I used. root@odroid:/# dd if=/dev/zero of=sd.img bs=1M count=2048 conv=fdatasync && sleep 3 && sync; dd bs=1M if=sd.img of=/dev/null 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 263.918 s, 8.1 MB/s 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 100.275 s, 21.4 MB/s

Today I tested the mechanical compatibility of 4 GPIO-Add-Ons. They all fit nicely and the distance between Add-On-board and core board is far enough to avoid shortcuts. But due to the different board layout some problems do exist. It would be a good idea if LeMaker exchanges the position of the battery connector and the mounting hole nearby so that 3 mounting holes could be used instead of 2. This would not only help with the first Add-On I tested but with many available Add-Ons and HATs that use the RPi's mounting hole positions. 
  16x2 LCD + IO Shield: The two top mounting holes match the positions of the wholes on Guitar's baseboard. But the bottom mounting holes are useless as well as the spacer on the bottom PCB side doesn't work so you have to DIY a mounting solution or build an enclosure where everything's securely mounted.
 
3.2inch TFT+Touchscreen Shield (also available from Waveshare): Same applies to this touchscreen LCD. The spacer is not of any use therefore you can't use this display with the Guitar without an specially designed enclosure
 
I2C to 1-Wire® bridge: Same problem. You cannot use the mounting hole to attach the Add-On-board to the base or core board so you have to either take care of mechanical force or invent a solution to securely fix both base board and Add-On
 
I2C GPIO extend board: Same problem since there is not even a mounting hole. You simply have to take care. But the space between I2C Extender and core board is wide enough
 

 

 

 

 

 

First steps with LeMaker's guitar:
  These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design):   Lemon Pi:     Roseapple Pi:     The Allo SPARKY is also compatible to RPi HATs     LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware:     (yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too)   All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness'   How differs the Guitar from the other boards:   The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable! Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that.   I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds: Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores)     The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet.   Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet    It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes)         Original Thread starting one week ago:   Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar   Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running.   Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors:     /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel     /sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0     /sys/devices/virtual/thermal/thermal_zone1/temp: 60000 The PMU can be queried (and maybe its behaviour also modified) using I2C:       root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al     total 0     drwxr-xr-x 29 root root    0 Jan  1  2011 .     drwxr-xr-x  4 root root    0 Jan  1  2011 ..     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-adckeypad.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-audio.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-cap-gauge.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-dcdc3.3     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ext-pwm-dcdc1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ext-pwm-dcdc2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-gpio.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-hwmon.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-irkeypad.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo1.1     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo11.11     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo2.2     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo3.3     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo5.5     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo6.6     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo7.7     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-ldo8.8     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-onoff.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-pm.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-power.0     drwxr-xr-x  3 root root    0 Jan  1  2011 atc2603c-pwm.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-rtc.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-sgpio.0     drwxr-xr-x  4 root root    0 Jan  1  2011 atc2603c-switch1.1     -r--r--r--  1 root root 4096 Oct  5 14:26 auxadc_dbg     lrwxrwxrwx  1 root root    0 Jan  1  2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c     -r--r--r--  1 root root 4096 Oct  5 14:26 modalias     -r--r--r--  1 root root 4096 Jan  1  2011 name     drwxr-xr-x  2 root root    0 Oct  5 14:11 power     -r--r--r--  1 root root 4096 Oct  5 14:26 pstore_dbg     -rw-r--r--  1 root root 4096 Oct  5 14:26 reg_dbg     lrwxrwxrwx  1 root root    0 Jan  1  2011 subsystem -> ../../../../bus/i2c     -rw-r--r--  1 root root 4096 Jan  1  2011 uevent          root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al     total 0     drwxr-xr-x 3 root root    0 Jan  1  2011 .     drwxr-xr-x 3 root root    0 Jan  1  2011 ..     -r--r--r-- 1 root root 4096 Oct  5 14:27 bypass     lrwxrwxrwx 1 root root    0 Oct  5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0     lrwxrwxrwx 1 root root    0 Oct  5 14:27 device -> ../../../atc2603c-dcdc1.1     -r--r--r-- 1 root root 4096 Oct  5 14:27 max_microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 min_microvolts     -r--r--r-- 1 root root 4096 Oct  5 14:27 name     -r--r--r-- 1 root root 4096 Oct  5 14:27 num_users     drwxr-xr-x 2 root root    0 Oct  5 14:11 power     -r--r--r-- 1 root root 4096 Oct  5 14:27 state     -r--r--r-- 1 root root 4096 Oct  5 14:27 status     lrwxrwxrwx 1 root root    0 Oct  5 14:27 subsystem -> ../../../../../../../class/regulator     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_disk_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_mem_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 suspend_standby_state     -r--r--r-- 1 root root 4096 Oct  5 14:27 type     -rw-r--r-- 1 root root 4096 Jan  1  2011 uevent   Kernel config: http://pastebin.com/9bUSA7Rr   For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below):       root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies     408000 720000 900000 1104000      root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors     conservative ondemand userspace powersave interactive performance      root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq     408000     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq     root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq     1104000   Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/   "sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards   Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all.   While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements.    I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong)   http://pastebin.com/ZpMNkbU1   Complete boot log via debug UART: http://pastebin.com/X2ppDEwS   Device tree used: http://pastebin.com/QNb3i9F6   Contents of /boot/uEnv.txt:   uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux; bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait   If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that?   UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs: S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500 XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page

hi all,
if someone need, I adapted for nagios the script to monitor battery cubietruck.
The script is pnp4nagios friendly.
#!/bin/bash ###################################################################################### # # Battery info # /usr/sbin/i2cset -y -f 0 0x34 0x82 0xC3 # read power OPERATING MODE register @01h POWER_OP_MODE=$(/usr/sbin/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=$(/usr/sbin/i2cget -y -f 0 0x34 0x79) BAT_VOLT_MSB=$(/usr/sbin/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) fi # define output format output="Load : $percent% | Load_Batt=$percent;80;35;3.4;4.2;" # if load% in range 80-10 ok if [ "$percent" -ge 80 -a "$percent" -le 100 ]; then echo "OK- $output" exit 0 # if load % in range 40-79 warning elif [ "$percent" -ge 40 -a "$percent" -le 79 ]; then echo "WARNING - $output" exit 1 # if load % in range 0-39 critical elif [ "$percent" -ge 0 -a "$percent" -le 39 ]; then echo "CRITICAL - $output" exit 2 # if check non riceve data else echo "UNKNOW" exit 3 fi if run script for non admin user need add permission to  /usr/sbin/iscget
ex:
chmod 777 /usr/sbin/iscget and change default permission for /dev/i2c-0
ex:
sudo nano /lib/udev/rules.d/60-i2c-tools.rules KERNEL=="i2c-0" , GROUP="i2c", MODE="0660" to
KERNEL=="i2c-0" , GROUP="i2c", MODE="0666" and reboot
 
 
 

I started to use terminology "Vanilla" which suits www.kernel.org aka mainline kernels. Not exactly correct interpretation but ..

Just to give an idea how many information sources are available (forget about the cameras since these are Raspberry Pis that record video on the Lamobo):
 

 
The disk's temp can be read using S.M.A.R.T. (hddtemp package, already included by Igor), PMU using sysfs, SoC using a small binary included with my sunxi fixes, and I also used an internal thermal sensor to get an idea what's going on (since in the enclosure are 2 PSUs and 1 LCD with backlight and signal board)
 
In the statistics view RPi-Monitor provides graphs and there I differentiate between available voltage and used amperage for the power sources "USB OTG" and "power-in" (unfortunately not available for the LiPo connector when used together with a PSU). But this way you get a clue what sort of problem you're running into (most likely undervoltage due to bad USB cables and the most crappy connector in the world: Micro-USB).

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)