Jens Bauer

I have tested GT1 under extremely load cases and it is the best hardware and thermal design I've seen so far. I'm highly interested in helping Armbian support GT1.
 
@tkaiser, can you help me with steps to help it go faster?

I think S912 boxes become support sooner or later but I'm personally not that much interested in it since I miss the use cases. Number crunching on TV boxes comes to my mind but that's nothing I'm interested in. I will go this route instead.
 
BTW: based on Jean-Juc's unboxing pictures I don't believe you get any decent 'octa-core performance' out of such S912 TV boxes unless you open the enclosure and mount a large heatsink + fan.

Ouch, that sounds you want to use this weird device as a firewall / router combination? Will never work without adding another Ethernet interface: http://forum.armbian.com/index.php/topic/549-banana-pi-r-as-router/?p=15959
 
Apart from that: Replacing en0 with wlan0 won't work. OS X uses a pretty different network setup/configuration compared with Linux. The onboard WiFi on Lamobo R1 is unusable crap anyway.
 
Edit: Oh, I just realized that you use a PowerBook G4 as 'wireless gateway'. Please be aware that the old OS X versions that can run on this old device in this mode do not provide any effective encryption (WEP max which can be opened within minutes). 

chester and Igor, as suggested by Igor here I have the changes in a rough form to make wifi in Lamobo R1 Stable.
 
$su
 
Install aptitude just because I prefer using it
 
