TonyMac32

Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board?  I see a few things on the Banana Pi site that are... awkward.  There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V"  is that accurate?  I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter. 
 
I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation. 
 
I am by no means looking for perfection, but it should be accurate enough that I can
Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed.  We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets.  Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to.  We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..."  They know what they're talking about.
 
Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual:  My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc.
 
Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete.  I see it's listed as AP6212 here, but on the R2 manual it says:  " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. "  <---  That is the sort of thing that causes trouble and upsets people.
 
The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are.  I do at least see +12V being specified there, and consistently through, so OK.  I was bracing myself for magic smoke everywhere...

Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board?  I see a few things on the Banana Pi site that are... awkward.  There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V"  is that accurate?  I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter. 
 
I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation. 
 
I am by no means looking for perfection, but it should be accurate enough that I can
Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed.  We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets.  Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to.  We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..."  They know what they're talking about.
 
Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual:  My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc.
 
Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete.  I see it's listed as AP6212 here, but on the R2 manual it says:  " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. "  <---  That is the sort of thing that causes trouble and upsets people.
 
The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are.  I do at least see +12V being specified there, and consistently through, so OK.  I was bracing myself for magic smoke everywhere...

I did not say there was, I was addressing your assertions that they were useless to software developers, in case anyone had a similar opinion or hadn't considered it before.  Now, let's all bring the combative nonsense and slander down a notch, shall we?  
 
   

@chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
 
There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
 
 
 
 

@chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
 
There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
 
 
 
 

I've just finished writing my SHT31-D (I2C) Nagios plugin.
As promised, it can be found here for anyone else interested.

Thanks a lot for the hints.
 
I chose the Marvell 64-bit patch instead of RK3288 to replace compressed zImage with the binary Image.
https://github.com/armbian/build/blob/master/patch/kernel/mvebu64-default/packaging-4.x-with-postinstall-scripts.patch
 
Now Armbian 5.32 (Ubuntu 16.04 Desktop) is successfully running on my board.
 
I forked the repo and make my own commit to add the support for RK3399. You can find the changes to original repo here:
https://github.com/nightseas/armbian-build/
 
Know issues:
 1. No GPU or VPU pack installed for now;
 2. There's a binary tool from RK used to convert u-boot, which can't be packed into the u-boot deb because it's for x86_64. Means you can't update bootloader in a running Armbian.
 
Next step will be GPU and VPU userspace lib porting. 
 
Screenshot of desktop, with CPU, temperature, and frequency:

 

HID is now working, of course the touch input does not rotate with the screen (perfect compatibility with raspberry pi! )
 
I can link to the Deb packages for the kernel/dtb if anyone wants to try them out, and if anyone with a MiQi can make sure they don't break anything before I push the patch to the repo.

[update 12/2017 at bottom]
Possibly late, but I would like to put everything we know in one place for anyone who might think of buying this board.
 

 
Overview:
 
   This is a form factor and (mostly) I/O clone of the Raspberry Pi 3 with a much more powerful quad-core Cortex-A17 Rockchip rk3288.  It supports HDMI 2.0, has 2 GB RAM, Gigabit Ethernet, Wifi and BT on board, etc:  https://www.asus.com/us/Single-Board-Computer/Tinker-Board/
 
   As numerous other sites have covered all the typical performance metrics and extolled the power and so forth of this board, I'm going to go ahead and give you the less exciting information and the tradeoffs/problems.
 
Mainline:
 
