RagnerBG

H2+/H3/H5 boards overview (2017/03 update)
 
Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
 
I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
 
While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
 
CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
 
In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
 
Hope that helps
 
Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.
 

Hello guys , I try to install Gl4ES  (https://github.com/ptitSeb/gl4es)  with success , in armbian Ubuntu Xenial Desktop .  For GL4ES you need to "put libGL.so.1 in your LD_LIBRARY_PATH". LD_LIBRARY_PATH is  "/usr/lib/arm-linux-gnueabihf" in the same path you need find "mesa" folder and rename it to ".mesa", maybe is the same for glshim.
You can run games like foobillard++ , openarena,quake ,etc .
Gl4ES is a wrapper for OpenGL 1.5, but the Hardware accelerated for chromium or firefox doesnt work.

Hoover over the attached picture and in a right bottom corner you have "Delete".

BTW: To edit picture settings, double click it when insert into post.

First i have to say - if i knew what i am gonna go through, i would never buy this troubled hardware. So don't buy it too. But if you are already strayed like me, i decided to share my modifications, to make this inconsiderate piece of hardware useful. With this mods the device finally work as i need it to and i am fully happy with hardware part. Not so happy with software though, but that's another story.
The main reason for me, to buy this router, except pc like capabilities, was SATA+SATA power connector. I used my old router with usb HDD, so it sounded good to have it in box and on native sata interface. Silly me, who would thought this will be the most troubled part. I thoroughly suspected, this sata port is designed for SSD disks and never provided for mechanical HDD-s, as this AXP209 power scheme, simple can't provide needed >2A in some cases (at spin up) current, for disk only, not to mention the board consumption itself. And native sata interface, is not so native, but lets ignore this.
So, first thing we have to think about, if we are going to use mechanical HDD with this board, is reliable power source. According to our needs 2A are for spin up and perhaps heavy load of HDD and the board with less peripherals should work at 1A, but 2A is by specifications. So 5V, 4A is the optimal power source we need to be sure we will not have hang outs at power on. 5V, 2A (real) is the minimum, but we have to pray at each power on, HDD to not stuck at spin up, so i wouldn't recommend this. In my case, i add some reserve (you know what those chinese power supplies are) and buy this:

Second thing is how to connect this power to the board. It's discussed many times - this micro-usb connector used in Lamobo R1 is not suitable. It can throughput 1.4A by specifications. The board will usually suffer instabilities even with something connected in USB port, not to think about HDD at all. One way is to use battery connector. I was using this method for some time. But there is one major disadvantage. The board will not automatically power on after power loss. We have to push the power button. I had special match stick just for this . Since Lamobo R1 have to be router in major, this is a problem. And here comes the first hardware intervention. We need better power connector added at + and - somewhere on PCB. Near micro-usb is fine, this is my solution (sorry for bad pictures, but will catch the idea):

Of course, we have to find place for the connector somewhere on acrylic case. In my case, it's become more messy than i wanted, but is ok. This way board will automatically boot after power loss, so is suitable for router purposes. This combination (proper psu and connector), make the board stable, but not the attached mechanical HDD. No matter what patch is applied like mentioned here, i still have situations when, at power on, board is powering, but attached HDD can't spin up and just ticking. It's often enough not not count on this for long term of work. So other, more drastic solution is needed.
Hardware mod number two, is to attach HDD power directly to PSU connector, avoiding AXP209 PMU and attach only sata - data part to board. I modified one of these:

On the bottom is my earlier self made sata cables. They worked, but coast me troubles with connectivity on the board part mostly and kernel automatically drop speed to SATA1. So on the above adapter i am using full male part for the board, with power cords cutted off. On the other side, sata - data cable is cutted and resoldered to sata data connector. And power for the HDD is from separate power sata connector wired directly to our new, power connector for the board. This is necessary, because there is not much space left if passive cooling is placed on SoC, as in my case. If someone is creative, or can't solder those tiny wires, can use lower radiator, or no at all. Or simply remove the side lid. In this case, above adapter can be used without much modifications, just cut the power cords on the male side and solder to the power connector. But i decided to make it clean. I didn't make pictures before everything to be assembled, but bellow can be roughly seen, what i am talking about:


As it's also seen, HDD have to be placed on the top cover, with at least two holes. This will not prevent power management of HDD in any way. Both hd-idle and hdparm (from what i tested) are able to spin down HDD this way. This is the only permanent for sure, solution i found for HDD powering on this board.
 
Here is the part to mention passive cooling of the board, as it is capable of overheating. Above is seen radiators i placed for SoC and RAM modules. But it's not the most heating part of the board, it is the switch chip - BCP53125. So some lower radiator is good for there. And also some small and lower radiator for PMU, especially if adding of USB peripherals is planned:

 
Mod three. Who own this board, is well known of it's crappy and unuseful wifi module. It's good for client, but not for AP mode, what is needed for actual router. I hardly reach 1Mb/s speed with it for single client and it's drop connection often. I was using external USB wifi module for AP mode. But inspired of this - Hardware Mod BPi-R1, i bought the same Ralink MT5572 module and do the same mod. My advice of removing the old module, is to cut 6 antenna pads with some utility knife and simply move the module up/down until it digress from the rest 7 pads. Then soldering the new module is easy:

As for the MT5572 module, it's very good for AP . 2.4Ghz/5Ghz capable, 30dBm output power. Range is more than on my old 24dBm router, no matter the 3 antennas. And we don't even have to talk about bult-in, old RTL8192CU, 20dBm (but this is the least problem of it) module. Some parameters:
I am using OpenWrt as OS for now. I just can't find anything so suitable for my needs, especially in firewall part. I have some ideas for "computer" part of the board in the future, but this will be for now, because i am bored and tired of this crappy piece of... nothing out of the box. OpenWrt is stable:

Some logs:
Don't mention redundant packages i added. With this "huge" sd cards, i am like - "hey, i am not sure what this is, but looks like i can use it someday, let's add it" . It's different when you have to fit it in 4/8Mb flash. Maybe some day i will make minimal image with only important stuff.
And finally at work :

 
Last thing i think i have to mention, as it is related to hardware too. There is this post of @tkaiser. It is all true. So if someone want a real router of this board, external USB LAN adapter is needed. I used this one:

It's specially chosen for this board because of USB hub and Gigabit LAN. Lamobo R1 have two USB interfaces - normal and OTG. But OTG have bug when acting as OTG and in all images and OS-s i know is disabled. I can enable it only in legacy Linux images and i need USB. That's why i was using this external LAN adapter for WAN interface. Saying "was", because, even if i agree with all in above post, i am one of those who actually think like this - 'hey, the few seconds when the device is booting... who cares that WAN and LAN are bridged?' I actually use pppoe and really don't care if my few devices will bet exposed to my ISP small local network for few seconds. So i am using vlans. And in a matter of fact, i've seen a lot of cheap routers with the same switch with vlans solution, or at least it look like this. So take it as you will, it's good for my needs. But if you want real router functionality with separate interfaces, consider adding some USB LAN like above and do yet another hardware mod of this board.
 
Sorry for the long post. I left this here if it could be useful for someone.
 

First i have to say - if i knew what i am gonna go through, i would never buy this troubled hardware. So don't buy it too. But if you are already strayed like me, i decided to share my modifications, to make this inconsiderate piece of hardware useful. With this mods the device finally work as i need it to and i am fully happy with hardware part. Not so happy with software though, but that's another story.
The main reason for me, to buy this router, except pc like capabilities, was SATA+SATA power connector. I used my old router with usb HDD, so it sounded good to have it in box and on native sata interface. Silly me, who would thought this will be the most troubled part. I thoroughly suspected, this sata port is designed for SSD disks and never provided for mechanical HDD-s, as this AXP209 power scheme, simple can't provide needed >2A in some cases (at spin up) current, for disk only, not to mention the board consumption itself. And native sata interface, is not so native, but lets ignore this.
So, first thing we have to think about, if we are going to use mechanical HDD with this board, is reliable power source. According to our needs 2A are for spin up and perhaps heavy load of HDD and the board with less peripherals should work at 1A, but 2A is by specifications. So 5V, 4A is the optimal power source we need to be sure we will not have hang outs at power on. 5V, 2A (real) is the minimum, but we have to pray at each power on, HDD to not stuck at spin up, so i wouldn't recommend this. In my case, i add some reserve (you know what those chinese power supplies are) and buy this:

Second thing is how to connect this power to the board. It's discussed many times - this micro-usb connector used in Lamobo R1 is not suitable. It can throughput 1.4A by specifications. The board will usually suffer instabilities even with something connected in USB port, not to think about HDD at all. One way is to use battery connector. I was using this method for some time. But there is one major disadvantage. The board will not automatically power on after power loss. We have to push the power button. I had special match stick just for this . Since Lamobo R1 have to be router in major, this is a problem. And here comes the first hardware intervention. We need better power connector added at + and - somewhere on PCB. Near micro-usb is fine, this is my solution (sorry for bad pictures, but will catch the idea):

Of course, we have to find place for the connector somewhere on acrylic case. In my case, it's become more messy than i wanted, but is ok. This way board will automatically boot after power loss, so is suitable for router purposes. This combination (proper psu and connector), make the board stable, but not the attached mechanical HDD. No matter what patch is applied like mentioned here, i still have situations when, at power on, board is powering, but attached HDD can't spin up and just ticking. It's often enough not not count on this for long term of work. So other, more drastic solution is needed.
Hardware mod number two, is to attach HDD power directly to PSU connector, avoiding AXP209 PMU and attach only sata - data part to board. I modified one of these:

On the bottom is my earlier self made sata cables. They worked, but coast me troubles with connectivity on the board part mostly and kernel automatically drop speed to SATA1. So on the above adapter i am using full male part for the board, with power cords cutted off. On the other side, sata - data cable is cutted and resoldered to sata data connector. And power for the HDD is from separate power sata connector wired directly to our new, power connector for the board. This is necessary, because there is not much space left if passive cooling is placed on SoC, as in my case. If someone is creative, or can't solder those tiny wires, can use lower radiator, or no at all. Or simply remove the side lid. In this case, above adapter can be used without much modifications, just cut the power cords on the male side and solder to the power connector. But i decided to make it clean. I didn't make pictures before everything to be assembled, but bellow can be roughly seen, what i am talking about:


As it's also seen, HDD have to be placed on the top cover, with at least two holes. This will not prevent power management of HDD in any way. Both hd-idle and hdparm (from what i tested) are able to spin down HDD this way. This is the only permanent for sure, solution i found for HDD powering on this board.
 
Here is the part to mention passive cooling of the board, as it is capable of overheating. Above is seen radiators i placed for SoC and RAM modules. But it's not the most heating part of the board, it is the switch chip - BCP53125. So some lower radiator is good for there. And also some small and lower radiator for PMU, especially if adding of USB peripherals is planned:

 
Mod three. Who own this board, is well known of it's crappy and unuseful wifi module. It's good for client, but not for AP mode, what is needed for actual router. I hardly reach 1Mb/s speed with it for single client and it's drop connection often. I was using external USB wifi module for AP mode. But inspired of this - Hardware Mod BPi-R1, i bought the same Ralink MT5572 module and do the same mod. My advice of removing the old module, is to cut 6 antenna pads with some utility knife and simply move the module up/down until it digress from the rest 7 pads. Then soldering the new module is easy:

As for the MT5572 module, it's very good for AP . 2.4Ghz/5Ghz capable, 30dBm output power. Range is more than on my old 24dBm router, no matter the 3 antennas. And we don't even have to talk about bult-in, old RTL8192CU, 20dBm (but this is the least problem of it) module. Some parameters:
I am using OpenWrt as OS for now. I just can't find anything so suitable for my needs, especially in firewall part. I have some ideas for "computer" part of the board in the future, but this will be for now, because i am bored and tired of this crappy piece of... nothing out of the box. OpenWrt is stable:

Some logs:
Don't mention redundant packages i added. With this "huge" sd cards, i am like - "hey, i am not sure what this is, but looks like i can use it someday, let's add it" . It's different when you have to fit it in 4/8Mb flash. Maybe some day i will make minimal image with only important stuff.
And finally at work :

 
Last thing i think i have to mention, as it is related to hardware too. There is this post of @tkaiser. It is all true. So if someone want a real router of this board, external USB LAN adapter is needed. I used this one:

It's specially chosen for this board because of USB hub and Gigabit LAN. Lamobo R1 have two USB interfaces - normal and OTG. But OTG have bug when acting as OTG and in all images and OS-s i know is disabled. I can enable it only in legacy Linux images and i need USB. That's why i was using this external LAN adapter for WAN interface. Saying "was", because, even if i agree with all in above post, i am one of those who actually think like this - 'hey, the few seconds when the device is booting... who cares that WAN and LAN are bridged?' I actually use pppoe and really don't care if my few devices will bet exposed to my ISP small local network for few seconds. So i am using vlans. And in a matter of fact, i've seen a lot of cheap routers with the same switch with vlans solution, or at least it look like this. So take it as you will, it's good for my needs. But if you want real router functionality with separate interfaces, consider adding some USB LAN like above and do yet another hardware mod of this board.
 
Sorry for the long post. I left this here if it could be useful for someone.
 

This do the trick for me. Thank you .

To be honest, i don't like new look of the forum. It is used from some time, in some other forums i used to visit, so i have a look into this already. I can't explain it well, but the skin and arrangement itself are confusing and dysfunctional for me. The biggest problem is Unread Content/All activity. This focusing on posts and not topics itself is not comfortable for me. It is not so notably here, but in forums with more activity is madness and making following of new treads and topics impossible. Not all "improvements" are good and i can't guess who can decide this as better. But i guess you have some functional reason for this upgrade, which is downgrade in my eyes. Maybe going into some other forum platform is better idea. After all, this is me, maybe other visitors would find it better.

To be honest, i don't like new look of the forum. It is used from some time, in some other forums i used to visit, so i have a look into this already. I can't explain it well, but the skin and arrangement itself are confusing and dysfunctional for me. The biggest problem is Unread Content/All activity. This focusing on posts and not topics itself is not comfortable for me. It is not so notably here, but in forums with more activity is madness and making following of new treads and topics impossible. Not all "improvements" are good and i can't guess who can decide this as better. But i guess you have some functional reason for this upgrade, which is downgrade in my eyes. Maybe going into some other forum platform is better idea. After all, this is me, maybe other visitors would find it better.

These packages are for default OpenWRT kernel and don't affect the kernel in unofficial Zero builds. Also firmware may be missing for the realtek wireless adapters.

I think it has something to do with SMB access method and mounting of the shares. If you had some incorrect path errors, then the file manager passed raw smb:// file path to the player and not all players support that (i.e. vlc requires installing additional plugin and even with it will happily throw you an error if there are spaces in file/directory names).
 
And it was probably "fixed" when we added additional packages to desktop images - gvfs-backends and gvfs-fuse. In this case file managers that support GVFS will mount SMB share locally so any players will access the path like a local FS and will easily pick up the external subtitles.

Oh, i missed that. I guess i have to try build it, instead of installing the .deb.

Can't run kerberosio in Armbian Xenial 5.25 i installed everything from the instructions:
kerberosio: error while loading shared libraries: libavcodec.so.56: cannot open shared object file: No such file or directory but it is there:
libavcodec-ffmpeg.so.56 => /usr/lib/arm-linux-gnueabihf/libavcodec-ffmpeg.so.56 (0xb5e75000) I am not sure what this mean:
~$ sudo ldconfig -v | grep libavcodec.so /sbin/ldconfig.real: Path `/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: Path `/usr/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: /lib/arm-linux-gnueabihf/ld-2.23.so is the dynamic linker, ignoring libavcodec-ffmpeg.so.56 -> libavcodec.so ffmpeg is from standard repos:
ffmpeg version 2.8.10-0ubuntu0.16.04.1 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 5.4.0 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 20160609 configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libavresample 2. 1. 0 / 2. 1. 0 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Maybe i have to compile it from source. I miss vdpau and libx265 for example. Or to try to install libavcodec from ubuntu-restricted-extras/libavcodec-extra?

It should be this part, which should be sth. like this
int operation_type = (rgba_dst->flags & RGBA_FLAG_NEEDS_CLEAR) ? PIXMAN_OP_SRC : PIXMAN_OP_OVER; pixman_image_composite32( operation_type, src, NULL, dst, (src_rect->x0 * fscale_x), (src_rect->y0 * fscale_y), 0, 0, dst_rect->x0, dst_rect->y0, (dst_rect->x1 - dst_rect->x0), (dst_rect->y1 - dst_rect->y0)); Not tested though
 
Regards rellla

The problem is not player related. On older architectures - A10/20 there is OSD and subtitles are fine. On H3>, software solution is used, through Pixman and there is this bug. I thought Pixman is causing the bug i tried to install different versions, but players always used built in version. I didn't thought it could be libvdpau-sunxi issue itself, this is beyond my potentialities. But it's definitely not player issue.

Instead, we were rewarded. Not many got this privilege.
 
 
 
https://distrowatch.com/weekly.php?issue=20170116#donation

This post is to share my successful webcam installation with Armbian and one of my SBC’s (orange pi plus).
 
I’ve used a Logitech C270 which can be purchased from eBay for roughly 20 Euros. Also el-cheapo shops like lightinthebox sell the C270. Benefit of such a cam is that you now have a cable from your SBC to your cam which makes (physical) cam installation easier IMHO. Also IMHO the C270 is a better camera than the famous GC2035, but it is also more expensive. Price / 'bang for the buck' ratio is more or less the same for both camera’s if you ask me. You get what you pay for.
 
Enough talk now: the installation
 
All I did was a fresh Armbian desktop v5.20 installation. The Armbian desktop version makes file editing easier, but is not mandatory. Nano / vim etc. can do this job via SSH as well. Performed the usual ‘apt update’ and ‘apt upgrade’ + reboot after installation. Then after restart ‘apt install xrdp tightvncserver motion’. xrdp and tightvncserver enable remote desktop. This is not needed for camera operation, but makes life easier… you can now access your Armbian installation with the Microsoft remote desktop protocol. The C270 camera works right out of the box and is auto-detected by Armbian. Also the needed modules are loaded automatically (use the lsusb and lsmod commands to see it).
 
Now edit /etc/motion/motion.conf with your favourite editor. 
 
Highest resolution I could get from the C270 camera is 1280x960. (search for ‘width’ and ‘height’) and adapt accordingly.
 
Find ‘stream_localhost’ and turn it off. Otherwise you won’t be able to http-stream to other computers.
 
Change ‘target_dir’ to anything you like, but preferably a folder outside of your armbian board with more storage capacity. Movies are rather large and may fill up your sd card or EMMC quickly. Make sure motion has writing privileges in the folder you choose.
 
Then (very important!) edit /etc/default/motion and set “start_motion_demon†to “yesâ€. Otherwise the daemon won’t start. 
 
Now a ‘sudo service motion restart’ should start motion. A ‘sudo service motion status’ might provide more info about issues.
Then the magical moment: direct your browser to http://your_armbian_board_address:8081 and it should provide the stream of your camera. When movement is detected, avi files are stored in the folder you’ve entered in motion.conf.
 
Further you can tweak some settings from /etc/motion/motion.conf according you your needs. I have disabled ‘output_pictures’ because I am not interested in a JPG file along with a movie file. The default motion detection threshold of 1500 works fine for me (recording backyard).
 
Every time you change something in /etc/motion/motion.conf you have to issue a ‘sudo service motion restart’ to load the new parameters. Always keep a copy of a working motion.conf file; this is helpful in case of mistakes / typos etc.
 
 
 
 
Good luck!

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.      

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

I am not sure i understand what you ask. If it's really - "Is it possible to view desktop view remotely, without having desktop installed on server", the answer is obviously - no, you can't view something you don't have installed. If you want to - "view desktop view remotely", you have to install desktop first, then follow the advises in this topic. I think it will be easier to use tasksel. It will add a lot of staff and packages, but if you have at least 16Gb sdcard it is no problem. So in console execute this:
sudo apt-get update sudo apt-get install tasksel sudo tasksel Then check "Xubuntu desktop" for XFCE, or "Lubuntu Desktop" for LXDE. After installation finish, reboot and install what is needed for remote view from topic.
If you only need console access to your server, just use ssh. If you don't have ssh server (i am pretty sure armbian have it installed by default) just install it:
sudo apt-get update sudo apt-get install openssh-server

As i own Samsung tv, i think your problem is not Armbian related, but you have to set up your tv properly. Go to your tv MENU and search for this option in Picture:

 
if 16:9 zoom and cut the screen to you, as to me in most of HDMI devices.

Hello to all
Now I'm doing my device based on Orange PC
It will be in the casing so it needs cooling.
I assembled a small fee for fan control
And he wrote a program for controlling and monitoring work
It can run as a daemon
 

 
To use I chose to 12V FAN 3PIN. To safely manage them with our Pi PC is necessary to collect the scheme in three transistors.
In the transistor Q3 will be lost that is 0.6V 5% of 12V. Therefore, the maximum speed of passport we can not achieve.
I have received the maximum at 2400 rpm of maximum 2500 passport.
Capacitor C1 pick up empirically, since of it will depend on the minimum threshold drawdown tachometer. As the tachometer now use Hall sensor.
For myself, I put 100uF, because with 50uF at a duty ratio of less than 50% control of the lost turnover.
 
To work it is necessary:
- Kernel with support for GPIO Support (sysfs interface)
- WiringOP from WereCatf https://github.com/WereCatf/WiringOP.git
git clone https://github.com/WereCatf/WiringOP.git -b h3 cd WiringOP chmod +x ./build sudo ./build  
Installation:
- Unpack the archive
- Define the value set that you need.
    Pina, minimum and maximum temperature, the number of Hall sensor pulses per revolution of the cooler, while the demon of the reaction, the minimum duty cycle.
- compile
g++ OPi-fan.c -o OPi-fan -lpthread -lwiringPi - Copy of your directory in /usr/local/bin
cp ./OPi-fan /usr/local/bin After that it can be used using various keys run.
The daemon reads the CPU temperature and basis of specified minimum and maximum temperature calculates the duty cycle of the PWM.
The software PWM. The same demon able to calculate RPM cooler. Data on the temperature, porosity and number of revolutions can be obtained from the console.
I tried more or less to describe the online help available on the key -h.
 
Legs please do not kick as programmer from me bad:D :D
 
https://github.com/StaLeWaR/OPi-Fan
 
Display in RPi-Monitor

Hello. Browsing through my email i note something from long forgotten, useless http://forum.banana-pi.org. It's about some new images they "release" like:
BPI-R1 new image:raspbian-jessie-bpi-m1-m1p-r1.img 2016-07-13

BPI-R1 new image:ubuntu-mate-16.04-desktop-armhf-raspberry-pi-bpi-m1-m1p-r1-sd-emmc 2016-07-21
or
BPI-R1 new image: Kanux-Beta-3.3.0-preview-bpi-m1-m1p-r1.img 2016-07-15
There is a note - "kernel 3.4.112 (based on armbian's build)", so hem, congratulations i guess. Looks like you guys are official support for team bpi now .

Hello,
 
I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.
 
Here are the commands I used to get OpenGL to work.
 
1. Install:
# install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone https://github.com/robclark/libdri2 git clone https://github.com/linux-sunxi/libump git clone https://github.com/linux-sunxi/sunxi-mali git clone https://github.com/ssvb/xf86-video-fbturbo git clone https://github.com/ptitSeb/glshim # install mali driver cd sunxi-mali                                                                    git submodule init                                                               git submodule update                                                             git pull                                                                         wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h             wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h    make config ABI=armhf VERSION=r3p0                                               mkdir /usr/lib/mali                                                              echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                             make -C include install                                                          make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install            cd .. 2. Build
# Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system
- configure your kernel to allocate memory for the GPU
- make sure mali and mali_drm kernel modules are loaded
- give your user permissions to access /dev/ump and /dev/mali
- configure Xorg to use fbturbo driver
 
4. Test:
# run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.
 
Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):
user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGLESv1_CM.so libGL:loaded: libEGL.so 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C

