Am 20.09.2016 um 17:53 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 20 Sep 2016 17:24:26 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- When the 5V LED is on (power is below 5.6V, which means it
switches to Power Jack Input), the EVM runs unstable. At least yours, mine and aTcs, from what we know. It seems Nikolaus' one is not affected (for whatever reason).
Well, I have never tested with higher voltages.
And you never tested the whole system, just the CPU itself (without using USB, HDMI, etc. with 5V) Which is a good information as well!
No, I have had also run tests with USB and HDMI... But not recently.
Okay... that would be interesting then.
Anyways my kernel hangs on the EVM are gone :(
I didn't say that had created a fresh SD card with the official omap5-uevm.dtb.
Well, WITHOUT any DSS device attached, which could be the clue!
I had it running now and the EVM got stuck @ high load. After 58 minutes. And cycling between 90° and 100°C.
What I had changed was to use the omap5-uevm+pyra4.dtb and connect the V4.9 Pyra mainboard.
The main differences are of course power consumption and MIPI running.
So yes, power demand increases if a mainboard is connected and MIPI is running. But this is not unexpected...
Next I will do some crucial tests. Use the omap5-uevm+pyra4.dtb which can initialize the display board - but not connect it. Or just connect the mainboard but no ssd plus panel. Or just detach the panel.
But all this is not extremely helpful for the Pyra since we have modified a lot of issues in that old mainboard and display board design. I.e. we are just repeating tests already done because we have no latest design produced.
I rather would prefer that we can test the latest design than reasoning about old stuff...
That nothing seems to have a high impact regarding stability ;)
Not necessarily. As described in earlier mails, a higher voltage of the power supply gives more safety margin if cables are weak. And that is independent of the existence of any 5V switch.
Yes, that's true. But looking at Roys Tests, it would be a weird coincidence.
But not a very unlikely.
As soon as the voltage is high enough to NOT switch to the 5V mode anymore (or rarely switches to that mode), using 6V or higher, it runs stable.
So I don't think the higher safety margin is the reason, it more sounds like the <5.6V setting.
Otherwise, it would probably still run unstable at 6.2V or 6.3V.
Unless there is a bug which makes the OMAP5 have the same power consumption regardless you stress it or not, but that's what a good power supply which shows the Ampere can answer.
This would also mean that the temperature would be constantly high... But that isn't. And I had measured the real power demand at the sense resistors a while ago. And that heavily depends on what I am doing.
Okay, then we can rule that out as well!
So why does simply using HDMI make the board run unstable, but only in that 5V mode?
Hm. That would mean a bug in the DSS system.
True, both HDMI and MIPI run through the DSS system!
And as my power tests with the Pyra PCBs have shown: As long as the display board is NOT connected, it always boots up fine!
And as soon as it is connected, it heavily depends on the power supply!
And: Running only off battery or AC adapter, most of the times it doesn't initialize the display at all - which means it can't find it which would also mean that there's something wrong here.
So DSS seems to have power supply issues...? Maybe a bug in the driver causes a high (but unseen) voltage peak when it's initialized and that peak either leads to a freeze during boot (which doesn't happen without the display board attached) or leads to the display not being found... and only sometimes, all works well and the display works fine.
Same thing again yesterday when I showed the Pyra to some guys of the MetaLab in Vienna: I only had an USB power adaptor with me (no battery). It took me about 12 - 13 tries to boot it up. But once it booted, it worked fine, without any crashes.
The most reliable setup is using a battery together with the AC Adaptor, even with battery it often doesn't find the display.
Is the power supply to MIPI/HDMI somehow filtered on our board to prevent such peaks?
Yes. There are filter capacitors.
Or something we can improve (maybe we can even hack something up to test with our current boards..?)
Does that mean the Pyra always run similar to the 5V mode or rather to the more than 5.6V mode (using SMPS)
As written in some other mail, the Pyra circuit is similar to EVM running in higher than 5.6V mode. It just uses a different SMPS to get that down to 3.7V. And one that does not want to see more than ca. 5.3V at its input (USB specifications).
Okay, that's a good thing then.
Hm, additionally, there is one huge difference: While the EVM seems to get unstable and tends to freeze, the Pyra only seems to freeze in bootup at a certain time (seen in my tests, two times it froze about 21 seconds after boot) or it doesn't freeze at all (even if the display is not running).
So yes, it does sound like there's a DSS issue (power peak?) that can lead to a freeze or MIPI not working.
As currently everything is enabled (all LEDs, USB Ports, Wifi, etc.), it could very well be it simply runs out of power when booting with a 5V 2A AC adaptor. The fix for that would be to disable most of the unneeded stuff during bootup (which is what the Pandora does as well).
Yes. Especially since the keyboard backlight draws more current than needed.
And yes, the rotator and panel and backlight also draws significant energy.
And of course they are turned on a some time during the boot process.
That would also explain why it ALWAYS powers off completely when X starts the MIPI stream when running only with AC power (and the display has been found during boot).
I never had see this but yes, it is a good explanation. If it needs too much energy because of display etc. the Palmas will shut off at some point. I don't know if it should/can automatically restart.
It is mainly an automatic bypass of the 5.6V - 12V -> 5V converter (because USB and HDMI need 5V). It is bypassed if input voltage is low enough.
Hmm, could HDMI or USB cause a freeze of the OMAP5 if the voltage is not stable enough?
I don't know how HDMI signaling works, but in theory: yes. A device that does inject invalid activities may not be properly ignored by the kernel and make it fail.
Well, I know both HDMI and MIPI have protocols, where they talk to each other finding out about the different specs and features.
I can imagine that this can lead to a freeze - OR to not finding the display, which is exactly what seems to happen on the Pyra.
Can the DSS / MIPI initialization be modified so we get a debug log of the commands being sent to the display and what we receive back?
It already does for MIPI.
That might give us some clues whether that works fine or not.
But since I am no longer finding the issues I had last week on my EVM it might simply have been a corrupt SD card. A single bad bit at the right position might have such effects.
Yes, but you still didn't use it with MIPI.
So it is IMHO not really helpful to invest much more time in understanding the EVM because I think we can't learn much about Pyra issues.
I wouldn't say that. So far, it does seem to point us to the fact that something is wrong with HDMI / MIPI (so DSS) and not with the fact that the OMAP5 is using too much power.
Hm. I only reasoned about HDMI 5V power being switched on the EVM which has some connection to the DSS system and you seem to conclude that DSS and MIPI on the Pyra must be the reason for Pyra problems...
Hm. I also do wonder whether some part on the mainboard could mess up the MIPI signal (EMV-Issue?)
If MIPI signals are messed up like you think, you only loose the video but not the processor.
But then again: Then it would be unstable later on as well
indeed.
- but it
seems to work without any issues once it has been properly initialized.
So it happens during initialization. And I did run many tests some months ago (you remember the oscilloscope images) that the current drawn by the OMAP subsystem makes big changes during boot.
What Kernel are you using? I've upgraded to the letux 4.8 RC5 via aTc's repo update and noticed this behavior with my bench supply capable of delivering 4A.
5.1V - Some instabilities HDMI, SATA resets and USB devices blink
out.
Sometimes freezes before getting to X.
5.2V - Boots up Consistently. random Freezes when using Firefox when attempting to watch a Youtube video. Sometime just HDMI blinks out occasionally.
5.3V - Seems stable running CPU intensive things. Firefox running youtube video, running 720p video in smplayer and quake 2 at once. highest current draw observed ~1.6A during spikes. Random Freeze occurs generally within 5 to 10 minutes of use.
5.4V - Same as 5.3V
5.5V - Same as 5.4V
5.6V - 5V LED blinks, HDMI blinks out or won’t go into a resolution above 1024x768. Can seem to use firefox, youtube videos without issues.
5.7V - 5V LED is off, but turns on when drawing ~1A. HDMI working appropriately.
5.8V - Same as 5.7V
5.9V - 5V LED is off, but turns on when drawing ~1A. oddly the 1024x768 bug appears again at this voltage. powered off a few times to confirm it.
6.0V - 5V LED is only displays as on with current draw is ~1.4A.
Seems
stable otherwise.
6.2V - 5V LED is only blinked a few times, when the current draw briefly spiked about 1.6A. seems just as stable.
6.3V - 5V LED off completely. No noticeable blinks. appears stable.
On Mon, Sep 19, 2016 at 12:06 PM, Tony Lindgren tony@atomide.com wrote:
> * H. Nikolaus Schaller hns@goldelico.com [160919 02:55]: >>> Am 19.09.2016 um 11:39 schrieb Grazvydas Ignotas >>> notasas@gmail.com: I could give it >>> a try on my uEVM to add another data point. FWIW my uEVM has >>> been always rock stable (12V supply), but I haven't updated my >>> kernel for a while. >> >> Yes, would be nice to compare your results and >> observations. > > My omap5-uevm is on a 5V power supply right now it seems, I'm > pretty sure it used to have 12V supply earlier. > > Regards, > > Tony > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org