petrmaje

If anybody is interested, I've got a single python script that works without needing to install any of the FriendlyElec software. Just enabled i2c0, python and a few dependencies.
 
You can find the code on: https://github.com/crouchingtigerhiddenadam/nano-hat-oled-armbian
The screen turns off after 15 seconds of inactivity to reduce burn-in, variable update rates, splash screen, date/time screen, computer stats screen and a shutdown screen.

The key is to reverse compile dtb to dts, then you get easy readable format of the file. So when you want to change this led to PH20, try this:
 
in first section: allwinner,pins = "PH20"
 
in second section:
 
gpios = <0x1a 0x7 0x14 0x0>;
 
This should work.
I found this way by reverse engineering, but once more gpios parameters:
 
0x1a - I dont konow
0x7 - port group, group is "H"=7 (A=0 etc)
0x14 - port number is 20 (PH20) and when you convert 20 to hexadecimal = 0x14.
 
PM

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.

I'm using webmin, there is module "Linux firewall", where you can nicely configure everything about IPTABLES using mouse. Try it!

Sorry, I forgot attachments

@Igor,
in the meantime, I was able to run some first tests with the ClearFog Pro:
 
1) Using a fast mSATA SSD
 
Samsung SSD 840 EVO mSATA 500GB
  Write: 1048576000 bytes (1.0 GB) copied, 3.06723 s, 342 MB/s (write cache=ON)
1048576000 bytes (1.0 GB) copied, 8.91889 s, 118 MB/s (write cache=OFF)
Read: 1048576000 bytes (1.0 GB) copied, 1.96029 s, 535 MB/s
 
2) Ethernet connection over SFP

Connecting two ClearFog Pro over a SFP fiber link. 
# ethtool eth1 Settings for eth1:         Supported ports: [ FIBRE ]         Supported link modes:   1000baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Advertised link modes:  1000baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Speed: 1000Mb/s         Duplex: Full         Port: FIBRE         PHYAD: 0         Transceiver: external         Auto-negotiation: on         Link detected: yes Network speed was just 1Gbit/sec, we were not able to change the settings to get up to 2.5Gbit/sec.
[ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender [  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver We used the following GBIC's "Brocade GBIC 4 Gbit/s SW FC SFP - 57-1000013-01".
Any clues how to get the maximum ethernet speed over SFP? Maybe for 2.5G there has to be some special settings, or there is something missing in the kernel drivers to support 2.5G. 
Update: 
The 2.5Gbit mode for SFP can be enabled with a patch in U-Boot. I already have prepared the patch and compiled the new u-boot, but I'm having trouble to boot the new image because u-boot has some problems. (will update this post as soon as I have a solution)
 
Update2: (13.03.2016)
We were able to successfully test the 2.5Gbit mode for SFP, using two ClearFog Pro boards connected directly with two Brocade GBIC's and a 1m optical fibre cable. Testing with `iperf3` shows us the maximum network speed which is really excellent.
[ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  2.74 GBytes  2.35 Gbits/sec    0             sender [  4]   0.00-10.00  sec  2.74 GBytes  2.35 Gbits/sec                  receiver 3) COMPEX WLE900VX-7A miniPCIe module

This WiFi module has just arrived, hope to get it running soon...
Specs: AR9880, 802.11ac, 2,4/5GHz, 3*3 MIMO

Update:
WiFi is working, I just added the correct kernel modules and recompiled and installed the new kernel 4.4.4.
CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m Additionally I had to install the correct firmware files for the Compex WLE900VX card:
/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin_10.2.4.70.22-2 /lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin -> firmware-5.bin_10.2.4.70.22-2 /lib/firmware/ath10k/QCA988X/hw2.0/board.bin

I have applied the patches / adapted the fix provided by openwrt for lamobo-r1
 
when zador suggested I use iperf3 to test local/internet (playing with the TCP window as well)
I realized:
- iperf3 results from lamobo-r1 to other (well know network linux) local machine is giving 850 Mbits/s for RX 450 Mbits/s for TX (with 10MB tcp window!) => it matches the statement from openwrt lamobo-r1 (so the fix is working, the bandwidth is CPU limited by the "too many interrupts" as well as TX issues with GMAC)
- iperf3 results from lamobo-r1 to the internet (Max 500Mbit/s down 200 MBits/s up) are RX/450 Mbits/s TX/220 Mbits/s (which is "OK" for my Fiber Internet contract)
- any local machine (my linux PC [former "router"], my Windows7, my odroidXU4), going through the lamobo-r1 is limited to RX/230Mbits TX/210Mbit/s
 
I tought of tkaiser saying the  B53125 has only on GMAC  A20 SoC has only one GMAC link to the B53125 (it would need 2 GMAC one "in" one "out" = at least 2 Gbit/s) to handle traffic in/out
 
so when the lamobo-r1 transfer data from one host to another (I limited my test to local network/Internet), it is doing RX from local/TX to internet (vice versa, handling IRQ for RX and IRQ for TX on the same cpu/thread even when changing this config having 2 cpu/thread available)
=> the limiting factor is TX to the internet / CPU handling the too many IRQ
 
ok, my conclusions are flowed, I would need to do transfer local/local through lamobo-r1 to have a more reliable statement, as I have not studied the impact of IPtables/NAT/etc.
 
so doing A20/GMAC in/out at the same time is limitation, my empiric idea is it cut the A20/GMAC bandwidth par 2 at best
(ok it is flowed)
 
NOTE: I am still hoping for a tech fix to reduce the number of IRQ

Hi Petr, 3 devices at the moment, multicasting a movie to an Apple TV while I made the measurements, and 2 simultaneous devices in the last couple of days without any hitches. For me it is far much better, I never had a wifi connection without stalling to a halt on the client side for more than 2-3 minutes. I will do more extensive tests next week.

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

apt-get update & upgrade will solve everything. 
 
It takes some time that all servers are populated so files might not yet be available in next minutes

Hi,
 
after pure installation Armbian_4.5_Lamobo-r1_Debian_wheezy_3.4.109.zip, the log is full of GMAC messages:
[43099.518189] GMAC TX status: VLAN frame [43099.521192] GMAC TX status: VLAN frame [43099.524646] GMAC TX status: VLAN frame [43111.775611] GMAC TX status: VLAN frame [43112.963963] GMAC TX status: VLAN frame [43112.980989] GMAC TX status: VLAN frame [43112.986370] GMAC TX status: VLAN frame [43112.989681] GMAC TX status: VLAN frame [43112.992410] GMAC TX status: VLAN frame [43112.996184] GMAC TX status: VLAN frame [43113.002038] GMAC TX status: VLAN frame [43113.973308] GMAC TX status: VLAN frame [43113.976078] GMAC TX status: VLAN frame [43114.143583] GMAC TX status: VLAN frame [43114.487643] GMAC TX status: VLAN frame [43114.700444] GMAC TX status: VLAN frame [43115.015755] GMAC TX status: VLAN frame [43115.188027] GMAC TX status: VLAN frame Bug? Or I configured something wrong?
 
PM
 

https://github.com/igorpecovnik/lib/commit/0b4f6424b60b00cf088810e7f8387552ad9ae61d
 
Sources are fixed, kernel recompilation and repository update will follow asap.

Yes, it's a bug ... I'll fix it asap. 

It worked, thanks a lot!
 
The support and dedication you put into this project is outstanding.

:-) I was in the same situation several months before. Lamobo can work perfectly, as both of my lamobo does, but you must: (thanks to Igor, Patcher, Tkaiser etc...)
 
- Operate Lamobo verticaly
- put high profile heatsink to BCM switch (under the harddisk)
- put heatsink to A20
 
If you use ordinary HDD with consumption 500mA, no USB, no WiFi, no HDMI and you have good USB power cable, you don´t need secondary power via battery connector.
 

 
:-) It works )))
 
