Seasalt

Thanks for the great Benchmarks.
 
Its always a delight to find out I managed to get the best bang per buck with my rapidly evolving collection of arm boards.
 
The Mecool KM8  s912 is clearly a stand out Corelec Kodi player in terms of Bang per buck.
 
I think the s922x for $65 will eat the s912-Armbian  market  once it is released as the Hard Kernel N2.
 
One of the things I did not understand about Arm chip boards being used as Linux computers. Is the HUGE delay between the hardware being in-effect "released in a unfinished state" and the time it takes for the software to catch up.
 
i.e. no VPU driver for s912 was solved in Corelec Kodi  by rapping the android VPU driver etc.
Orange Pi PC2 did not have a Hardware Video driver solved by a massive reverse engineering project.
The s912 was said to have 2.0ghz cores but it turned out to be 1.5ghz etc.

My thinking and experimenting on this is is..
Yes ..Passive cooling is a novel idea but these chips start to "cripple their performance if they get hottish"
 
A simple $5 raspberry Pi Fan soldered in will provide enough cooling to KNOCK 10 degree's to 15 degree's Celsius off the temperature of the CPU close to full load. 70 degree Celsius will go to 55 Celsius.
 
It will mean that you can play a HEVC x265 movie in "software" mode, with CPU utilization at 80-90% if you have to.
 
PS If you are using the s912 board for Amateur Radio or Software defined Radio the fan directly soldered to the s912 TV will cause a slight hum and may need a small capacitor to quieten it.
 
I have 3, KM8 Mecool s912. Two with fans one without.
 
One is running a dedicated  Corelec version of Kodi and I run it fan-less but I suspect occasionally it gets too hot and the HEVC video slightly stutters. I can live with this as I do not want a fan noise whilst watching a video on Kodi.
 
The other 2 Mecool KM8  I run Oleg's S912 Armbian..this is simply amazing with a fan I can run my software defined radio software at 3.2 MHz FULL  bandwidth (cpu utilization 70-80%) on a 5 volt low powered device at about 55degree Celsius. it is simply amazing.

Thanks. They are all under 25USD when I got them on sale
1. T95Z Plus 3Gb
2. TX9 Pro 3Gb
3. BM8 Pro 2Gb
all running off sdcard. Didn't want to risk bricking them by installing to eMMC
 
Maybe I'll try the Phoronix Benchmark Suite one of these days

Ok looks like I bricked my box forever with that method of installation (install-2018.sh with s912-uboot copied as uboot.img).
 
The firmware flash procedure does not even work anymore now. I now need to shortcut some pins from the emmc to start the flash process, and after that amlogic usb burning tools stops at 7%. It might be that pluging in the power source causes the system to boot, interrupting the interaction with emmc, but I am not sure. Any idea how to fix this, by forcing erasing of the emmc (even physically if possible).
 
I still have another S912 box, but keeping up to date with armbian is clearly too painful and risky, no installation guide whatsoever, just random bits of info here and there, generally without explanation of what happens under the hood, or link to opensource code, and high chance of bricking your box.

Consumption test:
(Wifi off. With Gigabit LAN connection)
 
Idle: 2.30W    
1-Core: 4.40W    
2-Core: 6.70W    
4-Core: 7.75W    
6-Core: 8.85W
6-Core + IO : 9.50W
 
Idle:

 
Full+IO:

mmh
I think there are some major misunderstanding here about the USB-C power supply.
 
1. The problem about the under voltage at the input of the board are the thin wires of the USB cable...
Solution?
Do not use USB cable to power the M4 board, just use a descent barrel Jack DC power supply (for example: Meanwell)
 
2. Do we have to power the board over the pin header?
No, not necessary.
The USB-C connector is rated for 5A, physically! Not 3A. The 3A limitation is a question of wiring limitation of the standard USB-C cable, not the connector itself (and hypothetically the PCB traces of the board)
The missing support for USB-PD isn't an issue either. Don't use USB-C power supplies, it's that simple as that. Again, just use a descent barrel Jack DC power supply! And if possible a 5.1V or 5.2V one.
 
You only need a cheap USB-C DC jack adapter (which causes also probably a weak voltage drop):

https://www.ebay.com/itm/DC-5-5mm-x-2-1mm-Female-To-USB-3-1-Type-C-Male-Right-Angle-Power-Supply-Adapter/302779342823
 
 
Now, about the USB 3.0 connectors. Well indeed, at load there is a voltage drop on the board, especially on heavy load, and they are partially caused by the mosfets on the power rail on the board I think.
 
