gnasch

Hi together,

I spent a lot of time in understanding the SPI driver architecture, and I came to the conclusion that I cannot gain the performance required for my application while using this linux SPI driver. Maybe I am wrong with that, but each SPI transfer requires traversing a driver architecture of three levels (spi-sun4i.c, spi.c, spidev.c) with many function calls in between. Even if the time for a pure SPI data transfer is determined by the SPI clock frequency only, the setup time before starting the transfer is significantly longer.
This does not play a role as long as we want to readout a temperature or inertial sensor a few ten times per second, but for controlling a QVGA tft display it is definitely too slow.

The display in question (see http://admatec.de/pdfs/C-Berry_0.pdf)is shipped with a demo software for the Rapsberry Pi, and on an Raspberry (an old model B+) I interestingly do not have any performance issues. The display runs as expected with about 2-3 fps. So I looked into their source code and found that they bypass the kernel's driver architecture. The software is based on the BCM2835 library which seems directly write into the peripheral registers via /dem/mem. In the BCM library documentation is said

"In order for bcm2835 library SPI to work, you may need to disable the SPI kernel module [...]"

There is a port of the bcm2835 library available for the Banana which claims to be fully compatible, but in fact the Banana version takes the long way over the linux driver which is about 10 times slower.

In order to come to a solution, I went the same way as the Raspberry software and handled all the SPI and GPIO stuff via the /dev/mem interface. The display performance is comparable to the Raspberry version now. However, accessing peripheral registers directly from the user space is clearly a nightmare from the kernel's point of view. So I decided to go the clean way and changed it into a separate kernel driver. Somebody already wrote a framebuffer driver for this display on the Raspberry again. I modified this driver and replaced the BCM specific parts by the A20 register interface. Then I build a kernel version without any SPI driver (except mine). There is still some potential or enhancement, for example I  take control over some GPIO pins even if the GPIO register space is occupied by another driver. Here I have to take care not to change any GPIOs used by other devices. However... it works.

It was a very long way to come here, but I think this is the best way. I tested some small demo applications using pygame. The speed is as I would expect from an SPI connected display.



 

Today I made a cooling radiator for Orange Pi One.
I used a heat sink on the motherboard.
I used the thermal paste GD900 and a little glue. One drop at angles.

 
 

 
Now idle temperature of 26 °С
In load mode:
root@orangepione:~# sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 run temperature of  42-43 °С
I think this is a great result !!!

Hi All,
 
After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
 
Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
 
1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
[ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
 

 
Solution?
 
Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
 
There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
 
So to fix, you need to type in the console:
sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
 

 
Press 'm' and you'll get the green 'OO', which means it's now active.
 

 
Exit alsamixer, and when you're back at the console type:
sudo alsactl store 0 ... to store you mixer settings.
 
For your information, the mixer settings are stored to the file:
/var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
       control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
 
As you might or might not be aware, the default /etc/asound.conf file looks something like this:
 
pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
# Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      

This is my final solution to this issue.   I hope it works consistently for everyone.
 
This applies to Armbian Jessie 5.15 Desktop.  No idea at this point about other versions.
 
After many trials, I find that wicd is broken.  Some confirmation can be found here: http://forum.armbian.com/index.php/topic/1775-wicd-gets-erroneous-bad-password/?p=14708
 
So abandoning wicd, I uncheck all "Automatcially connect to this network".
 
I turned to this post as a guide: http://askubuntu.com/questions/406166/how-can-i-configure-my-headless-server-to-connect-to-a-wireless-network-automati/406167#406167to use /etc/network/interfaces to do my connecting instead of wicd doing the connecting.
 
/etc/wpa_supplicant.conf
ap_scan=1 ctrl_interface=/var/run/wpa_supplicant network={ ssid="xxxxxx" scan_ssid=1 psk="yyyyyyy" } added to /etc/network/interfaces
auto wlan0 iface wlan0 inet dhcp pre-up sudo wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf -Dnl80211 post-down sudo killall -q wpa_supplicant [The following may not apply to everyone.  It might have been needed in my case because I began experimenting by plugging in a wifi dongle when I was having trouble with the built in wifi.  But if you have issues described below, it may help]
 
I was able to connect to my wifi ONCE, after rebooting it would not connect.  I couldn't see why, until I did an ifconfig -a, and I saw that instead of wlan0, it was wlan1...  I then just changed things to wlan1, and it worked ONCE.   So why is it changing?
 
It came down to the contents of /etc/udev/rules.d/70-persistent-net.rules, which records the mac address of the wlan interface and assigns device ids accordingly.
 
According to this post: http://forum.armbian.com/index.php/topic/1738-opi-lite-mac-address/the realtek driver generates a random mac address under certain conditions. 
The contents of /etc/modeprobe.d/8189fs.conf in my setup had a mac address in it that would indeed cause a new random mac to be generated.
 
So I changed it to one of the random macs that it generated.   I'd suggest that you use 00:e0:4c:xx:yy:zz where you randomly make up 3 hex bytes for xx:yy:zz  However if you don't come to my house, nor have multiple orange pi's on your network, you can just copy the line.
 
/etc/modeprobe.d/8189fs.conf
options 8189fs rtw_initmac=00:e0:4c:88:b2:2c I then removed all the wlan* entries from /etc/udev/rules.d/70-persistent-net.rules
 
That last step may not be needed if you've never plugged in any wifi dongles to the usb port.
 
 
I'm just happy it works now, and is consistent.
 
I'm convinced that my previous attempts at various command line and network script fixes found here and elsewhere where hindered by wicd running and trying to connect (since I had "Automatically Connect" set).  Once I determined that wicd was in the way, I was able to get things working.
 
/K

Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
 
Hi All,
 
I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
 
Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
 
However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
 
Step 1) Adjust /etc/lirc/hardware.conf
 
Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
 
For Ubuntu Xenial (September 2017):
 
The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
# /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
For Debian Jessie (~year 2016):
 
By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
 
Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
# Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
  As lirc is actually already running and installed in Armbian, do the following:
 
root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
 
Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
  user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
    Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
Pressing the remote reveals events like:
Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
 
 
Step 5) Configure lirc to map IR input to key presses or events.
 
Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
 
