wildcat_paris

Current CAN patch (version 8) consists of 4 parts (driver itself, kernel configs, DT config) and can be found in follow-ups to this message: http://www.spinics.net/lists/netdev/msg343137.html
You'll need all 4 parts, and DT config also needs CAN section in device-specific sun7i-a20-cubieboard2.dts file, as by default in dtsi file CAN controller is disabled.
By the way, mainline kernel just updated from 4.2.5 to 4.3, so right now build process most likely will fail due to outdated kernel config.

Dear Sir.

I really appreciate your enlightenment ...
I Got the picture

Sincerely
-bino-

I think that in sun7i-a20-cubieboard2.dts you need to change
leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; }; }; to
leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 4 11 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 4 10 GPIO_ACTIVE_HIGH>; }; }; and
led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PH20", "PH21"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; to
led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PE10", "PE11"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; You'll need to recompile kernel (or at least device tree part) with build script to get new sun7i-a20-cubieboard2.dtb file.
Alternatively you can try to decompile, change and recompile dtb file with dtc from device-tree-compiler package, but I'm not sure if it will work.

Mainline kernel comes with new gpio driver with standart linux gpio interface, it doesn't need any DT configuration. You need to "export" pin number for it to appear in sysfs tree (I'm assuming you want sysfs access)
Read section "Accessing the GPIO pins through sysfs with mainline kernel" here: https://linux-sunxi.org/GPIO

FYI, I checked, using dtc from device-tree-compiler on device itself is an easier way to make such small changes in Device Tree config.
http://forum.armbian.com/index.php/topic/382-armbian-on-pcduino3/#entry2444
Decompiled dts looks a bit different compared to original, but it's easy to find LED related sections and values.

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

Hello Igor,
 
I am using vanilla 4.4 for labomo-r1
 
it seems zram module is missing. Do you intend to compile the kernel with this option, please?
gr@bpi:~$ sudo modprobe -Rf zram modprobe: FATAL: Module zram not found. On raspbian, kernel 3.18.x-4.1.x, there is a kernel module "zram" useful for embedded systems... working fine (also using on my x86 laptop)
 
https://wiki.gentoo.org/wiki/Zram
 
Nice week-end,
 
Regards,
 
Guillaume
 
 

I have switched back to the armbian kernel and wifi driver
 
I have just tested a copper heatsink on the lamobo USB chipset (also added one copper pad on the switch chipset)
 
it seems the wifi signal is far more stable (within a 5 dB margin) and noticed so far a 5-10 dB lesser noise than previously
 
note: My Dlink 160 (B1) as AP is still 10dB better.
 
So far:
- the heatsink is probably improving thermal condition
- it is so large compared to the chipset... maybe a minor shielding effect

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

I have switched back to the armbian kernel and wifi driver
 
I have just tested a copper heatsink on the lamobo USB chipset (also added one copper pad on the switch chipset)
 
it seems the wifi signal is far more stable (within a 5 dB margin) and noticed so far a 5-10 dB lesser noise than previously
 
note: My Dlink 160 (B1) as AP is still 10dB better.
 
So far:
- the heatsink is probably improving thermal condition
- it is so large compared to the chipset... maybe a minor shielding effect

I had trouble with the wifi and bananian, openwrt AND armbian 4.5. First time I found it, and came to it because bananian and openwrt from sinovoip are full of problems - and netbsd/freebsd unfortunately do not support the switch. I already thought of buying an USB wifi that support 5Ghz...I used to have a new gen Time Capsule and use 5Ghz exclusively, however a power surge killed it - nevertheless it was in the cards setting up an open source solution to control my home traffic. Except for the external antenas I have no doubt it will be far better - ha, and losing the only USB connector.   I am 5m from my Lamobo and having between 83-80% signal, SNR 44dB-34dB connecting to the Lamobo wifi. Guillaume,  had a look at the new driver you mention, no AP mode yet. btw, does anyone know how to disable 802.11b? Already tried some of the official methods, none seems to work.

btw, a new driver replacement to come: rtl8xxxu-nextgen
"This driver is still under development, but has proven to be verystable for me. It currently supports station mode only." no AP yet

Hi Wildcat, Tido sent me the link to the documents in a private message and now put it in his signature. Apparently I had the package already installed, not working for me I am afraid. I will try to get again the original hostap files from the package to test them out.  I suggest also adding that disabling debug patch that I made, the first time my wifi went off, it was because all that garbage on the log file put it out, apparently. 
 
For chester and Petr, I have managed to have my wifi up several days now. Yesterday updated my Mac and iPhone with a lot of concurrent updates all fine. Today, managed to get iperf to 10 concurrent connections and 80Mbps in a single machine from my Mac to my Lamobo (via wifi).

Hi Rui,
 
In my Banana 15.04 manual these steps are documented for a couple months now :-)
In Igor's armbian these steps were not necessary because he already delivers a driver and a fresh hostapd.
 
The only new thing is this, that I found lately and is mentioned in this thread from me as well.
neighbours to enable always 40MHz channels.
 
I hope the first joy, will last long.
 
Cheers
Tido

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

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

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

 

 

 

 

 

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

dtc to old meen you have to install device-tree-compiler

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

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
 

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

Igor,
 
Thanks it is fine with http://mirror.igorpecovnik.com/test/linux-image-next-sunxi_4.5_armhf.deb
gr@bpi:~$ cat /proc/version Linux version 4.2.3-sunxi (root@kitchen) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #16 SMP Fri Oct 9 23:08:18 CEST 2015 gr@bpi:~$ lsmod [...] zram                   17790  2 lz4_compress            3201  1 zram gr@bpi:~$ swapon -s Filename Type Size Used Priority /home2/swap file 4999996 0 -1 /dev/zram0 partition 256980 0 5 /dev/zram1 partition 256980 0 5 ok, now testing... compiling thunderbird 42b1 on my "labomo-r1" FTTH home router
 
Edit : Igor, this is an awesome piece of work! :-)
 
Edit 2 : I am not sure if it is really useful here
CONFIG_CLEANCACHE=y CONFIG_FRONTSWAP=y Edit 3 :
compared to :
- (arm) Raspbian : zsmalloc seems to be missing
- (x86-amd64) Ubuntu 14.04 : the same as armbian : modules zram + lz4_compress
pi@pi ~ $ lsmod Module Size Used by zram 20112 0 lz4_compress 3100 1 zram zsmalloc 10430 1 zram pi@pi ~ $ cat /proc/version Linux version 4.1.10-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #820 SMP PREEMPT Sun Oct 4 16:26:51 BST 2015 Edit 4:
zsmalloc is probably useful : allocate small object to reduce memory fragmentation
http://lwn.net/Articles/477067/
 
zsmalloc is builtin, so ok
gr@bpi:~$ sudo modprobe --show-depends zram insmod /lib/modules/4.2.3-sunxi/kernel/lib/lz4/lz4_compress.ko insmod /lib/modules/4.2.3-sunxi/kernel/drivers/block/zram/zram.ko gr@bpi:~$ sudo modprobe --show-depends -v zsmalloc builtin zsmalloc

I already found and build a kernel ... Will be inside next build. Over and out
 
Thanks!

Fixed.
 
https://github.com/igorpecovnik/lib/commit/8eb7d85a4d1dbeeda857587e0b4d61b5bfe47c11