edit:
VDD_5V goes through the AO3415A mosfet to power the board. It has a 42mOhm Rds(on). which caused alone a 0.1V drop at full load of the M4 board (2A).
The USB 3.0 port uses a RT9724GQW load switch which has a Rds(on) of 100mOhm. That causes another 0.1V loss at 1A load.

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

Here's a video of GQRX receiving NOAA Weather Radio on my NanoPC-T4
 
armbian-nanopc-t4-gqrx-gnuradio.mp4

I'm going to test with the current stable armbian image and update this thread when done.
 

I think this is what he means.
 
https://yadi.sk/d/pHxaRAs-tZiei

Igor, I have a plan.
 
I will rework the kmpp module. rebuild ffmpeg and mpv with kmpp support.  I am looking at methods to fix the video playrate issue 
 
Once I have video playback working with hardware accelleration I will upload the binary and source Deb packages.
 
I never even thought the issue was Armbian Support. No.. everyone here is very helpful. It is all Rockchip fault.
I have some Asian friends.
I know they turn beet red after a few drinks and I wouldn't put it past rockchip that the poor vpu support is
Because they are trying to get a large share of and control of  the cheap TV box market.  
Reverse engineering takes longer... Vpu will be working soon
 
Thanks

You need a USB voltmeter. They are cheap and easy to find. Something like this. Just put it into a usb port, and it will show the voltage. If it's 5V while the cpu is maxed out, and maybe a 1A load on the USB, then you're ok, if it's a lot less. Then it's no good for powering a hard drive.

Update ver 5.67 20181128
Update kernel 4.19.2
 
Update ver Next 20181128 kernel 4.20

I was offered this board to see what I can do with it. Just like the other boards I got (MiQi, Tinkerboard, ...)
 
Concerning "plans", I won't have any until I at least get a way to install a Linux image with a Rockchip kernel that "kind of work" correctly, in an "automated fashion" (scripted and useable with rkdeveloptool and Windows tools, so that you can reflash it at any moment if things go wrong).
Then I'll start mimicking their drivers on latest kernels and see if there's any major barrier, though I will have to deal with a few other issues before that.
 
I still see that the VPU is neither documented anywhere on their schematics, so there's at least that. If they could at least document which channel the VPU uses with the DMA subsystem, it might help a bit.
 
For the GPU side, given how fast the Panfrost project is progressing, it might be possible to overcome Mali binary drivers issues with these drivers. The Rockchip team was never able to provide Vulkan-ready binary drivers for their Mali-T7xx and Mali-T8xx chips, and the only one ARM provided with Vulkan support was with fbdev support only. There's of course drivers able to use DRM/KMS but you're "limited" to OpenGL ES 2.x / 3.x and you need an old GPL kernel driver that's starting to pile up patches to get it work with latest mainline kernels.
 
Now, given how the NanoPC T4 4.4 kernel was able to provide : HDMI output, (kind of shaky but working) Ethernet, eMMC and SDCard support, there's chances that "Orange Pi" specific issues might be fewer than expected. What remains, in terms of connections, are : SATA ports, USB, USBC, Audio, Wifi and Bluetooth.
Bluetooth might just be like the Tinkerboard : Wake up the Wifi/Bluetooth chip, flip a few GPIO and then find a way to send the local "binary blob firmware" to the chip.
 
There's also the MIPI connectors, but I got nothing to connect to these ports. Same for the battery.
 
Anyway, I'll be a bit busy this week but I might be able to advance a bit this week-end.

The new version 20181116. Added support for ZRAM , iscsi.

Version 20181113.
Expanded the list of modules for wifi.

This is a good review of the Nano Pi M4.
 
 

I have just update my OrangePi PC2 and now I can play 720p video really well.
 
It appears to use 80 - 90 CPU to do it . So I am wondering is it playing the HEVC 720p file in software or is it using Hardware VPU decoding.
 
I am also totally impressed now that Armbian has fixed the screen resolution option box. Huge improvement.
 
This is a really big set of improvements to the Armbian PC2. Well done.

Do you mean that you installed Armbian desktop image and you want to access another samba server in your LAN in default file manager?
If I remember correctly, to do this you you need to manually install additional packages:
sudo apt-get install gvfs-backends gvfs-fuse  "Debian micro home server" script is designed to install server part, so you can access the files on your board from another device.