#apt-get install aptitude   Install tools for later on   #aptitude install dkms git   Correct missing sys/cdefs.h in the armbian 4.5 image or otherwise we wont be able to compile the hostapd version from realtek   #aptitude reinstall libc6-dev   Download the source of the new driver   #git clone https://github.com/dz0ny/rt8192cu.git   Steps to compile it   #cd rt8192cu   Edit include/autoconf.h and comment //#define CONFIG_DEBUG_RTL819X  (line 299) //#define CONFIG_PROC_DEBUG 1 (line 301)   If you do not disable the debug mode your logs will grow too fast.   Now let´s continue. This will compile, rmmod the old driver and install the new   #make dkms #cd ..   You do not need to reboot here. The make rules took care of removing the old driver, inserting the new, inserting a dkms rule for recompiling again the driver for kernel upgrades, and blacklisting the old module.   Go to this page  to download the realtek file   http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192CU  and download the linux kernel driver (under RTL8192CU)   I got a file called 0001-RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip. This file is around 1GB, if with limited space and/or MicroSD card on the destination unzip it on your machine, and just copy the tar.gz mentioned bellow.   $unzip 0001-RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip $cd RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911 $cd wpa_supplicant_hostapd   Copy wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz to your R1/pi/whatever.   #tar -zxvf wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz #cd wpa_supplicant_hostapd-0.8_rtw_r7475.20130812 #cd hostapd   Based on this page, I also commented out the check of neighbours to enable always 40MHz channels.  http://www.brunsware.de/blog/gentoo/hostapd-40mhz-disable-neighbor-check.html  It seems I am not needing it here, conditions might change in a near future.   In file src/ap/hw_features.c   line 453 - function ieee80211n_check_scan   /*              iface->conf->secondary_channel = 0; */   Now compile hostap   #make   stop hostap service. If it is not running, it will throw an error, ignore it   #service hostapd stop   not sure if the service was uninstalled by me before or by any previous script, installing the package just in case   #aptitude install hostapd   freeze hostapd package, for it in the future not to be upgraded   #echo hostapd hold | dpkg —set-selections      Overwrite hostap with the realtek ones that we compiled   #cp hostapd hostapd_cli /usr/sbin   Now create /etc/hostapd.conf file with: ssid=YOURSSID interface=wlan0 ctrl_interface=/var/run/hostapd channel=5 wpa=2 wpa_passphrase=YOUR_SSID_PASSWORD bridge=br0 wmm_enabled=0 driver=rtl871xdrv beacon_int=100 hw_mode=g ieee80211n=1 wme_enabled=1 ht_capab=[sHORT-GI-40][HT40+][HT40-][DSSS_CCK-40] wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP max_num_sta=8 wpa_group_rekey=86400   Start again the service.   #service hostapd start   DONE.   So after setting this up, to check up everything:   #iwconfig wlan0     IEEE 802.11bgn  ESSID:"YOURSSID"  Nickname:"<WIFI@REALTEK>"           Mode:Master  Frequency:2.432 GHz  Access Point: AC:A2:13:5C:96:31              Sensitivity:0/0             Retry:off   RTS thr:off   Fragment thr:off           Encryption key:off           Power Management:off           Link Quality=100/100  Signal level=88/100  Noise level=0/100           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0           Tx excessive retries:0  Invalid misc:0   Missed beacon:0     $lsmod | grep rtl8192cu rtl8192cu   My dmesg is after a reboot.   $dmesg  usb 2-1: new high-speed USB device number 2 using ehci-platform [    2.599494] usb 2-1: New USB device found, idVendor=0bda, idProduct=8178 [    2.599527] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [    2.599544] usb 2-1: Product: 802.11n WLAN Adapter [    2.599560] usb 2-1: Manufacturer: Realtek [    2.599575] usb 2-1: SerialNumber: 00e04c000001 [    3.909414] usbcore: registered new interface driver rtl8192cu [    4.944917] cfg80211: World regulatory domain updated: [    4.944946] cfg80211:  DFS Master region: unset [    4.944953] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [    4.944965] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [    4.944974] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [    4.944982] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [    4.944993] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [    4.945003] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [    4.945012] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [    4.945021] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [    4.945029] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [    9.504116] +871x_drv - drv_open, bup=0 [    9.508641]  ===> FirmwareDownload91C() fw:Rtl819XFwImageArray_TSMC [    9.508664] FirmwareDownload92C accquire FW from embedded image [    9.508674] fw_ver=v88, fw_subver=2, sig=0x88c0 [    9.534123] fw download ok! [    9.534140] Set RF Chip ID to RF_6052 and RF type to 2. [    9.930023] IQK:Start!!! [    9.941896] Path A IQK Success!! [    9.946770] Path B IQK Success!! [    9.955388] Path A IQK Success!! [    9.960148] Path B IQK Success!! [    9.965028] IQK: final_candidate is 0 [    9.965066] IQK: RegE94=ff RegE9C=3fe RegEA4=f7 RegEAC=3 RegEB4=101 RegEBC=a RegEC4=fb RegECC=9  Path A IQ Calibration Success ! [    9.967525] Path B IQ Calibration Success ! [   10.081283] pdmpriv->TxPowerTrackControl = 1 [   10.086157] rtl8192cu_hal_init in 580ms [   10.102538] MAC Address = ac:a2:13:5c:96:31 [   10.103040] -871x_drv - drv_open, bup=1     # iwlist wlan0 channel wlan0     14 channels in total; available frequencies :           Channel 01 : 2.412 GHz           Channel 02 : 2.417 GHz           Channel 03 : 2.422 GHz           Channel 04 : 2.427 GHz           Channel 05 : 2.432 GHz           Channel 06 : 2.437 GHz           Channel 07 : 2.442 GHz           Channel 08 : 2.447 GHz           Channel 09 : 2.452 GHz           Channel 10 : 2.457 GHz           Channel 11 : 2.462 GHz           Channel 12 : 2.467 GHz           Channel 13 : 2.472 GHz           Channel 14 : 2.484 GHz           Current Frequency:2.432 GHz (Channel 5)     Listing neighbours frequencies    # iwlist wlan0 scan | grep Channel                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.467 GHz (Channel 12)                     Frequency:2.467 GHz (Channel 12)                     Frequency:2.472 GHz (Channel 13)   Working like a charm, no drops, 40MHz bandwidth in channel 5.   --   Rui Ribeiro

Any recommendations?
 
http://wiki.lamobo.org/index.php/Lamobo_R1S
New version is coming out but with Mediatek wifi which is as crappy as Realtek.
 
I think we'll get more cheap (but with a little better hw) router boards soon.

You will loose your time only, when you are trying onboard wifi get running. I tested with all available drivers/kernels/systems and result is the same - nearly unusable.
Buy quality USB wifi, and you will have zero problems.

We have work hard to find out parameters for better performance, but unfortunately this is the best we could squeeze out. It's an low cost device with poor design. Performances does not match what they advertised and if you choose a manufacturers images, you will face even more problems and speed regression.
 
If you find this as a problem, consider getting Clearfog / Turrris omnia router board. There, performances are @ advertised speed.

An alternative for isc-dhcp on Page 9,
written from Ashok Aiyar, I put it here because it is not just a fix but an instruction how to replace the isc-dhcp server with dnsmasq.
 
 
I find dnsmasq to be a better option to isc-dhcp-server, because it provides both DNS and DHCP servers in a single package and configuration file.
Also, dnsmasq supports caching, so with a large cache, it provides really fast name resolution after using it for a little while.
 