There's plenty of information on how to use irrecord, command I used was:
/etc/init.d/lirc stop ...to first stop the service, then:
irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
 
 
Step 6) Test with irw
 
Now that I recorded my configuration file with irrecord:
/etc/init.d/lirc start .. to start lird service again
 
then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
  Step 7) Create a /etc/lirc/lircrc file to run commands
 
sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
# http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
 
 
Additional References:
[Guide] Android + InfraRed (IR) + Kodi 
How to setup Remote Control for Linux

Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup.
  I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO.   Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect.   Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable).   When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS.   The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!)   I used iozone with 3 different runs: 1 MB test size with 1k, 2k and 4k record sizes 100 MB test size with 4k, 16k, 512k, 1024k and 16384k (16 MB) record sizes 4 GB test size with 4k and 1024k record sizes The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size.   The results:   NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage:   Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected )   ODROID-C2 @ 1536 MHz / 3.14.74-odroidc2 / xenial / USB Mass Storage:   Sequential transfer speeds with USB: ~39MB/s with 1MB record size and ~10.5MB/s at 4K/100MB. All USB ports are behind an USB hub and the performance numbers look like there's always some buffering involved (not true disk test but kernel's caches involved partially)   Orange Pi PC @ 1296 MHz / 4.7.2-sun8i / xenial / UAS:   Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian)   Banana Pi Pro @ 960 MHz / 4.6.3-sunxi / xenial / SATA-SSD vs. USB-HDD:   This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are.   SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present).   The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only.   Lessons to learn? HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question) With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important) It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs! Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality. If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes).   So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds).   I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.

There is a desktop version of armbian, but you may will have trouble with wicd, a GUI program that is supposed to
help set up the network connections. When this happens, search for "tutorial wireless success" in this forums *titles*,
then apt purge wicd and configure it by hand.
Be sure to read the Docs: http://docs.armbian.com/
Please forget about configuring your system with the GUI. You will use the command line tools, and you will
have to read, google and learn a lot, From a user perspective armbian is like debian and mostly like ubuntu.
So general user instructions on these systems can often be cautiously adapted.
Many of the problems you will encounter have already been solved in this forum, so use the search.
 
