We've started to order things!


Since most emulators and games that we're going to be running on this initially are single threaded, what is the behavior when a single core is abused like that?
 
While it's good news on it's own, it bring back the sad truth that it simply won't be possible to 100% the CPU for an extended period of time. I know this handcrafted test to stress the CPU to the fullest extend, but for purposes like longer time 2 thread compiling or really well optimized software:
What is the clock speed where the OMAP5 doesn't reach critical temperatures at all? The planned cooling stuff will only postpone the emergency downclock, so I think it may be better to avoid that stage if possible. For demanding games you'd probably also rather want consistent performances instead of random drops.

when this magic 'stays-always-cool'-clockrate is known somewhere in the future after more testing, i probably will set my max on-demand-scaling mhz to this too.
it is a nice thing to have some bonus-mhz for a short time when needed, but for longer operations i like it to stay under any t-max values.
hey, this is a real computer and no stoopid 'smart'-phone, right? ;)

... and superhuge kudos to zmatt for doing this cool things (i don't understand currently, but... i'm learning...;) for enabling 4gb ram and 1.7ghz stable overclock, epic.
superfreakin'awesomeness!!!! :)

edit: i too would like to see an general gnu/linux section for sharing and careing bash command-line tips and more. :)
 
Last edited:
People stop freaking out it's running a special stress program running the CPUs well beyond typical use, even heavy use. I've thrown a ton of crap at the EVM devboard without reaching temps seen here even without a cooling solution.
 
It would be interesting to know if the throttle occurs or not with a 100% stress test on 1 core only.
I feel I will almost never use both cores at 100% each but emulation may push one core to the limit.
 
@hns - What are you running for simulating stress? I've used the stress command with a varying number of CPU hogs enabled and don't get the high temperatures you seem to get on the EVM.

@elvissteinjr - We can't yet say how real life CPU load behaves, I'm not sure if they've even played with applying thermal pads/paste yet to help it dump the heat to the PCB.
Yes, it is without any special thermal measures. It is more to see if the CPU runs at all at higher clock.
Scripts (high temperatures come with ./high-load -n):
http://git.goldelico.com/?p=gta04-k...b05819e9d121bd5da2f9;hb=refs/heads/letux-4.10
http://git.goldelico.com/?p=gta04-k...953aebbeb3b7f6e278ab;hb=refs/heads/letux-4.10
 
Well, these CPUs were never designed to run full power for an extended period of time. They were designed to have some extra power for short time frames (like rendering a website) which won't heat them up too much.

It's also worth noting that Nikolaus probably has the keyboard LEDs lit as well, and they also produce some heat which adds up inside the case.

The heat pad that connects the SoC to the PCB (which has copper layers for cooling) is also not yet installed and an aluminium plate will be installed as well behind the SoC.

But as I always said... don't expect it to run with full strength all the time. There won't be many programs that really would need that (except for compilers and stuff that renders a lot of things).

Webbrowsing peaks only for a few seconds to render the page, as do most other programs as well.
 
Im more interested in running GHZ Pandora Tasks (N64, PSX DS Dreamcast Fullspeed) whit more Batterielive as the Pyra will run this in stand trottle,

For me the Pyra will be a Pandora in much better ..

Some news about the Board Production yet?? ,
 
I'm aware of the not final cooling and the CPU being designed for short peaks. My question was out of pure curiosity of the current knowledge, though.

Also @TrashyMG, as much as I like your videos and insights from the EVM board, please don't generalize from just you not experiencing things. We're not gonna tell people who do manage to hit critical temperatures "well duh, you're not supposed to do this with this device you're allowed to do whatever you want on", or are we?
I mean, yeah, I totally feel like I'm exaggerating here, but I tend react harshly to things that go "doesn't happen to me, so the issue is non-existent". No offense intended.
 
Did i understand correctly, the 1.5GHz issue seems to be solved by a u-boot pactch? What was this magic bit?
So the last prototype boards are already working with full speed?
 