Here is a dnsmasq setup consistent with the rest of the Armbian BPi R1 configuration given in this very helpful guide.
 
a) Install dnsmasq (apt-get install dnsmasq)
 
b  shutdown dnsmasq (service dnsmasq stop)
 
c) Edit "/etc/dnsmasq.d/dnsmasq.conf" with the contents shown below:
 


# interfaces
interface=br0
no-dhcp-interface=eth0.101
#
# DNS configuration
min-port=4096
cache-size=10000
local-ttl=3600
neg-ttl=3600
bogus-priv
domain-needed
expand-hosts
resolv-file=/etc/resolv.conf
#
# DHCP configuration
dhcp-authoritative
dhcp-leasefile=/var/lib/misc/dnsmasq.leases
dhcp-option=br0,1,255.255.255.0
dhcp-option=br0,3,192.168.9.2
dhcp-option=br0,6,192.168.9.2
dhcp-option=br0,28,192.168.9.255
dhcp-range=br0,192.168.9.150,192.168.9.250,255.255.255.0,72h
# explanation of options:
# option 1 = net mask
# option 3 = gateway
# option 6 = DNS
# option 28 = broadcast address
# assign address range = 150-250
# lease time = 3 day (72h)


d) shutdown isc-dhcp-server (service isc-dhcp-server stop)
 
e) start dnsmasq (service dnsmasq start)
 
f) confirm that IP assignment is working and that you are making use of the caching nameserver within dnsmasq
 
g) If it works, then remove isc-dhcp-server (apt-get remove isc-dhcp-server)
 
 
Thank you Ashok for your contribution 

Hi
 
Back in February '15 I have started to write an instruction about the setup of a BPi-R1 (Router).
In the threads of the Forum, the information is scattered and it takes so much time for each to get along.
So I thought such a document would help to become not only faster, but to achieve a better result as well, as you can faster spend time with the device and tweak it.
My know how is getting better, but things are still missing.
If you like to help the 'community' with your know how, please leave comments in the document if you find errors or you find something missing.
 
Google Docs 
 
Thank you in advance - for your support
 
Cheers
Tido

Ok, I think I may have stumbled on the solution by accident last night, no surprises in that it looks like the cause was me being an idiot as usual... 
I use ctrl-r and bash's history alot and it would appear that sometimes I've been trying to write the .raw file to /dev/sdb1 instead of /dev/sdb. As expected the Pi fails to boot, my Kubuntu desktop can't mount the fs etc. etc.
 
The interesting thing is that testdisk appears to be able to fix this up! I need to confirm all of this with a few more tests but if that's the case then not only problem solved, but also how awesome is testdisk!!

Hi,
 
since a Geekbox (Rockchip RK3368) and two Pine64+ (Allwinner A64) are collecting dust and at least for the latter longsleep already prepared a nice image build process that makes including a 'foreign' rootfs quite easy I thought about supporting arm64 also and not just only armhf.
 
But I still lack oversights over our own build process or don't know in which direction other devs will move (I saw zador rearranging stuff the last days) so I thought I better ask first instead of hacking around
 
I thought about adding a global variable defaulting to "armhf" and setting it to "arm64" for the new boards in configuration.sh since we later have to call
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- debootstrap --arch=arm64 My goal for now is just being able to spit out an Armbian arm64 rootfs (RELEASE="jessie"/"xenial") I can use with longsleep's image build process to get an idea how far we get with arm64 now (both 3.10.65 and mainline). But I also thought about doing it right from the beginning and stop doing q&d hacks...
 
Any thoughts?

Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users
 
BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.

Success!
 
macbookpro-tk:~ tk$ slogin 192.168.83.88
tk@192.168.83.88's password: 
 ____  _             __   _  _         
|  _ \(_)_ __   ___ / /_ | || |    _   
| |_) | | '_ \ / _ \ '_ \| || |_ _| |_
|  __/| | | | |  __/ (_) |__   _|_   _|
|_|   |_|_| |_|\___|\___/   |_|   |_|
                                       
 
Welcome to ARMBIAN Ubuntu 16.04 3.10.65+ 
 
System load:   0.08            Up time:       2 min
IP:            192.168.83.88
CPU temp:      30°C           
Usage of /:    16% of 3.5G   
 
Last login: Mon Feb 29 12:03:04 2016 from 192.168.83.91
 
