Am Sat, 30 Jul 2016 21:54:13 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
The CPU board I am running these test on has additional wires which allow to measure the voltages VDD_MPU, VDD_CORE, VDD_DDR3, VDD_MM, 1V8, VSYS.
This might be a good idea. Maybe the combination of Palmas and the charger / battery chip causes an issue here and the voltage isn't increased for some reason.
Very unlikely that the charger / battery has such an influence. How should it know that I increase the cpu-freq...
It provides the power that the Palmas requests, does it not? Or does it always provide the same power and the Palmas changes it based on what you set it to?
There are other factors (e.g. Speakers on/off, Display on/off) which also have a high influence on VSYS and currents flowing through connectors but turning them on or off makes no such difference as cpufreq.
One thing just came to my mind: You mention that it runs fine with SINGLE core 1,5GHz. If that's the case, then the power has to be set correctly, otherwise, the single core would crash as well right away.
So the question is: Why does it run with 200% CPU on dualcore 1GHz but crashes as soon as you switch it to 1,5GHz. 1,5GHz without doing anything should need less power than 200% at 1GHz, so it can't probably be the overall power consumption.
Hm, well, there is one difference:
I=U/R... if you have a higher voltage, you need more Ampere as well, depending on the resistance the traces have. Maybe it can't handle to keep the voltage high enough for that reason, or peaks.
If the voltages turn out that they are not increased, there would be a software bug.
But then it wouldn't work single core 1,5GHz, so you can probably rule that out.
- Are there differences in the board files that could cause
our CPU to misbehave?
Yes. The Pyra has a different DT file than EVM. And for the IGEP I don't even know what it has. There is omap5-board-common but we have a lot of extensions.
I know they have different DT-Files, but the question is: Are the power / voltage / timing settings in them different?
And there could be some problem in a driver for a device that does not exist on either EVM or IGEP.
Well, in that case it should work when all drivers are disabled and the system is being run under a minimum condition.
- Is there a difference in our hardware setup that could lead to
that? We got different RAM, a diffrent quartz, different power setup (we don't have a simple AC like the devboards, but a battery / charger circuit)
RAM and power setup / battery / charger is something I would remove from the list of potential reasons. Because they are exactly the same at 500 MHz, 1 GHz or 1.5 GHz. There is nothing controlled differently.
Well, except if they cap the maximum voltage for some reason, so the PALMAS can't change to the requested voltage. This would explain why 200% CPU at 1GHz would still work, as not the power is the issue, but the voltage.
The SoC die temperature when running at 500 MHz is ~55°C. And when switching to 1.5 GHz it rises to 65°C in 2-3 seconds and then the CPU hangs. This does not change the quartz temperature.
10°C more in 2-3 seconds? That sounds strange - unless you are running performance as governor, setting the CPU speed to 1,5GHz shouldn't really do much as the CPU would still be idling... so why does the temperature rise that fast?
Anyways, please all kernel developers think about potential kernel issues (scheduling, SMP, locking, interrupts, I&D-caches) that might lead to such a behaviour. And potential tests (I can add printk etc. where needed).
What puzzles me most is that the system hangs at low system load. As soon as cpufreq-set goes to >ca. 1 GHz. In that situation the OMAP should be in idle 98% of the time and is just blinking some I2C LEDs and waiting that I type the next command over UART console. Well, DSS is also running in the background. But not much more.
Yes, but that sudden increase of temperature does NOT sound like idling.