lanefu

I'm a big fan of markdown-based solutions.
 
I moved my team from a wiki to markdown + mkdocs and have great success.
 
here's a few bullet points (i recognize some of these may be redundant to other posts in the forum)
 
* typically content renders nicely out of the box with modern version control front ends such as github, bitbucket, gitlab
* markdown's popularity lowers barrier to entry across masses
* text file nature easy for *nix users and developers to quickly update docs while coding from their favorite editor or IDE
* file ÷ git commit process makes writing the doc feel more deliberate / focused because process is the same as commiting code. ive experienced documentation quality go up because of it
* output in multiple formats via post processing.
 
 
as an example my doc repo has a git hook that executes mkdocs on post commit. my internal documentation is automatically updated with searchable documentation.

Hi all,
 
since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
 
Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
 
My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
 
But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
 
Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

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 )

Okay since i'm pretty much doing the same thing with my team at work,  I'll take on establishing clearer process / procedures for issue tracking.   Since both the forum and github support a concept of tagging there's some opportunities there for integration.    
 
We want to make issue/task creation is easy, but deliberate enough that we don't end up with having to filter a bunch of noise.

I don't know what your financial constraints are, but launching a Ubuntu 14.04 AWS EC2 instance and running armbian builder on it is cake....and fast..    AKA $1 of cloud computing will save you a lot of time and effort.

TL;DR: All available H3 boards do not differ that much. But the few differences sometimes really matter!
 