tk@pine64plus:~$ uname -a
Linux pine64plus 3.10.65+ #31 SMP PREEMPT Sun Feb 28 18:55:54 CET 2016 aarch64 aarch64 aarch64 GNU/Linux
tk@pine64plus:~$
 
Just kidding, I only used longsleep's Xenial OS image for Pine64 to get a clue what to expect when switching to Xenial (for example packages missing, eg. figlet/toilet) and arm64 in general. I believe it's good to 'just have a look' now before starting to adjust our new templates
 
BTW: I used 'sysbench' the last 2 years to roughly compare performance of ARMv7 boards. Not possible any longer when running on ARMv8 with software compiled for ARMv8:
 
tk@pine64plus:~$ sysbench --test=cpu run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark
 
Running the test with following options:
Number of threads: 4
 
Doing CPU performance benchmark
 
Threads started!
Done.
 
Maximum prime number checked in CPU test: 10000
 
 
Test execution summary:
    total time:                          3.2562s
    total number of events:              10000
    total time taken by event execution: 12.9950
    per-request statistics:
         min:                                  1.21ms
         avg:                                  1.30ms
         max:                                 13.14ms
         approx.  95 percentile:               1.30ms
 
Threads fairness:
    events (avg/stddev):           2500.0000/10.70
    execution time (avg/stddev):   3.2487/0.00
 
(the Raspberry Foundation uses the very same silly benchmark and published today benchmark results for the yet available RPi 3: also ARMv8 based but not that impressive: 49.02 seconds that's just 15 times slower than A64! Maybe they get the idea why it would make sense to make use of Aarch64/ARMv8 architecture and not let code for ARMv6 run on ARMv8 cores in ARMv7 mode )
 
And running these sorts of benchmarks only for a few seconds like above is pretty useless since thermal throttling should also be considered (this happens when sysbench runs for a few minutes and the A64 wears already a heatsink):
 

 
(I made an RPi-Monitor template for A64 already available). Even with this light workload already throttling occurs and CPU frequency will be reduced. And then I tried to run ssvb's new Cortex-A53 cpuburn version but the Pine64+ immediately deadlocked. Seems I have to buy the new 2.5A PSU for RPi 3 to compensate the crappy Micro USB DC-IN connector also used on the Pine boards.

You might want to look here http://www.armbian.com/using-armbian-tools/ forvarious options, between lib.config and customize-image.sh you really shouldn't have to touch the Armbian code at all. I've been through the same process as you and learnt that almost everything can be customized.
 
As you can see from the link, running
compile.sh COMPRESS_OUTPUTIMAGE=no   will prevent Armbian from shrinking your image.
 
As for disabling change of root password and first login, I do exactly the same with customize-image.sh
#Remove annoying user creation at login rm -f /root/.not_logged_in_yet echo -e "password\npassword" | (passwd root) Note that the above will change the root password to "password"

The write speed must be limited by the SSD (small capacity --> less parallelism --> slow write speeds). I hope these little beasts arrive soon:
 

Will then try to do some tests with some SSDs in parallel. BTW: 15 minutes ago a packet from Solid-Run arrived:
 

 
Wow, up and running within 10 minutes including download of your Armbian image: http://pastebin.com/Y3vJmX3H
 
Great first experience. Everything already provided to start through (onboard UART-to-USB adapter, PSU adapter, TF card).

I will give it a try even if it almost hurts to combine such a quality board with cheap JMB321 crap
 
But it will take some weeks for the mechanical adapters to arrive to be able to use 'plain SATA' together with the Clearfog.
 
Thx for the update regarding kernel. Then let's see how far we get with 4.1.x (when I start testing I want to rely on btrfs to detect possible corruptions and there the kernel version matters)

http://www.armbian.com/clearfog/
 
3.10.96 and 4.4.1
 
Jessie and Trusty

Some more measurement:
 
M2 SSD TRANSCEND MTS400 128GB   Write: 1073741824 bytes (1.1 GB) copied, 6.65401 s, 161 MB/s Read: 1073741824 bytes (1.1 GB) copied, 2.07552 s, 517 MB/s   Mechanical 2.5" drive Western Digital 500Gb / 5400rpm   Write: 1073741824 bytes (1.1 GB) copied, 9.56753 s, 112 MB/s Read: 1073741824 bytes (1.1 GB) copied, 10.4673 s, 103 MB/s   SD card Sandisk Extreme PRO 8Gb   Write: 1073741824 bytes (1.1 GB) copied, 68.9829 s, 15.6 MB/s Read 1073741824 bytes (1.1 GB) copied, 68.4105 s, 15.7 MB/s

Update 3 days later: SinoVoip's software/support is worse than ever before:
 
They're still busy fixing essential things long after sales have started: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master They close Github issues without investigation: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/3 They close Github issues without even reading/understanding them and answer pure nonsense to questions: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/4 They provide a faked Armbian image: http://forum.banana-pi.org/t/bpi-m3-new-image-armbian-v4-70-30-11-2015-for-bpi-m3/ Their own images don't boot: http://forum.banana-pi.org/t/bpi-m3-new-image-ubuntu-mate-15-10-for-bpi-m3-20151203/817 Still no MD5/SHA1 checksums to verify download integrity. But it wouldn't help if there were any since even if they provide an MD5 hash, they upload corrupted images at the same time but don't care about. They simply don't give a sh*t about anything else than selling hardware.  
If you buy any product from this vendor be prepared that software/support will be catastrophic.

Overview
 
(Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time  ) 
 
EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source)
 

 
SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki.
 
