Am Tue, 20 Sep 2016 18:20:09 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
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.
Did you connect the mainboard at the beginning or after those 58 minutes?
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.
Sounds interesting!
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.
Not really. You did some basic tests, but you never did some high stability tests, as far as I know.
Connecting a display board to see "it works" is different than connecting it and trying if it still works with full CPU power for an extended period of time.
I rather would prefer that we can test the latest design than reasoning about old stuff...
Well, you know best what has been changed with the latest designs: Anythign that could lead to that issue?
Is there a changelog between the old version, the current one we're using (with our modifications) and the upcoming version?
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.
I'd say more unlikely than likely, but as that seems to be an issue with the EVM only, not with the Pyra PCB, it's not that much relevant.
Is the power supply to MIPI/HDMI somehow filtered on our board to prevent such peaks?
Yes. There are filter capacitors.
Hm. Okay. Is there an easy way to check with measurement tools if these are big enough? Or would the peaks be too fast to see on your multimeter?
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.
Ah, right. Well, it should be easy switching the, off with a script before X is being started. rc.local is your friend here.
Will do more tests with that!
And yes, the rotator and panel and backlight also draws significant energy.
I will also use a non-ssd panel for the test. aTc already has a non-ssd panel.
And of course they are turned on a some time during the boot process.
And always about the same time.
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.
Ah, the PALMAS shuts it off? Then that's most probably the reason here, as it's always a clean shutoff, not a freeze.
All LEDs go out, the power LED blinks, the display goes out.
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.
Hmmm, but are you sure it's the first time the panel is being talked to? The first time I see these MIPI messages are shortly before X is being started, whereas the backlight of the display is switched on already shortly after the kernel has booted.
If the display it not being found, the backlight also is not being switched on. So I can tell after a few seconds of booting if the boot will be successful or not.
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...
Nope. I never concluded that. I said it COULD be a reason. It's always good to follow clues if you have no real idea what's going on.
And both the EVM and the Pyra PCBs seem to have issues with the DSS device which seem to be connected with the power supply.
Coincidence? Maybe. But maybe not.
- 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.
Yes. But does the OMAP subystem need more power during boot than it needs later when you run the CPU at 200% while having a running MIPI stream?
Because that works fine - once the DSS initialization is successful (with display found), it runs stable.
With the exception of the full switch-off from the PALMAS once the MIPI stream is enabled (which makes me think that the MIPI stream needs quite a bit of power as well).
> 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