TonyMac32

I will be looking at this tomorrow with Armbian, the 4.14 stuff and the various other odds and ends got me off course. I will try it on the intended kernel first, but then I'll see if it goes with 4.14.

That would be my expectation then, considering the evidence. Check and see if there was any ASUS support agreement

Rockchip-dev kernel hdmi fixed, testing other functions. The device nodes for the video ports were still defined with 32 bit registers instead of the 64 bit now that they want LPAE capabilities. [a little bit later...] OK, reboot works, wifi works, browser works. [edit] 4.13 tested ok short term, I'll set up a long-term test a little later.

Cancelling this test because there are others at the moment as well... :-/ root@tinkerboard:~# uptime 03:20:38 up 1 day, 54 min, 1 user, load average: 2.53, 2.14, 1.91 root@tinkerboard:~# uname -a Linux tinkerboard 4.12.0-rockchip #9 SMP PREEMPT Fri Jun 23 20:40:07 CEST 2017 armv7l armv7l armv7l GNU/Linux Well, it didn't say that was the kernel when I updated. so I guess I'll be repeating this...

I sincerely hope not.

Well, I did give the disclaimer I hadn't tried this board. Let me look into it now that I have it. You did mirror the pinout for the fact it's a jack, right?

@Igor I'll look at the thermals, mine hit 74 with my large heat sink (it should be throttling at 70), so I'm going to guess there may have been more than just the cooling nodes changed in 4.13, I didn't check the polling speed., For example.

Did the Tinker Board go on sale? No posts in this forum for weeks, now the sky is falling... I have not compiled, booted or tested a 4.14 kernel, the last time I tried Dev (Monday?) It was still 4.13. I will be doing that tonight. I can't think of any reason for that behavior, so this should be interesting.

4.11 did not have wifi, no driver in the kernel. 4.12 added the staging driver for WiFi. I was not completely prepared to make next 4.13, let me review the next patches (a couple were experimental, they don't break anything but may give the user the impression they have functionality they don't), and I'll work on Dev.

Can you give me a uname -a ? I have been running various tests, I have not come across that issue. Now, unplugging the HDMI on Mainline results in it not coming back that power cycle, something I havent tracked down. Have you tried to boot it with another monitor? No changes have been made on the board side involving the display system, my 4.13 has no issue with the display. Currently I am having the board play YouTube videos indefinitely to see if I get a reset or hang, so far nothing (14 hours)

Were these on the carrier board or just the module? Remembered you answered this already.

Do you have any logs to share? More amperage won't help, the problem is voltage drop, which increases with amperage consumed. GPIO can supply a decent amount of power, I would not be overly concerned of the consumption. While long term you can't pull 4 amps, in short bursts it is achievable. If there is concern, I would make sure to attach to both 5V and 2 gnd pins (The 2nd ground pin is a few pins over from the 3 typically used.)

I just apt upgrade'd my fresh 4.13 Dev install and I wound up with a 4.11 kernel, so wifi and reboot broken. @Igor, do you know what would cause that?

That is strange. I've had my board running 24 hours now with no hang, now it is with minimum load I realize. I'll give it something to do and see if it gets better or worse.

I have recently switched to using a 65 Watt MeanWell 5 Volt chassis supply (I'm running multiple boards and peripherals) they make smaller units for those not running up to 7 boards at once Note that I only recommend this if you are familiar with wiring and know how to not die from a lethal dose of Tesla's magic. If you are the sort putting together a permanent installation I do fully recommend such a supply, as you can adjust the output, typically between 4.5 and 5.5 volts, allowing you to overcome voltage drop if necessary (I keep mine at 5.25 volts because of specification limits for USB)

Followed Balbes150's advice using u-boot.bin.sd.bin for my blob source, and switched the dd commands. @martinayotte you should be able to build a booting Armbian right from the build script. I've also added the K2 to the u-boot repo I'm keeping. So far Mainline (4.14) isn't giving me an HDMI display for the K2 I'll check my kernel config. 3.14 has "static", I assume this has to do with not shutting off the other framebuffer and I'll work with that later, as well as build a 4.13 "next" image. (More heavily patched). Very much WIP [edit] The Mainline device tree for the K2 is very skeletal, we just need to flesh out the things we know, drivers exist for the hardware already. [edit] Added HDMI to nanopi-k2 dts, also seeing static like on 3.14, however functional desktop otherwise.

Yes, some issues have been resolved since that one came out, it would be best not to keep them in circulation. First though, I'd like to see if the nightly resolves his issue and do some testing myself. The 4.12.y builds were all very stable, I don't know the 4.13 as well.

@Igor all archive images for Tinker appear to be 5.30 on dl.armbian.com/tinkerboard. @marcopete87 please try a nightly image, they all have the newer kernel/device tree.

If only any wifi were so simple... https://github.com/fifteenhex/xradio is an example of someone working on this. The readme excerpt below came from there: Also: The xr819 chip/firmware drops tons and tons of frames with FCS errors and this makes performance horrible at best. Most people have lost interest in having anything to do with the xr819 because of people being idiots and demanding that issues that are incredibly hard to fix without documentation be fixed because they spent $8 on a board and somehow people that got exactly zero of their $8 are responsible. Moral of the story: If you're going to post nasty things on the interwebs and demand people fix stuff because reasons at least have a bunch of packet dumps etc and have some idea about what you're talking about.

@marcopete87 I just tried that, lost wireless functionality and reboot. I'm assuming kernel modules are the issue. Now letting a fresh install run to see if I get any hangs [edit] Kernel 4.13.2

Hmmmmm, I'll set a mine up and just monitor it to see.

Just pushed re-organized thermals to repo, cpu_thermal is zone0, gpu_thermal is zone1. This is for dev, next, and default. All I did was move the "reserve_thermal" entry to the end of the list of three. @tkaiser

Wondering if we should have a release notes/changelog that gets tossed into the image somewhere? Something very simple that we maintain by just updating a text file with a significant commit. (Like changing kernel versions, fixing a known bug from previous release, etc). Maybe toss it up onscreen at first boot. Moving the thermal zones on Tinker made me think that might be a good idea.

Good catch. I'll go ahead and swap the device tree entries There's nothing hackish about this one, they get numbered in the order they are declared.

The supply has to always be considered suspect on any of these boards that power their elephant CPU through a small straw. See my post within the length "Tinkerboard" thread: That said, 4.11 was prone to HDMI dropouts, had no WLAN support, and had an incomplete device tree/potentially incorrect thermal trip points. (I updated as the Asus/Rockchip team updated.) There have been a considerable list of improvements in driver support since.