This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC.
 
Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care 
 
Getting Started:
 
The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off.
 
Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3).
 
To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show.
 
One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also).
 
First Showstoppers:
 
Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works.
 
But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin)
 
First Impressions:
 
Heat (dissipation):
 
The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so:
echo 1 >/sys/devices/system/cpu/cpuX/online Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds.
 
This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead:
 

 
CPU performance:
 
Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink).
 
Network throughput:
 
I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below):
 
BPi-M3 --> Client:
[ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec Client --> BPi-M3: [ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me  )
 
Accessing disks:
 
Since there's a SATA connector on the board I gave it a try.
 
Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!).
 
I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable:
GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441 I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell.
 
I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). 
 
Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse:
GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362 If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better.
 
SD-card and eMMC:
 
Just a quick check with the usual iozone settings running @ 1.8 GHz:
kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660 LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too.
 
EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s
 
Other issues:
 
If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s) Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken)  
Conclusion:
 
Still no idea what to do with such a device.
 
Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead).
 
Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one).
 
And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV 
 
Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis.
 
But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important!
 
Armbian support:
 
Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly).
 
Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.

Which fix? It's easy to improve performance when you do it step by step, start from bottom to top and identify every single factor that affects performance (and there are a lot when it's about slow ARM boards). Everything outlined here, if not feel free to impove the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS
 
And at the moment you can try what you want but there seems to be a limitation that prevents A20 being capable of exceeding 45 MB/s write speed. But since it's still SATA it's superiour compared to USB (especially when you can't use UASP) since random I/O is way better (that's more important for other workloads -- eg. running databases -- than sequential transfer speeds mostly used in braindead benchmarks)

Dear Jens Bauer,
 
three things :
1) when you said : "Since 'ping' reports timeout for the loopback interface 127.0.0.1, I strongly believe that you do not have a valid network connection and therefore SSH will not be available."
That is exactly why I explained here my problem to not having SSH connection and no IP address.
 
2) I used the perfect Jessie Legacy image burned on a new SD but ...
    I changed the /etc/network/interfaces.default to which /etc/network/interfaces is linked to it. I will check the rights to see if they are the same as the default installed when I burned the armbian image on the SD card.
 
3) your idea that could try to boot to the attached HDD (on the SATA port) let me remember I need to test it again without the HDD and perhaps it will solve (in part the boot problem).
 
I will do it during the week-end and will come back with the results.
 
Have a ncie day and thanks for your help ;-)

Well, I doubt that TX DELAY is related to the problems you experience (these delay settings should only matter when you compare different boards or board revisions).
 
But anyway. Now I have a patchset to create 64 u-boot variants with all possible TX/RX delay variations and will give them later a try (with Lamobo-R1 first, will try the very same stuff with my Lime2 if I suceed with testing and this brute-force approach shows good results). I just added two more lines to gmac.c and hope that they will work:
diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c index 8849132..1bce3ce 100644 --- a/board/sunxi/gmac.c +++ b/board/sunxi/gmac.c @@ -26,6 +26,8 @@ int sunxi_gmac_initialize(bd_t *bis) CCM_GMAC_CTRL_GPIT_RGMII); setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY)); + setbits_le32(&ccm->gmac_clk_cfg, + CCM_GMAC_CTRL_RX_CLK_DELAY(CONFIG_GMAC_RX_DELAY)); #else setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_MII | CCM_GMAC_CTRL_GPIT_MII); The diff for modifications of Igor's scripts are here: http://pastebin.com/ZMF89Y57 and you still would need to define 'GMAC_DELAY_TEST="yes"' in compile.sh

