RK3328 Kernel

[plasta-blaster]

seconde attemptde
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     2890     2853    10059    10153     8828     3774                                                          
          102400    1024    49388    43091    54599    54656    54541    47202    

 

 

 

[TonyMac32]

Oh my.

 

In other news the Tinkerboard will power up and operate normally via the GPIO (Pins 2,4,6)  My above-board idea is a little closer to my heat sink modification than I like, but if I make a proper board I want to include a USB charge port for powering external HDD's assuming they won't spin up on the USB alone (I tested with an old 2.5" USB-PATA enclosure, worked like a charm)

 

Supply used:  Odroid XU4 5.0 V 4 Amp, I stuck a capacitor on there, will probably include an overvoltage protection diode as well.  I wasn't too worried, all of the really sensitive stuff goes through the RK808, which is fairly forgiving.

[tkaiser]

7 hours ago, TonyMac32 said:

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.

 

Me neither. But we're dealing here with a device that shows a peak consumption of 1.7A already without connected peripherals when just booting. A connector rated for 1.8A on the power lines is just 0.1A away from this. 2.5A is still a joke (but since throttling jumping in almost immediately the average users won't notice). And beyond 2.5A it gets critical. Wrt your findings to power through GPIO pins: Is it save to recommend users powering through GPIO pins like we had to do with the other prominent Micro USB victims:

• https://www.armbian.com/miqi/ (here the fan header must be used)
• https://www.armbian.com/pine64/ (pins on Euler connector must be used)
• https://www.armbian.com/tinkerboard/ (no recommendation yet, only problem description)

