Am Thu, 10 Nov 2016 18:47:56 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
I have tried to bridge the weak wire to the capacitor with an external wire. Unfortunately there is as expected no visible difference (well, this statistics isn't very precise due to small sample size). But as before it did come to login: in 2 out of 10 attempts and stuck in 8 of 10 (@1.25 GHz OPP enabled).
Okay.
Then I made another observation which makes me believe a little more in a SW issue again: If the kernel freezes, it is always between 6 and 10 seconds kernel time (@1.25 GHz). Never before and never after this. If the kernel runs successfully for 10 seconds, the boot process completes and after ~30 seconds we have a login: prompt. This 6-10 seconds windows is for 30 boot attempts where a total of 7 did succeed.
Okay, that sounds interesting. Have you only let it sit at the login then or done some other things (like high-load of the CPU for a minute or so).
Now I really wonder what the kernel doing in this time frame which can make it freeze here but not outside this window? Some interrupt initialization? Waiting during a spinlock for some wrong address to have a specific state?
Well, there is a REALLY accurate guide for the kernel bootup process... https://0xax.gitbooks.io/linux-insides/content/
The problem is: We have no idea where we are after the three seconds, unless the serial output gives some clues.
As far as I remember, when booting the Pandora, it peaks in power consumption shortly after switching on, also within 3 - 4 seconds.
First, it uses about 0,3A, then it peaks up to 0,7A and after a short while it goes back down to 0,3A. (After booting up, when everything goes into power saving mode, it goes down even more).
The kernel probably initializes and looks for all the devices / hardware first, it checks all busses and IOs at the same time.
I guess that's a power consumption peak then, and when the initialization is gone, it goes back down.
So maybe with 1,5GHz and all busses being checked at once, it needs too much power, and at 1,25GHz, it doesn't need as much, and depending on how fast the devices / hardware is being recognized, it works or doesn't work.
That's why I asked whether you did a high-load or similar if the 1,25GHz have booted up: If it crashes then as well, I don't think it has to do with something specific during the initialization.
I will try playing with the OPPs and various speeds as soon as possible.
Is the voltage for 1,5GHz and 1,25GHz the same?
In addition we know that clock initialization and switching from U-Boot speed (1GHz) happens at ca. 3 seconds. That is where 1.5 GHz freezes. Anyone with other ideas?
Or explanations for this effect (immediate crash @3 seconds @1.5GHz, freeze never between 3 and 6 seconds or after 10 seconds @1.25GHz)?
Well, if all the initialization happens in that time frame, that's where we have the highest power consumption, so it might be related to a voltage drop.
I don't know whether there's a parameter that let's the kernel pause a bit after each initialization, or check the devices one by one, not at the same time. That might help.
Another thing that might be interesting: http://dev.pyra-handheld.com/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=blob;f=d...
The PALMAS regulator driver, line 725 and later:
pmic->desc[id].uV_step = 1250000;
It seems it has a fixed voltage step for SMPS10. I don't know what SMPS10 or that step is - but has that something to do with changing the frequency?
Could it help lowering the voltage step, so we'd have less peaks?