BTW: Since I want to play around with both TX and RX delay parameters I started to modify Igor's build scripts for this purpose. Since the build system creates a .deb package for u-boot that overwrites the SPL/u-boot on SD card my idea was to let create all 64 variants of possible TX/RX delay values and then let a script automatically install the different u-boot variants, reboot afterwards, test network performance using ping/iperf, tries the next u-boot.deb until all combinations are tested.
  Currently I got the first step finished: Automatically creating 8 different u-boot .deb packages by adjusting Igor's script.   1) Add  GMAC_DELAY_TEST="yes" to compile.sh   2) Modify one line in lib/common.sh. Exchange  CHOOSEN_UBOOT="linux-u-boot-$VER-"$BOARD"_"$REVISION"_armhf" with  CHOOSEN_UBOOT="linux-u-boot-${VER}-${BOARD}_${REVISION}_${TX}_${RX}_armhf" 3) Add the following lines in lib/main.sh after "grab_kernel_version" # check whether we should just build a bunch of u-boot versions to # brute-force all available GMAC TX/RX delay variations. if [ "X${GMAC_DELAY_TEST}" == "Xyes" ]; then         for TX in 0 1 2 3 4 5 6 7 ; do                 for RX in 0 ; do                         CHOOSEN_UBOOT="linux-u-boot-${VER}-${BOARD}_${REVISION}_${TX}_${RX}_armhf"                         UBOOT_PCK="linux-u-boot-$VER-"$BOARD                         # search defconfig file for $BOARD                         Defconfig="$(grep -i -- "-${BOARD}.dtb" ${DEST}/u-boot/configs/*_defconfig | cut -d: -f1)"                         if [ ! -f "${Defconfig}" ]; then                                 case ${BOARD} in                                         aw-som-a20)                                                 Defconfig="${DEST}/u-boot/configs/Awsom_defconfig"                                                 ;;                                         cubieboard2)                                                 Defconfig="${DEST}/u-boot/configs/Cubieboard2_defconfig"                                                 ;;                                         lime)                                                 Defconfig="${DEST}/u-boot/configs/A20-OLinuXino-Lime_defconfig"                                                 ;;                                         micro)                                                 Defconfig="${DEST}/u-boot/configs/A20-OLinuXino_MICRO_defconfig"                                                 ;;                                         bananapipro)                                                 Defconfig="${DEST}/u-boot/configs/Bananapro_defconfig"                                                 ;;                                         udoo*)                                                 Defconfig="${DEST}/u-boot/configs/udoo_quad_defconfig"                                                 ;;                                 esac                         fi                         # patch defconfig with appropriate tx/rx values                         MyTmpFile="$(mktemp /tmp/gmac_test.XXXXXX || exit 1)"                         trap "cd /tmp; rm -f \"${MyTmpFile}\"; exit 0" 0 1 2 3 15                         grep -v CONFIG_GMAC_TX_DELAY "${Defconfig}" | grep -v CONFIG_GMAC_RX_DELAY >"${MyTmpFile}"                         cat "${MyTmpFile}" >"${Defconfig}"                         echo -e "CONFIG_GMAC_TX_DELAY=${TX}\nCONFIG_GMAC_RX_DELAY=${RX}" >>"${Defconfig}"                         compile_uboot                 done         done         exit 0 fi Step 2) and 3) as patch: http://pastebin.com/RC5WptYB
 
After execution of compile.sh you will end up with 8 different u-boot.debs in output/output/u-boot containing different GMAC TX DELAY settings that can be installed using "dpkg -i".  Execution will stop afterwards.   Next step is to patch gmac.c so that different definitions of "CONFIG_GMAC_RX_DELAY" might lead to different results.

You are probably referring to this:
 
 
http://lists.denx.de/pipermail/u-boot/2014-September/190239.html
 
This is done in uboot so you need to experiment with this parameter:
CONFIG_GMAC_TX_DELAY= (try with numbers from 1-10)
 
File is here:
 
u-boot-sources/configs/A20-OLinuXino-Lime2_defconfig
 
I don't know for any better way than this:
 
1. compile - DD to SD card - reboot
2. test
3. change parameter and try again