And again: Contact resistance and potential thermal problems with a current reading way beyond specs are just one part of the Micro USB problem (connector alone can be responsible for a whopping 500mV drop and this will be spread as heat). The more severe one is that users don't understand that the cable between PSU and board matters. And you can tell them multiple times, they still don't want to understand this and that this device needs at least a 3A PSU with a cable that can handle this (if you want to run heavy stuff on both CPU cores and GPU and attach some USB periperals consumption need will exceed 3A easily, there's a reason Hardkernel recommends/sells a 5V/4A PSU with barrel plug with their similar powerful ODROID XU4!).

 

Again: Where are the results from 'minerd --benchmark'? Is Tinkerboard able to reach advertised speeds (at least 8 khash/sec) or what do people get in reality? This is the most simple test to get that you either suffer from insufficient heat dissipation (throttling happening due to no or crappy heatsink) or insufficient powering (board freezing/crashing/rebooting). It's as easy as

sudo armbianmonitor -p
minerd --benchmark

 

[Tido]

Did ASUS somewhere make the promise, that you can fully load the SOC and it will be running stable at 1,8GHz?
And how many day-to-day application really beat the SOC like this?
In this regard I think it is nonsens to blame ASUS for bad cooling. It is what it looks like, a RPi-clone with far more CPU & GPU power whatsoever.

I agree with @tkaiser that MicroUSB was everyting else than a smart decision from ASUS.
On the other hand I can see the that it is an exact copy of Raspberry connector wise.

Nonetheless, they could have think one or two steps ahead and design a combination like SinoVoip has done (picture) it with their M3, before they made the 'smart move' and switched production to standard barrel DC-IN (the M3 with 8core is still nonsense by the way).

[tkaiser]

22 minutes ago, Tido said:

On the other hand I can see the that it is an exact copy of Raspberry connector wise.

 

Exactly, this Tinkerboard is a perfect example for development driven by marketing only. Management asked 'How do we get as much RPi users as possible to buy a Tinkerboard?!'

 

Simple answer: trick them into believing they can re-use all their already existing equipment (PSU and cable included) and squeeze out the max of clueless people (adding a good 5.2V/3A PSU to a Tinkerboard bundle would've increased the BOM by $5 if at all for ASUS)

 

Is anyone here able to understand that Micro USB already fails on almost every RPi 2 or 3 out there? There are people running RPi 3 clusters limited to 600 MHz all the time since Micro USB is that shitty as it is. And people don't even know it since RPi foundation decided to cheat on them here too (the SoC is downclocked while /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is lying about still running at 1200 MHz). Just read through this https://github.com/bamarni/pi64/issues/4#issuecomment-291425512

 

With Tinkerboard (and MIQI or Pine64) it's only even worse since there's no under-voltage detection circuitry and the average user will run into troubles unless he knows and accepts the problem and tries to improve powering. 

 

And it's not the first time that this happens, it's just another micro community being affected and rejecting reality. In Pine64 land -- also using shitty Micro USB -- it's even so that users blame community OS images being unstable while Allwinner's horrible Android images are reported as running 'perfectly stable'. And the only reason is that community OS images use good settings resulting in overall much higher performance and are therefore able to trigger Micro USB shittyness while Allwinner's don't (killing CPU cores and stuff like that to masquerade the problems).

 

That's the real problem from an Armbian point of view! If we start to improve software on crappy hardware we are blamed for 'Armbian being unstable' since people don't want to accept what's wrong with this Micro USB connector and the 'average USB cable' being simply insufficient to power anything needing more than 500mA!

[Tido]

This is the reason, why I somewhere in this thread asked, can we readout the supply Voltage of rk808.
If we can display all these information within RPi-Monitor (so ironic that this tool shall help), the statistics page will probably show when it failed and why (voltage) ?

[Myy]

20 hours ago, TonyMac32 said:

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

 

@TonyMac32 Yeah, I just compiled a 4.12-rc1 today and added/removed a few patches to make it work. Still, most of patches applied nicely, which is a nice thing... I guess ?

 

Anyway, here's the new patchset for Mali r17p0 drivers :

https://github.com/Miouyouyou/MyyQi/tree/master/patches/Mali/r17p0-01rel0

The UMP drivers failed to compile because the headers for copy_from_user and copy_to_user were unified to linux/uaccess.h instead of asm/uaccess.h. ( Is there a way to inline code nicely with Invision ? (´・ω・`　) )

https://github.com/Miouyouyou/MyyQi/blob/master/patches/Mali/r17p0-01rel0/0005-Using-the-new-header-on-4.12-kernels-for-copy_-_user.patch

 

That said, I might drop UMP support soon as, with dmabuf, PRIME and others kernel and GPU memory sharing features provided by the new DMA and DRM infrastructure; the Unified Memory Protocol is not really useful anymore.

 

The new 4.12 patchset I'm using is available here :

https://github.com/Miouyouyou/MyyQi/tree/master/patches/kernel/v4.12

 

Now, I haven't followed this thread for a week, so I don't know if there's new patches for the rk3288-tinker.dts file. I just avoided the creation of the rk3288-miniarm.dts file, as I don't know if it's still useful now that there's a mainlined Tinkerboard DTS file, and I cannot test and compare the two as I do not possess such hardware.

However, I'll take a look at this thread now and see if there's any useful patch that I could add for the -rc2 release.

 

On 2017/5/10 at 4:05 AM, TonyMac32 said:

Final question:  does anyone else lose HDMI after an extended inactive period?  I won't discount it being my monitor, but show of hands?

 

Yes ! This is a known bug and I'm starting to wonder if it's related to overheating, as I do not have such problems when running the fan at full speed, however this typically happen if I don't put it on and run a few compilations on Gentoo.

That said, there were some 4.4 Rockchip patches that seemed to solve this issue. I'll try to find back the references and see how this could be implemented on the 4.12 side.

Edited May 17, 2017 by Myy

[TonyMac32]

I haven't had the issue on 4.11 for a while (I let it run overnight for a few days), I think this commit probably have handled temp issues, which I didn't link to the HDMI fallout.   ( I also improved my mechanical cooling situation, so my unit may not be representative at this point)

 

I carried over the rk3288-miniarm.dts because it keeps it simple on my side, I already had it developed to a relatively complete (as the kernel will support) level.  The dts I created for 4.11 was simply the 4.12 Tinker board DTS with some newer patches.

 

Tinker OS, and Rockchip-linux gits have both been very quiet, I'm going to assume that's due to the mainline work and the fact "ASUS" has released 2 Android versions since their last Linux update.  

 

 

[cyberk]

Just reporting back that my tinkerboard is borderline unresponsive after a 2 day up time, I'm running the 4.11 kernel. Temperatures seem OK and top doesn't report anything out of the ordinary CPU wise. A review of journalctl showed the following:

https://hastebin.com/abocuhesab.xml

 

Looks like system services didn't fully recover after that. I'm not entirely sure if this is power-supply related, but perhaps the logs will mean something to someone more informed than I

[TonyMac32]

I would switch to nightly and try the 4.11.1  build, it has some updates concerning power and thermal regulation, and also search the forums for posts about power supply/cable combos and SD card quality.

[cyberk]

Thanks @TonyMac32, I'm using a reliable SD card. I'll keep monitoring and see if it's a power issue, but I don't think it is. The error I pasted shows something about a possible video error, did that dump make any sense to you?

[lucifercipher]

@TonyMac32I check up here few times daily to see if the "next" server image is on its way with Wifi and reboot bug fix.  For now i am using tinkerOS for 1.8G clock and Wifi. Can't wait to go back to Armbian again as this is utter useless crap that Asus brewed. 

 

@cyberkYou should get a Nillkin USB cable with the Aukey power brick . That combo or Samsung S7 cable + Aukey brick will never freeze your tinkerboard due to power issue on that piece of crap USB power port.

[cyberk]

@lucifercipher thanks, I'm using a PoE solution, I guess I have to run some tests to fully rule out the power issue. Here are the specs
http://wifi-texas.com/pdf/WT-AF-microUSB-SL.pdf

I have a 2.5amp transformer that I'll try if this issue pops up again:
https://www.amazon.com/gp/product/B01F1LVZ0G/

[lucifercipher]

I personally don't rely on those loveRPi ones. This is the only one which has been stable enough to provide juice for multiple devices. 

 

You can see i have multiple devices on two of those bricks. The two in case are the tinkerboards. 

[TonyMac32]

12 minutes ago, cyberk said:

I have a 2.5amp transformer that I'll try if this issue pops up again:
https://www.amazon.com/gp/product/B01F1LVZ0G/

 

It's not necessary to go to 2.5 Amp, and won't help at all unless it is producing over 5.0 Volts.  Any on-board system using a 5V supply (USB, HDMI, etc) will will see Power supply voltage - (consumed_current * powerline_resistance).  In my case that hits almost 500 mV, so I use a 5.25 Volts supply. which is the only way to see improvement.  If you want to see for yourself, test the voltage on the GPIO header for 5V_SYS.  Below 4.75 and you have a problem.  This is why I tested powering the board through the GPIO, I can provide significantly more power without the losses.  See any post by tkaiser to get the official stance on micro USB.

 

The reason I recommended trying a newer kernel is due to firstly the kernel has had some bugfixing, and HDMI glitches (not crashes) have been common with all kernels, however I believe I may have made some progress when implementing some thermal and power consumption fixes to the dts.  Other than the possiblity of memory corruption, it's probably a driver bug that hopefully has been fixed.  

 

27 minutes ago, lucifercipher said:

@TonyMac32I check up here few times daily to see if the "next" server image is on its way with Wifi and reboot bug fix.  For now i am using tinkerOS for 1.8G clock and Wifi. Can't wait to go back to Armbian again as this is utter useless crap that Asus brewed. 

 

1.8 GHz is currently in place on the 4.4, 4.11 (NEXT), and 4.12 (dev) kernels.  Wireless is another issue, 4.4 had a lot of custom code to support the sdio rockchip wifi system interface, that's not explicitly part of the mainline kernel, I need to see what other rockchip boards with wifi are doing.  The reboot hack didn't work out of the box with 4.11, however I may have a lead on that.

[lucifercipher]

1 minute ago, TonyMac32 said:

1.8 GHz is currently in place on the 4.4, 4.11 (NEXT), and 4.12 (dev) kernels.  Wireless is another issue, 4.4 had a lot of custom code to support the sdio rockchip wifi system interface, that's not explicitly part of the mainline kernel, I need to see what other rockchip boards with wifi are doing.  The reboot hack didn't work out of the box with 4.11, however I may have a lead on that.

 

What do you need in form of help? Looks like you are pretty much tied up with this alone. 

[TonyMac32]

Well, ASUS was supposed to get boards to tkaiser but, weeks (months?) later nothing. Honestly I'm spending most of my time with the kernel support items, so any help straightening out the user side (like that realtek codec for sound defaulting to the wrong subdevice for pulse audio, or the screeching noise you get sometimes playing back audio on any device (I've gotten it on the usb codec, over I2S to a 5102, and on a set of USB headphones)

 

If you're using the boards as shown, just power them via GPIO and get the heat sink I linked earlier in the thread.  You'll get better performance and stability all around.

[traumfaenger]

16 hours ago, tkaiser said:

Again: Where are the results from 'minerd --benchmark'? Is Tinkerboard able to reach advertised speeds (at least 8 khash/sec) or what do people get in reality? This is the most simple test to get that you either suffer from insufficient heat dissipation (throttling happening due to no or crappy heatsink) or insufficient powering (board freezing/crashing/rebooting). It's as easy as

sudo armbianmonitor -p
minerd --benchmark

 

@tkaiser : I've posted the results in my last post under a tiny link, because I made .pdf out of it, since the overview was too ugly. Here once again, as attachment.

Tinkerboard had maximal value of 6,76 (@1.8GHz, kernel v. 4.11.0)... So yea, this was without throlling taking place.

cpu-miningtemp.pdf

[TonyMac32]

What CPU governor was this?

[traumfaenger]

Uhh, sorry. Kinda always forget about this.

 

  current policy: frequency should be within 600 MHz and 1.80 GHz.
                  The governor "conservative" may decide which speed to use
                  within this range.

This is again, default governor, since I didn't change anything.

[TonyMac32]

Switch it to performance and repeat.  This is with that heat sink?

[traumfaenger]

Yep, this is the stock heatsink, with 80mm fan on the side

Check attachments. Still, system running without problems, since 2 days now, no reboot and a bit testing.

Just too bad, I can not provide any checks for power supply because of reaching thermal limit.

Maximal value I saw was getting 6,8 khash/s done.

perfmining.pdf

[chrisf]

So... don't run boinc with the ASUS supplied heatsink:

Message from syslogd@localhost at May 18 12:32:06 ...
 kernel:[136071.192623] thermal thermal_zone1: critical temperature reached(90 C),shutting down
Connection to 10.0.0.110 closed by remote host.

It was throttling around 1.2 - 1.4GHz

RPimonitor was showing it hovering between 70 and 80 degrees.

I've never had any power issues yet. I power it via a micro USB plug with 18AWG wire. It's also got a 2.5" drive plugged in to the USB port. It's then connected to a 5V/6A PSU that also powers two Pine64's

[TonyMac32]

Yeah, that heat sink is no good, were you running an Armbian image with that?  Mainline will throttle at 70, I believe legacy should as well...

 

Also, it is entirely possible you could damage the micro USB connector with the amount of current this board is capable of pulling.  So maybe it's best if the CPU cuts out first...  ;-)

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

Thanks for the updates. Only 6.8 khash/s are somewhat surprising (since the Exynos on ODROID XU4 scores above 8 khash/s when running on the A15 cores alone, something that's not working any more after enabling HMP with XU4 mainline kernel variant).

 

Wrt 'thermal_zone1: critical temperature reached(90 C),shutting down'. We had the same thing with Pine64 last year. Coming up with reasonable trip points was both necessary for good performance (not jumping too much between cpufreq OPs far away from each other, minerd is a great tool here to test for efficiency of settings) and for preventing such emergency shutdowns. Should be documented here: 

• https://github.com/longsleep/build-pine64-image/pull/3
• https://github.com/armbian/build/issues/298

It helped to enable as much cpufreq OPPs as possible to allow the throttling code to do smaller jumps and last trip point should be high enough to not trigger emergency shutdown.

[TonyMac32]

46 minutes ago, tkaiser said:

It helped to enable as much cpufreq OPPs as possible to allow the throttling code to do smaller jumps and last trip point should be high enough to not trigger emergency shutdown.

 

I will have to check the 4.4 kernel again, 4.11 and 12 are currently set to throttle at 70 C, the worst "overshoot" I've seen was to 73, which is why I asked @chrisf if he was running Armbian or not.

 

At present we have all OPPs available that are used by Rockchip in their kernel, more or less every 200 or so MHz until 1.4GHz, then every 100 or so up to 1.8GHz, and this patch encompassing a few put in by Rockchip concerning power and thermal zones and providing a generic dissipation value for the CPU. Given it's junk heat sink, I'll need someone to provide some factory minerd data so I can see if that needs to be more or less, although it's set to what the documentation claims is less than a 4" phone can manage at present...

[tkaiser]

1 hour ago, TonyMac32 said:

every 100 or so up to 1.8GHz, and this patch encompassing a few put in by Rockchip concerning power and thermal zones and providing a generic dissipation value for the CPU

 

Hmm... the patch uses 1350mV for the higher cpufreq OPP which seems a little bit odd (since either 1.6GHz would allow a lower voltage or those higher clockspeeds would also need higher voltages. But that's stuff for stability testing so just as a hint: https://github.com/ehoutsma/StabilityTester -- was used for developing sane dvfs table for Orange Pi PC2, can be used with any 64-bit ARM platform and for 32-bit SoCs you would need to build xhpl yourself, links available in the Pine64 issue/thread above. The great thing with this xhpl approach is that this tool does some benchmarking but tries to validate results later and is able to report data corruption caused by undervoltage before the board starts to freeze/crash)

 

But this is rather time consuming and it should be noted that we're talking now about a totally different meaning of under-voltage here. This time it's not the voltage drop between PSU and PMIC but the PMIC feeding the SoC with a voltage too less for certain clockspeeds. In case Rockchip engineers provide a table for their 4.4 kernel I would believe it's the best to adopt the values for mainline. 

 

Edit: Wrt stability testing (verifying dvfs table OPPs being not dangerous): when cloning the above StabilityTester repo (or my fork with some additional tools/tests) it's just building an OpenBLAS enabled 32-bit xhpl lying next to the xhpl64 binary and replacing the call in the script to be able to test through dvfs tables on RK3288 too (see 6th post by user deater here: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=139712&p=927615)

 

Edit 2: Based on @chrisf's results it's obvious that only DVFS OPP from Rockchip's 4.4 might be interesting but not the thermal trip points  

[chrisf]

2 hours ago, TonyMac32 said:

I will have to check the 4.4 kernel again, 4.11 and 12 are currently set to throttle at 70 C, the worst "overshoot" I've seen was to 73, which is why I asked @chrisf if he was running Armbian or not.

Yes, with kernel 4.4.67, I built it from git two days ago. I could see it throttling fine for a few minutes on rpimonitor

 

Edit: After replacing the heatsink it hasn't shut down. It may have been due to low thermal mass and slow temperature polling frequency. It's still throttling but the temperature is much more stable in the low 70's.

 

Looking back over the rpimonitor stats, with the old heatsink it peaked at 85+ 3 times before the shutdown

Edited May 18, 2017 by chrisf

[traumfaenger]

Thanks to everyone, who is trying to get the best out out this board

 

@TonyMac32 : I'm pretty interested into powering Tinker through GPIO. By now I don't know, whether you've posted something what explains *how* you've connected the power source to GPIO pins. If you do not mind, would you please post a picture, or a small schematics how you've powered the Tinker via GPIO? I would not do this on RPi, but with RK808 handling all the power management, I would like to try that one out.

 

Again, thanks to you guys, I've already learned *a lot* regarding throttling, USB amperage, thermal and linux