Very sadly I was expecting and fearing this.
I have been following mobile/cell phone industry for a very long time, and I have seen near nobody choosing Cortex-A15 because they were too much power hungry with lots of problems. I saw how most manufactures jumped over Cortex-A15, and who didn't had problems.
Well, there were a few smartphones that used the Cortex-A15, and yes, they're power hungry.
Running the Pyra with full CPU power (means: stressing both CPU cores to the maximum) will eat up the battery in 2,5 - 3 hours.
That's nothing new. And then again, with a CPU heating to 120°C when using both cores fully for a longer period of time, you should not do that.
Most modern smartphones clock down when the CPU gets too hot, and I guess we will have to do the same as well.
However, that's a very unlikely scenario (unless you compile something, but then again, you should use an AC Adaptor for that), and my smartphone can also eat it's battery within an hour if I stress both cores to the maximum
What's more important is that the CPU itself uses LESS power for the SAME processing power than on the Pandora.
Which means: If you run stuff that works on the Pandora (which doesn't use the full CPU), the Pyra should have a WAY longer battery life.
Typical tasks like Webbrowsing, for example, increase the CPU load when rendering a page, but that's only a short peak, until it's loaded. So webbrowsing should be faster and use less power.
When using stuff like DreamCast or N64 emulation, which needs more CPU power than the Pandora can offer, the power usage will increase. To what amount cannot be said yet, but I doubt they will use both CPU cores fully (as N64 already runs pretty well on the Pandora).
3D Stuff doesn't use the A15 but mostly the GPU, so the power issue is not really a thing here.
The battery time will be something between 2,5 hours and probably 20 hours, depending on what you do.
However, that has NOTHING to do with the issue we have, so lets get back to the topic
¿A simple solution? ¿Use only one core? ¿Lower frequency? Not nice.
Nope, that's not a solution, and no one said that.
This is just part of the "tracing-the-issue-back"-part.
This shows that the SoC clearly doesn't get enough power. And as that issue doesn't happen on the EVM, but we are using a different system for providing the power (as the EVM doesn't need to handle battery charging), it's clear that this is most probably where to find the solution.
It could be hardware, it could be software.
It could be that the power circuit limits the power for some reason (i.e. it automatically limits to 500mA when you a USB power source, and that needs to be changed in the software configuration) and therefore, the SoC simply doesn't get enough power for higher speeds.
It could be that there are some power spikes when changing the CPU speed which just need a higher capacitor to smooth them.
There is a solution, that's for sure, but finding it can be fast or slow, you never now before.
It is sad to find this problems in this development stage, where other points are so advanced.
Umm - that's exactly where these problems occur
The prototypes are the first real produced systems based on a theoretical layout. They exist in order to find out if everything works right and then fix it
They couldn't have occured before, as the hardware didn't exist before.
We end up with a 32 bit ARM with problems, while there are lots of 64 bit ARM without problems (only Snapdragon 820 had problems, and are they are thermal problems); and with closed driver for GPU, using a rotator chip (more power demand, lots of initially problems and forcing to use 720p display instead of 1080p as originally planned) instead of using SOC graphic hard to rotate screen as all modern hard/SO can do.
TI still has the best support for their SoCs in Linux. Try to find other current SoC stuff in mainline kernel.
The SoC has nothing to do with switching to a 720p display, btw, the reason was that I tried a 1080p display and everything was too small to be used. While Linux desktops have a dpi setting, not all programs respect those, so e.g. GIMP is unusable until you manually change some configuration files with a text editor.
A 1080p display with that size would have had too many drawbacks and wouldn't really have given us any advantages.
I understand Pyra problem: to find a manufacturer supplying so little quantity and some support; so little to choose.
I'm pretty sure I could get a Rockchip or Allwinner somewhere, but they are pretty much fixed on Android whereas the TI SoCs even have mainline Linux kernel support.
We don't want to end up with outdated kernels at some time.
Also, I'm not sure how well they're SoC guides are written...
I don't know if in the end it may be I should wait for upgraded Pyra with a better CPU board (64 bit ARM v8A and without power issues).
Well, if everyone does this, there won't be a Pyra.
One reason the CPU is upgradable is that it's attractive for everyone, as the system doesn't need to be thrown away in a few years like smartphones are, but you can upgrade it for about 100 EUR with a brand new CPU.
And, honestly, what I've seen of the OMAP5 so far, we got plenty of processing power for a while
PD: Sorry for being this crude but I was fearing this problem and this add-up to the handicaps.
In other way I haven't lost all hope on Pyra.
Well, my guess is you didn't understand the post correctly.
This is not an issue with the SoC, it's an issue with the power circuit right now. Any Snapdragon, Rockchip, etc. would freeze as well in this case.
The parts we have CAN provide enough power according for the datasheets, but something limits it right now. And that's what we're trying to find
