Search function seems to be working correctly again after the outage earlier and I came across this regarding heat spreaders:Thanks for the info! So these are potentially instead of the heat pipes, or additional to? IIRC, the heat pipes are supposed to be arriving any day now...
Fujitsu aren't the only ones with such solutions.
There are some synthetic carbon (I think) pads which let you distribute the heat or move it anywhere you want.
And special silicone mats that can shield the heat (so that it doesn't warm up critical areas like the battery). You can actually put these mats on a 200°C stove and put your finger on top of it
We've got both here and can test whatever we want. We got enough space between the PCB and the battery compartment to shield, we got enough space between the CPU and the PCB to use some heat distribution if need be.
The main idea is to move some of the heat to the SD Card slots (which have a large metal case and are open, so they can exchange the heat with fresh air) and use large copper areas in the PCB for heat distribution.
The most important thing is to DISTRIBUTE the heat, so that it doesn't stay in one tiny spot.
I've opened some tablets which use the carbon stickers I mention above. They mostly only have a 4x4cm sized carbon sticker on top of the CPU. It doesn't connect anywhere, it just exists to distribute the heat to a wide area, so that the overall temperature is lowered.
The EVM doesn't do anything like that.
It has a very simple heatsink on the SoC that doesn't do much: According to my measurements with a temperature meter, it only lowers the temperature by about 10 - 15°C.
Additionally, the EVM is not very optimized regarding power usage. Without even switching it on, I used up to 300mA when I measured.
And the heat from the EVM doesn't seem to come from the CPU only. When I did my testings, it seemed to me that the PALMAS (the power chip) also adds a lot to the heat, and it sits near the OMAP5.
I was able to measure up to 120°C when running the EVM with full stress test for a while, whereas Nikolaus only measured up to 65°C yet on the Pyra CPU board (also with stress test).
I can imagine the PALMAS heats up a lot on the EVM - it needs so much power that a Pandora AC adaptor isn't powerful enough to run it without crashes... and as all the power distribution goes through the PALMAS... yep, that generates quite a bit of heating.
The EVM was never built to be optimized in power usage, it's built so customers can evaluate all features.
When I was running the EVM with X and standard usage, I measured about 55 - 60°C.
Nikolaus measured about 35 - 40°C for the same on the Pyra PCBs.
So I don't think it'll be that bad, but sure, it'll generate a lot more heat than the Pandora when you fully stress it.
First you will need to start with a Buster installation (I think dist-upgrade should work, otherwise install one of the newer images). Then, to install the new kernel - instructions from @aTc on IRC as I haven't tried this on my own unholy hybrid of Letux and PyraOS that I am currently developing with:
Hopefully, this should start up with a correctly rotated screen.
For the TILER+3D, first download and extract tiler_shim somewhere. apt install supertux or whatever you want to play (TORCS works too but is quite slow).
Then wherever you extracted tiler_shim; run `./init.sh` followed by `./run.sh /usr/games/supertux2` (if running from SSH or serial, make sure DISPLAY and XAUTHORITY are set)
I have only tried SuperTux on the uEVM, so I can't guarantee it will behave correctly on the Pyra hardware (resolution settings might need changing, etc).
irccloud where I uploaded that has been having a very bad day today...
Try this link instead: http://ds0.me/tiler_shim.tgz
Post automatically merged:
Sorry, I'm an idiot, looks like I created a tar archive with a tgz extension for some reason. Try renaming it to .tar and all should be fine (I'm so use to stuff auto-detecting compression that I didn't notice when I was using it).
Yeah - something isn't clicking. I'll just have to wait for you to get a Pyra.Due to various naming possibilities and the fact that the proper Pyra kernel usually loads the module automatically anyway that error can probably be ignored for now.