TonyMac32

There has been some shuffling of code, but as the symptoms are identical and, from what I can tell, nothing has really changed in the actual shutdown process, I would assume so. Given the hackish nature of the 4.4 fix, however (even the Rockchip repo has it labeled "HACK"), I haven't probed too deeply into it, I'm holding out hope that 4.12 will include an actual fix for this eventually.

It is good to remember that a massive amount of work has gone into linux on the part of rockchip over the last year, so any older linux distro is likely to have *many* bugs of various sorts. To be honest, with a proper device tree and a look at the format of the SD card, Armbian should pretty readily boot on the device. Assuming they've done nothing crazy our MiQi/Tinker boot images should valid (it's a Rockchip standard), but the device tree will be problematic. I stuck a Tinker Board card in my UT3S and got nothing on HDMI, leading me to think we're getting U-boot, as a non-boot SD actually displays an error on-screen How did you pop yours apart? Mine is serving the purpose my Tinker Board was supposed to (media center), so I haven't gotten the knife out. Mind posting images?

Yes, I've had trouble with Bluetooth, although to be honest it hasn't been at the top of the list. There is also the camera/display ports and the reboot bug.

Thanks tkaiser, I obviously didn't look around hard enough. :-/ *update* wifi firmware added, kernel config updated, and device tree patched. Anyone using 4.12 should be able to happily use wifi. 4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs. You would have to patch in the driver/etc.

Progress! Meaning the driver module is being loaded but is babbling out errors like crazy! [ 59.019326] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 59.019392] rtl8723bs mmc1:0001:1: Direct firmware load for rtlwifi/rtl8723bs_nic.bin failed with error -2 [ 59.019403] Request firmware failed with error 0xfffffffe So, to figure out why the firmware either doesn't exist or isnt being loaded. *update* I manually dumped the firmware file from https://github.com/hadess/rtl8723bs into the appropriate directory, disabled/enabled wifi and success! Now, I don't know what to do about the firmware itself, some how-to would be handy, there is firmware for the BT as well I believe. I should be able to roll this through both the Next and Dev kernels. In the meantime I'll get the patches out for the device trees and hopefully I can get help with the firmware.

config WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP bool "Wifi load driver when kernel bootup" default y ---help--- Wifi driver will be load (use late_initcall) when kernel bootup Is from the kconfig. I remembered seeing that in the conifgs when I got wifi running on the 4.4 kernel (most of the rockchip stuff is in there, so it was simple) As for what's currently happening: http://sprunge.us/ZieI That will give you the pertinent bits from my boot in case you're curious, but excerpts: [ 1.573208] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 1.573258] mmc1: error -84 whilst initialising SDIO card [ 1.573395] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range [ 1.581858] mmc1: error -110 whilst initialising MMC card [ 1.635230] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 1.635285] mmc1: error -110 whilst initialising SDIO card [ 1.635427] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range [ 1.643855] mmc1: error -110 whilst initialising MMC card [ 1.658874] mmc_host mmc1: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0) [ 1.704513] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 1.704567] mmc1: error -84 whilst initialising SDIO card [ 1.704734] dwmmc_rockchip ff0d0000.dwmmc: card claims to support voltages below defined range [ 1.712853] mmc1: error -110 whilst initialising MMC card Also noticed the io domain entry for the wifi-supply was missing, trying it out. http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/power/rockchip-io-domain.txt

I will take a look, I haven't had much any luck getting it going personally, although I haven't had the time of late (extra work projects/etc) [edit] oh my, I actually missed the declaration in the Sunxi file entirely... that is different. x_x [edit 2] First round no success, compiles but no device, noticed the "wireless-wlan" node was missing, added. No effect. :-/ Something I saw in the rockchip kernel (common to the Tinkerboard and the MiQi 4.4) was all that intricate management and https://github.com/TinkerBoard/debian_kernel/blob/linux4.4-rk3288/drivers/net/wireless/rockchip_wlan/wifi_sys/rkwifi_sys_iface.c

I haven't configured that module in the kernel config, so for this particular issue the newer kernel won't help. The spidev patch has been committed, has anyone tried using it?

@chrisf try to build now and let me know. I'll be out town for a few days for the holiday here in the US, but I'll keep tabs on the forums. Also, forgot to mention, running for several days on GPIO power, and no HDMI dropouts.

It could be attempted, however I'd guess spidev.c won't take the patch, since those definitions get added to periodically. (It had to be adjusted from 4.11 to 4.12, for instance). You can try it, worst case you need to go into spidev.c and manually add the compatibility entry you see in the patch to whatever list of devices is there.

Ah, something I've mentioned but didn't make a big deal of: the RK808 gets hot enough to burn you under heavy loads. Put a heatsink on it.

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

Right, but like I've said before, my setup cools quite well, I used a thermal epoxy since there's no hope of a nice mechanical attachment. (25x50 mm heatsink with a little notch to clear that inductor beside the codec), this processor is simply capable of some serious dissipation. It was unlikely mine would go clear to shutdown, although I didn't let it either way, it was simply significantly exceeding the trip points. I also have no such issues with 4.11 or 4.12. ;-) I've made the adjustments to the dtb and am testing. Definite improvement, however I need to look at the hysteresis values I think, it's jumping to higher clocks prematurely. [edit] Forgot to say, no fan, only larger heatsink I'm seeing 75 C maximum (25 minutes test). I hit 85 C within 5 minutes before stopping the test before the patch to the tree. I'm also evaluating the core voltages used here. [edit] Patch with updated polling and trip points in, voltages will not be experimented with until proper stability testing is performed. The system was up for just over 2 hours running minerd with the patch, temperature never climbed above 75 C with or without fan. Try it out, I don't have the same cooling solution as the rest of you, I want the feedback.

I loaded kernel 4.4 today and reproduced the thermal shutdown condition (although not get to shut down) with my larger heat sink (it hit 85 C and hung around there), that pitiful little fan I have was enough to keep it from happening *but* turn off the fan and you're done. The GPU polling rate is incredibly slow, mainline is 10x faster, the CPU polling is 2x faster on mainline than legacy as well, I'm guessing that has something to do with it.

@Myy, have you looked at the Rockchip packages in the Rockchip Repo? I just saw the "Packages" part of that, poking around.

Yes, that' sit. For the more advanced that want additional robustness, add a 5.3 V zener diode for overvolt protection on 5.0 to 5.25 Volt supplies and a capacitor to help reduce ripple if that is a concern (it can also soak up surge demand by the USB peripherals) A low-profile hat would be best for the more paranoid among us, I personally put an electrolytic and ceramic on mine to clean up any noise.

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

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... ;-)

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

What CPU governor was this?

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.

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

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.

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.