best wishes,
gnasch

-
 

Started to write a long wall of text several times, but wasn't happy with the result, so to keep this short:
 
Making Armbian for selected number of boards and kernel configurations more IoT friendly is possible, but requires some effort to maintain (for mainline kernel).
Compared to RPI we don't have uniform interface for activating and configuring different hardware interfaces, so everything should be done (for legacy kernel) and maintained (for mainline) for each SoC and board/group of similar boards individually.
 
GPIO group and udev rules should be done as an option in armbianmonitor (since we don't have any GUI/dialog based system configurator) should be provided by default in board support package, users will be able to use this by adding themselves to "gpio" group.

IT WORKS!!!! DAMN IT WORKS!!!!!!!! I HAVE SUCCESFULLY UPGRADED ALL PACKET IN LESS OF 5 MINUTE!!!
 
i have no idea why first was not working, but now as worked! I have upraded via remote terminal (ssh and Putty on windows)

FYI for anyone else wanting to avoid having Armbian use all your SD card when it first boots... 
a) download armbian and write image to SD. Don't boot with it yet!
plug SD card into a running linux system as external drive (e.g. via a USB-SD adapter) - I just used a previous Armbian image on my Banana Pi - and mount it,
c) cd to the card's root directory
d) echo 50% >root/.rootfs_resize     <<Where 50% is the amount of the actual SD card you want to utilize
e) sync and remove card.
f) Boot it
e.g. I used a 4GB card and set it to resize to 65% and now my Armbian is using 2.4G of the 4G card.  I want this because I keep my images compact so I can zip up the SD image and send it to my factory in China (who I have set up with a production programmer/tester device using BananaPi + Armbian)
 
Thanks Armbian guys, I can barely express how much I love your work. My fave distro for embedded systems EVER!

Nope
 
The real fix will be delivered as an update within the next 2 weeks (fixing fex file to allow downclocking to 240 MHz). Just received a fat parcel from FriendlyARM a few minutes ago and fortunately they also added two NanoPi M1. So within the next few days we come up with a few fixes for H3 boards.
 
But I'll start with the octa-core Nano-Cluster first
 

I am a sailor and use OpenCPN for the navigation chart plotter. The charts load and zoom much faster with hardware openGL/ or ES.
It has a way to display rendering technique and frames/sec and is barely useful without acceleration. It is very nice with it, even on the Orange Pi One. But I will use the Opi PC Plus for my final installation.
 
I compiled opencpn(4.2 and 4.4) on the default Jessie desktop of both 5.05 and 5.10. I will be recompiling on 5.17 soon.
 
So it is not only games and display managers that use openGL and hardware acceleration.
Thank you all for armbian and the rest.

try depmod -a

Members of the forum may like to know that I have used Armbian's image of Debian Jessie for Orange Pi Lite Wifi that I found quite easy to set up.
 
I have connected Orange Pi to a PIC device to control it with Telegram bot.
 
My tutorial can be read at my blog Redacacia:
 
https://redacacia.me/2016/07/17/telegram-bot-control-with-orange-pi-lite-wifi-and-axe056-board-with-picaxe-18m2/

When ./compile.sh command is used to compiling a new Armbian version (especially with some source changes for debugging), in case there was an error during compilation, it can be impossible to find real reason of the problem. Log files located in output/debug folder are not very informative - they just show the last message, which also appears on the screen - failed in script line number . The following command was used to get full log of the compilation process:
 
command | tee -a log.txt
 
Hope this will be useful for somebody else (newbie), who like me spent a lot of time trying to understand, why the compilation failed after some changes in kernel configuration.

Update on Tested Working OPI Remote Desktops :
 
