tkaiser

It's 3 GB: http://linux-sunxi.org/A64#A64_SoC_Features(and this means unless someone manufactures 12gb DDR3/LPDDR3 modules you will be limited to 2 GB).
 
But that seems to be a common problem with all those cheap Cortex-A53 ARMv8 implementations. While you can benefit from a huge virtual address space the useable physical address space doesn't exceed the 'magical' 64-bit border of 4 GB. And if you don't move both kernel and userspace from ARMv7 to ARMv8 code you won't get that much more performance either. According to Allwinner's PM A64/H64/R18 (all the same more or less) are made in a 40nm process (so the linux-sunxi wiki is still wrong) which might be responsible for the low clockspeeds possible (1152 MHz max.). The A64 seems to be just a bunch of 64-bit Cortex-A53 cores in a 32-bit SoC and the whole '64-bit thing' is more or less marketing and no technical improvement.
 
But hey, people buy numbers: They need 64 bit since... that's twice as much as 32 bit. Same with memory: the very same people cry for 4 GB RAM instead of reading through http://www.linuxatemyram.comand being happy with 1 GB.

What about reading the forum you're writing in?
 
http://forum.armbian.com/index.php/topic/617-wip-support-for-the-upcoming-orange-pi-one/
  http://forum.armbian.com/index.php/topic/504-quick-review-of-orange-pi-pc/page-2#entry3758

Nope: http://linux-sunxi.org/Orange_Pi_PC#Tips.2C_Tricks.2C_Caveats
 
In case you're doing development work with such an UART-to-USB adapter you should keep in mind that this adapter somewhat powers the board also and that sometimes you run into strange symptoms trying to reboot the device when the serial connection remains established.

Don't fall quickly to this either  Linux support for S905 is also not done / questionable at the moment / Android only. How long, when, into which direction will development go. Don't know.

What do you mean with 'a fee'? Feel free to donate at any time
 
Regarding Orange Pi One please read these two threads:
 
http://forum.armbian.com/index.php/topic/617-wip-support-for-the-upcoming-orange-pi-one/
 
http://forum.armbian.com/index.php/topic/504-quick-review-of-orange-pi-pc/?p=3758

FYI: SMP should work now without the ugly hack from two weeks ago: https://groups.google.com/d/msg/linux-sunxi/XNpJYmSeN1o/ygQM7S5mCAAJ
 
Regarding network it seems Allwinner used a new GMAC implementation starting with H3 (and A83T/R58/H8 and A64/H64/R18 as well) therefore LABBE Corentin writes a new mainline driver from scratch. Progress unknown.

Just to add some more confusion here
 
I learned today that Linksys WRT1200AC is based on Marvell's Armada 38x (see Clearfog Pro -- using the internal 128MB NAND for u-boot and combining this with external USB/eSATA storage it would be even possible to run Armbian on it).
 
And since a new toy arrived today the next thing I'll try is to get an USB3-to-GbE adapter. This board idles at 2W, Ethernet throughput 940 Mbits/sec, quick USB3 storage test showed 170 MB/s (didn't had a faster drive to test). But definitely no candidate for Armbian support
 
 
 

Small update: the ODROID-C2 is now officially announced (and Hardkernel did it right again: large heatsink as factory default and same board dimensions and connector layout -- I hope they will release a C2+ based on S912 with 4GB RAM later that year).
 
And the Pine guys started promoting their Peripheral On Top (POT) 'pseudo standard' with a few announced add-ons that look good to me (missing an 1-Wire-to-I2C POT, based on eg. DS2482S)

Small update: the ODROID-C2 is now officially announced (and Hardkernel did it right again: large heatsink as factory default and same board dimensions and connector layout -- I hope they will release a C2+ based on S912 with 4GB RAM later that year).
 
And the Pine guys started promoting their Peripheral On Top (POT) 'pseudo standard' with a few announced add-ons that look good to me (missing an 1-Wire-to-I2C POT, based on eg. DS2482S)

I accidentally (hard) crashed the WEB server so a post or two might be gone
 
BTW: the reason was micro USB power short on common PSU which causes reset on devices which ware not backed with battery

Nope, seems impossible since you provide broken links (404) and mix up hardware (different boards that all have their own issues) and software (different OS images that all have their own issues).
 
The whole idea to collect crappy hardware (enc28j60 for example, why do you expect 'performance' from such a thing?!) that is both slow and hard to even physically interconnect seems a bit weird. Also posting things like 'I CANT USE THE 4 EXTERNAL USB'? Do you really expect an answer to that?

