TonyMac32

Well, it will be at least as efficient as those thick tapes, or those non-thermally-conductive stickies on most of the RPi ones. A proper thermal tape or, with those cast enclosures, a thermal paste does a good job. @chwe, look up diacool heat sinks, you'll be entertained. Sent from my Pixel using Tapatalk

I was looking for a discussion on cases, not sandwiches of acrylic. I can make an acrylic sandwich in my basement using hand tools, not much to talk about there. ;-). With the size of the Pi community I'm sure there are cases I (and a lot of others) have never seen, so thought I'd start this thread.

I know a few, they're not too bad.

This is a given, and per Chwe: Well, I was being the good engineer and ignoring the math in favor of measurement. ;-)

Yeah, I second tkaiser on the flirc, just like that nice cast one, it's Pi specific. It would be ideal to have a large thermal mass for most situations, although surface area is still important for sustained loads (bear in mind my brain gets stuck in 30-100watt dissipation situations, so the fins may be utterly unnecessary here). Use the proper thermal tape to make up the space or copper spreaders...

I have that for the Pi3. Being so specific, I didn't list it, but it performs well. Logging ambient, internal case temperature, SoC temp, and controlling cpu processes, it can be determined what the rate of power dissipation is. A decent approximation of the thermal energy input can be made by measuring power consumption. An improvement on this case would be holes on the lower side to allow proper convection

No, all TV-box stuff is handled by Balbes150's excellent work.

Since I've a pile of these boards lying about, and really prefer a proper case to a plastic one, I have one particular one that stood out to me: https://www.amazon.com/gp/product/B079CF5FNX/ The case is aluminum, with machined end blocks and a perforated top. This would be my recommendation for any hot board like the Tinker Board, and to be honest the one I bought is quite nicely put together, with a somewhat industrial feel. Does anyone else have a favorite? I'm not really talking about those zebra cases or open-air acrylic/standoff sandwiches.

Best nights I don't remember. The stuff was illegal in the United States for a long time...

Well, I am using our conventions for the sake of this discussion. "Default" is vendor legacy kernel. "Next" is mainline but stable, not rc. Dev is rc mainline/holding pen before rolling over into next. So were this already in place, "default" would be 4.14, "next" would be 4.15, an dev would be 4.16 rc-6 (or whatever) Has Google translate been improved past the level of a house pet's linguistic capability? I'll have to give that a try. ;-)

Ahhhhh, the mix of English into that about killed me, hahaha "Ich verstehe nur Bahnhof". Idioms are only taught to the students who have the good teachers that also teach how to swear properly. I think this falls into the same category as "Stop beating around the bush", the German version says something about cats... For the change, we don't currently offer more than 1 kernel option, and that option is in the "next" category. So I want to put 4.14 into the unused "default" kernel category (such as Rockchip 4.4), and make all new "Next" category images the current stable kernel (upcoming 4.16)

I am re-testing this now, the initial problem was the UI locking up on large programs launching. couldn't track down why, but seems to be gone now.

We use the same patchset for kernel 4.14 as the vendor, so yes, the fix has been in, I believe, all 4.14 builds, certainly is in the linked downloads.

Alright, I have the issue fixed, Mali frequency is correct per the opp table, and can be changed using the proper echo's. The culprit, I believe, was the rockchip kernel having mali400 enabled by default. (this was true of the old kernel as well, I disabled it, but it kept showing up selected in other kernels so I left it alone here) In any case, this violated the dependencies of the devfreq driver. I also enabled all the various governors (no powersave, I'll check again): Found it, some reason was "m" instead of "y" root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# ls available_frequencies cur_freq governor max_freq polling_interval subsystem trans_stat available_governors device load min_freq power target_freq uevent root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat available_governors userspace performance simple_ondemand root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat available_frequencies 100000000 200000000 300000000 400000000 600000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat cur_freq 400000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# echo 100000000 > min_freq root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat cur_freq 100000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# (I changed it from 400000000 to 100000000 because I had already run through the commands once.) Going to ./build/output/config the file was sitting there waiting for me. I will have uploaded it to the development branch by the time you read this. (unless you're sitting waiting for this message to post, in which case you may check before it gets committed)

Building one now, let me see if it does the same.

This was briefly discussed in another topic, but the idea would be to make 4.14 the default kernel for Le Potato and K2, and change next to the newest stable kernel. The reason is, the 4.14 is the vendor kernel for Le Potato, K2 is only supported via it's similarity to C2 and Le Potato, and we currently don't have a "mainline" for Amlogic as everything moves forward. Consequences: Default build it yourself with the 3.14 will no longer be possible. We do not provide images of this build anyway. Next image users will get updated to the newest stable rather than staying on 4.14 This is what needs the discussion. I put a quick post on the Facebook group for Libre Computer I belong to, so far I've gotten half the community having seen the post and nothing but positive feedback on the change proposal. Looking to get any feedback available here. March 30, 2018 Status: Building "Default" image for either Le Potato or K2 will give you 4.14.y with Current BayLibre patches (K2 had other issues due to a board rename some time ago, broke u-boot process and boot script generation) Next still at 4.14.y waiting for 4.16

;-) A joke of course. I do not mind some German, of course I can read it, so that makes it less distracting. Sent from my Pixel using Tapatalk

I could put this up for discussion on the Facebook group and see. I know we don't want to interrupt the stream, but we're still getting people showing up with 4.13 kernels, so... Let's wait for 4.16 to be released, see how stable the result is and go from there.

@Igor Quick concern I thought of, people running "Next" currently would probably get automatically (and possibly unwantedly) updated to 4.16.

I did that by default, sorry for not pointing it out

It would appear there's a regression in 4.14 concerning sound on rk3288 SoC drivers. This has been seen on Tinkerboard Next and some reports came in on @Myy's github about the same thing. I'll look into the fix, but that's been the holdup.

I think so. Maybe see if any of the usual suspects have feedback first.

My intention, and I think Igor agrees, is to go LTS kernel to LTS kernel. It is possible to build a current "bleeding edge" mainline if you have the means to do it yourself, the "Dev branch is current. @Igor, the vendor kernel (vendor being Libre Computer) in this case is 4.14, should we make that "default" for this board? Especially since, IMHO, @balbes150 has provided the definitive guide and images to run the 3.14 on anything with an s905(x) adequately using his fork. "Next" then could be a current mainline image that we're comfortable with.

Sound was added to Next for Tinker, and Dev for MiQi. I will try to bring them to equality today.

VCC_SYS appears to be setup exactly the way it is on the RK3288 Tinker Board. So the micro-USB provides VCC_SYS, which is piped directly to the RK805, the HDMI, and the USB. To be honest other than over and reverse voltage, I don't think you can do much damage. Nice reference materials though, thank you for the links!