The following is an attempt to compare the different available H3 SBC that are supported by Armbian. The majority of boards is made by Xunlong but in the meantime two more vendors started cloning the Xunlong boards (and also Olimex is preparing H3 boards as OSHW). Both Foxconn/SinoVoip with their Banana Pi M2+ and FriendlyARM with their NanoPi M1 tried really hard to copy everything as exact as possible (the so called pin mappings -- how the many contacts the used H3 SoC is providing are routed to the outside).
  All the boards share the same 40 pin GPIO header (trying to be compatible to the newer RPi boards) and since all the other pin mappings are also 99 percent identical you can for example boot a NanoPi M1 with an Armbian image for Orange Pi PC without loosing any functionality (except of camera module) and the same applies to BPi M2+ that will boot happily an Armbian image for Orange Pi Plus 2E (except of camera module and WiFi/BT)   In fact all the various H3 boards just differ in a few details:  Amount of DRAM No, Fast or GBit Ethernet Voltage regulator and 'thermal design' (responsible for performance in full load situations) Storage capabilities (pseudo SATA and eMMC or not) Count of available USB ports (with or w/o internal USB hub) Some additional features like camera modules, WiFi/BT and additional/optional connectors (here it's important to check for driver functionality/availability. If there's no driver providing the necessary functionality then these 'additional features' are pretty much useless -- camera connector for example) Why focussing on the H3 SoC for this comparison? Since some of these boards are priced pretty competitive Mainlining support for H3 SoC and these boards is progressing really nicely so we'll be able to run these boards with mainline kernel pretty soon (thanks to the great linux-sunxi community) 2D/3D/video HW acceleration is available with legacy kernels (again thanks to the great linux-sunxi community) The feature set is nice for many use cases (quad core SoC, GBit Ethernet and 4 useable USB ports on some boards make a really nice low cost/power server) It got somewhat confusing regarding the many available Oranges and now also the cloned Banana and NanoPi This is also in preparation of a broader overview of the capabilities of all the boards Armbian currently supports now focussing on the H3 family. So let's get into details:   Amount of DRAM   That's an easy one. The H3 SoC supports up to 2 GB DRAM. The available and announced boards use either 512MB, 1 GB or 2 GB DRAM (low-power DDR3L on the bigger Oranges and DDR3 on OPi One/Lite, BPi M2+ and NanoPi M1). In case you're using Armbian it simply depends on the use case. And also it's necessary to understand that Linux tries to use all your RAM for a reason: Since unused RAM is bad RAM. So don't be surprised that Armbian will eat up all your RAM to cache stuff which improves performance of some tasks but the kernel will immediately release it when other tasks have a demand for it. If still in doubt please enjoy http://www.linuxatemyram.com.   If you want to use your boards with the unofficial H3 OpenELEC fork too please be aware that OpenELEC benefits from at least 1 GB RAM since then the whole filesystem remains in memory and no accesses to a probably slow SD card happen. Prior to jernej/OpenELEC and Armbian resolving the kswapd bug a few weeks ago the 512 MB equipped boards performed rather poor. But now it seems that the unofficial OpenELEC fork runs pretty well also on the boards with less available RAM.   Whether 1 vs. 2 GB RAM make a difference absolutely depends on the use case and no general recommendations can be made.   Since OpenELEC has been mentioned it should be noted that the current implementation of the unofficial OpenELEC port for H3 boards makes use of the cedarx-license-issues-library (no clear license preventing the use if you care about legal issues -- please have a look at http://linux-sunxi.org/Kodi for further details)   Networking:   The H3 SoC contains an Ethernet implementation that is capable of 10/100 MBits/sec Ethernet and also GBit Ethernet. A PHY (that handles the physical interconnection stuff) for Fast Ethernet is already integrated into the H3 SoC but to be able to use GBit Ethernet an external GbE capable PHY is needed (the RTL8211E used on all boards adds approx 1.2$ to the costs of the board in question).   Most H3 boards use the internal Fast Ethernet PHY so wired networking maxes out at ~95 Mbits/sec. Orange Pi Plus, Plus 2, Plus 2E and BPi M2+ provide GBit Ethernet (+600 Mbits/sec with legacy and exactly 462 Mbits/sec with mainline kernel) while Orange Pi Lite saves an Ethernet jack at all. The good news: Even with the Lite you can use wired network adding a cheap RealTek USB3-Ethernet dongle like this which is confirmed to exceed 300 Mbits/sec in a single direction.   The currently available boards have either no WiFi (NanoPi M1, OPi 2 Mini, One and PC), rely on RealTek 8189ETV (OPi 2, Plus, Plus 2), the newer RealTek 8189FTV (OPi Plus 2E, Lite, PC Plus) or a WiFi/BT combination: AP6181 is used on the BPi M2+ but the vendor didn't manage to get BT working at the time of this writing. Currently only jernej's OpenELEC fork and Armbian have a working driver included for the new 8189FTV chip on the fresh Orange boards that seems to perform quite ok and provides client/AP/monitor mode. Can't say that much about that since in my very personal opinion all these 2.4GHz onboard WiFi solutions are simply crap   Voltage regulator and 'thermal design':   This is a very important differentation: All Orange Pi boards use a programmable voltage regulator to adjust the voltage the SoC is fed with. The SY8106A used on every Orange except of One and Lite can be controlled though I2C and adjusts the so called VDD_CPUX voltage in 20mV steps. This is important since 'dynamic voltage frequency scaling' relies on the principle of providing less voltage to the SoC/CPU when it clocks lower. So when the board is idle also the supplied voltage will be reduced resulting in less consumption and also less temperature.   Since H3 is somewhat prone to overheating being able to adjust VDD_CPUX is also important when we're talking about the opposite of being idle. The SY8106A equipped Oranges reduce very fine grained the core voltage when they start to throttle down in case overheating occurs under constant heavy load. As a direct result they will automagically perform better since reducing VDD_CPUX voltage also reduces temperature/consumption so both CPU and GPU cores in H3 due not have to throttle down that much.   Quite the opposite with BPi M2+. For whatever reasons SinoVoip saved put a the same programmable voltage regulator on their board as OPi One, Lite and NanoPi have but does not implement voltage switching so H3 there will always be fed with 1.3V. In addition it seems 'Team BPi' didn't take care of heat dissipation through PCB design (it seems Xunlong added a copper layer to the PCB that helps dramatically spreading the SoC's heat) and so with BPi M2+ (and NanoPi M1 too) you have to be prepared that you need both a heatsink and a fan to let this board perform under full load since otherwise heavy throttling occurs or when you use a kernel that does not implement throttling (4.6/4.7 right now for example) be prepared that H3 gets either destroyed or will crash through overheating if you run something heavy on BPi M2+ or NanoPi M1. We're still investigating whether this crappy thermal behaviour might be related to DRAM also (DDR3 vs. low power DDR3L on the Oranges) It seems this thermal behaviour is not that much related to the DRAM type used but more to PCB design (maybe using large internal ground/vcc planes optimizing heat dissipation on Oranges.   NanoPi M1 and Orange Pi One/Lite use a rather primitive GPIO driven voltage regulator that is able to just switch between 1.1V and 1.3V VDD_CPUX which already helps somewhat with throttling.   A rather demanding benchmark using cpuminer (a bitcoin miner making heavy use of NEON optimizations and assembler instructions) that knows a benchmark mode where it outputs the khash/s rate. On the left OPI+ 2E with the superiour SY8106A voltage regulator switching CPU frequency between 1200 and 1296 MHz. On the right little OPi Lite with the SY8113B voltage generator able to switch between 1.1V and 1.3V and with slightly lower performance since throttling prevents clocking that high. And in the middle as only board with applied heatsink on H3 poor Banana Pi M2+ using the same SY8113B voltage regulator but always feeding the H3 SoC with 1.3V (for whatever reasons!).      Storage capabilities:   The H3 SoC doesn't feature native SATA capabilities so the 2 boards that have a SATA connector (Orange Pi Plus and Plus 2) implement that using an onboard USB-to-SATA bridge. Unfortunately the chip used there -- a Genesys Logic GL830 -- is horribly slow limiting sequential transfer speeds to 15 MB/s write and 30 MB/s read. It also does not support the USB Attached SCSI Protocol (UASP) so when using mainline kernel attached disks an especially SSDs couldn't show their full random I/O performance.   Given that common USB-to-SATA bridges used in external USB enclosures show way better sequential performance (35 MB/s in both directions and close to 40 MB/s when using an UASP capable bridge together with mainline kernel) the SATA port on these 2 SBC can not be considered a feature worth a buy.   Every H3 board has a TF card slot (Micro SD card) and some of the boards feature onboard eMMC storage. The H3 can cope with TF cards that are compliant to the SD, SDHC and SDXC standards so rather large cards with more than 64 GB capacity can also be used (be aware that there do not exist that much cards with a capacity larger than 128 GB. Chances are pretty high to get a counterfeit card especially when the price looks too good to be true ). You should also be aware that all H3 boards show the same sequential speed limitations (maxing out at ~23 MB/s) so choosing cards that are rated way faster aren't worth a buy. Better have a look at random I/O performance that is more important in most use cases.   The eMMC used on various boards is pretty fast (sequential speeds maxing out at ~75 MB/s and especially random IO way faster than the fastest tested SD cards which is important for desktop useage and databases for example) so you don't make a mistake choosing any of the eMMC equipped H3 boards (BPi M2+, Orange Pi Plus, Plus 2, Plus 2E or PC Plus). You find detailed test results of current SD/TF cards as well as all the eMMC variants used in these two threads: http://forum.armbian.com/index.php/topic/954-sd-card-performance/ http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/ Count of available USB ports:   The H3 SoC features 3 USB2.0 host ports and one USB OTG port. With Armbian we configure the OTG port as a host port that shows pretty similar performance so on some H3 boards (Orange Pi PC, PC Plus and Plus 2E) you can benefit from 4 USB2 ports that do not have to share bandwidth.   Some other boards use an internal USB hub (Orange Pi 2, Plus, Plus 2) so the available USB ports have to share bandwidth in reality. Please keep that in mind when you compare the 4 USB Type A jacks OPi 2, Plus or Plus 2 feature (all being connected to a USB hub so having to share the bandwidth of a single USB 2.0 host port) with the 3 you can count on OPi PC, Plus 2E or NanoPi M1. On the latter boards you get full USB 2.0 bandwidth on each USB receptacle without the need to share bandwidth.   BPi M2+ does also not use an internal USB hub but only exposes 2 USB host ports on type A receptacles and the 3rd host port only without ESC protection via soldering (but since this board shows such a terrible thermal design and is relatively overpriced compared to other H3 boards that doesn't matter that much)   Additional features:   The only board featuring a Bluetooth capable chip from BroadCom is the BPi M2+. Currently the vendor admits that BT is not working so better don't count on this feature to be ever available.   Update: Jernej got BT already working in his OpenELEC fork so it's just a matter of time until it works with Armbian too.   The H3 SoC is able to output/intercept additional signals, eg. analog audio, Composite video (TV out), IrDA that are present on most of the boards. On the Orange Pi One many of those interfaces are only present as solder points (a bit too tiny to be used by the average maker) and on some other boards they are not present at all (BPi M2+ for example has neither composite video nor analog audio) so always check first what you need or want to use.   We have a nice sortable table in linux-sunxi wiki showing most of the important details: http://linux-sunxi.org/Table_of_Allwinner_based_boards   Camera modules:   Xunlong provides a pretty cheap 2MP camera module that should work with every H3 Orange Pi out there (they all have the necessary connector but for OPi One, Lite, PC and PC Plus you have to tell Xunlong that you also need a so called 'expansion board' that they ship free of charge if you add to your order that you need it. Starting with Armbian release 5.15 we also include an improved driver for this camera.   Regarding current state of available camera modules for Oranges, BPi M2+ and NanoPi M1 please look through this thread: http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/?view=getlastpost

Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
  Mainline kernel:   The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.    In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)   BSP kernel:   So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).   Allwinner's 1st BSP kernel variant:   Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards)   Loboris' kernel:   The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.   Yann Dirrson's fork:   When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.   1st Armbian legacy kernel:   Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)   Alwinner's 2nd BSP kernel variant:   When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.    2nd Armbian legacy kernel:   So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.   Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes)   The SinoVoip experience:   While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.   Further improvements:   In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)   Summary:   Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)