Fast reliable ssh-protected remote desktops ( LXDE-based for best performance )
OPI x2goserver - x2goclient - LINUX OPI x2goserver - x2goclient - WinXP, Win7 , Win10 OPI x2goserver - x2goclient - OSX (+Xquartz) Traditional workaround Windows-style ( safer and faster if tunneled via x2goserver-proxy )
OPI xrdp - rdesktop - LINUX OPI xrdp - rdp - WXP / W7 / W10 OPI xrdp - MS rdp - OSX OPI xrdp - aFreeRDP - Android 4.1 / 5.1 OPI as Remote Desktop Client ( Universal Thin Client )
LINUX x2goserver - x2goclient - OPI WXP,W7,W10 terminal server - rdesktop - OPI OSX remote - rdesktop - OPI Virtualbox remote - rdesktop - OPI VNC has not been separately tested, use cases are all covered by x2go or rdp
 
Conclusion :
 
OPI ONE/LITE both show excellent performance when used as terminal servers or remote desktop clients. X2go as a ssh-based terminal service uses the processing power of H3 to dwarf any Windows based RDP setup. X2go on OPI as a proxy for Windows rdp even enables secure and reasonably faster terminal services for Windows.
 
Even the bitty-gritty embedded masters of bitbanging might profit from a multi-desktop grand view of their tiny victims shown on BIG screens and thus enjoy the best of both worlds. Armbian has proven to be a reliable useful platform to turn OPI bricks into useful gadgets.
 
Enjoy !

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).
    I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)   Low end   3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951   They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.   Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).   Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)   I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):     Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination   High end   Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).   You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)     What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)   Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.   And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.   Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.

You may try an atx power supply from an old pc, and connect your OPI with one of these:
 
http://www.ebay.com/itm/4pcs-30cm-1ft-DC-Power-Cable-4-0x1-7mm-DC-Tip-Male-Plug-Straight-CCTV-Cord-Cable-/321914510023?hash=item4af3999ac7:g:1H8AAOSw~bFWPew9
 
this way you can also connect your disks directly.
 
 
if you have several power supplies please join their ground wires on the secondary side.

But why Wens was telling me that C.H.I.P is already using it with Mainline ?
Also Beaglebone is using overlays since awhile, my current kernel on it is beaglebone 4.4.9+.
Samething about RaspeberryPi which is using overlays since awhile, my current kernel on it is raspberrypi 4.4.11+.
 
From my early studies in both RaspberryPi and BeagleBone, Nope, the DT overlays isn't loaded by the bootloader, only the plain DTB is loaded at that time.
Then, when kernel is started completely, there is a service that simply copy overlays defines in a conf file to be copied into something like /sys/bus/platform/devices/bone_capemgr in case of BeagleBone (I don't remember my recent foundings). Same kind apply to RaspberryPi although I don't remember details. The EndUser can also load new overlays/"capes" from command line at the time he wish just before running a software that actually use those "capes"/i2c/spi peripherals.
My next goal is to compile some OrangePi kernel is this flag CONFIG_OF_OVERLAY and see if I can start to upload "dynamic overlays" from UserSpace. If this succeed, then, lot of maintenance tasks, but it will be the way to go, like other boards such RaspberryPi, BeagleBone or C.H.I.P (like Wens emphasised as an example)

Hi @tkaiser,
 
Unfortunately, this task isn't finished ...
First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet.
Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"...
Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did.
So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace !
I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc.
I hope to met expectation, especially that "time is the missing ingredient" !
 
Ciao !

Maybe this is not strictly related to Orange Pi PC but a few weeks ago I had problems with booting my device - mainly OpenELEC and I had to debug it somehow using serial port and the terminal. Unfortunately my PC is rather far from the place where I keep OPiPC. So I was forced to prepare separate device - cheap STM32 MCU based terminal display with 2.2" LCD screen directly supplied from Orange Pi PC 3.3V. It can be used also with other devices which allow serial console debugging.
Watch below videos for more details and the code:


Maybe someone finds it useful.

I have this same issue. It is only on the hdmi console not ssh. I am trying to figure out what is causing it. I have been digging in the code all day. No luck so far. 

I plugged in and tested the 3.95 inch display with Orange Pi PC and Armbian Jessy. It can be used for own use, this is only a test program   
http://pl.aliexpress.com/item/Free-shipping-LCD-module-Pi-TFT-3-6-inch-for-raspberry-pi-display-screen/32236159766.html
 
https://github.com/flexiti/WiringOP

 
Just compile and run displayTFT.c  file (display shows also CPU temperature )