TonyMac32

@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 

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

Dev (4.12-rc1) will build now.  Note that I changed only what was needed to make it build, so some of the patches may not be needed/may not help/etc.
 
@Myy I had to take out the post-mali UMP patch, UMP is failing to build for some reason or another on 4.12 using this build system. 
 
Otherwise it appears to be at the same level of functionality as 4.11, although I did notice a marked improvement in USB audio (external cards, not the built-in codec), even though it does still try to blow my eardrums out of my head using the browser with certain source materials.  (I haven't tried to mess with PA yet).
 
I am building a "Hat" or "Shield" or (more likely) "tombstone" for the board to see if I can power it via the gpio pins and avoid the micro USB.  If it powers on with a smaller supply, I'll build to suit the Odroid XU4 4A adapter.  (Obviously this board is going to be trouble power wise, however, since I've already got one I'm going to make it work for me)
 
OK, back to the job that pays me.  ;-)

I still have to get the patches submitted, but:
 
|_ _(_)_ __ | | _____ _ __| |__ ___ __ _ _ __ __| | | | | | '_ \| |/ / _ \ '__| '_ \ / _ \ / _` | '__/ _` | | | | | | | | < __/ | | |_) | (_) | (_| | | | (_| | |_| |_|_| |_|_|\_\___|_| |_.__/ \___/ \__,_|_| \__,_| Welcome to ARMBIAN 5.27 stable Ubuntu 16.04.2 LTS 4.12.0-rockchip System load: 0.48 0.14 0.05 Up time: 0 min Memory usage: 2 % of 2007MB IP: 10.0.0.46,10.0.0.54 CPU temp: 32°C Usage of /: 8% of 29G  

I still have to get the patches submitted, but:
 
|_ _(_)_ __ | | _____ _ __| |__ ___ __ _ _ __ __| | | | | | '_ \| |/ / _ \ '__| '_ \ / _ \ / _` | '__/ _` | | | | | | | | < __/ | | |_) | (_) | (_| | | | (_| | |_| |_|_| |_|_|\_\___|_| |_.__/ \___/ \__,_|_| \__,_| Welcome to ARMBIAN 5.27 stable Ubuntu 16.04.2 LTS 4.12.0-rockchip System load: 0.48 0.14 0.05 Up time: 0 min Memory usage: 2 % of 2007MB IP: 10.0.0.46,10.0.0.54 CPU temp: 32°C Usage of /: 8% of 29G  

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  )

Hey guys,
 
Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

Our kickstarter page :  Helios4
 
For some specs : Helios4_Specifications.pdf
 


Basic Kit - 1GB (USD$125)
(Save 16% off the $149 Retail - Limited to 50 units)

Full Kit - 1GB (USD$139)
(Save 18% off the $169 Retail - Limited to 130 units)

Full Kit - 2GB (USD$165)
(Save 11% off the $185 Retail - Limited to 70 units)
 
Our kickstarter page :  Helios4
 
Cheers ;-)
 

If anyone picked up the UGOOS box:  http://freaktab.com/forum/tv-player-support/ugoos-aa/530975-official-ugoos-firmwares-for-devices-based-on-rk3288
 
Quite a bit of info on how to flash it/etc.  I picked one up because, why not...

If anyone picked up the UGOOS box:  http://freaktab.com/forum/tv-player-support/ugoos-aa/530975-official-ugoos-firmwares-for-devices-based-on-rk3288
 
Quite a bit of info on how to flash it/etc.  I picked one up because, why not...

I am going to attempt to put the reboot patch in there tonight and get some more dts work done, I'm afraid none of the rockchip wifi system interface is built into the 4.11 kernel.  I'll take a look at 4.12 to see how much work I want to put into it, and of course look at some other rockchip-oriented kernels to see if they have it implemented or not.  Remember we don't have working BT in the 4.4 either.  And then there's the sound issue, which should just be an ALSA configuration and maybe a PA fix, if someone else wanted to start looking into that.  ;-)

I went too far and stuck a copper GPU RAM liquid block on it... 

I'm using some cables I spec'd online, I can' tremember the exact source, however their voltage drop is minimal and so far they've worked well.  That said I'd prefer a better solution, if someone were to take care to use adequate protection, it looks like putting 5V on the GPIO (pins 2-3) will supply VCC_SYS, which is what the RK808 uses to get all the system voltages.  You'd only be missing the surge suppressor, current limiter, and usb charge detector. (that one might be a sticking point, I think it might signal power OK)

regulator.13 is vdd10_lcd, you want regulator.4, vdd_arm
 
 

The op points are in the device tree, it only has op points to 1.608 GHz.  I have seen 1.8 working, I didn't add it to the tree because I was not certain they all had the -C like mine and didn't want to cause a major issue.  So far I've seen them all be -C's however, anyone want to chime in if they do not?

Uploading patch to fix reboot on Tinker board 4.4 kernel.  The miqi must not use vmmc or vqmmc supplies, or else it would also be affected.  The shutdown sequence turns the SD card off completely before reboot, and fails to reset to 3.3 volts from 1.8 (for high-speed cards)

Built, no longer getting the "error, address not set" on the ethernet at boot.  Getting late, can't dig in much further but I'd guess it's a success.

I put them both to build, but haven't test yet - only for building.
https://github.com/Kwiboo/u-boot-rockchip/commit/244f8753744eefbd7cd1307c0bd8f7b297486211

I would guess.  The info I've found for both drivers was that they were I2C only, so I'm poking through the Tinker OS 1.4 kernel for some insight, if any is to be had.

Thanks @Myy, I was actually looking at your repo last night, I'll give it a look later today after work.
 
In other news, it looks like the basic stuff will be in Kernel 4.12, including the wifi driver, albeit the old one (not sure why). However they've changed everything to tinker board from miniarm, so we'll have to adjust for that.

On a better note, I've hijacked the miqi device tree ( @Igor, I'm not sure how but I missed your response way back about stealing the Miqi one).  It (the kernel) did get mad about the storage situation, and the dts format likewise is more like the rockchip-linux model than it is like the 4.4 miqi setup, which most likely explains the rockchip-linux setup.  
 
[edit]  So mangling the miqi one didn't work out, it was getting messier by the second.  I did, however, decide to just stuff the Eddie Cai patch for the tinker board in there, renaming it miniarm, and it worked out.  Has 1080p desktop and not a lot else.  The LED's work...  ;-)
 
[final edit]   This image video output is extremely smooth, much better than the 4.4 based image.  I'm able to use Plex Web to play videos in a 2/3 screen sized window smoothly. 
 
In case anyone wants to check it out: http://sprunge.us/POjR

Tinker OS is the only distribution to use UART 1 as the communications port.  All others I've tried, including Armbian, use Uart 2, pins 32 and 33.  I have an FTDI Friend and a little pigtail harness I made for that purpose, I've been using it to debug since I became involved, see:
 

Found a GIC-related patch on RK3288 (and actually a bunch of other) SoC's concerning interface size, https://github.com/torvalds/linux/commit/387720c93812f1e702c20c667cb003a356e24a6c .  Building the rk3288 one, doubt I'll see anything new and different, but thought I'd give you guys a heads up, I see exynos and allwinner in the list as well.
 
[edit]
 
Looking through commits at rockchip, there are quite a few small error corrections in the rk3288.dtsi, I'm collecting them, and I'll clean up my patches accordingly.

I edited the file on local linux-rockchip-default.config and work perfctly
 
whit this config
 
NFS is work !!

Sorry about that tkaiser, I ran out of time last night to try it out.
 
Wifi should be available in default nightlies tomorrow, no bluetooth yet.