We've started to order things!


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

hns says above:
Then we run a tool that uses assembler code to fully stress the NEON processor. This task is run in two background processes at 100% each. A third process is monitoring current clock rate and temperatures inside the OMAP5.

Sounds like something hand-cranked to me. Dunno if it's on a public repo or not.
 
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?
 
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?

AFAIU is not solved but "improved". We still need to see if the new CPU board works fine.
 
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.
 
Back
Top