Hi
I'm trying to get gqrx-sdr to work with my RTL 2832 DVBT dongle.
In spite of having the driver blacklisted it loads at start up but can be easily
removed by
rmmod dvb_usb_rtl2832u as root
No need to reboot and TV applications can use the dongle normally
Then you have to install pulse audio for an unknown reason
Here the strange behaviour begins:
At start the sound on an FM station is very poor. Only bits of sound in fact.
On a text console running Armbian monitor -m shows lots of fall back to 480MHz
although my well cooled CPU is around 30 degrees
waiting about 10 minutes it gets perfect
temperature rises to 45
and CPU clock stays at 1296 MHz
But waiting more the sound gets bad again at times.
htop shows that pulse audio is using a rather big % of CPU
The only other OS that allows me to use gqrx on my OPI PC is XFCE Kali.
There CPU frequency  is steady at 1540 MHz temperature is higher
and pulse audio use less CPU .
I managed to get a fixed 1296MHz CPU frequency by putting 
GOVERNOR =performance
in /etc/default/cpufrequtils
It changes absolutely nothing
So I believe my problems are due to pulseaudio which seems rather complicated
May be a fifo written at 44Khz and read at 48 or the opposite.
Any idea is welcome
Edit :
Partial success I plugged a pair of USB speakers It is OK
So the problem seems to be somewhere between pulse audio and HDMI sound.
Now the CPU temperature rise to 54 degrees and it makes me happy because
since I used Armbian I thought that the big radiator I put on the CPU was useless  

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

I am thinking about the Over-scan on first boot issue and the problems people are having trying to log in if the login questions are off the screen bottom.
 
I under stand it is caused by not having a lot of development into the screen size adjusting software.
 
 
It is essential that the lead developers prioritize the main Armbian bugs issues and I do not consider on the fly screen resizing a major issue when a stop gap solution could possibly work.
 
My temporary solution would simply be that all logins scripts be tripled.
 
ie..
 
 
Login
login
login:
 
password
password
password:
 
Enter New Password
Enter New Password
Enter New Password:
 
So even if some one cannot see all three due to over-scan they can at least understand how to get into a graphical interface by completing the first boot login procedure.
 
Seasalt.

In other words: You're telling me that displays exist where it's not possible to fix the display's problem (overscan) through buttons or OSM? Hard to believe...
 
There's a psychological experiement going on over there: Selling IT devices to a rather clueless Kickstarter crowd to figure out how they manage to overcome the various stumbling blocks without any help from the vendor. The good news: They all succeed in the end.
 
Unfortunately the stuff above doesn't work. And we will not spend any time with this horrible BSP kernel/drivers since mainlining efforts are progressing nicely. So searching through the display's OSM is currently the only way to get Armbian up and running if you're running in this issue.
 
Maybe it's better to ship with 1080p60 instead of 720p60 by default since this avoids overscan issues on more displays. But again: At least I won't spend a second on this so either this will be a collective research project done by users or it will not happen

Lesson learned.. OPI software is in it's infancy, and with time and effort spent, 
and some temporary workarounds.. it will find many uses.
 
If you want closer to perfection out of the box than what OPI has to offer? Pay more and benefit from a 
more developed product.. however, if you want to work the line a bit -  between cost and functionality -
perhaps you have more time than money available at the moment - don't dispair at your purchase.. 
persist a while before you opt for the lump hammer option.. and you may get what you need out of 
the RPi's clone-family with a bit of effort spent..  Good Luck.
 
 
I totally LOVE my OPi.PC and OPi. one running Armbian 5.05.
 
I have the over-scan problem but I am used to it now and can kind of guess whats going on.
 
I just love the low power.
 
It is 50% faster at least than the Raspberry Pi i had been using.
I feel it is quite snappy for low powered applications.
 
Ie it can write a letter and surf the net all for $15.00. I have had bad meals for more money.
 
I am running a Sandisk 32gb Class 4 SD Card and it seems really fine. I am using x11vnc to remote desktop. Its ok but it crashes after a while. So now I ssh into the unit and restart x11vnc. Its kind of a happy compromise.
 
My only problem I have is I can not access a USB storage drive if I plug it into the USB ports.
 
It says I do not have permission?
 
I am thinking of having the OPi on all the time 24 hrs a day and am trying to think of any uses that would be worth setting up on it. So far I use it for a bit of downloading and print server.
 