Getting the mainline kernel to boot on this machine was pretty straightforward, mainline support for the hardware, including WiFi, makes for less patching and allows a lot of functionality from the mainline kernel without excessive patching.  That said, so far Bluetooth and squashing a reboot bug have not been successful (I'm under the impression the rk3288 was never truly intended to boot solely from external sdmmc devices)
 
Important Hardware Considerations:
 
          Power Solution:  This board is equipped with a micro-USB connector as it's power input.  Micro-USB is only rated for 1.8 Amps, no matter how big the numbers on your power supply are.  It is entirely possible, even likely, that you will hang this board by plugging in peripherals to the USB 2 slots.  Micro-USB is a terrible method of providing power to a single board computer, and is the most serious problem with this device.  This device should be powered via the GPIO header using a filtered supply if you wish to have any semblance of stability.
 
          Heat:  The rk3288 is not a low-power chip, and the heat sink supplied (pictured above), is not adequate for any CPU-intensive activity, quickly throttling performance when it gets too hot. 
 
          USB throughput:  I have not empirically tested this, mostly because it is unnecessary.  For some reason the 4 USB 2.0 ports on the board are all routed through a single USB Hub as on the Raspberry Pi.  Not incredibly useful, other than not having to buy an external hub to make the one exposed USB port into 4.  (unless of course those devices use power, then you need a powered hub anyway)  In case you are wondering, there are 2 USB2 ports available on the SoC, however the dev team for this board decided to dedicate one to an "HD Audio codec" instead of using the dedicated I2S/PCM output to do that job.
 
          Undocumented pins:  The 4 pin header  next to the micro-USB power serve no documented purpose.  One pair is definitely the power button as references in the device tree for the board,  I've determined (and have seen others likewise verify) that the pins closest to the edge are the power button input. The other is not documented at all, and I've not wanted to tempt fate by shorting it out.
 
Software/Support Considerations:
 
          The Documentation for this board is terrible.  Incomplete, non-existent, etc.  The Official ASUS image is a series of workarounds and, until release 1.6, was not properly available to the community.  Even then, development does not appear to be occurring publicly (if it is that means development has stopped).  Rockchip representatives (seemingly not the ones working on the Tinker Board) have at least come forward to provide some helpful hints concerning issues, but ASUS has been entirely silent. 
 
My opinion after use/development:
 
          This is a very powerful board.  Unfortunately I had to build an adapter to power it over GPIO so it would run properly with any moderately demanding USB peripherals, I added a larger heat sink to stabilize the thermal situation, and am currently trying to find a way to get the board to reset properly without using what the Tinker Board source code itself labels a "HACK".  I can not recommend this board to a new buyer.  It's a shame, really, this board had every opportunity to be a really good solution. 
 
If the prospective buyer wants nothing more than a 4K media player, there are other options that will serve that niche better, including a small mountain of inexpensive TV boxes.  This board is not ideal for a NAS due to the USB Hub (unless you want to test the limits of the SD card interface).  CPU intensive operations will throttle the device to under 1 GHz with the factory cooler, so without modification you are limited there. Powering peripherals through the board is simply not possible out of the box due to the Micro-USB power solution.  Powering through GPIO is the only sane option. Raspberry Pi compatibility is not absolute.  The GPIO libraries (WiringPi, etc) are not exact, some of the pins serve multiple purposes on the header, etc. This board may be adequate as a small kiosk linux desktop, it is fast enough to provide a snappy interface, and will fit in many of the available cases for the RPi.  I would still recommend GPIO power and probably improved cooling in case a lot of video/etc are needed.  
[update]  I've been running the Tinker Board as a daily driver for over a week, powering it via micro USB with my normal peripherals (mouse/keybd, wireless active, touchscreen attached)  My findings are what would be expected:
 
Power supplied to micro USB port:  5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port:  4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop.  
Now, you might be saying "I run my Tinker on micro USB all the time and don't have any issues"  You're right, and you're wrong all at once.
 
The processor/RAM use much lower voltages provided by the RK808 PMIC, so the system doesn't fold up and crash when the input voltage gets too low.  HOWEVER, here is a snippet from my dmesg:
 
What you're seeing here is my little wireless mouse receiver giving up the ghost because of voltage starvation.  More or less, when I get these voltage dips, anything that needs 5 volts (like USB peripherals, say that external HDD, webcam, card reader, mouse) shut down and/or could be damaged/corrupted.  I have not had a single system failure, however were I to be reading/writing external media (or running this off of a flash drive for some reason) I'd have experienced some real problems.

Nice catch ! This might prove useful, yeah.
 
Reading this document, I still don't understand why they're dead focused on having technology specific buffers, where all those techs use DMA buffers in the end though. At least internally.
 
I'm currently looking at DRM PRIME and trying to understand if you can, as a user-space application, allocate a DMA buffer, pass it to something else (user-space or kernel-space) so that it writes some bitmap in it and then display the bitmap on the screen using DRM calls. If that can be done, I'm throwing out the DRM/ION part of the VPU driver and let the user-space app/MPP do the buffers allocation.

Update images 20170803.
Added support for remote control. To use it you need to add the correct file "remote.conf" in the /boot directory or /etc/amremote. By default, a part of the image includes several predefined files (in the /boot directory). To use it you need to rename one of the files in "remote.conf". Additionally uploaded the site to the directory the deb package "amremote.deb" , which can be installed in the old system (do not download the whole image). After installing this package you need to run service "amlogic-remotecfg" and add (rename) the correct file 'remote.conf".

The FAQ is totally incorrect, it is actually true 4K.  Their initial release used a "fake" 4k where it was up-scaled, why, honestly I don't know.  Now, the Legacy kernel works with 4k on my Samsung, however I am aware that some Acer products are... different.  I believe I saw a patch related to this, I can take a look.  The Next and Dev kernels do not yet have 4k support, I haven't rounded up everything needed, and the DRM system has gone through some changes since 4.4, so it's not a drop it in and go situation.
 
their 4k video player is the QT based one found in the rockchip repo.
 
@chwe I understand, I was actually outdoors repairing some masonry, I had to rebuild/replace some sections of a 70 year old wall.  Beautiful weather for it, and a good excuse to work with my hands.
 

Are you a child in the schoolyard looking for ways to taunt someone, or are you an adult?  I understand being frustrated with an issue, but your lack of basic manners is unacceptable.
 
As far as FS corruption: Win32DiskImager causes it.  It is a tool that is only used out of ignorance of superior options like Etcher.  Because of that, we do not support its use and automatically recommend the use of Etcher before we spend our time debugging issues that may simply be faulty SD card burning.  
 
Other common problems: garbage/counterfeit SD cards, inadequate power supply, etc.  Read the documents you were given a link to.

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
 
Boot log: http://pastebin.ubuntu.com/25206030/
 
I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

Awesome.  I'll patch this into the Dev image for anyone here that wants to experiment with the user space parts.

Cool, I will check how this VPU driver works with a 4.13 kernel on LibreELEC later this weekend.
 
I would suggest testing the VPU driver and mpp using Rockchip's gstreamer plugins or possibly LongChair's mpv/ffmpeg.
I don't know much about gstreamer but it seems to be what the Rockchip's developers use to test video decoding.
Both mpv/plexmediaplayer and kodi use DRM/KMS, gbm version of libmali and a few kernel hacks on LibreELEC for smooth 1080p/4k video playback, they most likely need modifications to run on x11/wayland.
 
For a version of ffmpeg that use mpp for decoding, see https://github.com/LongChair/FFmpeg/commits/rockchip or the rockchip-new branch.
LongChair also have a mpv version for both those branches of ffmpeg at https://github.com/LongChair/mpv/commits/rockchip or the rockchip-new branch.
I have a ffmpeg 3.1 backport at https://github.com/Kwiboo/FFmpeg/commits/rockchip-krypton and Kodi Krypton patches at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-krypton.
The Kodi Leia patches in the rockchip-leia branch will be updated once we have achieved more stable playback on rk3328 devices using mpv and Kodi Krypton.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

I understand why you would love it cause your ferrari powered VW golf gets hammered quite often:
 
 
keep fighting, if you solved all this issues there's nothing else which works properly on a RPi.  Maybe they come up with something like 'is the tinker able to play 8k hardware encoded video?'  If I have time on weekend, I may play a little bit my asus tinker and try to solve some of these issues (if the weather gets better I go sailing ).

I would if I could, but I've no way to log into the device on the standard images as this is my only keyboard! Maybe they'd let me borrow one from work.
 
I have to say thanks thanks for all your work and input in this thread. When I got this device I was unaware of armbian, and happened to discover it because you posted a link in the asus forum: https://tinkerboarding.co.uk/forum/thread-330.html
 
I found armbian and its users so interesting I must have read this entire thread two or three times! If you follow the link above you can see how I followed your example with GPIO power and an uprated heatsink and was able to hacksaw a hole into my case and attach a little fan! You can even see my dongle

*High-Five*
 
I'm testing the 4.4 legacy kernel with the emergency patch, I added all the changes we made to it so as to protect the MiQi (And I think it's just smart).
 