Boot log:
 
 
___ _ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | | | |___ / | | | | '__/ _` | '_ \ / _` |/ _ \ | |_| | |_ \ | |_| | | | (_| | | | | (_| | __/ | _ |___) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_|____/ |___/ Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.40-sun8i System load: 2.02 Up time: 6 min Memory usage: 6 % of 1000Mb IP: 172.16.100.142 CPU temp: 29°C Usage of /: 15% of 7.4G [ 59 updates to install: apt-get upgrade ] Image for OPi+ (the one with external GMAC). Should boot on any H3 orange, serial console only.
http://mirror.igorpecovnik.com/test/Armbian_4.83_Orangepiplus_Debian_jessie_3.4.40.zip
 
Kernel for those who has internal MAC
http://mirror.igorpecovnik.com/test/OPI_PC_linux-image-sun8i_4.83_armhf.zip
 
Can be rebuild with:
https://github.com/igorpecovnik/lib/(default is without external GMAC support)

Just a small update: I implemented the aforementioned approach (record the peak value of battery/charge and then use this and the actual value to calculate percentage) and at least it looks good:
 

 
Discharging started at 9:50, at 10:00 I started a sysbench run and at 10:10 an iozone run on the connected SSD and sysbench in parallel (~4W consumption). When the value derived from my primitive formula fell below 49% I stopped the benchmarks to let the Lime2 being idle more or less. I'm curious how high the value is when the Lime2 shuts down due to battery being drained. Update this evening or tomorrow morning.
 
EDIT: The Lime2 was shutdown when the calculated remaining percentage was at 13% -- will post an updated graph later...
 

 
When recharging the percentage value reaches 104% so this time the peak battery/charge value exceeds the one from yesterday (in case this formula is useful then the daemon approach to adjust the peak value while charging will prevent percentage to exceed 100%).
 
While this percentage value looks better I still doubt that it's useful without further corrections (implementing emergency shutdown if battery capacity falls below a certrain treshold and stuff like that).

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.

If we're talking about Linux -> Linux then choosing btrfs on both sides would be the best solution since you can then create consistent syncs (impossible with rsync!) in fewer time more safely. Just create a btrfs snapshot on the client device (and flush open databases before) and send the snapshot to the remote server using 'btrfs send/receive'.
 
I don't now whether btrfs' FAR format (to transport the snapshot) uses the source's checksums and compares with the destination's in the meantime but that's something a subsequent rsync (--dry-)run could provide.
 
We do syncing with a similiar approach (relying on Solaris and ZFS but also using snapshots and 'zfs send/receive') through VPNs for quite some time and never experienced any problems since the transmitted data was also checked/retransmitted at the TCP/IP layer.
 
Well, I know that saying 'forget about well known mechanisms and become an early adopter' sounds somewhat weird when it's about backup. But if no one starts implementing/testing new methods things can't improve and the word won't be spread (that there exist far better alternatives to well known tools in the meantime)

While starting to discharge it remains the same. Let's see how it behaves later (will update in 24h -- this time I disconnected the SSD to get an idea how long an idle Lime2 can run on battery):
 
 
 

Unfortunately I hadn't the time to put all the stuff on Github. So again just as a reference:
setup-armbian-monitoring-environment: This will be started at boot, creates the symlinks (TODO: filesystem/disk config, implement battery template selection and your plug-in approach instead of functions for each SoC/PMIC combination and add the loop stuff) and a basic /etc/armbianmonitor/armbian.conf template where /etc/armbianmonitor/cpu_pmic.conf is included which is a simple symlink to the correct template (/etc/armbianmonitor/templates/axp209_template_battery.conf in this case) If SoC/PMIC have the ability to use/charge batteries i would prefer maintaining two templates (since you don't want to see empty battery stuff when there's no battery possible/available). You could do this in a single template using RPi-Monitor's visibility feature. But then setting up the templates gets overly complicated therefore I would prefer maintaing a battery and a non-battery template and let setup-armbian-monitoring-environment decide which to link to cpu_pmic.conf armbian-monitoring: helper script to activate monitoring (also debug mode or not) and to deal with disks (TODO: finish)  
Please give me just a little bit more time. I want to finish this for A20/AXP209 and Armada 38x (my Clearfog should arrive today or tomorrow) and put it then on github.
 
The basic idea is still:
Relink data sources to files below /etc/armbianmonitor/datasources (and where no datasource is available create a file instead and let setup-armbian-monitoring-environment write values collected in daemon mode into (applies to disk temperatures for example or A20 temperature when not using mainline kernel) Use maximum 4 templates for each SoC/PMIC configuration (with and w/o battery, each with and w/o debug mode) At the moment I'm in this stage:
 
 
 
 
Let me try out to add the Clearfog and to compare with the old AXP209 sysfs interface, put this on github and then decide together in which direction to go?

https://github.com/igorpecovnik/lib/commit/4c7a6b15e34a4f792ab7fd09898cadd332e4dd40
 
I added legacy, next and dev H3 building ... image is not booting but kernel building works. It's prepared but untested ... 4.5 might work with 2016.01

Great news: My Pine64+ dev sample arrived. Due to advanced packaging techniques the position of components could easily be explored without opening the sleeve:
 

 
And here you can see Eular + Ext connector:
 

 
 
Serial console output from first (and also last ) boot attempt: http://pastebin.com/9NfD8FxX

Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
  The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning.   Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus').   The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub")   In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs).   The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably.   Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below.   Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki.   Getting started   To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery)   In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!)   Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well)   On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair:     If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink   Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI).    Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me.   I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!)   Consumption/temperatures in headless mode:   The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC.   Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores:   240 MHz: not exceeding 2.0W, 25°C above ambient temperature 600 MHz: not exceeding 2.5W, 32°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50°C above ambient temperature   2 CPU cores deactivated and testing again:   240 MHz: not exceeding 1.9W, 23°C above ambient temperature 600 MHz: not exceeding 2.1W, 29°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40°C above ambient temperature   The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense.   Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq   With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed.   Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago.   Camera module   Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module:     The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion.   Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz)   For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy.   Other use cases   Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS   At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely:   OpenELEC HW accelerated video decoding   RPi-Monitor   I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums.   All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot:  cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.

Xunlong did no improvements to any of their images. They released a few ones in the beginning and then community took over. With Xunlong OS images you won't be able to use Ethernet or USB on the Orange Pi PC since definitions were wrong. CPU cores would've been shut down when overheating (and they wouldn't come back until the next reboot). Every improvement made was done by community members and required sometimes massive pushing of Xunlong's Steven to release necessary informations. The SoC used is pretty irrelevant.
 
Regarding software it simply doesn't matter what Xunlong did in the past or will do in the future. And this is the same with Pine64 -- but they never created the impression they would care about Linux or even made any promises! They said just: "We do Android, community does Linux" (and sent out over 50 dev samples in the meantime -- the linux-sunxi devs now doing the fundamentals and members of the Pine64 forum afterwards flooding the net with shitty Linux OS images )
 
EDIT: Just to prevent misunderstandings: The Pine64 folks do care about Linux support (trying to get source code from Allwinner and pushing them a bit in the 'open source' direction) but don't provide it on their own. 

There's some sort of a hard limitation at 25 MB/s (50 MHz data rate at 4 bit). Can be overcome if hardware vendor and drivers provide the ability to switch voltages (default 3.3V, for faster modes is 1.8V needed). I'm not that much into that, you should better read from here on: https://olimex.wordpress.com/2016/01/22/a64-olinuxino-routing-completed-but-we-still-have-to-final-touch-this-and-that/#comment-21480
 
 
 
Not true. Until yesterday they had 2 boards relying on A20 and some based on H3. The A20 boards seem to be discontinued and everything regarding software/support for the remaining H3 and the upcoming H8 based board depends on community. You must be a moron if you think you get decent software/support at the price of $10 or $15.
 
H8 on the announced 'Orange Pi 3' is another variant of A83T used on Banana Pi M3 so I would suspect software support will be as crappy as now with Banana Pi M3 or pcDuino8 Uno (also H8 based) EDIT: (I though about Cubietruck Plus that relies on H8).
 
H64 on the announced 'Orange Pi 3' is another variant of A64 used by Pine64 so regarding software support you either have Allwinner BSP crap or wait for mainline u-boot/kernel done by linux-sunxi community. I wouldn't expect that Xunlong has resources/knowledge to provide a good OS image. The best they can do to release soon is to take any of the crappy Pine64 images based on Allwinner's 3.10.65 kernel provided by the Pine64 community and to exchange boot0/SPL to be able to boot H64 instead of A64. It will be as bad as it was when Xunlong started with H3
 
But regarding H3 everything interesting will happen at linux-sunxi and not Xunlong.

Great news: My Pine64+ dev sample arrived. Due to advanced packaging techniques the position of components could easily be explored without opening the sleeve:
 

 
And here you can see Eular + Ext connector:
 

 
 
Serial console output from first (and also last ) boot attempt: http://pastebin.com/9NfD8FxX

Just the result of a simple web search for this exakt phrase above: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/248530
 
Apart from that: You know that using a PM is not the best idea? http://linux-sunxi.org/SATA#Caveats

Great! 
 
BTW:
Yes, this M2 disk can't write faster in general. All my other high performance SSD drives are in use
 
Remember to recompile u-boot to make use of mSATA instead of mPci when your little beasts arrive. Patch is prepared but disabled.
 
Edit: If you run into MAC address / Eth remapping problem, set MAC in u-boot - simply use this boot.cmd,