lafalken

EDIT: I deleted a lot of the results I just posted after re-reading the thread... It's all been done before! I got similar resuls as others who've done the test, around 6.6khash/s followed five minutes later by a decline to around 6.1, caused by thermal throttling to ~1.7GHz.
 
At least I seem to have a stable setup. Any other tests I can run on armbian's behalf? Anything I can do to help, I'm happy to give it a go.

But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ?
 
Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.

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

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. 

Yay ! So we got a 4.13 kernel that can reboot on ASUS Systems then ?

Well, I guess it already fits as it is - so there is no need for me to compile the Kernel?
Burned the SDcard with armbian 4.12 nightly (unfortunately desktop image, quite large).
What I did:
git clone -b Tinkering --depth 1 https://github.com/Miouyouyou/MyyQi cd MyyQi tar cJpvf kernel.tar.xz boot lib usr Followed by: sudo dolphin create a folder on the SDcard (home directory) copy the kernel.tar.xz into that. Connect the UART cable.
Insert the SDcard in tinker board, Power.
Boot the tinker board (reboot doesn't work so while extending the SDcard it 'dies').
Power off - Power on - login as root.
cd /home/tido/ Unpack all the files: tar xJpvf kernel.tar.xz open a second SSH look into the folder:
cd /usr/ ls -la copy the files
cp -r usr/* /usr/ cp -r lib/* /lib/ in the second SSH cd /boot ls -la cd /home/tido/boot/ ls -la cp -r zImage /boot/ cp -r rk3288-tinker.dtb /boot/dtb/ Armbian uses currently not the dtb called: tinker. Instead rk3288-miniarm.dtb rk3288-miqi.dtb. cp -r rk3288-miniarm.dtb /boot/dtb/ cp -r rk3288-miqi.dtb It is actually an easy instruction for everyone
uname -a
Linux tinkerboard 4.12.0-rc6-The-Twelve-MyyQi+ #1 SMP PREEMPT Fri Jun 30 19:37:05 UTC 2017 armv7l armv7l armv7l GNU/Linux
 
UART connection
reboot, it died at:
[  OK  ] Started Session c2 of user tido.

reboot - now I can login
armbianmonitor -u
/var/log/armhwinfo.log has been uploaded to http://sprunge.us/NAFa
 
Is this already in the file ? 
Add the following boot option to your boot loader : rockchip_tinkerrebootfix=on  
Just the shutdown
 
 
reboot command:
 

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

I am aware that this board has severe powering issues when using the USB power connector..
After struggling a lot to find a reliable PSU, I ended up buying the "official" RPi PSU that's supposed to provide 2.5 amps, however I still get a shutdown once every 2.5-3 weeks. (I suspect it's power)
Are these patches going to improve this by any chance, or will I forced to craft and use a 3A GPIO PSU?

I'm kind of reluctant, because I've heard that there are no fuses/protection in the GPIO and you can easily toast the board that way.
The reboot fix will be awesome, however.

PS: I'm also coding a nifty little Nagios check for the SHT31-D I2C sensors that just arrived, when my friend takes care soldering the pin headers and making the wires for me, I expect to get it on github soon.

Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection...
 
However, I did it the same way before and it worked. So I don't know what they've added that could fail...
 
Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches :
https://github.com/Miouyouyou/RockMyy
 
EDIT :
Well my 4.12 DTB file works so it's clearly an issue generated by the new definition...
 
Oh... please...
/tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c
if (!strncmp(irq_res->name, "JOB", 4)) { irqtag = JOB_IRQ_TAG; } else if (!strncmp(irq_res->name, "MMU", 4)) { irqtag = MMU_IRQ_TAG; } else if (!strncmp(irq_res->name, "GPU", 4)) { irqtag = GPU_IRQ_TAG; } else { dev_err(&pdev->dev, "Invalid irq res name: '%s'\n", irq_res->name); return -EINVAL; }  
I replaced the strncmp calls by strncasecmp and... it works...
 
Well, I'll reassemble the patches, and commit this.

Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH.
If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it.
 
Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't.
 
Note that you can run :
 
systemctl set-default multi-user.target  
To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need.

I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday.
 
I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay !
 
For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process.
For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way.
 
That said, the main focus with this release will be :
The hardware video decoder/encoder chip.
RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it. Trying to start pushing patches to arm-soc .
The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches. Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases.

To secure top download speed around the globe, we need to have as many torrent seeders as possible. Currently we have dedicated seeders in: Estonia, Germany, Pakistan, Slovenia, Argentina, Singapore, USA, ... but we might be slower in China or Japan.
 
Prerequisite:
 
- Armbian or any Debian or Ubuntu based distribution (check instructions how to run armbian-config on a generic Debian/Ubuntu),
- 1TB of free space.

a) Installation with installing Transmission server
 
login and obtain superuser rights, execute armbian-config, select Software -> Softy, install Transmission server. (use space to confirm and enter to proceed with install)
   
Leave armbian-config and after a few minutes check your torrent server status with the following command:
transmission-remote -n 'transmission:transmission' -l and you should see some progress:
 

Note:
Torrent server installed this way is auto updating - it checks daily for new images, adds new and purge old ones.
 
 
 
b.) Installation to the existing Transmission server
 
You only need to install a cron job script that your client serve only most recent files.

Create file:
sudo nano /etc/cron.daily/seed-armbian-torrent with this content:
 
 
Change username(transmission) and password(transmission) if have something else than stock, save and exit, then run:
sudo chmod +x /etc/cron.daily/seed-armbian-torrent sudo /etc/cron.daily/seed-armbian-torrent Optional:
 
If you use GUI, you can install desktop front end for simple torrent server monitoring.
 
apt install transmission-remote-gtk Host: localhost
Username: transmission
Password: transmission

Confirm and click connect.
 
 
How to stop seeding torrents?
Remove cron job: sudo rm /etc/cron.daily/seed-armbian-torrent  
Remove torrents:  transmission-remote -n transmission:transmission -t all --remove-and-delete This command will remove all files on your torrent server! If you seed other stuff do a cherry pick.
 

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)
I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 
I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)
You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.
 
For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.
 
Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go
 

Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then.

I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors):
Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that? From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO)
If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right? In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin) I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem? Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them. Thanks in advance.

Yes, your script is working.
I want it to use nginx. Please help to configure with it.
$ /usr/local/php7/bin/php -v PHP 7.1.3 (cli) (built: Mar 31 2017 18:57:35) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.1.3, Copyright (c) 1999-2017, by Zend Technologies  

Sure, but if we go this direction we have to keep in mind that based on combination of kernel and board the sysfs paths differ the udev rule has to adjut permissions for, that we then also have to ensure that BS fex contents like the one famous 'Team BPi' provided for their M2+ board have to be corrected by someone able to test through (same for NEO), that the module to be loaded and added to /etc/modules might be named differently depending on kernel and so on.
 
Adding a group and users to it is simple. Limiting this whole thing to one platform (H3/legacy) also. But if we don't provide consistent support for at least all boards that feature a RPi compatible header the efforts are somewhat useless since the time saved for supporting a specific board will be spent answering the same question again and again in forum

Sure, but we are no hardware vendors. Armbian is still a community project initially driven from different use cases. All we could do now is to ease transition (for example allowing user pi access to GPIO pins, but since we do not provide hardware and some board vendors do not comply to standards -- see example with BPi M2+ and 1-Wire above -- we never are able to provide a similiar situation as with the various RPis and Raspbian)
 
All we can try to do is a move in the right direction, learn what IoT people expect, discuss whether this is possible with Armbian internally and then slightly improve the situation. But only if Armbian users/devs want to go this direction and volunteers familiar with this stuff join the party. So for the moment this thread should serve as collection of ideas/objections only.
 
Since you mentioned FriendlyARM boards... from our perspective all H3 boards are more or less the same (at least it's pretty easy to support a new one -- coming up with optimal settings for different devices based on their differences is another story). So if you already want to try out Armbian then there's not much difference whether you choose an Orange Pi PC (slightly higher idle consumption but slightly better consumption under load due to better voltage generator) or a NanoPi M1 (better idle consumption, higher temperatures but otherwise identical feature set compared to Orange Pi -- stop! I forgot: blue led instead of red ).
 
If you don't want to use Armbian (though this is something somewhat weird from our perspective ) then it makes a huge difference since vendor provided software/support for Oranges are hard to get while FriendlyARM does an awesome job here (also if you want to try out their various Matrix modules then choosing their official OS image will be the better choice since I would fear nothing of the stuff will work out of the box with Armbian now, at least no one had looked into). But if Armbian is the OS image of choice it really doesn't matter that much which of the various H3 devices will be used -- the differences are minimal if it's not about special use cases like 'NAS' where GBit Ethernet or 2GB DRAM instead of 256MB are important.

I agree - the Pi for me is the "main" unit of this type - as everyone else has copied the name Pi - and they have masses of support - so to me all other systems should attempt where possible, compatibility in addition to their own unique offerings.  So in my script I make a user Pi and add that user to a load of groups.  As you'll see here...   http://tech.scargill.net/the-friendlyarm-nanopi-neo/ the Friendlyarm people have Ubuntu which is of no interest to me -  as a Pi user I wanted Debian - as near to Raspian as possible - well, Armbian is a great start from what I can see - I have it installed - and thanks to readers I now have normal (pi) user control over GPIO - suitable for Node-Red (though no-where near as good as having the GPIO nodes in Node-Red running natively).  I've a couple of pins I've no idea why I can't access them but I have the bulk of them.  Being able to use them for PWM and I2c as one can do EASILY on the Pi without root access, would make these boards a lot better - after all, with a Pi3 for £29 - for me just about the only reason to use alternatives is cost. The FriendlyArm M1 and NEO seem great little boards and cheap - and now I have Node-Red etc running on both (as you'll see in the blog) - but more control over the GPIO would be marvelous without having to guess which pin maps to what.
 
Here for example  -http://abyz.co.uk/rpi/pigpio/ a great library for the Raspberry Pi - with gpio, PWM, I2c etc. Surely this is the kind of thing that should be readily available in the other boards too.
 
Oh, my blog - and the NEO...   http://tech.scargill.net/the-friendlyarm-nanopi-neo/

Hello,
I have a problem with wifi access point. I can define the access point but can't connect to it from any device. The status switch between Registered and try to connect.
Otherwise the wifi can connect to my wifi router.
I have the same result either with the 4.4.71 kernel or the 4.12 kernel.
Might it be a symptom of wifi hardware disease ?
 

Can anyone with a MiQi verify they can correctly reboot using kernel 4.4 ?  @Myy reported that the attempt to implement the Tinker Board reboot change on the 4.12 kernel made the MiQi have reboot issues.  @IgorThis change has not been rolled out on the 4.12 kernel at Armbian, it has been so far unsuccessful, the device is hanging in BootROM mode because the SoC bootloader does not support high speed SD (1.8V) and the kernel does not reset everything before going for reboot.  Another fun Tinker Board issue, one that I'm looking at other devices to see if there are solutions.  Oh, to have my $60 back...    That said, if anyone has an extra MiQi laying about...
 

Well, I went with the r17p0 drivers with my kernels and the user-space binary drivers work fine, whether it's the rockchip libmali drivers, or the one provided by ARM for Firefly systems (mostly used for fbdev).
 
The Mali user-space and kernel-space drivers are not directly correlated. They're both needed (although I wonder if it's possible to access the GPU acceleration directly through the kernel interface). However, the user-space binary drivers will work as long as the kernel-space driver version is equal or superior. I guess there's a dumb check like this, in the user space binary drivers.
 
uint_fast8_t is_kernel_version_valid() { return user_version <= kernel_version; }  
Also, recent versions of the Mali kernel drivers tend to support more 'recent' kernels (4.9 maximum, IIRC), while older versions might have to be patched and adapted to 4.7, 4.8 and 4.9 changes.
 
That said :
If you encounter issues with Rockchip r13p0 user-space binary drivers and kernel r16p0 drivers, I could provide some help.
If you want to try integrating the r13p0 kernel drivers, you could get them here :
https://developer.arm.com/products/software/mali-drivers/midgard-kernel
And try playing with my script here :
https://github.com/Miouyouyou/MyyQi/blob/master/GetPatchAndCompileKernel.sh
Or you could also try to adapt phusson OOT Mali modules drivers here :
https://github.com/phhusson/rockchip_forwardports

You can't and that's fine since no one needs ELAR branded OS images where people manually fiddled around. Armbian's approach is different (creating images ALWAYS from scratch and therefore 'documenting' every necessary step or let's better say every single step done in form of scripts and templates in the build system).
 
@Igorcompare the situation with DietPi here, it's essentially the same but this time the results are 'ELAR images' or something like that.

Our root system is simple to maintain, matured, clean - in any way better than official creations. I am not sure anyone wants to analyse, how Asus glue their images together. They failed on board design and generally all board makers images proved to be bad quality. We only peek for some special thing, but here I don't see any reason.
 
We just started to add wireless and Bluetooth support and I am not sure it's already fully done. ASUS still haven't deliver board samples, which means not many people can work on this.
 

You have to contact image creators (Asus or whoever). There is a reason why we don't alter stock Debian / Ubuntu much, since there is plenty of complexity already and time is wasted on irrelevant issues.

I'm afraid I can't speak to this issue, although I have tried installing autofs on 4.4 and I got the error you did.  I then tried it on 4.12, and had no errors.  If you don't have a specific requirement for the 4.4 kernel, I'd recommend trying the 4.12.