Am 20.09.2016 um 18:49 schrieb Michael Mrozek EvilDragon@openpandora.org:
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?
While power down. It can not be connected while powered up...
So I have to reboot when switching any hardware configuration.
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!
Is running while I am doing something else.
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.
I did as good as possible for debugging the u-boot bq24297 driver and kernel driver.
And I did run the ./high-load script on the EVM as well once we had designed it. Maybe not systematically. And more on the Pyra because the Pyra easily hangs. Without powering down.
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.
That is the difference between "functional test" and "stress test". You can do the second one only if the first one is ok (which took quite some time if you remember).
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?
No. Because I can't test if it is not already solved in the latest design and we are hunting a known bug on the old one...
Is there a changelog between the old version, the current one we're using (with our modifications) and the upcoming version?
Yes, there is (or can be worked out), but it doesn't tell us anything about potential or remaining issues of the new verson. Therefore I do not care about the past.
Like your balance sheet of last year doesn't tell anything about this year... Or when hiking, the path behind you does not give hints for the path in front of you.
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?
On a multimeter you can't see them. But I checked with Oscilloscope a while ago and could not identify anything problematic. Expected changes in current consumption are very high.
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!
Yes, please try to find out if it is more stable with backlight off. Maybe display backlight dimmed to the minimum.
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.
The SSD should make 200mA difference or so (somewhere I have the values but it is too long ago to remember).
And of course they are turned on a some time during the boot process.
And always about the same time.
Roughly the same time. But boot hangs on Pyra did often occur before the panel is initialized.
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?
Who else? The Power-button is only connected to the Palmas and only the Palmas can shut off so that you have to press the power button to reboot. This is to get lowest µA power consumption if battery is connected and the users powers off the device. It is more or less the central power switch.
The charger is passively sitting between battery and Palmas and just forwarding energy. Unless charging or instructed to do something through I2C.
Then that's most probably the reason here, as it's always a clean shutoff, not a freeze.
That is interesting because I have never seen a clean shutoff. Just quite some freezes.
All LEDs go out, the power LED blinks, the display goes out.
This is shutoff by Palmas.
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.
Yes, they are run by the shell script in the panel-mipi-debug driver setup.
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.
I was referring over "the fact that something is wrong with HDMI / MIPI (so DSS)" which sounds like a conclusion from all symptoms we know :)
The problem is that we do not know if problems seen with HDMI / MIPI are the result of a different problem or the reason for the different problem.
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.
Where do you conclude from that there are issues with DSS?
Coincidence? Maybe. But maybe not.
Indeed. So this doesn't give any bit of information.
- 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?
I don't know many details what the kernel is doing during boot up...
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).
Interim status: EVM runs since 1.5 hours in high-load with no problem. Just after disconnecting the Pyra 4 Mainboard and rebooting.
> > >> 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
-- 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