Do you guys have any other 24hr apps that you intend to set up?
 
 
Once again well done to the Orange PI Armbian Team
 
Seasalt

If you are reading this you've probably discovered that there are a few things about 
the Orange Pi series of boards that can be frustrating.  I know I have been..
 
I purchased an Orange Pi PC and two Orange Pi Ones anticipating Pi bliss at a 
fraction of the cost of the Raspberry equivalent.  I tried, and tried hard, to 
load distro after distro of various linux flavors onto micro SD cards with many 
a blank screen or an aborted boot attempt.. Orange Pi site distros, 
laboris distros, Armbian distros.. nothing seemed to make a difference.
 
Reading about power supply issues, ornery boot processes, and overscan issues 
I was really beginning to think this was money poorly spent, after all the boards 
weren't much use as intert bricks.. too small and light to make for a decent paper 
weight or door stop.. no practical use at all.. perhaps I could crush them with 
a lump hammer to derive some satisfaction for fruitless hours spent trying to get 
these things to work..
 
Then it dawned on me.. perhaps there was something to the advice I was seeing 
on the forum.. Out of curiosity I tried a decent USB-lithium battery pack instead 
of the little 5v wall wart I was using to power my Orange Pi PC and low and behold 
the thing booted reliably. Go figure.. all this time I was blaming the board when 
it was really the #$!#!@ underpowered wall-wart causing the issue.. try the OPI-One..
same deal, it booted.. try the next One.. same deal, it booted happily.
 
I then measured the current draw during the boot process and found that the Quad 
core board was actually a hungry little bugger.. peaking out at almost 600ma 
at one point in the boot process with no accessories attached.. before settling 
down to around 240ma at an idle. Lesson learned: Don't cheap out on your 
power supply for these boards... and you've made it over the first hurdle.
 
Next hurdle..  the damn video is overscanning my LG HDMI monitor.. no adjustment 
on the monitor to scale the desktop image to fit the screen size, and no easy boot 
config file like RPi to turn underscanning on in the linux OS. This means I can't 
see the menus at the top of the screen.. I didn't have this issue with the RPi.. 
but hey the RPi cost more, has a user base of 6 million users and a dedicated, paid 
software development team with 4 years under its belt.
 
Put it in perspective.. OPI is a smaller community and it takes time to develop 
code and work out the kinks in a product.. so a bit of patience is in order.
Thank you to the Armbian developers and testers, your efforts are appreciated.
 
 
 
So what to do about the overscan issue.. well I happened to have an HDMI to VGA 
adapter with a 3.5mm audio jack output on the side.. so I added it into the mix, 
and lo and behold the overscan issue was dimished a great deal..not perfect, 
but much more usable desktop real estate. 
 
Then I tried the MPV media player with Armbian distro to play canned mp4 videos 
and was favorably impressed with the play quality with the built in Mali hardware 
graphics acceleration.. easily as good as the RPi and Omxplayer.. perhaps even 
with better controls in the MPV media player app.. score one for OPI.. 
things were looking up.. this was along way from the inert brick I owned earlier in the day.
 
So what about the overscan issue.. yes it is annoying, but perhaps over time there will
be a software fix developed to make it go away.. patience.
 
What else to do in the mean time?  
 
Well it is likely that the OPI in you life is not the only computer you have at 
your disposal..  so why not VNC into your OPI..?  You can set the X-window defaults 
to a reasonable screen size.. and have your OPI desktop arrive in a window on 
your other computer..  
 
Googling RPi VNC I found xtightvncviewer and xtightvncserver install instructions.. 
I installed, and went with a desktop size of 1280x600 for a comfortable fitting window 
on my RPI desktop..  and soon had a serviceable non-overscanned OPI remote desktop 
from my RPI..  hooray!
 
No hardware accelerated video through the VNC session.. but a decent desktop experience 
for most other pursuits.
 
Lesson learned.. OPI software is in it's infancy, and with time and effort spent, 
and some temporary workarounds.. it will find many uses.
 
If you want closer to perfection out of the box than what OPI has to offer? Pay more and benefit from a 
more developed product.. however, if you want to work the line a bit -  between cost and functionality -
perhaps you have more time than money available at the moment - don't dispair at your purchase.. 
persist a while before you opt for the lump hammer option.. and you may get what you need out of 
the RPi's clone-family with a bit of effort spent..  Good Luck.