There is a huge overscan on this boards and your login screen is hidden bellow. Just enter default login and pass and change resolution later, or adjust screen position with your monitor controls. If you use Desktop version of image, it will boot after you change your root pass, create new account and reboot. I was confused too at the beginning, but there is nothing wrong with the OS.

It's not that hard to build ffmpeg on Armbian, directly from official source. I will show all steps i am using and all codecs i install, if some is not needed, skip and remove it from ffmpeg ./config. First i create some temporary folder, it's named "t" in this example. Then we can get dependencies with "apt-get build-dep". As ffmpeg is present in Ubuntu repositories, we can get directly:
sudo apt-get update sudo apt-get build-dep ffmpeg But in Debian ffmpeg is not present, so we can get deps for libav:
sudo apt-get update sudo apt-get build-dep libav It's also a good idea to have ffmpeg support samba, so we can install it too:
sudo apt-get install samba samba-common attr samba-vfs-modules smbclient Get some more dependencies:
sudo apt-get install autoconf automake build-essential libass-dev libfreetype6-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo zlib1g-dev We will probably need this packages too:
cd t wget http://www.tortall.net/projects/yasm/releases/yasm-1.3.0.tar.gz tar xzvf yasm-1.3.0.tar.gz cd yasm-1.3.0 ./configure --prefix=/usr make -j2 sudo make install cd .. tar -xjvf fribidi-0.19.7.tar.bz2 cd fribidi-0.19.7 ./configure make sudo make install cd .. http://savannah.nongnu.org/download/freetype/ wget http://download.savannah.gnu.org/releases/freetype/freetype-2.6.3.tar.bz2 tar xjvf freetype-2.6.3.tar.bz2 cd freetype-2.6.3 sh autogen.sh make setup ansi make -j2 cd .. Let's install some codecs, avoid what you don't need:
sudo curl https://yt-dl.org/downloads/2016.02.27/youtube-dl -o /usr/local/bin/youtube-dl sudo chmod a+rx /usr/local/bin/youtube-dl https://sourceforge.net/projects/lame/files/lame/ tar -xzvf lame-3.99.5.tar.gz cd lame-3.99.5 ./configure make -j2 sudo make install cd .. git clone http://git.videolan.org/git/x262.git cd x262 ./configure --prefix=/usr --enable-static --enable-shared make -j2 sudo make install sudo ldconfig cd .. git clone git://git.videolan.org/x264.git cd x264 ./configure --enable-static --enable-shared make -j2 sudo make install sudo ldconfig cd .. video4linux/libv4l2 git clone git://linuxtv.org/v4l-utils.git cd v4l-utils ./bootstrap.sh ./configure make -j2 sudo make install cd .. http://downloads.sourceforge.net/opencore-amr/fdk-aac-0.1.4.tar.gz tar xzvf fdk-aac-0.1.4.tar.gz cd fdk-aac-0.1.4 ./configure --prefix=/usr --disable-static make -j2 sudo make install cd .. wget http://downloads.xiph.org/releases/opus/opus-1.1.tar.gz tar xzvf opus-1.1.tar.gz cd opus-1.1 ./configure make -j2 sudo make install cd .. wget http://storage.googleapis.com/downloads.webmproject.org/releases/webm/libvpx-1.5.0.tar.bz2 tar xjvf libvpx-1.5.0.tar.bz2 cd libvpx-1.5.0 ./configure --prefix=/usr --disable-examples --disable-unit-tests make -j2 sudo make install cd .. sudo apt-get install flac git clone https://github.com/libass/libass.git cd libass ./autogen.sh ./configure --prefix=/usr make -j2 sudo make install cd .. https://www.xiph.org/downloads/ wget http://downloads.xiph.org/releases/ogg/libogg-1.3.2.tar.xz tar xJvf libogg-1.3.2.tar.xz cd libogg-1.3.2 ./configure make -j2 sudo make install cd .. wget http://downloads.xiph.org/releases/vorbis/libvorbis-1.3.5.tar.xz tar xJvf libvorbis-1.3.5.tar.xz cd libvorbis-1.3.5 ./configure make -j2 sudo make install cd .. If you need x265 (as H3 support HEVC/H265) this is a tricky one and took me some time to deal with, because of a bug, so it need special attention. We need shared libraries but we will get error during make. So first some dependencies:
sudo apt-get install mercurial cmake cmake-curses-gui build-essential hg clone https://bitbucket.org/multicoreware/x265 We have to modify one file, so shared version can be build. Open the following file:
nano /t/x265/source/common/primitives.cpp
and locate this lines:
- #if ENABLE_ASSEMBLY && X265_ARCH_ARM == 0 void PFX(cpu_neon_test)(void) {} int PFX(cpu_fast_neon_mrc_test)(void) { return 0; } - #endif } #endif Remove the two lines with "-" in front and save (ctrl+o, ctrl+x). Now we can build what we need:
cd x265/build/linux ./make-Makefiles.bash #> c > g make -j2 sudo make install sudo ldconfig cd ~/t As we have all packages and codecs we need, we can build ffmpeg:
wget http://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 tar xjvf ffmpeg-snapshot.tar.bz2 cd ffmpeg ./configure --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libpulse --enable-libv4l2 --enable-libx264 --enable-libx265 make -j2 sudo make install This will take a while, but i think it worth.