traumfaenger

@Ruslan Dzanmahmudov I need the patch tested, so the request is directed to anyone using nightly builds or building themselves.  :-).  
 
Interesting micro USB plugs, remember of course the limitations of the pin/pin contact of the USB itself limiting the current to ~1.8 Amps continuous.

Hello again, I've got a new SD card, SanDisk Ultra 32GB UHS-I.
Because of the restart bug in newer kernel builds, I have flashed the 4.4.66 kernel, made apt-get update && apt-get upgrade ... and reboot is not working properly.
Is the reboot patch applied to your armbian 5.27 version with 4.4.66 kernel build for our Tinker?
 
EDIT: I've flashed the SD with Etcher, ~15MB/s with validation successful
 
Thanks

I remember that they had a repository named "rootfs", which had Debian packages for the proprietary drivers and their video codecs libraries. I see that they renamed it rk-rootfs-build. Their packages worked when I tested them, however they were only generated for one specific version of Debian (Debian 9 I think, if I'm not mistaken), and so they tend to depend on specific outdated components versions sometimes.
 
Also, since the drivers provided by the ARM Mali team seem to have better support for some technologies, at some points, I made my little aliases scripts to juggle with the different drivers.
 
That said, on my Gentoo system, I tried to use their drivers to run different KMS/DRM and Wayland GL benchmarks and they work fine. Using mutter and qtwayland was a mess, but I blame these projects for providing terrible error messages and poorly written documentation.

Just connect your 5V to pins 2 and 4 and ground to pin 6 of the GPIO header.
 
This goes straight to the power input of the RK808. It bypasses the input over voltage protection and current limit. Make sure you don't put in more than 5.5V
 
Edit: Further reading of the schematic (providing it's accurate) shows you should be able to power it directly from a single lipo battery. Obviously this won't put 5V out to any USB devices you connect though.

@tkaiser it looks safe to power it that way.  I would of course give the typical "don't hook it up backwards" warning, but the entire system, with the exception of the HDMI and USB, is powered via the RK808-B, and every input to it has multiple capacitors/etc.  I've put 6 hours on mine and run various load tests, no odd behavior.
 
Using my cooling solution it took 6 minutes 40 seconds before it throttled, and even then it was only cutting back momentarily then spending 10+ seconds at full speed.  At 10 minutes it started spending 30% of it's time throttled to 1.7 GHz with an occasional 1.6 tossed in there and the impact was observable in the minerd output.  I think my cooling solution is adequate, I can run a test to see if the system hangs using the micro USB input, using the GPIO to power it I had a rock solid 4.99 Volts at all times (measured at USB port).  I will update this post with those results.  Oh, I only achieved 6.8 khash/sec.
 
Attached devices:
 
25 mm fan -                       50 mA Wireless mouse dongle -   80 mA Amazon Basics Keybd -     100mA HDMI to monitor -             ????  
Recorded Data:
 
Using 5.0 V 4000 mA GPIO power:           Open circuit - 5.23 Volts     Idle - 5.21 Volts     minerd - 4.99 Volts  -->   Rated/load drop:  10 mV *** Using 5.25 V 2400 mA microUSB:            Open circuit - 5.36 Volts     Idle - 5.20 Volts     minerd - 4.84 Volts   -->  Rated/load drop:  410 mV Using 5.0 V 2 2000 mA AWG20 cable:      Open circuit - 4.96 Volts     Idle - 4.84 Volts     minerd - 4.75 Volts   -->  Rated/load drop:  250 mV  
Observations: 
 
Under no/low load situations power supplies will often output more than advertised, it takes a load to stabilize the regulation, that is why Open circuit and Idle were taken for all situations. My integrated cable supply is not as good as I thought, it was obviously the contributor to the voltage drop, going from a rated 5.25 to 4.84 volts while the quality charge cable only dropped from 5 to 4.75 Volts Teardown shows: ***This supply used 22 AWG wire over a 1 meter length*** The fan, being powered via the USB port of the tinker board, ran slower due to the voltage drop and the processor throttled at the 5 minute mark. The RK808 got pretty hot.  Stick one of the baby heatsinks they give you for the USB/ethernet chip or whatever nonsense on the Raspberry pi on there. I do not forsee any instability issues on the part of the processor at these voltages, however any powerhungry peripheral will shut it down.  
Conclusion:
 
Power for the Tinker board should be provided via the GPIO header If the micro USB must be used, a supply with heavy-gauge wire and an output of 5.25 volts must be used This is not to "increase the amperage available" <--- No.   <--- Pay attention.  No. This is to keep the operating voltage of the USB and any other 5V peripherals at an acceptable level. Voltage drop is independent of applied voltage (it is current and resistance dependent (Ohm's Law) ) A 5.25 V supply of equivalent quality to the 5.0 V AWG 20 test will experience the same 250 mV drop That will only reduce it's operating voltage to 5.0 Volts, so a happy (albeit peripheral-less) SBC DO NOT EXCEED A 2.5 AMP SUPPLY Stranded is not capable of carrying the current you found on that ampacity chart on google for solid wire Typical home-grade equipment is only 60 C rated (if lucky), meaning heat generated by the wire can melt it As mentioned before the micro USB connector is only guaranteed for 1.8 Amps by specification Credentials:
 
Electrical Engineer with 10 years' design experience in automotive sensors and actuators Stayed at a Holiday Inn Express last night 

For USB contact rating in micro USB:
 
    1.8 Amps is cited along with a 500 mA current on all other pins simultaneously.  An odd way to write the requirement, however if only pins 1 and 5 are involved, assuming heat dissipation is the primary concern, then you could, in theory (after performing adequate testing *TO FAILURE* on multiple devices), pull a known current more without risking a "thermal event".  I'm sure some less-than-brilliant soul simply added 1.8 and 1.5 and decided they had plenty of headroom...    In any situation, you can only assume 1.8 Amps, but I would not break into cold sweats or lose sleep over using 2A intermittantly.
 
  

No. I asked whether people who claim their Tinkerboards would 'run without any problems' (impossible BTW without hardware modifications) are able to run these two lightweight test tools. If you want to test power supply stability then you have to eliminate throttling first (!!!) and then use other tools instead: openssl, 7z and cpuminer for example (in Armbian it's 'sudo armbianmonitor -p' and 'sudo apt install p7zip' to get all prerequisits).
 
Then it's
openssl speed rsa2048 -multi 4 7zr b minerd --benchmark You're running throttled, that saves you from freezes/reboots. What's the purpose of this 'test' apart from demonstrating that ASUS' heatsink is insufficient?
 
Looks still a bit like throttling (since my ODROID-XU4 running at 1.8 GHz 90% of the time scores 62 seconds here but with Debian and Ubuntu Xenial numbers have to be 30 percent better). It's always advisable to switch to performance governor before, then to let 'sudo armbianmonitor -m' run in another shell while testing and check /sys/devices/system/cpu/cpu0/cpufreq/stats/total_trans before and after (since if numbers are different throttling occured and you fooled yourself -- for details check /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state). If you see cpufreq going below 1.8 GHz you're testing only for insufficient heat dissipation and not 'power supply' any more.
 
It's useless to continue here since around Tinkerboard there's just another micro community infected by the believe Micro USB would be ok for powering anything that needs more than a few 100 mA. It's not, it's the same sh*t show as on every other SBC, it's not relevant if some people with some understanding and able to buy approriate PSUs and cables won't fail since the majority of users gets a Tinkerboard that becomes unstable under load just due to the manufacturer's stupid choice of using Micro USB for DC-IN.
 
 
Why? Do you want things catching fire? Again:
 
Either take your solder iron and replace the crappy Micro USB connector with a sane burrel plug (and only then use a PSU exceeding 2A) or simply remove the heatsink and accept that you bought an overpriced fail limited to maybe 1.2GHz and let throttling or even adjusting /etc/defaults/cpufrequtils help 'solving' your underpowering problems.
 
BTW: I would recommend testing with cpuminer (minerd --benchmark) since this tool provides a khash/sec output so you're able to detect throttling pretty easy. On my XU4 running only on the 4 Cortex-A15 cores it starts with 8.5 khash/s (that's what the Tinkerboard must also show) and will drop almost immediately down to 6 khash/s or even below since load is too heavy and ODROID's fansink is a joke. If you Tinkerboard owners are able to improve heat dissipation that much that you get a constant +8 khash/sec value then you start to test for powering problems on this board.

I did some tests - http://tinkerboarding.co.uk/forum/thread-310.html

Status update on power usage:
 
@tkaiser suggested to test power supply stability by sysbench and stress commands. My power supply seems to be the same as @cyberks because hes data for the power source is following: 5V and 10W, what gives us
 
P = U*I --> I=P/U --> I=10/5 --> 2A
 
My power supply unit is also 5V/2A. Well, here comes the testing:
Temperature in idle state: 34°C
 
Test #1: sysbench, ran once, 2 Threads: passed
Test #2: sysbench, ran once, 4 Threads: passed
 
More interesting is the stress command:
 
Test #3: stress, 2 Threads, 15Min execution time (measured by CPU Time in top): passed, Temp from 34°C to 50°C
Test #4: stress, 4 Threads, 15Min execution time (measured by CPU Time in top): failed after 3Mins, reboot followed
 
Conclusion: During the benchmark my 2,5" HDD drive and a 80mmx80mm FAN were attached. It is clear, supply rated 5V/2A is not enough (what was told many times :))
After, I replaced the power supply by RPi3 official supply 5V/2,5A and ran the test again:
 
Test #5: stress, 4 Threads, 15Min execution time (measured by CPU Time in top): passed, Temp from 34°C to ~61°C
 
I would suggest using at least 5V/2,5A power supply. My RPi3 won't get it back
And in terms of USB cable, use one, which can also establish a data link between a device and computer, because they have better quality as those cheap-ones with charging-only function.

That's nice but your hardware setup is not an average one (good PSU and good USB cable) and sysbench as well as stress are both rather light workloads. IIRC @wtarreauuses OpenSSL to stresstest his boards. His Micro USB adventures with another RK3288 device can be followed over there: https://forum.mqmaker.com/t/miqi-based-build-farm-finally-up-and-running/605/10
 
Anyway: a board that exceeds already 1.6A peak consumption just by booting equipped with Micro USB is simply asking for trouble or even fire. Please read the last paragraph here: https://www.loverpi.com/blogs/news/93532993-canakit-2-5a-vs-loverpi-2a-power-adapter-comparison

And, if you are looking for a good power supply you go to IKEA - as usually

Absolutely not. That's the last thing I would think about. My use cases are 'combined router / nas / mini-server with no GUI at all, and only using CLI' + IoT stuff in the meantime. For these use cases the Tinkerboard is just an absolutely overpriced fail and the only use case I could think of is such a desktop replacement since CPU performance is superiour (Cortex-A17 are still the only ARM cores available that can compete with x86 when thinking of both performance and price) and VPU/GPU situation looks also promising (so unlike most if not all other SBC out there HW accelerated video and 2D/3D stuff will work even with mainline kernel now or pretty soon).
 
That being said: Combining such a powerful hardware with the most stupid choice ever to provide power to the board (something unreliable called Micro USB) makes it a double fail and a support nightmare too. The Tinkerboard is a nice example for 2 big brands focusing on marketing and they attract the same kind of people that buy Raspberries. The majority of these people has no clue about Ohm's law, voltage drops and instability caused by one single reason: the crappy Micro USB jack encouraging people to use crappy chargers instead of power supplies and crappy cables instead of short ones with low resistance (at least 20AWG rated -- always remember: If you buy cheap you buy twice)
 
A lot of Tinkerboard users will run in underpowering problems causing all sorts of weird symptoms and they will not understand that this is only related to the hardware vendor having finished the Tinkerboard's hardware design driven by marketing and maximizing profit only instead of responsible choices (instead of Micro USB using a barrel plug for DC-IN and selling only Tinkerboard kits with a good 5.2V/3A PSU using a fixed cable with low resistance). Of course Tinkerboard users will blame the software for the stability issues they run into and when you ask them to replace PSU/cable they will answer: 'Can't be the reason since with my RPi 3 same combination works perfectly'.
 
Which is NOT the case since Micro USB with SBC is the same sh*t show everywhere. The Raspberry folks just added under-voltage detection circuitry starting with 2nd generation Raspberries triggering a GPIO state change to let the 'firmware' downclock CPU, VPU and GPU cores so instead of solving the problem they simply masquerade it. You find all details RPi users are plagued with since years and Tinkerboard users suffer from in a more severe way due to choosing shitty Micro USB here: http://www.cnx-software.com/2017/04/27/selecting-a-micro-usb-cable-to-power-development-boards-or-charge-phones/ (reading through the comments too is recommended).
 
TL;DR: Tinkerboard's powering scheme is a fail targeting clueless people (letting them think Tinkerboard would be an easy replacement for their already existing Raspberry 2 or 3) which will lead to stability issues in most installations while always software will be blamed for.

Dude, I like you
 
Seriously, I agree with you, but there is something what I won't do, simply because of the use-case I am up to. You see, you are right, 60€ and not even a proper SoC to USB output, I mean, there have to be soldered 2/4 lines from the SoC to USB to be able to provide fully operational port, but they didn't.
 
But what expectations do I have. What will I be using it for. What is going the board you are talking about cost?
 
For me, it's about a fast CPU, to handle the network requests. I want fast Adblocker (PiHole), own DNS Service with local caching, openvpn to be able to connect to my data on network, and simple cloud solution That's all. And for this scenario I think this board has still more potential than RPi3
 
I had this awful Banana pi m2u whick looked hardware-wise indeed very promising, but it's software was a no-go.
And if I wait for a board, I mean, we all know PC industry. You can basically wait all the time, and you get better and better devices for your money.
 
And that's why I'd like to thank everyone who is contributing to this project I have basic knowledge of C# and Cpp but it's by far not enough to slip into kernel-thingy. 
 
I am actually pretty happy when I can compile some user-space driver (ntfs-3g)

BTW: I don't want to discourage anyone working on this board and further improving support. It's just me giving up on this hardware since ASUS performs so lousy (wrt deal with 3rd parties wanting to do exactly that: improving software support for their hardware). So as a last hint: since I believe the only really interesting use cases for this board are 'Desktop replacements' you should focus on this when experimenting with different cpufreq governors. Most desktop tasks benefit a lot from cpufreq being ramped up as quick as possible. Also have a look at: https://forum.armbian.com/index.php?/topic/4246-can-improve-the-desktop-performance/ (though I believe it's also important to improve IO behaviour of browsers)
 
 
 
This is Rock64 with an I2S companion board sitting on it: https://drive.google.com/file/d/0B0KJDZUkcqOqUnBYNU9JN0EwV2c/view (details will be available soon so I won't share more information now since there isn't much more I know anyway  )

Thank you very much
Well, it's a small and powerful SBC which shows compatability to RPi, and I think it will attract people to deal with this platform.
These are also kinda good news, because work is being done. What I hope, apart of you guys here @Armbian,
is the fact, that ASUS is not a small non-sence China corp. So I hope they will deliver
 
Has anyone experienced "dnsmasq", which is present, but is not working properly. When I restart the service, it will come back online,
but again, after coule of mins my browser can not resolve IP address. Pi-Hole uses it to block ads on DNS-level.
Update: Pi Hole seems to be running fine. I'm excited to test this box with Seafile  Maybe I'll get over 2,3MB/s as it was the case with RPi3

Well, I did some benchmarks regarding built-in USB Hub, Samba share write/read, and copying from USBHDD#1 to USBHDD#2.
 
First of all, the file system on the USB Drive made not much difference (about 2MB/s more or less).
Both drives are from WD, one is formated as NTFS (1TB, USB3.0), the other as ext4 (750GB, USB 2.0).
 
As long as I was doing a single write-operation through Samba to one of the USB drives, I got a transfer rate ~30MB/s.
Reading data from the drives by copying them to local machine was about the same speed ~30MB/s.
 
Now, when writing same file simultaneously to both drives, the bandwidth splitted by half for each drive, resulting in ~15MB/s for each drive.
Reading data by the same scenario was also ~15MB/s for each drive.
 
Interesting part was trying local (on Tinker, SSH, rsync) USB Drive #1 to USB Drive #2 copy and the other way around.
There, the choise of the file system gave +/- 2MB/s being somewhere between ~8-11MB/s.
 
As I did the benchmarking, the system was pretty stock only running Pi-Hole in the background, so pretty much all the resources were free.
CPU usage did not climb over 80% by the ntfs-3g driver, so the CPU (max. 1.6GHz on the image used by me) had enough potential.
 
The limiting factor is in fact the freaking USB Hub! As a member of this forum mentioned, ASUS made really stupid move by not soldering one more USB Port, which is provided by the SoC  However, the system is fluent, can deal with my upload speed, and makes fun! Maybe, someone would find this test interesting. Thanks
 
Edit: Just in case, someone wants to know... 5V/2A power supply did not managed to spin up one of the 2.5" drives properly, although the system was stable and did not crash. I've used the RPi3 official supply 5/2.5A, and it powered the board and two 2.5" drives well.

Hello, folks. First of all, I really appreciate your efforts maintaining practical and powerful Armbian image for this board.
You, guys are the reason why I have returned my Banana Pi m2u back to the seller.
 
Today I got my Tinker in the mail.
 
I've installed Armbian 5.27 (stable) with kernel version 4.4.66, it is pretty smooth, and I'm not looking back for the BPi m2u.
 
Thank you very much!
 
I have attached a picture, of what I have found out, but you will surely know this already.
 
Tinker is running via SSH, hosting Pi Hole and some other network-based services. No GUI, no video acceleration required in my setup.
 
When connected to a Gigabit Network, I can write and read up to ~30MB/s to a Tinker-attached USB drive. (Compiled ntfs-3g latest stable 2017.3.22)
 
My question is, whether, and to what extent does the speed drop, when I do a copy to two drives connected to Tinker simultaneously.
 
I mean, USB/Ethernet bus is not shared, what is big pro. But its SoC has internally 3 USB hosts (info provided by dmesg, one of them is also OTG) and a USB Hub is connected to one of them providing us with 4 ports. The bandwidth of the USB drives would need to split between them because of the HUB. Can you agree on that?
 
In this scenario, I would copy a file to two network shares (Samba) simultaneously, the speed would drop to half. Resulting in 15MB/s for each drive. Have anyone tested this?
 
Also interesting is USB to USB transfer rate, since Ethernet is not involved in that process.
I mean, the USB 2.0 bus has 480Mbps of bandwidth, but ~30MB/s is about 250Mbps, so this is the real speed (overhead subtracted).
In addition, would be there any bandwidth free for the second drive in USB to USB scenario leading to the transfer rate to be the nearly same? Like if 130Mbps of 480 would be available to the second drive?
 
Again, thank you very much!
 
Edit: I have experienced following trouble: When copying at full speed (CPU usage is about 49%; Computer to Tinkers USB drive on Gbit LAN) it seems that the system has not enough internal bandwidth, or an ability to set an interrupt to be able to handle PiHole DNS.
Because of that behavior, pi hole does not get enough "CPU time" or whatever and does not resolve and forward a DNS address. I understand, it is busy by copying, of course, but it is be able to do multitasking, right? Since only 1/4 of total available Gbit speed is used by copying the data. It still should be able to do other network stuff.