TonyMac32

For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image. 

[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.

I've been toying with the idea of designing a simple board and publishing the artwork/BOM for it, but if you look around, one for the raspberry pi should be available, look for DIN rail pi accessories, some of them have regulator hats.
 
As far as filtered (I forgot to hit that point), I am referring to a capacitor/zener diode combo to protect against switching noise and over voltage. 

http://share.loverpi.com/soc/amlogic/buildroot/dl-2017-05-15.tar
 
Extract it to the buildroot/dl folder for the buildroot from 2017-05-15. I will upload the 2017-06-19 files tomorrow.

Patches are being pushed on patchwork for mainline support of Le Potato as promised on Kickstarter.  https://patchwork.kernel.org/patch/9845599/
 
At this rate it will have a better mainline device tree than the Tinker Board (Armbian's NEXT and DEV DTB's are my mashups using the 4.4 device tree from "ASUS" and the Rockchip Linux github)

I used
echo b > /proc/sysrq-trigger to trigger reboot on 4.12.2 with the ugly hack installed, and it worked.  Without the hack it does not.  Let me see if I can apply it to the normal reboot process.

I have the dl portions of the buildroot from May and June. I will upload them for you soon.

You may take my copy here. I'm curious if your kernel will boot (wasn't successful so far).

Ooops...
I forgot this.
It is a native compilation on the target.
 
M5
GPIO_API-armbian-build.tar.gz

In case you haven't read about it: TinkerOS_Debian V1.9 (Beta version)
18. Don't hold libsbc1 at 1.3-1 and update to latest libsbc1 since the issue for A2DP has been resolved.

I use either flashcp or nandwrite from the mtd-tools, those can work directly on /dev/mtd0 or partitions..

Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:
https://www.w3schools.com/cssref/css3_browsersupport.asp
 
If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells
 
2c
 
 
 
 
 
 

Well, I am the only poor guy to have the board.  ;-)
 
 

Well, I am the only poor guy to have the board.  ;-)
 
 

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1702407

Yeah the connectors for USB3-A are tricky. On my old Thinkpad the lower USB3 port which I used a lot more than the upper port enumerates half the time only as high speed instead of super speed because it seems to be worn out, I also noticed some USB3 connectors fit a lot tighter than others... I wonder if there is some low level stats we can pull out of Linux to see USB transmissions errors as an indicator for bad cable connections?
 
Edit: apparently there is this https://wiki.wireshark.org/CaptureSetup/USB

My default workstation. Soon it will be deserted on those small notebooks for summer time.
 
Usually there is, little but not much, random clutter around: papers, cables and boards. Core testing and debugging infrastructure is on the right side. Under the table I have two fix mounted and easy accessible USB powered hubs, which serves as powering and debug. Half ports have secured 1.5A per port. 14 ports in total, connected to server and shared around the network. Powering via extended USB3 hub proved to be enough in most cases, for rest and for special cases I use their original power supplies. which are somewhere below, differentiated with colours. Than there are 15 gigabit and 5 fast Ethernet ports and 2.4G AP. Since I am software developer first and tinkerer second, 40" of property is central point of interest. Sometimes it also get too small and also to avoid more cables, I have another fixed 19" in debug section. On the top of folder shelves I got an extremely low noise build server and another cabinet of electronics stuff. Lower left cabinet is place for small desktop computer and printer, while right side is filled with various parts, from cables, bigger boards, soldering equipment, hard drives, etc. Most of cables are hidden / embedded, to make this mess manageable. When I don't play with boards, I move cabinets in upper level and make use of whole table (minus keyboard and mouse).

The rk3288's H.265 support is supposedly a bit buggy and is considered "legacy" hardware by Rockchip.  I've not tested it to be honest, as I've been working on the peripherals/etc. 
 
@chwe I doubt my reply meets Heinrich's quality standard for freely provided information, sadly.

Look at rockchip patchwork area, they are adding the RK805, which I believe is the pmic involved here? They are very similar, but not quite the same.  https://patchwork.kernel.org/project/linux-rockchip/list/?q=rk805

Awesome Helios4 is successfully funded !!!
 
We still accept orders till the end of the campaign : July 19, 2017
 
https://shop.kobol.io/
 
Thanks for the support.

I can contribute to this, I would recommend having a checklist for each SBC marking off what Armbian-related documentation has been completed.  People with specific hardware would of course have to step up, of course a lot of this stuff exists in piecemeal throughout the forums.  

I just flashed the first 16MB from my sdcard on the SPI flash and well, it boots :-)
 
DDR version 1.06 20170424 In SRX LPDDR3 786MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:7 OUT Boot1 Release Time: 2017-05-18, version: 2.43 ChipType = 0x11, 187 emmc reinit emmc reinit SdmmcInit=2 20 SdmmcInit=0 2 powerOn 702746 Usb re Boot. 6702743 Usb re Boot. 12702748 Usb re Boot. 18702750 SoftReset SoftReset, 19367264 us  
Miniloader seems to run SPI at 12Mhz, but I guess now the boot image needs tweaking since I dont see any u-boot...

I remember reading about issues with UART DMA on the Tinkerboard, so maybe Rockchip DMA in general is partially broken?
According to Rockchip SPI DT bindings DMA properties are optional so you can try removing them, but whether it will work without DMA depends on the driver.

[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.

And it continues: https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=200#p194654
 
Another user reports general XU4 USB3 receptacle issues as 'UAS problems' for unknown reasons. The symptoms are exactly those user @Kosmatikreported with his defective Cloudshell 2 cable when blacklisting UAS (see two quoted links above). So if @joaofl would really use UAS he would run in the same errors but this time of course not having
reset SuperSpeed USB device number 3 using xhci-hcd in the logs but various occurences of 'uas_eh_abort_handler' and 'uas_zap_pending' (same problem, different driver --> different dmesg output). What do we see happening in is this funny micro community creating their own micro reality over there? A user not using UAS reporting an XU4 problem (USB3 receptacle troubles) gets the recommendation to 'DIsable UAS'. And at the same time the usual suspects still run their insanely stupid 'UAS is broken in Linux everywhere' campaign in ODROID forum. 
 
Why I'm mentioning this? Since situation with ROCK64 is very promising also in this area. We're currently in touch with Rockchip engineers since I reported UAS trouble regarding 'ERROR Transfer event for disabled endpoint or incorrect stream ring' --> http://sprunge.us/HURC
 
A Rockchip engineer almost immediately confirmed being able to reproduce (only with RK3328 but not RK3399 -- same xHCI host controller as RK3328 but different USB3 PHY). Currently they're buying USB-to-SATA bridges we recommended for testing and I hope to be able to soon report some progress.