PM
 
 

Nothing to add, just a breadboard a 4.7K res on a base of a transistor (picture TKasier) and that  petrmaje didn't give up on the R1, makes me smile.  
I geuss Goethe is right again : "In the realm of ideas everything depends on enthusiasm... in the real world all rests on perseverance." 
 
Currently i´am on a D.V.R. with R1 and zoneminder (ipcamera) project, no problems, and damn the A20 still keeps surprising me.
 
Caio from Holland

:-) I was in the same situation several months before. Lamobo can work perfectly, as both of my lamobo does, but you must: (thanks to Igor, Patcher, Tkaiser etc...)
 
- Operate Lamobo verticaly
- put high profile heatsink to BCM switch (under the harddisk)
- put heatsink to A20
 
If you use ordinary HDD with consumption 500mA, no USB, no WiFi, no HDMI and you have good USB power cable, you don´t need secondary power via battery connector.
 

 
:-) It works )))
 
PM
 
 

:-) I was in the same situation several months before. Lamobo can work perfectly, as both of my lamobo does, but you must: (thanks to Igor, Patcher, Tkaiser etc...)
 
- Operate Lamobo verticaly
- put high profile heatsink to BCM switch (under the harddisk)
- put heatsink to A20
 
If you use ordinary HDD with consumption 500mA, no USB, no WiFi, no HDMI and you have good USB power cable, you don´t need secondary power via battery connector.
 

 
:-) It works )))
 
PM
 
 

Wooww !! Great !
 
Thank you for your great recipe, it is working great !
So the only way to work with device tree is to reverse engineer the code ?
 
It was really hard to find the right info on the net ! I hope it is going to be a little bit easier for battery management, not sure :s 

Now all things are working
 
-> Great Job: @petrmaje, @tkaiser 

yes, now ok

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

 

 

 

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.

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

Hi petrmaje
 
With my farmer logic its probly your Broadcom BCM53125 chip that sits right under your HDD.
Your prbly dont have a HDD attached that funktions (@here) as a very luxury cooling plate with additional data parking space.
 
My sollution :
 
If your using the standard acrlyc housing loose the sides and put it verticaly like tkaiser said. There is enough space between the acrylic housing backplate to fit in a small cooling element/plate. Always cool the A20 but thats not the problem imho. Well i dont have it build like Tkasier but its realy stable 2 altough i might paint it black 2
 
see pictures
 
loose the side panels
 
cool your BCM53125 chip
 
 
Sinc Patcher