I'll be working on 4.13 later today to get Dev set up.
 
I forgot to change the compatible line in the dts, so it didn't run the code.  Well, I guess that works.

*Updated 7-23*
 
~~All kernels should be fixed at this point, Legacy, Next, and Dev.~~
 
The ASUS Tinker Board has a big problem with rebooting properly, centered around the SD card power supplies.  Upon issuing a shutdown request, the kernel is turning everything off , including the vmmc regulator.  To make matters worse, vqmmc is set to 1.8 Volts if you use a UHS SD card, and the kernel is not switching it back to 3.3 volts before rebooting, which is required if the Rockchip boot ROM is to communicate with the device.  The result is a hung board in MaskROM mode.
 
For the Default kernel (4.4), a patch was carried over from the vendor software (quite literally tagged as "HACK" which added a shutdown routine to the rk mmc driver.  It powers vmmc back up, switches vqmmc back to 3.3 volts, then delays for 20 uS or so.  It works on default.
7-22:  Need to add fix for " echo b > /proc/sysrq-trigger "  ETA:  7-22 or 7-23 7-22:  Adding device check to make certain there are no complications with the MiQi.  Concurrent with sysrq fiq.  Complete and uploaded.  
For Next/Dev kernels, however, it does not work.  I don't know the full system that well, so I can't comment as to why just yet.  It is also important to note that testing the patch on kernel 4.11/4.12 resulted in a MiQi crash on reboot, wheras I've had confirmed this doesn't appear to be an issue on 4.4.
7-22: It was determined a day or so ago that the issue was the mmc not being powered down before the hack happened.  Now that is commanded.  7-22: Initial patch broke MiQi, myself and @Myy worked today on figuring it out, trading kernels and patches.  We thought it a good idea to use the device tree platform to discriminate.  Fix is now known, adapting patches and moving them from Dev to Next.  Implemented 7-23:  Rockchip-DEV is now kernel 4.13, reboot patch tested and works.  
Any expertise in this area would be welcome, I'll update this post as things go on.

I finally made a copy past monkey work out of it and posted it in the forum. So if people want to keep this 'white paper' idea alive we could still do it, but as long as there's not enough manpower i'll left it in the forum (doesn't make sense to hide it)
 

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

I flashed the file from the download link above: Armbian_5.32.170724_Tinkerboard_Ubuntu_xenial_next_4.12.3_desktop.7z 
 
After entering root/1234/etc and getting to the desktop, the first thing I tried was a reboot, and it successfully rebooted back to the desktop. I tried again from the newly rebooted desktop, and success again. 

NEXT nightly = 4.12.3, updated this morning.
https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z