I hit this nasty blob long ago on a previous post.
 
Some nice article why is closed source: http://www.anandtech.com/show/6777/understanding-camera-optics-smartphone-camera-trends/4

I don't think we need to maintain documentation for several languages at once, so let's better have single language, but good coverage and quality.
 
Some suggestions are noted in the first message of this topic. Also some GitHub issues need testing and checking documentation (i.e. #337), some require having a specific device to test (i.e. #286), some require creating and testing a small kernel patch (#222 and #323), and some are obsolete and will be closed after checking.
 
Was discussed already, feel free to add your suggestions.
 
For now I would stay at using Markdown as markup language, stay at maintaining user-level documentation in current state and maybe migrating build script documentation to GitHub wiki attached to main repository (https://github.com/igorpecovnik/lib/)

I'm totally interested in participating.   Is the issues list on github the source of truth for open tasks or are there other places?
 
PS it looks like the issues in github arent taking advantage of labels.  probably worth while

[Ended]   Be active, creative, helpful and you can get a powerful board in return. First give away batch is starting 11.6.2016  
It's not often that you can work on a software project that actually brings joy and helps people. Armbian is one of those project. It is a system that helps one build a kernel or boot images for several ARM development boards. 
 
It's in common interest that we improve level of support and to relieve most active people. Our crew needs an upgrade:
we need more coders, kernel hackers, UX designers to find and solve problems. If you are one of them, join our forum, join project at Github. we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc. we need to put together much better documentation. We need to fine tune MkDocs documentation tools For those who are willing to claim a task or help others to understand "how do I do this in Armbian" we prepared a dozen of boards as a small reward. It's a Xunlong Orange PI+ 2E, which design was improved based on requests from our community. It's H3 based quad core with 2G RAM, 16G eMMC, Gigabit LAN, WIFI and 3x USB.     There might be just enough boards for everyone who are willing to do some public service work. Claim your projects at this topic and each weekend we will discuss and select up to 15 people who will get the board, starting with 11.6., ... until we run out of boards. One will be notified by email and expect an answer within 48 hours, if not, board goes to somebody else.   Boards were donated and will be sent directly from Xunlong Co., Shenzhen, China.     1st batch is going to: Kriston, lanefu, vlad59, martinayotte, jeanrhum, Gravelrash, xcasex, naibmra, Xer0, madilabs, wha, @lex, WereCatf   naibmra - Bulgaria - kernel testing, try hooking to kernelci.org, docs - mid July wha - USA - 50unattended-upgrades, issue #337 - June Kriston - USA - documentation rework - July, August Xer0 - Germany - media build - July, August lanefu - USA - issue tracking improvements between forum and github - 22 June, July madilabs - Martinique - Packaging for desktop video acceleration - June xcasex - Sweden - desktop packaging - July, August jeanrhum - France - documentation and debian packaging - July martinayotte - Canada - maintain/fix DTS entries for some devices such I2C/SPI/W1 - ASAP vlad59 - France - Nanopi M1 testing and documentation Gravelrash - UK - Prepare HOWTO's & package "armbian-gc2035-fswebcam package" - June   2nd batch is going to: dimag0g, R2D2_C3PO, miked, 0x0, sysitos, jmcneill    dimag0g - France -  Packaging of OpenGL wrapper library - end of July R2D2_C3PO - Germany - Improved SD-Card partitioning - end of August miked - Canada - build system recension - end of August 0x0 - Russian Federation - Redesign site and documentation WIP + add some changes to graphics in distro. - end of July sysitos - Germany - replace/rework ramlog for systemd - end of August jmcneill - Canada - (Armbian is helping porting Freebsd)    Users were notified and were requested to provide: project name, due date and their shipping address

Just a small update on eMMC on Orange Pi Plus 2E (and also Orange Pi PC Plus since there it's the same). My goal was to get Armbian running from the eMMC. Igor had to provide a new mini release 5.14 yesterday since we forgot to add the necessary bits to u-boot the day before yesterday to be able to use both SD card and eMMC on Plus 2E and PC Plus.
 
So I took this new image, burned it to a small and slow SD card lying around, inserted the card into the board and booted. The usual procedure with one automated reboot, then I logged in, transferred the image on my SD card just to overwrite the eMMC contents in one single step:
sudo dd if=Armbian_5.14_Orangepiplus2e_Debian_jessie_3.4.112.raw of=/dev/mmcblk1 bs=10M Partition table before and after:
 
 
 
Afterwards I ejected the SD card, rebooted and then Armbian started its usual 'firstrun' procedure now running from eMMC. There are more elegant ways to get Armbian on eMMC but I had to choose this way since I was in a hurry. As recommended I checked the eMMC for errors and performance using 'armbianmonitor -c':
 
 

 
Interesting observation: the f3write tool seems to use a rather small block size to write the test data patterns to 'disk' (so the 9.21 MB/s should be taken with a grain of salt since the eMMC is much faster with larger block sizes -- see here for a comparison of OPi Plus 2E and BPi M2+: http://pastebin.com/L1S7b3m7 )
 
Now the OPi Plus 2E is temporarely gone replacing a customer's 'server' (an aging Sun Fire 280 that died recently hosting an image archive for layout purposes. They allowed me to re-save all the images that were on a 8 disk RAID and with applied compression the TIFFs now fit on a 64 GB Samsung Pro SD card and are served by OPi Plus 2E which is also faster compared to the +1000W setup they used before).

sure ill take a look this evening. i was just using ttl serial.console last time. ill hook it up.to a monitor this time
 
Sent from my SM-G920V using Tapatalk

More about NanoPi M3 - USB ports are behind USB hub...
 
Very specific board with high enough price, "Applications" tab on their site tells enough use cases where this price is OK. Unless you need FPGA  or RISC co-processor and you know how to work with this stuff, you don't need this board.
 
Using as headless server: NAS with 2 HDD drives for storing stuff (Samba, rsync, syncthing), headless music server (mpd controlled via IR remote or Android app).
 
Waiting for Ethernet and USB support in mainline kernel, meanwhile it's useful for testing intermediate Armbian releases.
 
Waiting for the bright future (at least mainline u-boot with SPL and basic support in mainline kernel).
 
Turn lights on and off with IR remote using connected IR sensor and nRF24L01+ module
Display stuff (weather forecast, date&time, new e-mail notifications and some other things) on HD44780-compatible LCD display.

Fired up and tested my Plus 2e
 
I posted my DRAM test results.   Hopefully my comment makes sense.
 
Other stuff
 
I built latest Armbian 5.12 jessie for OPi PC from repo and booted without issue Once I symlinked my fex to /boot/bin/orangepiplus2e.bin, I was able to see the onboard eMMC, and the onboard ethernet. Ethernet was able link at gigabit.   I hit 700mbit on a quick iperf No luck with wifi with  using already included modules no luck with wifi following instructions described in this thread http://forum.armbian.com/index.php/topic/942-rebuild-rtl8189es-from-git-for-opi/page-2?hl=8189ftv#entry9574 There's a garbage Fat32 Filesystem with android stuff on the onboard flash (let me know if anybody really interested) I found this while poking around on the onboard flash
 
 

root@orangepipc:/mnt/tmp# cat misc/wifi/wifi_hardware_info  realtek:rtl8189fs

my opi 2e arrived today.
 
so i should
* run and document dram test
* see if the untested wifi driver works
* make a dorky unboxing video
 
 
... anything else of value I can do in the name of armbian?
 
Sent from my SM-G920V using Tapatalk

I had to blacklist the standard realtek module in order to get things to behave with the patched one that comes with the distro
lane@orangepione-2:~$ cat /etc/modprobe.d/wifi-blacklist.conf  blacklist rtl8192cu Prior to blacklisting, it would just crash and reboot as soon as the wifi module loaded.  
 
This was using one of the little rt8192 dongles from adafruit running an armbian image I built from the repo yesterday.

AFAIK @lex provided a more improved version here (already as patch that should apply flawlessly). Thread/discussion here: http://forum.armbian.com/index.php/topic/996-gc2035-driver-update-320x240640x480-20-fps/

Thanks for the hard work on Armbian. I finally got the EmulationStation GUI to run under OpenGL ES @ ~88fps on OrangePI PC.

The trick was mostly building SDL2 from source and not installing it with apt-get per the instructions. Really want to avoid anything "mesa".

IIRC, I configured SDL2 with a similar command before making:

./configure --host=arm-linux-gnueabihf --disable-video-opengl
Then building EmulationStation from source using:

cmake -DGLSystem=OpenGL\ ES .
make
make install

FWIW I did symlink some shared objects into /usr/lib/ (like libMali.so)

Next is sorting out libretro stuff.
 

I fought the good fight over the weekend trying to get Armbian builder to build full images while running in a docker container.    I've had some success, and managed to build a armban 5.11 image for my Orange Pi One.. I'm running on it with wifi etc.
 
I'm using a CentOS7 Docker 1.9.1 host and using Ubuntu 14.04 Trusty Docker Container for the Armbian builder container. (I just used the Dockerfile from the armbian git repo)
 
Bottom line loopback management inside containers is a bad time.. especially when losetup implementations vary between host and container.   The partprobe step in the container doesn't seem to trigger appropriate feedback to udev to create partitiion devices on the /dev loop back devices.   I got around it by creating them ahead of time.
 
Here's a few tricks to limp through.  I'll try to add more clarity later.
 
1.  Don't. just go build a ubuntu 14.04 VM or use a turn key one on amazon and get your life back.
 
 
From Docker Host
#you need modules modprobe binfmt_misc modprobe loop #scrub loopbacks for good luck rm -rf /dev/loop[0-9]*     Launch armbian builder container with --privileged=true #sudo docker run --privileged=true --name=armbian -it armbianbuilder #or if you're re-using container #sudo docker start -i armbian From container   #start apt-cacher-ng service apt-cacher-ng start ​ #scrub loopbacks again in container for good luck rm -rf /dev/loop[0-9]* #create all your loop back devices mknod /dev/loop0 b 7 0 mknod /dev/loop0p1 b 259 0 mknod /dev/loop0p2 b 259 1 mknod /dev/loop0p3 b 259 2 mknod /dev/loop0p4 b 259 3 mknod /dev/loop1 b 7 1 mknod /dev/loop1p1 b 259 0 mknod /dev/loop1p2 b 259 1 mknod /dev/loop1p3 b 259 2 mknod /dev/loop1p4 b 259 3 mknod /dev/loop2 b 7 2 mknod /dev/loop2p1 b 259 0 mknod /dev/loop2p2 b 259 1 mknod /dev/loop2p3 b 259 2 mknod /dev/loop2p4 b 259 3 #build your dreams cd ~ ./compile.sh Every time you build an image you should destroy the loopbacks and recreate.  It's your best chances of getting the partitions in the loopback image to behave for mounting.
 
 
     

I have 2 Opi Ones if additional testing is needed. one with heatsink one without. i have a 2e coming also
 
Sent from my SM-G920V using Tapatalk

Wow! Guess who made the original picture: http://linux-sunxi.org/File:Orange_Pi_One_Top.jpg#filehistory
 
Someone sent me two pictures from Orange Pi forums (which I've not visited since 5 months), I combined those two images in Photoshop so that the image alone should be significant enough to get the idea and forgot to mention "@GUTEK@ the greatest artist on planet" since I didn't even know that the great @GUTEK@ was responsible for creating this masterpiece of art (combining a screenshot from schematic with someone else's photo). I truly apologyze for my mistake. Will correct that immediately!
 
OMFG! It was such a mistake starting to support Orange Pi H3 boards.

Relax - Wireless is solved for OPI ONE
 
There seems to be a lot of confusion and missing information on how to access the dirt cheap OPI ONE wirelessly and the steps necessary to successfully use cheap Realtek USB dongles ( 8188cus, 8188eu ) with Armbian_5.10.
 
This is a short summary of the needed materials and steps to turn your OPI ONE into a wireless client or wireless AP. There are NO custom kernels, custom modules or anything else needed, we are using stock Armbian_5.10 with stock kernel, stock modules and stock software to configure wireless access for select tested and working Realtek wifi dongles.
 
Follow the steps without variation. Once you get wifi working you may adapt setup/configuration to your specific needs
 
Prerequisites
 
- OPI ONE with quality power supply 5V/2A
- MicroSD ( 4G or higher ) with stock Armbian_5.10 installed per official instructions
- Supported wifi USB dongle
- LAN connection to host computer ( preferrably notebook running Linux ) for needed setup/configuration 
- WLAN-router accessible from host computer to test wireless connections.
 
General procedure to set up wireless on OPI ONE
 
- Set up your OPI ONE with basic Armbian_5.10 and configure a static IP LAN-address
- Access OPI ONE via ssh from your host computer
- Plug in wireless dongle and load correct driver module
- check capabilities of wifi dongle (iw list)
- configure wpa_supplicant for client mode
- configure hostapd for AP mode
 
>>> all configurations will be minimal without added automagic complexities ( bridges, DHCP etc...)
 
OPI ONE wireless client
 
Module 8192cu works with Realtek 8188CUS dongles and provides a wireless interface wlan0 ready to be configured in managed mode with wpa_supplicant.
 
 
nano /etc/modules-load.d/modules.conf
=====================================

#8189es
8192cu
 
 
 
nano /etc/network/interfaces (adapt to your network setup)
==========================================================

auto lo
        iface lo inet loopback

#----- lan interface ( standard maintenance connection via ssh ) 
        
allow-hotplug eth0
   iface eth0 inet static
        address 192.168.3.164           
        netmask 255.255.255.0
        network 192.168.3.0
 
#----- Realtek 8192cu wlan interface client ( access defined in /etc/wpa_supplicant/wpa_supplicant.conf )
            
allow-hotplug wlan0
   iface wlan0 inet static
        address 192.168.2.164
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.77
    dns-nameservers 192.168.1.1
    dns-nameservers 8.8.8.8

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
 
 
nano /etc/wpa_supplicant/wpa_supplicant.conf
============================================

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="<your_ssid>"
        psk="<your_password>"
        key_mgmt=WPA-PSK
        priority=99
}
 
 
After restarting OPI ONE it should be connected to your configured wireless router and accessible under the static IP.
Wireless connection is working now and the rest is up to your hopefully wild imagination and creativity.
 
Tested working dongles
 
RTL8188CUS cheap no-name dongle from Aliexpress ( < $2 )
 
Bus 002 Device 003: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

RTL8188CUS Edimax EW-7811Un high quality dongle ( $10 )
 
Bus 001 Device 008: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Wifi performance is not stellar, but definitely adequate. Under ideal conditions ( same room as router, little interference ) speeds of 80mbps ( measured with iperf ) can be expected. Crossing two walls at 20m distance from router the signal was still usable yielding 20mbps.
 
 
OPI ONE access point + wireless client
 
Surprise : You were asking for AP mode and  now you are getting AP deluxe with an extra client interface for free.
 
Module 8188eu works with Realtek 8188EU dongle and provides TWO wireless interfaces : wlan0 is ready to be configured in AP mode with hostapd and wlan1 in managed mode with wpa_supplicant.
 
When the dongle is plugged in and the driver correctly loaded, iw list will enumerate the drivers parameters for the two new interfaces. iwconfig will show wlan0 and wlan1.
 
 
 
nano /etc/modules-load.d/modules.conf
=====================================

#8189es
8188eu

nano /etc/default/hostapd
=========================

DAEMON_CONF="/etc/hostapd.conf"


nano /etc/network/interfaces
============================

auto lo
        iface lo inet loopback

#----- lan interface ( standard maintenance connection via ssh )
        
allow-hotplug eth0
   iface eth0 inet static
        address 192.168.3.164
        netmask 255.255.255.0
        network 192.168.3.0

#----- Realtek 8188eu wlan interface AP ( access defined in /etc/hostapd.conf )
              
allow-hotplug wlan0
   iface wlan0 inet static
        address 192.168.4.164
        netmask 255.255.255.0
        network 192.168.4.0

#----- Realtek 8188eu wlan interface client ( access defined in /etc/wpa_supplicant/wpa_supplicant.conf )
            
allow-hotplug wlan1
   iface wlan1 inet static
        address 192.168.2.164
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.77
    dns-nameservers 192.168.1.1
    dns-nameservers 8.8.8.8

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf


nano /etc/hostapd.conf
======================

ssid=<your-OPI-ONE-ssid>            
interface=wlan0
hw_mode=g
channel=5
driver=nl80211
logger_syslog=0
logger_syslog_level=0
wmm_enabled=1
ieee80211n=1
wpa=3
preamble=1
#wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27
wpa_passphrase='12345678'
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
auth_algs=1
macaddr_acl=0
noscan=1
#ht_capab=[HT40-][sHORT-GI-40][sHORT-GI-40][DSSS_CCK-40]
country_code=<your country code>
#ieee80211d=1


nano /etc/wpa_supplicant/wpa_supplicant.conf
============================================

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="<your-router-ssid>"
        psk="<your-router-password>"
        key_mgmt=WPA-PSK
        priority=99
}
 
 
After restarting OPI ONE it should be connected to your configured wireless router and accessible under the static IP. On your notebook the newly created OPI ONE access point should be visible when scanning. Specify a static IP for the link and connect using the chosen password ( e.g. '12345678' ) . Feel like a hero, empty a sixpack and order more pizza....
Wireless connection is working now and the rest is up to your hopefully wild imagination and creativity.
 
 
Tested working dongle for AP mode :
 
RTL8188EU cheap no-name dongle from Aliexpress (  $2.20  )
Bus 001 Device 009: ID 0bda:0179 Realtek Semiconductor Corp. ( noname identified as 8188EU )

Wifi performance with both interfaces active is surprisingly good. Under ideal conditions ( same room as router, little interference ) speeds of 60 (client) / 30 (AP) mbps can be expected. Crossing two walls at 20m distance from router signals were still usable yielding 20 (client) / 5 (AP) mbps.
 
 
Troubleshooting
Most of the problems encountered while setting up WIFI are caused by inadequate or overly complicated testing setups, procedures and rampant wild guesses. Keep it simple and solve one problem at a time. As a stable datum you should realize that the procedures outlined above DO WORK and have been adequately TESTED and RETESTED..
 
Solution No. 1 :  Follow the steps outlined
Solution No. 2 :  Find out where you did not follow the steps outlined
Solution No. 3 :  Find out what you added to the steps outlined
Solution No. 4 :  Reiterate
 
 
Good luck with your wireless OPI ONE, enjoy and flood the forum with working solutions.

You find most if not all used methodologies/tools listed here: http://de.slideshare.net/brendangregg/broken-linux-performance-tools-2016
 
On a SBC I would always take care to use a minimalistic monitoring approach since when the monitoring task starts to influence the behaviour of the system (always running at highest clockspeeds for example when interactive performance governor is used) then this is simply 'Monitoring gone wrong'.
 
Another huge difference when we're talking about more recent SBCs is the thermal/throttling and dvfs/cpufreq behaviour. Not taking that into account and looking at something more or less useless like 'load average' is just fooling yourself (without taking notice). So if you've fun watching at meaningless graphs this might be great. Otherwise better stay away from it unless it serves ok for specific use cases you're an expert in (networking stuff for example)
 
Please just think a few seconds about a monitoring approach that does not monitor CPU clockspeeds and throttling strategies either. Is having an average CPU utilisation of 50% 'bad'? When the system is downclocking to 240 MHz at the same time to save energy and lower temperatures? Is it better when the system only shows 10% CPU utilisation since cpufreq settings let it run at 1200 MHz instead (and the SBC consumes twice as much energy due to dvfs settings)?

I'm running an Orange Pi One -- no heat sink, open sitting on my desk.    I built latest legacy armbian kernel via armbian build process.  Folllowed instructions for fex settings, etc.
 
I've been running cpuburn for over an hour, and here's the bottom of my log.. I'll run overnight and post on a gist or something
 
It's been holding steady with these numbers for at least 30 minutes
23:43:33:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:38:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:43:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:48:  912MHz  4.01 100%   0%  99%   0%   0%   0%   77°C 23:43:53:  912MHz  4.01 100%   0%  99%   0%   0%   0%   77°C 23:43:59:  912MHz  4.01  99%   1%  98%   0%   0%   0%   78°C 23:44:04:  912MHz  4.01  99%   0%  99%   0%   0%   0%   78°C 23:44:09:  912MHz  4.01  99%   0%  99%   0%   0%   0%   77°C 23:44:14:  912MHz  4.01  99%   0%  99%   0%   0%   0%   77°C 23:44:19:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:24:  912MHz  4.00 100%   0%  99%   0%   0%   0%   78°C 23:44:29:  912MHz  4.00 100%   0%  99%   0%   0%   0%   78°C 23:44:34:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:40:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:45:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:50:  912MHz  4.08  99%   0%  99%   0%   0%   0%   78°C 23:44:55:  912MHz  4.07 100%   0%  99%   0%   0%   0%   78°C 23:45:00:  912MHz  4.06 100%   0%  99%   0%   0%   0%   77°C 23:45:05:  912MHz  4.06  99%   0%  98%   0%   0%   0%   78°C 23:45:10:  912MHz  4.05  99%   0%  98%   0%   0%   0%   78°C 23:45:15:  912MHz  4.05  99%   0%  98%   0%   0%   0%   78°C 23:45:21:  912MHz  4.05 100%   0%  99%   0%   0%   0%   78°C
 
 
And Since I had already let it run overnight.. here's a graph of it holding steady just because