This is quite some improvement as I remember, and therefore some really good news in all. As I recall before the reduced number of vias on the CPU board meant the power supply wasn't clean enough for the CPU when the clocks were running fast and the SoC crashed. If this one bit change fixed that that's pretty remarkable!

Edit: Or maybe I'm just forgetting who's got what. Perhaps hns and zmatt have got boards with the new vias. Perhaps this is the result of the new vias doing everything that was expected of them and even giving the chips the ability to clock over their rated rates quite well for short blips!
 
Last edited:
Edit: Or maybe I'm just forgetting who's got what. Perhaps hns and zmatt have got boards with the new vias.
No, production of the new boards has just started. I think the last prototypes are from November. This could imply that the cause was not power delivery related after all.

If the magic bit is the RAM impedance calibration enable bit, then that's really perplexing. How could impedance mismatch on the memory bus cause the CPU or the memory controller to crash, but only above a threshold of CPU frequency? And the neon test loop doesn't touch memory, so it's likely not because a faster running CPU pushes RAM harder.
 
Well, I forget who initially reported the instability at 1.5GHz. Maybe it was always hitting thermal limits and shutting down? I'd hope even a layman could spot the difference between a CPU hang and a controlled shutdown, but stressed people aren't always as attentive as the relaxed layman.

But either way, it doesn't really matter now. The only thing to take away is the CPU can run at a range of frequencies quite stably now by whatever means.
 
The heat pad that connects the SoC to the PCB (which has copper layers for cooling) is also not yet installed and an aluminium plate will be installed as well behind the SoC.

I don't think that any of us have ever seen this combination. This is the first I recall seeing mention of the aluminum plate - though I could have just missed it.

I'm assuming that since the plate would rest between the SoC board and the case plastics that it would have been taken into account in the mold generation. Does it connect over to the SD cages?

Some time if/when you have the chance, a few pictures of all of the pieces (including the heat pad(s?) and aluminum plate) and how they go together would be fascinating.
 
I'm assuming that since the plate would rest between the SoC board and the case plastics that it would have been taken into account in the mold generation. Does it connect over to the SD cages?
I don't have a reference right now, but ED said a long time ago that the cooling solution for the SoC would connect to the SD cages. This makes some sort of heat sink necessary and while he's at it it would only make sense to expand it over as much of the footprint of the Pyra as possible.

I'm not sure how well that would work, but it might even be worth considering to put some larger heat sink element in the empty lower front left corner. Since the plastic case would still block the heat dissipation I'm not sure if it would be better to design it like a traditional heat sink with a lot of surface area, or if a solid block of aluminium would make more sense, so it would be more of an actual heat sink to absorb thermal peaks instead of a heat dissipator.
 
I'm not sure how well that would work, but it might even be worth considering to put some larger heat sink element in the empty lower front left corner.
Don't fill that corner - it's where the longer RHS extends into. (Red Hot Stylus - side experiments of mine.)

Since the plastic case would still block the heat dissipation I'm not sure if it would be better to design it like a traditional heat sink with a lot of surface area, or if a solid block of aluminium would make more sense, so it would be more of an actual heat sink to absorb thermal peaks instead of a heat dissipator.

Which raises the question again of how to get the heat out of the case instead of just adding places for it to accumulate.

I've had this idea/fantasy of someone, someday, making a CNC milled aluminum replacement for just the lower case plastics. It could then act as both a much larger heat sink and a liquid cooled heat exchanger - to the user's hands. (Don't panic - it would not be that hot once spread to that material volume.) I don't really think that such exotic solutions will be necessary. It is more of a mental exercise in how a Pyra form factor could work with a much hotter running SoC.

I wonder - Does the @zmatt prototype have the thermal pad & AL plate thermal solutions in place?

This project keeps getting closer to reality. I'm really looking forward to the next round of updates.
 
Back
Top