Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
Regards,
Tony
Am Wed, 14 Sep 2016 13:49:14 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi Tony and Nikolaus,
okay, I had a little chat with aTc right now, who has a Pyra prototype and also has issues booting it with a stock 5V AC adaptor (and without battery).
I think we made quite a huge step with that issue.
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
However, we all switched to using 12V AC adaptors with the EVM, as we ALWAYS had stability issues with 5V adaptors.
I guess both you and Nikolaus are running your EVM with 5V? Then that would be a difference!
aTc found some interesting information about that:
page 19 of omap5432-ref-swcu130.pdf: if the input voltage from the jack is below approximately 5.60V, load switch U4 is enabled (driving the main 5V power rail DC_5V with the jack input), and if it is > 5.60V then load switch U18 is enabled (driving the main 5V power rail DC_5V with the SMPS 5V output).
-----------
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It seems to be unstable when running directly from jack input. The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5?
What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
It sounds like they forgot to smoothen and filter the power source here, so the better your AC adaptor is, the more stable it runs.
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
Regards,
Tony _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
* Michael Mrozek EvilDragon@openpandora.org [160917 07:35]:
Am Wed, 14 Sep 2016 13:49:14 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi Tony and Nikolaus,
okay, I had a little chat with aTc right now, who has a Pyra prototype and also has issues booting it with a stock 5V AC adaptor (and without battery).
I think we made quite a huge step with that issue.
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
However, we all switched to using 12V AC adaptors with the EVM, as we ALWAYS had stability issues with 5V adaptors.
I guess both you and Nikolaus are running your EVM with 5V? Then that would be a difference!
Interesting, will need to check the voltage here. I've been slowly rearranging the devices in my rack and it certainly is possible that I've moved my omap5-uevm from 12V input to a 5V input source around May or so.
aTc found some interesting information about that:
page 19 of omap5432-ref-swcu130.pdf: if the input voltage from the jack is below approximately 5.60V, load switch U4 is enabled (driving the main 5V power rail DC_5V with the jack input), and if it is > 5.60V then load switch U18 is enabled (driving the main 5V power rail DC_5V with the SMPS 5V output).
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It seems to be unstable when running directly from jack input. The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5?
I've always powered igepv5 with 5V input and never had any issues.
What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
It sounds like they forgot to smoothen and filter the power source here, so the better your AC adaptor is, the more stable it runs.
That seems like the best explanation so far :)
Tony
I can also confirm having issues with some off the shelf 5V supplies with the EVM and ended up using a 12V supply. My bench supplies are really clean, maybe I'll run a few experiments.
On Sat, Sep 17, 2016 at 11:35 AM, Tony Lindgren tony@atomide.com wrote:
- Michael Mrozek EvilDragon@openpandora.org [160917 07:35]:
Am Wed, 14 Sep 2016 13:49:14 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi Tony and Nikolaus,
okay, I had a little chat with aTc right now, who has a Pyra prototype and also has issues booting it with a stock 5V AC adaptor (and without battery).
I think we made quite a huge step with that issue.
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
However, we all switched to using 12V AC adaptors with the EVM, as we ALWAYS had stability issues with 5V adaptors.
I guess both you and Nikolaus are running your EVM with 5V? Then that would be a difference!
Interesting, will need to check the voltage here. I've been slowly rearranging the devices in my rack and it certainly is possible that I've moved my omap5-uevm from 12V input to a 5V input source around May or so.
aTc found some interesting information about that:
page 19 of omap5432-ref-swcu130.pdf: if the input voltage from the jack is below approximately 5.60V, load switch U4 is enabled (driving the main 5V power rail DC_5V with the jack input), and if it is > 5.60V then load switch U18 is enabled (driving the main 5V power rail DC_5V with the SMPS 5V output).
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It seems to be unstable when running directly from jack input. The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5?
I've always powered igepv5 with 5V input and never had any issues.
What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
It sounds like they forgot to smoothen and filter the power source here, so the better your AC adaptor is, the more stable it runs.
That seems like the best explanation so far :)
Tony _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 17.09.2016 um 16:35 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Wed, 14 Sep 2016 13:49:14 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi Tony and Nikolaus,
okay, I had a little chat with aTc right now, who has a Pyra prototype and also has issues booting it with a stock 5V AC adaptor (and without battery).
I think we made quite a huge step with that issue.
Well, IMHO this is drawing too fast a conclusion.
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
BTW: I have built a completely new SD card with Debian Jessie 8.6 and letux-4.8-rc6 kernel today according to the instructions I sent yesterday and the EVM runs and runs and runs.
It runs at full 1.5GHz at ca. 100°C from my 5V 2A power supply (a different model and brand than the one used for the Pyra!).
The only difference to my last tests is that I have not connected the old pyra prototype hardware to the expansion connector and I use the official omap5-uevm.dts which does not enable any MIPI output or loads drivers for pyra peripherals.
However, we all switched to using 12V AC adaptors with the EVM, as we ALWAYS had stability issues with 5V adaptors.
I guess both you and Nikolaus are running your EVM with 5V?
Yes, I am. It is rated 2A 5V.
Then that would be a difference!
aTc found some interesting information about that:
page 19 of omap5432-ref-swcu130.pdf: if the input voltage from the jack is below approximately 5.60V, load switch U4 is enabled (driving the main 5V power rail DC_5V with the jack input), and if it is > 5.60V then load switch U18 is enabled (driving the main 5V power rail DC_5V with the SMPS 5V output).
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It is a quite complex circuit (schematics pages 10 and 16).
But look at Figure 6 on page 20 of omap5432-ref-swcu130.pdf.
The wrong conclusion is that this load switch and input voltage detect has anything to do with powering the OMAP5.
The Palmas is powered from VSY_BRD, i.e. the output of U7 (TPS54426) which is *not* switched at all.
DC_5V outputs are for the USB ports and HDMI.
It seems to be unstable when running directly from jack input.
According to this analysis it shouldn't be less or more stable with either input because all power to OMAP5, twl6040 and WLAN runs through this U7 which just gets different input supply.
In other words: this does not explain any difference between 5V and 12V operation.
The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5?
What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
Well, the Pyra also has a SMPS between power source and the 3.7V system voltage which may even be active in battery mode under certain low-voltage situations.
So both EVM and Pyra are essentially operated from a 3.7V "Battery" if you connect an external power supply.
On the EVM it is a TPS54426 to make 5-15V to 3.7V On the Pyra it is a bq24297 to make 5V to 3.7V
There are two significant differences between these chips:
1. maximum current TPS54426: 4A bq24297: 3A
But this must be sufficient according to all we know. And the bq24297 is also rated 3A for battery operation.
What I can't tell is if the "load transient response" is comparable.
2. while the TPS54426 is completely hard-wired the bq24297 has an USB power supply detection logic which tries to find out what the current limit of the power supply is. This depends on some resistors built into the USB plug of the USB power supply cable.
This detection might differ between different power supplies and cables.
There is a nice Table 2 how this detecftion works: http://www.ti.com/lit/ds/symlink/bq24297.pdf
So this means that a power supply can throttle down the current going into a Pyra below the minimum the Pyra needs. This is something we can't easily modify without violating USB standards.
And there is one case where we simply have to: if someone tries to boot from external power only with no battery installed.
This is the reason why I have patched the boot loader to write to the bq24297 to immediately increase the input current limit to 2A if no battery is detected.
Note: for battery operation such a limit does not exist.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
One significant difference is that a power supply at 12 V needs a lower current rating and precision as a 5V supply.
It sounds like they forgot to smoothen and filter the power source here, so the better your AC adaptor is, the more stable it runs.
No, they are there and the whole TPS54426 is sort of a power filter.
There is some theoretical effect which could be possible.
The TPS54426 runs into trouble if a 5V supply is 10% below rating (4.5V) while 10% at 12V is completely irrelevant.
So if a 5V power supply has high resistance of the cable or connector the real voltage at the power input jack may be critically low.
Well, it could be some effect. I measure 4.66 to 4.68V directly across the big DC input jack when running the EVM at 200% load at 1.5Ghz.
On the other hand, the Palmas operates down to 3.2V so there is still a lot of margin. And a second regulator to stablize voltages.
So in summary I think we still need a different explanation for the 1.5GHz problems (we should soon know for the Pyra if the SMPS3 modification solves it), and the boot from USB power on Pyra some people have with some power supplies.
All these problems might be related or unrelated issues and have the same or different solutions.
Even if this might read resignating, we must solve them. And better understand what is going on by comparing setups that work and setups that don't work.
BR, Nikolaus
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
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
Am Sat, 17 Sep 2016 19:05:37 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
BTW: I have built a completely new SD card with Debian Jessie 8.6 and letux-4.8-rc6 kernel today according to the instructions I sent yesterday and the EVM runs and runs and runs. It runs at full 1.5GHz at ca. 100°C from my 5V 2A power supply (a different model and brand than the one used for the Pyra!).
Have you just run some tests or used it? For me, it always booted fine with 5V 2A, but as soon as I started to use X heavily (moving windows around fast, scrolling huge FireFox websites, etc.) it crashed.
The only difference to my last tests is that I have not connected the old pyra prototype hardware to the expansion connector and I use the official omap5-uevm.dts which does not enable any MIPI output or loads drivers for pyra peripherals.
Could you give a quick information what you changed in the kernel (I don't want to read through the whole instructions)?
What's the difference that it suddenly works but always crashed for you before?
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It is a quite complex circuit (schematics pages 10 and 16). But look at Figure 6 on page 20 of omap5432-ref-swcu130.pdf. The wrong conclusion is that this load switch and input voltage detect has anything to do with powering the OMAP5. The Palmas is powered from VSY_BRD, i.e. the output of U7 (TPS54426) which is *not* switched at all. DC_5V outputs are for the USB ports and HDMI.
Hm. However, we have at least 3 users confirming that using 5V always crashed and 12V worked rock stable. Me, aTc and Roy.
It seems to be unstable when running directly from jack input.
According to this analysis it shouldn't be less or more stable with either input because all power to OMAP5, twl6040 and WLAN runs through this U7 which just gets different input supply. In other words: this does not explain any difference between 5V and 12V operation.
Well, but ther has to be one :)
The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5? What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
Well, the Pyra also has a SMPS between power source and the 3.7V system voltage which may even be active in battery mode under certain low-voltage situations. So both EVM and Pyra are essentially operated from a 3.7V "Battery" if you connect an external power supply.
On the EVM it is a TPS54426 to make 5-15V to 3.7V On the Pyra it is a bq24297 to make 5V to 3.7V
There are two significant differences between these chips:
- maximum current
TPS54426: 4A bq24297: 3A
But this must be sufficient according to all we know. And the bq24297 is also rated 3A for battery operation.
What I can't tell is if the "load transient response" is comparable.
I ran some tests today, and apparently, the power supply makes HUGE differences on the Pyra.
I'll send the results within the next few minutes.
- while the TPS54426 is completely hard-wired the bq24297 has an USB
power supply detection logic which tries to find out what the current limit of the power supply is. This depends on some resistors built into the USB plug of the USB power supply cable.
This detection might differ between different power supplies and cables.
There is a nice Table 2 how this detecftion works: http://www.ti.com/lit/ds/symlink/bq24297.pdf
So this means that a power supply can throttle down the current going into a Pyra below the minimum the Pyra needs. This is something we can't easily modify without violating USB standards.
This is the reason why I have patched the boot loader to write to the bq24297 to immediately increase the input current limit to 2A if no battery is detected.
So the battery charging mode only works when a battery is in... okay.
Note: for battery operation such a limit does not exist.
What does the charger chip do if it has a battery in? Grab as much power as possible?
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
One significant difference is that a power supply at 12 V needs a lower current rating and precision as a 5V supply.
Which would mean that we need more capacitors in the Pyra?
So in summary I think we still need a different explanation for the 1.5GHz problems (we should soon know for the Pyra if the SMPS3 modification solves it), and the boot from USB power on Pyra some people have with some power supplies.
I was not talking about the 1.5GHz issue right now, but more of the instability the EVM and the Pyra has running with 5V.
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
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
Hi,
Am 18.09.2016 um 16:45 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sat, 17 Sep 2016 19:05:37 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
BTW: I have built a completely new SD card with Debian Jessie 8.6 and letux-4.8-rc6 kernel today according to the instructions I sent yesterday and the EVM runs and runs and runs. It runs at full 1.5GHz at ca. 100°C from my 5V 2A power supply (a different model and brand than the one used for the Pyra!).
Have you just run some tests or used it? For me, it always booted fine with 5V 2A, but as soon as I started to use X heavily (moving windows around fast, scrolling huge FireFox websites, etc.) it crashed.
Is running the high-power script for >2 hours enough?
Last time I tested I could not even run apt-get update.
The only difference to my last tests is that I have not connected the old pyra prototype hardware to the expansion connector and I use the official omap5-uevm.dts which does not enable any MIPI output or loads drivers for pyra peripherals.
Could you give a quick information what you changed in the kernel (I don't want to read through the whole instructions)?
Nothing.
What's the difference that it suddenly works but always crashed for you before?
Just tested three days later...
Well, I also used a newly build SD-card and upgraded to Jessie 8.6.
And one (maybe significant) difference. If I remember correctly I did have the only Pyra 4.9 main board and display board with all MIPI stuff connected. While currently it is unplugged because it has a problem with I2C2.
So this instability on EVM could be by a defective old board which had been working before.
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It is a quite complex circuit (schematics pages 10 and 16). But look at Figure 6 on page 20 of omap5432-ref-swcu130.pdf. The wrong conclusion is that this load switch and input voltage detect has anything to do with powering the OMAP5. The Palmas is powered from VSY_BRD, i.e. the output of U7 (TPS54426) which is *not* switched at all. DC_5V outputs are for the USB ports and HDMI.
Hm. However, we have at least 3 users confirming that using 5V always crashed and 12V worked rock stable. Me, aTc and Roy.
Yes, I don't doubt that.
It seems to be unstable when running directly from jack input.
According to this analysis it shouldn't be less or more stable with either input because all power to OMAP5, twl6040 and WLAN runs through this U7 which just gets different input supply. In other words: this does not explain any difference between 5V and 12V operation.
Well, but ther has to be one :)
There is one (see below).
12 V can break down by 50% to 6V and is still above 4.5V, while 5V can only go down by 10% to potentially 4.5V.
So there is more margin.
The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5? What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
Well, the Pyra also has a SMPS between power source and the 3.7V system voltage which may even be active in battery mode under certain low-voltage situations. So both EVM and Pyra are essentially operated from a 3.7V "Battery" if you connect an external power supply.
On the EVM it is a TPS54426 to make 5-15V to 3.7V On the Pyra it is a bq24297 to make 5V to 3.7V
There are two significant differences between these chips:
- maximum current
TPS54426: 4A bq24297: 3A
But this must be sufficient according to all we know. And the bq24297 is also rated 3A for battery operation.
What I can't tell is if the "load transient response" is comparable.
I ran some tests today, and apparently, the power supply makes HUGE differences on the Pyra.
I'll send the results within the next few minutes.
Ok.
- while the TPS54426 is completely hard-wired the bq24297 has an USB
power supply detection logic which tries to find out what the current limit of the power supply is. This depends on some resistors built into the USB plug of the USB power supply cable.
This detection might differ between different power supplies and cables.
There is a nice Table 2 how this detecftion works: http://www.ti.com/lit/ds/symlink/bq24297.pdf
So this means that a power supply can throttle down the current going into a Pyra below the minimum the Pyra needs. This is something we can't easily modify without violating USB standards.
This is the reason why I have patched the boot loader to write to the bq24297 to immediately increase the input current limit to 2A if no battery is detected.
So the battery charging mode only works when a battery is in... okay.
Note: for battery operation such a limit does not exist.
What does the charger chip do if it has a battery in? Grab as much power as possible?
No, as much as the USB charger allows it to grab. This is USB standard.
What we don't know is how well the power supplies comply to the USB standard.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
One significant difference is that a power supply at 12 V needs a lower current rating and precision as a 5V supply.
Which would mean that we need more capacitors in the Pyra?
No. I mean this 50% vs. 10% thing and 10 Watt @5V is 2A while a 12V 1A power supply has more.
So overpowering is always good.
But does not help us to know if we want to operate the Pyra with USB power supplies.
Anyways, this is only relevant for running without battery. With battery we must only make sure that the battery is charging if the Pyra does not draw more power than the power supply can provide.
So in summary I think we still need a different explanation for the 1.5GHz problems (we should soon know for the Pyra if the SMPS3 modification solves it), and the boot from USB power on Pyra some people have with some power supplies.
I was not talking about the 1.5GHz issue right now, but more of the instability the EVM and the Pyra has running with 5V.
Which I only see at 1.5GHz for the Pyra.
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
Looks like it's been happening now for past few months with mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
On igepv5 I can compile kernels no problem, but on omap5-uevm things fast hang if I do:
$ dd if=/dev/urandom of=/dev/null & $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
If I comment out the 1.5GHz mode in the dts file it behaves I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
I did update bootloader to the mainline u-boot recently on my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
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
-- 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
Hi,
if somebody could share an SD image (or at least all the boot files, to eliminate any possible bootloader/MLO differences) 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.
Gražvydas
On Sun, Sep 18, 2016 at 6:15 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 18.09.2016 um 16:45 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sat, 17 Sep 2016 19:05:37 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
BTW: I have built a completely new SD card with Debian Jessie 8.6 and letux-4.8-rc6 kernel today according to the instructions I sent yesterday and the EVM runs and runs and runs. It runs at full 1.5GHz at ca. 100°C from my 5V 2A power supply (a different model and brand than the one used for the Pyra!).
Have you just run some tests or used it? For me, it always booted fine with 5V 2A, but as soon as I started to use X heavily (moving windows around fast, scrolling huge FireFox websites, etc.) it crashed.
Is running the high-power script for >2 hours enough?
Last time I tested I could not even run apt-get update.
The only difference to my last tests is that I have not connected the old pyra prototype hardware to the expansion connector and I use the official omap5-uevm.dts which does not enable any MIPI output or loads drivers for pyra peripherals.
Could you give a quick information what you changed in the kernel (I don't want to read through the whole instructions)?
Nothing.
What's the difference that it suddenly works but always crashed for you before?
Just tested three days later...
Well, I also used a newly build SD-card and upgraded to Jessie 8.6.
And one (maybe significant) difference. If I remember correctly I did have the only Pyra 4.9 main board and display board with all MIPI stuff connected. While currently it is unplugged because it has a problem with I2C2.
So this instability on EVM could be by a defective old board which had been working before.
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It is a quite complex circuit (schematics pages 10 and 16). But look at Figure 6 on page 20 of omap5432-ref-swcu130.pdf. The wrong conclusion is that this load switch and input voltage detect has anything to do with powering the OMAP5. The Palmas is powered from VSY_BRD, i.e. the output of U7 (TPS54426) which is *not* switched at all. DC_5V outputs are for the USB ports and HDMI.
Hm. However, we have at least 3 users confirming that using 5V always crashed and 12V worked rock stable. Me, aTc and Roy.
Yes, I don't doubt that.
It seems to be unstable when running directly from jack input.
According to this analysis it shouldn't be less or more stable with either input because all power to OMAP5, twl6040 and WLAN runs through this U7 which just gets different input supply. In other words: this does not explain any difference between 5V and 12V operation.
Well, but ther has to be one :)
There is one (see below).
12 V can break down by 50% to 6V and is still above 4.5V, while 5V can only go down by 10% to potentially 4.5V.
So there is more margin.
The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5? What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
Well, the Pyra also has a SMPS between power source and the 3.7V system voltage which may even be active in battery mode under certain low-voltage situations. So both EVM and Pyra are essentially operated from a 3.7V "Battery" if you connect an external power supply.
On the EVM it is a TPS54426 to make 5-15V to 3.7V On the Pyra it is a bq24297 to make 5V to 3.7V
There are two significant differences between these chips:
- maximum current
TPS54426: 4A bq24297: 3A
But this must be sufficient according to all we know. And the bq24297 is also rated 3A for battery operation.
What I can't tell is if the "load transient response" is comparable.
I ran some tests today, and apparently, the power supply makes HUGE differences on the Pyra.
I'll send the results within the next few minutes.
Ok.
- while the TPS54426 is completely hard-wired the bq24297 has an USB
power supply detection logic which tries to find out what the current limit of the power supply is. This depends on some resistors built into the USB plug of the USB power supply cable.
This detection might differ between different power supplies and cables.
There is a nice Table 2 how this detecftion works: http://www.ti.com/lit/ds/symlink/bq24297.pdf
So this means that a power supply can throttle down the current going into a Pyra below the minimum the Pyra needs. This is something we can't easily modify without violating USB standards.
This is the reason why I have patched the boot loader to write to the bq24297 to immediately increase the input current limit to 2A if no battery is detected.
So the battery charging mode only works when a battery is in... okay.
Note: for battery operation such a limit does not exist.
What does the charger chip do if it has a battery in? Grab as much power as possible?
No, as much as the USB charger allows it to grab. This is USB standard.
What we don't know is how well the power supplies comply to the USB standard.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
One significant difference is that a power supply at 12 V needs a lower current rating and precision as a 5V supply.
Which would mean that we need more capacitors in the Pyra?
No. I mean this 50% vs. 10% thing and 10 Watt @5V is 2A while a 12V 1A power supply has more.
So overpowering is always good.
But does not help us to know if we want to operate the Pyra with USB power supplies.
Anyways, this is only relevant for running without battery. With battery we must only make sure that the battery is charging if the Pyra does not draw more power than the power supply can provide.
So in summary I think we still need a different explanation for the 1.5GHz problems (we should soon know for the Pyra if the SMPS3 modification solves it), and the boot from USB power on Pyra some people have with some power supplies.
I was not talking about the 1.5GHz issue right now, but more of the instability the EVM and the Pyra has running with 5V.
Which I only see at 1.5GHz for the Pyra.
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
Hi Tony,
> Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com: > > Hi, > > So what was the root cause of the 1.5GHz mode issue on Pyra?
Well, we do not really know and have not solved it.
One issue we have found is that the feedback line of SMPS3 is wired up wrongly which should be floating according to Palmas data sheet but is connected.
So we think that SMPS1+2+3 runs into problems when switching to triple mode. Which it probably only does at the 1.5GHz OPP because power demand raises significantly.
This is a real hardware bug in the Pyra CPU board but production of a corrected PCB has just started today. So we will need some 2-4 weeks until we can check and compare.
OK
> Looks like it's been happening now for past few months with > mainline kernel on omap5-uevm.. Does not happen on igepv5.
Yes, that is what I also observe. I have tried today to boot my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot attempts.
When it boots, I can work for some time but an apt-get update did make it hang during the % completion display (where both cores are fully active to scan the package database).
This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
> On igepv5 I can compile kernels no problem, but on omap5-uevm > things fast hang if I do: > > $ dd if=/dev/urandom of=/dev/null & > $ dd if=/dev/urandom of=/dev/null &
I have a test script which also prints CPU/GPU temperatures which can rise quite quickly:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature...
I haven't run it recently but can to tomorrow.
OK
> If I comment out the 1.5GHz mode in the dts file it behaves > I think.
Yes, I have the same observation on Pyra. I did try to reduce the 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it did run completely stable.
OK
Interestingly it seems as if I am the only one with such problems on the uevm. Other Pyra developers with an uevm did not confirm it.
I'm pretty sure things were working fine for me until June this year.
> I did update bootloader to the mainline u-boot recently on > my uvem.
Do we have an idea what the last version w/o problems is? Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
I might still have some working uImages where the oldest one with OMAP5 support being the 4.1 kernel:
http://download.goldelico.com/letux-kernel/
If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
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
-- 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
Hi,
Am 19.09.2016 um 11:39 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
if somebody could share an SD image (or at least all the boot files, to eliminate any possible bootloader/MLO differences)
DEV=/dev/sdd ./makesd omap5432evm -f1 -b OMAP5432-uEVM/2016-05-10 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 xfce
generates a complete bootable 2 partition SD card and is what I have currently (last 2-3 days) running on the EVM.
download makesd: see http://projects.goldelico.com/p/gta04-makesd/
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.
BR and thanks, Nikolaus
Gražvydas
On Sun, Sep 18, 2016 at 6:15 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 18.09.2016 um 16:45 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sat, 17 Sep 2016 19:05:37 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
As mentioned, some users at IRC with the EVM don't have any issues with the EVM and more recent kernels.
BTW: I have built a completely new SD card with Debian Jessie 8.6 and letux-4.8-rc6 kernel today according to the instructions I sent yesterday and the EVM runs and runs and runs. It runs at full 1.5GHz at ca. 100°C from my 5V 2A power supply (a different model and brand than the one used for the Pyra!).
Have you just run some tests or used it? For me, it always booted fine with 5V 2A, but as soon as I started to use X heavily (moving windows around fast, scrolling huge FireFox websites, etc.) it crashed.
Is running the high-power script for >2 hours enough?
Last time I tested I could not even run apt-get update.
The only difference to my last tests is that I have not connected the old pyra prototype hardware to the expansion connector and I use the official omap5-uevm.dts which does not enable any MIPI output or loads drivers for pyra peripherals.
Could you give a quick information what you changed in the kernel (I don't want to read through the whole instructions)?
Nothing.
What's the difference that it suddenly works but always crashed for you before?
Just tested three days later...
Well, I also used a newly build SD-card and upgraded to Jessie 8.6.
And one (maybe significant) difference. If I remember correctly I did have the only Pyra 4.9 main board and display board with all MIPI stuff connected. While currently it is unplugged because it has a problem with I2C2.
So this instability on EVM could be by a defective old board which had been working before.
So that means, if you use 5V, you most probably have U4 enabled whereas everyone who runs at 12V has U18 enabled (which uses SMPS 5V output instead of direct Jack input).
It is a quite complex circuit (schematics pages 10 and 16). But look at Figure 6 on page 20 of omap5432-ref-swcu130.pdf. The wrong conclusion is that this load switch and input voltage detect has anything to do with powering the OMAP5. The Palmas is powered from VSY_BRD, i.e. the output of U7 (TPS54426) which is *not* switched at all. DC_5V outputs are for the USB ports and HDMI.
Hm. However, we have at least 3 users confirming that using 5V always crashed and 12V worked rock stable. Me, aTc and Roy.
Yes, I don't doubt that.
It seems to be unstable when running directly from jack input.
According to this analysis it shouldn't be less or more stable with either input because all power to OMAP5, twl6040 and WLAN runs through this U7 which just gets different input supply. In other words: this does not explain any difference between 5V and 12V operation.
Well, but ther has to be one :)
There is one (see below).
12 V can break down by 50% to 6V and is still above 4.5V, while 5V can only go down by 10% to potentially 4.5V.
So there is more margin.
The igepv5 doesn't have that issue - so something is different here. Could it be that the power is filtered better on the igepv5? What we've found out on the Pyra is that it runs A LOT more stable with a battery. I guess the battery provides a more stable power source than some random USB AC adaptor.
Well, the Pyra also has a SMPS between power source and the 3.7V system voltage which may even be active in battery mode under certain low-voltage situations. So both EVM and Pyra are essentially operated from a 3.7V "Battery" if you connect an external power supply.
On the EVM it is a TPS54426 to make 5-15V to 3.7V On the Pyra it is a bq24297 to make 5V to 3.7V
There are two significant differences between these chips:
- maximum current
TPS54426: 4A bq24297: 3A
But this must be sufficient according to all we know. And the bq24297 is also rated 3A for battery operation.
What I can't tell is if the "load transient response" is comparable.
I ran some tests today, and apparently, the power supply makes HUGE differences on the Pyra.
I'll send the results within the next few minutes.
Ok.
- while the TPS54426 is completely hard-wired the bq24297 has an USB
power supply detection logic which tries to find out what the current limit of the power supply is. This depends on some resistors built into the USB plug of the USB power supply cable.
This detection might differ between different power supplies and cables.
There is a nice Table 2 how this detecftion works: http://www.ti.com/lit/ds/symlink/bq24297.pdf
So this means that a power supply can throttle down the current going into a Pyra below the minimum the Pyra needs. This is something we can't easily modify without violating USB standards.
This is the reason why I have patched the boot loader to write to the bq24297 to immediately increase the input current limit to 2A if no battery is detected.
So the battery charging mode only works when a battery is in... okay.
Note: for battery operation such a limit does not exist.
What does the charger chip do if it has a battery in? Grab as much power as possible?
No, as much as the USB charger allows it to grab. This is USB standard.
What we don't know is how well the power supplies comply to the USB standard.
So maybe it's a hardware issue of the EVM, which runs unstable whenever rail DC_5V is powered directly from the input jack and NOT from SMPS 5V output.
One significant difference is that a power supply at 12 V needs a lower current rating and precision as a 5V supply.
Which would mean that we need more capacitors in the Pyra?
No. I mean this 50% vs. 10% thing and 10 Watt @5V is 2A while a 12V 1A power supply has more.
So overpowering is always good.
But does not help us to know if we want to operate the Pyra with USB power supplies.
Anyways, this is only relevant for running without battery. With battery we must only make sure that the battery is charging if the Pyra does not draw more power than the power supply can provide.
So in summary I think we still need a different explanation for the 1.5GHz problems (we should soon know for the Pyra if the SMPS3 modification solves it), and the boot from USB power on Pyra some people have with some power supplies.
I was not talking about the 1.5GHz issue right now, but more of the instability the EVM and the Pyra has running with 5V.
Which I only see at 1.5GHz for the Pyra.
- H. Nikolaus Schaller hns@goldelico.com [160914 13:32]:
> Hi Tony, > >> Am 14.09.2016 um 21:43 schrieb Tony Lindgren tony@atomide.com: >> >> Hi, >> >> So what was the root cause of the 1.5GHz mode issue on Pyra? > > Well, we do not really know and have not solved it. > > One issue we have found is that the feedback line of SMPS3 > is wired up wrongly which should be floating according to > Palmas data sheet but is connected. > > So we think that SMPS1+2+3 runs into problems when switching > to triple mode. Which it probably only does at the 1.5GHz OPP > because power demand raises significantly. > > This is a real hardware bug in the Pyra CPU board but production > of a corrected PCB has just started today. So we will need some > 2-4 weeks until we can check and compare.
OK
>> Looks like it's been happening now for past few months with >> mainline kernel on omap5-uevm.. Does not happen on igepv5. > > Yes, that is what I also observe. I have tried today to boot > my uevm with letux-4.8-rc6 and it hangs on ~70% of all boot > attempts. > > When it boots, I can work for some time but an apt-get update > did make it hang during the % completion display (where both > cores are fully active to scan the package database). > > This seems to be exactly the same symptom as for the Pyra.
OK yeah that's what I'm seeing too.
>> On igepv5 I can compile kernels no problem, but on omap5-uevm >> things fast hang if I do: >> >> $ dd if=/dev/urandom of=/dev/null & >> $ dd if=/dev/urandom of=/dev/null & > > I have a test script which also prints CPU/GPU temperatures > which can rise quite quickly: > > http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/high-load;h... > http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Letux/root/temperature... > > I haven't run it recently but can to tomorrow.
OK
>> If I comment out the 1.5GHz mode in the dts file it behaves >> I think. > > Yes, I have the same observation on Pyra. I did try to reduce the > 1.5Ghz frequency and noticed failure above 1.2GHz. At 1.0GHz it > did run completely stable.
OK
> Interestingly it seems as if I am the only one with such problems > on the uevm. Other Pyra developers with an uevm did not confirm > it.
I'm pretty sure things were working fine for me until June this year.
>> I did update bootloader to the mainline u-boot recently on >> my uvem. > > > Do we have an idea what the last version w/o problems is? > Or does the latest TI or Robert Nelson kernel work?
I downgraded my bootloader to be same as on igepv5, and I'm still seeing hangs. Maybe not so often though?
> I might still have some working uImages where the oldest one > with OMAP5 support being the 4.1 kernel: > > http://download.goldelico.com/letux-kernel/ > > If I find time, I will try to boot that.
I'm now wondering if we've had some kernel regression from around May or June.
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
-- 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
* 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
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
Am Mon, 19 Sep 2016 12:14:04 -0400 hat Roy Gillotti gillottir@gmail.com geschrieben:
Hi Roy,
thanks for the comprehensive test! This is quite interesting!
I didn't know the EVM even has a 5V LED, but thanks to that, two things are pretty clear here:
* 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).
* The voltage probably drops below 5.6V when you provide 6.2V and there is a high current draw
So the questions are:
* What has the 5V switch to do with the power supply of the OMAP5? Why does it run unstable? VSys is even lower than 5V, so what's going on there?
* Does the igepv5 have the same issue? If not: What's different there?
* Is that a hardware bug of the EVM or a problem with the OMAP5?
* Is that switch between the two modes controllable by software? Meaning: Can we disable that the EVM switches into that special 5V mode?
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
Am 20.09.2016 um 02:22 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 19 Sep 2016 12:14:04 -0400 hat Roy Gillotti gillottir@gmail.com geschrieben:
Hi Roy,
thanks for the comprehensive test! This is quite interesting!
I didn't know the EVM even has a 5V LED, but thanks to that, two things are pretty clear here:
- 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.
- The voltage probably drops below 5.6V when you provide 6.2V and there
is a high current draw
So the questions are:
- What has the 5V switch to do with the power supply of the OMAP5?
Nothing.
Except one thing: if there are power sinks at the USB ports which draw high current, switching might make glitches on the DC input.
But I don't see how this should affect OMAP operation.
Unless we assume that the USB stack is unstable, i.e. if connected devices behave erratically if voltage is noisy.
BTW: I have nothing connected to USB or HDMI in my tests where the EVM runs stable from 5V.
Why does it run unstable? VSys is even lower than 5V, so what's going on there?
Does the igepv5 have the same issue? If not: What's different there?
Is that a hardware bug of the EVM or a problem with the OMAP5?
I tend to think it is an EVM specific effect. Pyra does not have this switch circuit at all.
Unfortunately I have no IGEP5 circuit diagram to compare.
- Is that switch between the two modes controllable by software?
Meaning: Can we disable that the EVM switches into that special 5V mode?
No software control.
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.
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
On September 20, 2016 7:45:01 AM GMT+02:00, "H. Nikolaus Schaller"
hns@goldelico.com wrote:
- 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!
- What has the 5V switch to do with the power supply of the OMAP5?
Nothing.
That nothing seems to have a high impact regarding stability ;)
Except one thing: if there are power sinks at the USB ports which draw high current, switching might make glitches on the DC input. But I don't see how this should affect OMAP operation.
That theory has one problem: It doesn't crash while switching. If voltage you feed the EVM with is below 5.6V, it ALWAYS runs in that special 5V mode without any switching happening.
So it seems to have something to do with that mode, not with the switching.
What's interesting though: As it runs stable for you (without using HDMI or USB), it probably doesn't have anything to do with the AC adapter breaking down because of a too high power consumption. HDMI should not use as much power as running the OMAP5 with full power for a while!
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.
So why does simply using HDMI make the board run unstable, but only in that 5V mode?
- Is that a hardware bug of the EVM or a problem with the OMAP5?
I tend to think it is an EVM specific effect. Pyra does not have this switch circuit at all.
Does that mean the Pyra always run similar to the 5V mode or rather to the more than 5.6V mode (using SMPS)
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?
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
Hi,
Am 20.09.2016 um 16:29 schrieb Michael Mrozek EvilDragon@openpandora.org:
On September 20, 2016 7:45:01 AM GMT+02:00, "H. Nikolaus Schaller"
hns@goldelico.com wrote:
- 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.
Recent and current tests I have done were w/o HDMI and USB devices but the old Pyra Mainboard + a Displayboard.
Anyways my kernel hangs on the EVM are gone :(
In other words: I was not able to reproduce them so far. Even with the same 5V 2A power supply as before...
Running for hours at 200% CPU load. Or doing heavy apt-get update.
- What has the 5V switch to do with the power supply of the OMAP5?
Nothing.
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.
Except one thing: if there are power sinks at the USB ports which draw high current, switching might make glitches on the DC input. But I don't see how this should affect OMAP operation.
That theory has one problem: It doesn't crash while switching. If voltage you feed the EVM with is below 5.6V, it ALWAYS runs in that special 5V mode without any switching happening.
Yes. 5V in goes only through the switch chip to 5V out.
So it seems to have something to do with that mode, not with the switching.
What's interesting though: As it runs stable for you (without using HDMI or USB), it probably doesn't have anything to do with the AC adapter breaking down because of a too high power consumption. HDMI should not use as much power as running the OMAP5 with full power for a while!
Indeed.
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.
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.
- Is that a hardware bug of the EVM or a problem with the OMAP5?
I tend to think it is an EVM specific effect. Pyra does not have this switch circuit at all.
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).
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.
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.
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.
BR, Nikolaus
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.
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 :(
Well, WITHOUT any DSS device attached, which could be the clue!
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. 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? 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).
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).
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?
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 also do wonder whether some part on the mainboard could mess up the MIPI signal (EMV-Issue?)
But then again: Then it would be unstable later on as well - but it seems to work without any issues once it has been properly initialized.
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.
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
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
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
here are new test results from
* EVM @5V 2A * Kernel letux-4.8-rc7 (not yet published) * Ethernet connected and active * USB-memory stick plugged in. * Runs ./high-load but not other activities (except networking daemons like nntpd, blinking LEDs)
1. omap5-uevm+pyra4.dtb, Pyra Mainboard V4 connected, Panel with SSD2858 connected (working incl. rotation)
root@letux:~# ./high-load Tue Sep 20 14:53:41 UTC 2016 51672 54868 50600 Tue Sep 20 14:53:43 UTC 2016 51672 54421 51000 Tue Sep 20 14:53:45 UTC 2016 65304 57996 55400 Tue Sep 20 14:53:46 UTC 2016 67860 60118 57800 Tue Sep 20 14:53:48 UTC 2016 70416 62017 59400 Tue Sep 20 14:53:49 UTC 2016 70842 63357 60200 Tue Sep 20 14:53:51 UTC 2016 72120 64698 61000 Tue Sep 20 14:53:53 UTC 2016 72120 64251 61000 Tue Sep 20 14:53:54 UTC 2016 72120 65145 61800 Tue Sep 20 14:53:56 UTC 2016 73398 65591 61800 Tue Sep 20 14:53:57 UTC 2016 74356 66485 62200 Tue Sep 20 14:53:59 UTC 2016 73824 66038 62600 Tue Sep 20 14:54:01 UTC 2016 74356 66932 63000 Tue Sep 20 14:54:02 UTC 2016 73824 67379 63400 Tue Sep 20 14:54:04 UTC 2016 74995 66932 63800 Tue Sep 20 14:54:05 UTC 2016 74356 66932 63800 Tue Sep 20 14:54:07 UTC 2016 74995 67379 63800 Tue Sep 20 14:54:09 UTC 2016 74995 68272 64200 Tue Sep 20 14:54:10 UTC 2016 74995 68272 64200 Tue Sep 20 14:54:12 UTC 2016 75954 68272 64600
It took 31 seconds to reach 75°C.
did hang after 48 minutes
Tue Sep 20 15:41:12 UTC 2016 99810 92399 86600 Tue Sep 20 15:41:14 UTC 2016 100236 91953 86200 Tue Sep 20 15:41:16 UTC 2016 99384 92399 86200 Tue Sep 20 15:41:17 UTC 2016 100236 92846 86600 Tue Sep 20 15:41:19 UTC 2016 100236 92846 86600 Tue Sep 20 15:41:21 UTC 2016 91290 90165 83800 Tue Sep 20 15:41:22 UTC 2016 89160 89272 82200 Tue Sep 20 15:41:24 UTC 2016 98532 91506 85000 Tue Sep 20 15:41:25 UTC 2016 98532 91953 85000 Tue Sep 20 15:41:27 UTC 2016 98532 91953 85000 Tue Sep 20 15:41:29 UTC 2016 98958 91953 85000 Tue Sep 20 15:41:30 UTC 2016 99810 91953 86200 Tue Sep 20 15:41:32 UTC 2016 99810 92846 86200 Tue Sep 20 15:41:33 UTC 2016 100236 91953 86200 Tue Sep 20 15:41:35 UTC 2016 100662 92399 86200 Tue Sep 20 15:41:37 UTC 2016 100236 92399 85800 Tue Sep 20 15:41:38 UTC 2016 100236 92846 85800 Tue Sep 20 15:41:40 UTC 2016 100662 92846 86600
Intersting are the temperature sawtooth cycles! With approx. 10-20 seconds cycle time. Which means that the internal over-temperature protection is activated, something cools down and heats up again.
One thing I had never seen is that temperature rises beyond 100°C and the thermo-shutdown does not happen any more!
Who is limiting the CPU temperature to 100°C? Some kernel mechanism?
2. omap5-uevm+pyra4.dtb, Pyra Mainboard V4 disconnected, Panel with SSD2858 connected (not working)
Did run for 2 hours w/o hanging.
root@letux:~# ./high-load Tue Sep 20 16:17:52 UTC 2016 49968 53975 50200 Tue Sep 20 16:17:54 UTC 2016 54228 53975 50600 Tue Sep 20 16:17:56 UTC 2016 64878 57996 55400 Tue Sep 20 16:17:57 UTC 2016 67008 60677 57000 Tue Sep 20 16:17:59 UTC 2016 67008 60677 57000 Tue Sep 20 16:18:00 UTC 2016 68286 62017 57800 Tue Sep 20 16:18:02 UTC 2016 69990 62464 59000 Tue Sep 20 16:18:03 UTC 2016 70416 62911 59400 Tue Sep 20 16:18:05 UTC 2016 70842 63357 60200 Tue Sep 20 16:18:07 UTC 2016 70842 63804 60600 Tue Sep 20 16:18:08 UTC 2016 71694 64251 60600 Tue Sep 20 16:18:10 UTC 2016 72120 64698 60600 Tue Sep 20 16:18:11 UTC 2016 72120 64698 61400 Tue Sep 20 16:18:13 UTC 2016 72972 65145 61400 Tue Sep 20 16:18:15 UTC 2016 73398 65145 62200 Tue Sep 20 16:18:16 UTC 2016 72972 66485 61800 Tue Sep 20 16:18:18 UTC 2016 74356 66038 62200 Tue Sep 20 16:18:19 UTC 2016 73824 66038 62600 Tue Sep 20 16:18:21 UTC 2016 73824 66932 62600 Tue Sep 20 16:18:23 UTC 2016 74356 66932 63000 Tue Sep 20 16:18:24 UTC 2016 74356 66485 63400 Tue Sep 20 16:18:26 UTC 2016 74356 67379 63800 Tue Sep 20 16:18:27 UTC 2016 74356 67825 64200 Tue Sep 20 16:18:29 UTC 2016 74995 67379 63400 Tue Sep 20 16:18:31 UTC 2016 74995 67825 63800 Tue Sep 20 16:18:32 UTC 2016 75528 67379 64200
Here it took 40 seconds to reach 75°C.
ca. 17 minutes after starting high-load:
Tue Sep 20 16:34:24 UTC 2016 98532 91506 85400 Tue Sep 20 16:34:25 UTC 2016 98958 91953 85400 Tue Sep 20 16:34:27 UTC 2016 98958 91059 84600 Tue Sep 20 16:34:28 UTC 2016 98958 91059 85000 Tue Sep 20 16:34:30 UTC 2016 99384 91953 85400 Tue Sep 20 16:34:32 UTC 2016 98958 91506 85400 Tue Sep 20 16:34:33 UTC 2016 98958 91059 85000
Interestingly, the CPU-Temperature remained almost constant here! And did not (yet) run into protection. No sawtooth.
Some time later sawtooths started but slower than in scenario. Ca. 1 minute.
2 hours later...
Tue Sep 20 18:13:00 UTC 2016 99384 91953 85800 Tue Sep 20 18:13:02 UTC 2016 98958 92399 85800 Tue Sep 20 18:13:04 UTC 2016 99810 91953 85400 Tue Sep 20 18:13:05 UTC 2016 99384 91953 85800 Tue Sep 20 18:13:07 UTC 2016 99810 91953 85800 Tue Sep 20 18:13:08 UTC 2016 100236 91953 85800 Tue Sep 20 18:13:10 UTC 2016 99810 92399 85800 Tue Sep 20 18:13:12 UTC 2016 100236 91953 85800 ^Ckill 2566 2567
root@letux:~#
So this means that really running MIPI/DSS makes the OMAP draw more power. So that it heats up faster.
And generally this draw less power than scenario 1.
3. omap5-uevm.dtb, Pyra Mainboard V4 disconnected, Panel with SSD2858 connected (not working)
root@letux:~# ./high-load Tue Sep 20 18:33:03 UTC 2016 41874 45150 41800 Tue Sep 20 18:33:05 UTC 2016 41874 45150 43100 Tue Sep 20 18:33:07 UTC 2016 56358 48166 47000 Tue Sep 20 18:33:09 UTC 2016 58914 50847 49000 Tue Sep 20 18:33:10 UTC 2016 60618 52187 50600 Tue Sep 20 18:33:12 UTC 2016 61470 53081 50200 Tue Sep 20 18:33:14 UTC 2016 61896 53975 51000 Tue Sep 20 18:33:15 UTC 2016 62748 53528 52200 Tue Sep 20 18:33:17 UTC 2016 63174 54868 52600 Tue Sep 20 18:33:19 UTC 2016 64026 54868 53800 Tue Sep 20 18:33:21 UTC 2016 64026 57102 54200 Tue Sep 20 18:33:22 UTC 2016 64452 57102 54200 Tue Sep 20 18:33:24 UTC 2016 65304 57102 54200 Tue Sep 20 18:33:26 UTC 2016 65304 57102 55000 Tue Sep 20 18:33:28 UTC 2016 65304 57549 55000 Tue Sep 20 18:33:29 UTC 2016 65304 57996 55400 Tue Sep 20 18:33:31 UTC 2016 66156 58443 55900 Tue Sep 20 18:33:33 UTC 2016 66156 59448 55900 Tue Sep 20 18:33:34 UTC 2016 66582 58889 55900 Tue Sep 20 18:33:36 UTC 2016 66582 59448 56500 Tue Sep 20 18:33:38 UTC 2016 67434 59448 55900 Tue Sep 20 18:33:40 UTC 2016 67434 59448 56500 Tue Sep 20 18:33:41 UTC 2016 67434 60677 57800 Tue Sep 20 18:33:43 UTC 2016 68286 61570 58200 Tue Sep 20 18:33:45 UTC 2016 67860 61123 58200 Tue Sep 20 18:33:47 UTC 2016 67860 61570 58600 Tue Sep 20 18:33:48 UTC 2016 68286 61123 58600 Tue Sep 20 18:33:50 UTC 2016 69564 61570 58600 Tue Sep 20 18:33:52 UTC 2016 68286 62464 58600 Tue Sep 20 18:33:54 UTC 2016 69564 62464 58600 Tue Sep 20 18:33:55 UTC 2016 68712 62017 59000 Tue Sep 20 18:33:57 UTC 2016 70842 62464 59800 Tue Sep 20 18:33:59 UTC 2016 70416 62464 59400 Tue Sep 20 18:34:00 UTC 2016 70416 63357 59400 Tue Sep 20 18:34:02 UTC 2016 70842 62911 59800 Tue Sep 20 18:34:04 UTC 2016 70416 62911 59400 Tue Sep 20 18:34:06 UTC 2016 70842 63804 60200 Tue Sep 20 18:34:07 UTC 2016 71694 63357 61000 Tue Sep 20 18:34:09 UTC 2016 71268 64251 60600 Tue Sep 20 18:34:11 UTC 2016 71694 64251 61000 Tue Sep 20 18:34:12 UTC 2016 71268 63357 60600 Tue Sep 20 18:34:14 UTC 2016 72120 64698 61000 Tue Sep 20 18:34:16 UTC 2016 72546 64251 61400 Tue Sep 20 18:34:18 UTC 2016 72972 64698 61800 Tue Sep 20 18:34:19 UTC 2016 73398 65591 61800 Tue Sep 20 18:34:21 UTC 2016 72972 65145 62200 Tue Sep 20 18:34:23 UTC 2016 73398 66038 61800 Tue Sep 20 18:34:24 UTC 2016 73398 65591 62200 Tue Sep 20 18:34:26 UTC 2016 73398 66038 62200 Tue Sep 20 18:34:28 UTC 2016 73824 66038 63000 Tue Sep 20 18:34:30 UTC 2016 73398 66485 63000 Tue Sep 20 18:34:31 UTC 2016 74356 66038 62600 Tue Sep 20 18:34:33 UTC 2016 74356 66038 63000 Tue Sep 20 18:34:35 UTC 2016 73824 66485 63000 Tue Sep 20 18:34:37 UTC 2016 73824 66485 63000 Tue Sep 20 18:34:38 UTC 2016 74356 66932 63800 Tue Sep 20 18:34:40 UTC 2016 74356 66932 64200 Tue Sep 20 18:34:42 UTC 2016 74995 66485 63800 Tue Sep 20 18:34:43 UTC 2016 75528 67379 63800
So it takes 100 seconds to reach 75°C.
Tue Sep 20 19:54:37 UTC 2016 99384 91953 85400 Tue Sep 20 19:54:39 UTC 2016 98958 91506 85800 Tue Sep 20 19:54:40 UTC 2016 99384 91953 85800 Tue Sep 20 19:54:42 UTC 2016 99384 91953 85400 Tue Sep 20 19:54:44 UTC 2016 100236 91506 85400 Tue Sep 20 19:54:46 UTC 2016 99384 91506 85000 Tue Sep 20 19:54:48 UTC 2016 90438 90165 83000 Tue Sep 20 19:54:49 UTC 2016 98106 90165 84600 Tue Sep 20 19:54:51 UTC 2016 98106 90612 84600 Tue Sep 20 19:54:53 UTC 2016 98532 91506 85400 Tue Sep 20 19:54:54 UTC 2016 99384 91059 85000 Tue Sep 20 19:54:56 UTC 2016 98958 91506 85400 Tue Sep 20 19:54:58 UTC 2016 98958 91506 85400 Tue Sep 20 19:55:00 UTC 2016 98958 91059 85400 Tue Sep 20 19:55:01 UTC 2016 98958 91059 85400 Tue Sep 20 19:55:03 UTC 2016 98532 91506 85000 Tue Sep 20 19:55:05 UTC 2016 98532 91953 85400 Tue Sep 20 19:55:07 UTC 2016 98958 91953 85400 Tue Sep 20 19:55:08 UTC 2016 98958 91506 85400 Tue Sep 20 19:55:10 UTC 2016 99384 91059 85400 ^Ckill 2592 2593
root@letux:~#
Did not hang within 1.5 hours.
4. omap5-uevm.dtb, Pyra Mainboard V4 connected, Panel with SSD2858 connected (not working because missing in DT files)
root@letux:~# ./high-load Wed Sep 21 04:39:46 UTC 2016 49116 52634 49400 Wed Sep 21 04:39:48 UTC 2016 49542 53081 48600 Wed Sep 21 04:39:50 UTC 2016 64026 57102 54200 Wed Sep 21 04:39:52 UTC 2016 67008 58889 55900 Wed Sep 21 04:39:53 UTC 2016 67860 60677 57400 Wed Sep 21 04:39:55 UTC 2016 69564 61570 58200 Wed Sep 21 04:39:57 UTC 2016 70842 62464 59800 Wed Sep 21 04:39:59 UTC 2016 70416 63357 59400 Wed Sep 21 04:40:00 UTC 2016 71268 63357 59400 Wed Sep 21 04:40:02 UTC 2016 71694 63804 60200 Wed Sep 21 04:40:04 UTC 2016 71268 63804 61000 Wed Sep 21 04:40:05 UTC 2016 72120 64698 60600 Wed Sep 21 04:40:07 UTC 2016 72120 64698 61000 Wed Sep 21 04:40:09 UTC 2016 72546 64698 61400 Wed Sep 21 04:40:10 UTC 2016 73398 65145 61800 Wed Sep 21 04:40:12 UTC 2016 72972 65145 61800 Wed Sep 21 04:40:14 UTC 2016 73398 65591 62200 Wed Sep 21 04:40:16 UTC 2016 73824 66932 62600 Wed Sep 21 04:40:17 UTC 2016 73824 65591 63000 Wed Sep 21 04:40:19 UTC 2016 73824 66485 63000 Wed Sep 21 04:40:21 UTC 2016 74995 66932 63000 Wed Sep 21 04:40:23 UTC 2016 73824 66932 63800 Wed Sep 21 04:40:24 UTC 2016 74356 67379 63800 Wed Sep 21 04:40:26 UTC 2016 74356 67825 63400 Wed Sep 21 04:40:28 UTC 2016 75954 67825 64200 Wed Sep 21 04:40:29 UTC 2016 75528 67379 63800 Wed Sep 21 04:40:31 UTC 2016 75954 68272 64200 Wed Sep 21 04:40:33 UTC 2016 76380 68272 64200
So that is 42 seconds until 75°C.
Wed Sep 21 06:44:53 UTC 2016 100236 91953 85800 Wed Sep 21 06:44:55 UTC 2016 90438 90165 83400 Wed Sep 21 06:44:56 UTC 2016 89160 88378 81800 Wed Sep 21 06:44:58 UTC 2016 98106 90165 84200 Wed Sep 21 06:45:00 UTC 2016 98532 91059 85000 Wed Sep 21 06:45:01 UTC 2016 98532 90612 85000 Wed Sep 21 06:45:03 UTC 2016 99384 91953 85400 Wed Sep 21 06:45:05 UTC 2016 98958 91953 85400 Wed Sep 21 06:45:06 UTC 2016 98958 91506 85400 Wed Sep 21 06:45:08 UTC 2016 98958 91953 85800 Wed Sep 21 06:45:10 UTC 2016 99810 92399 85800 Wed Sep 21 06:45:12 UTC 2016 99384 91506 85400 Wed Sep 21 06:45:13 UTC 2016 99810 91059 85800 Wed Sep 21 06:45:15 UTC 2016 99810 91953 85400 Wed Sep 21 06:45:17 UTC 2016 99810 91059 85400 Wed Sep 21 06:45:18 UTC 2016 99810 91953 85400 Wed Sep 21 06:45:20 UTC 2016 99810 91953 85800 Wed Sep 21 06:45:22 UTC 2016 99384 91953 85400 Wed Sep 21 06:45:24 UTC 2016 99384 91953 85400 Wed Sep 21 06:45:25 UTC 2016 99810 92399 85400 Wed Sep 21 06:45:27 UTC 2016 99384 92399 85400 Wed Sep 21 06:45:29 UTC 2016 99384 91953 85800 Wed Sep 21 06:45:31 UTC 2016 100236 91953 85000 Wed Sep 21 06:45:32 UTC 2016 89586 89719 82600 Wed Sep 21 06:45:34 UTC 2016 88308 87485 81800 Wed Sep 21 06:45:36 UTC 2016 97254 90165 83800 Wed Sep 21 06:45:38 UTC 2016 98106 90612 84200 Wed Sep 21 06:45:39 UTC 2016 98106 91059 84600 Wed Sep 21 06:45:41 UTC 2016 98958 91506 85000 Wed Sep 21 06:45:43 UTC 2016 98532 91059 85400 ^Ckill 2590 2591
root@letux:~#
Also did run for 2 hours. With approx. 30-40 seconds sawtooth.
A little unexpected is that it appears to suffice to connect the Pyra mainboard (which is not configured by DT but powered by Palmas) to heat up the OMAP faster.
5. Discussion
So this clearly shows that the heat production in the CPU depends on the device tree file and if the mainboard is connected or not.
We have 31 sec with pyra mainboard and pyra DT 40 sec without pyra mainboard and pyra DT 42 sec with pyra mainboard and uevm DT 100 sec without pyra mainboard and uevm DT
This is of course to be expected since the uevm.dtb does not know anything about panels and Pyra peripherals and therefore does not enable anything - and does not have to process polling loops etc.
A key conclusion is that the OMAP5 temperature is not a problem per se.
But if we assume that the scenario 1 has the highest energy consumption, it explains why it is more risky to run into power supply limits. So again we have not gained a really new insight that a too weak power supply makes trouble.
BR, Nikolaus
- Discussion
So this clearly shows that the heat production in the CPU depends on the device tree file and if the mainboard is connected or not.
This is REALLY weird. Why should the OMAP5 produce more heat simply because the mainboard is connected? It doesn't do anything with the additional connected devices if no driver is configured. Unless... could it be that it sees there's something there (like on i2c bus) and it tries to permanently probe that? But then again, it would need to be something that has nothing to do with load, as you're putting the OMAP5 on high load anyways.
We have 31 sec with pyra mainboard and pyra DT
So it heats up three times as fast simply because the mainboard is connected and MIPI is active? That sounds like WAY too much. It shouldn't have much impact.
40 sec without pyra mainboard and pyra DT
Wow! Still twice as fast. Some bug with the DT file maybe?
42 sec with pyra mainboard and uevm DT
... combined with something that the mainboard does?
100 sec without pyra mainboard and uevm DT
This is of course to be expected since the uevm.dtb does not know anything about panels and Pyra peripherals and therefore does not enable anything -
and does not have to process polling loops etc.
Is that the way the DT file works? Does it poll until it finds everything? No timeout, etc.?
Because usually Linux checks for the devices and that's it. It doesn't constantly poll. Well, that would explain the faster heat up when using Pyras DT file without the mainboard attached - but then again, polling is being done by the CPU which is already under high load, so the polling shouldn't make any difference at all.
So something really weird is going on there.
Having the additional components (mainboard) simply connected shouldn't heat up the OMAP5 at all, unless it does something actively with them (which it shouldn't). Yes, the PALMAS needs to provide power for them, so that one might heat up a bit more, but the OMAP5 shouldn't, when everything is properly setup.
So for me, this raises the following questions:
1. Why does the OMAP5 heat up when the mainboard is attached? It really shouldn't do that, unless it actively uses any of these added components.
2. Why does the MIPI stream produce THAT much more heat? Based on the temperature rising, it needs... almost the same amount as both cores under full load? That can't be right.
But if we assume that the scenario 1 has the highest energy consumption, it explains why it is more risky to run into power supply limits.
Yes, but raises the question why so much more energy is needed. It shouldn't really add much!
Is the software setup causing that? Could there be a hardware issue on the mainboard that could cause the OMAP5 to heat up for some reason?
Realistically, the heating difference in my opinion shouldn't be more than 5 - 10 seconds. And you even have a 70 seconds difference with the Pyra.dt setup and mainboard connected. That's WAY too high (and also explains why I always thought the prototype heats up way too fast).
When doing absolutely nothing, it shouldn't really warm up at all, but it's clearly noticeable.
So something (hardware, software, whatever) on the mainboard causes the OMAP5 to heat up immensively, and we need to find that part and check what's wrong with it!
Hi,
Am 21.09.2016 um 09:53 schrieb Michael Mrozek EvilDragon@openpandora.org:
- Discussion
So this clearly shows that the heat production in the CPU depends on the device tree file and if the mainboard is connected or not.
This is REALLY weird. Why should the OMAP5 produce more heat simply because the mainboard is connected? It doesn't do anything with the additional connected devices if no driver is configured. Unless... could it be that it sees there's something there (like on i2c bus) and it tries to permanently probe that?
Exactly.
But then again, it would need to be something that has nothing to do with load, as you're putting the OMAP5 on high load anyways.
We have 31 sec with pyra mainboard and pyra DT
So it heats up three times as fast simply because the mainboard is connected and MIPI is active? That sounds like WAY too much. It shouldn't have much impact.
I agree that it shouldn't, but it does according to this test.
40 sec without pyra mainboard and pyra DT
Wow! Still twice as fast. Some bug with the DT file maybe?
42 sec with pyra mainboard and uevm DT
... combined with something that the mainboard does?
100 sec without pyra mainboard and uevm DT
This is of course to be expected since the uevm.dtb does not know anything about panels and Pyra peripherals and therefore does not enable anything -
and does not have to process polling loops etc.
Is that the way the DT file works? Does it poll until it finds everything? No timeout, etc.?
No. DT configures drivers. Those might or might not poll.
Because usually Linux checks for the devices and that's it. It doesn't constantly poll. Well, that would explain the faster heat up when using Pyras DT file without the mainboard attached - but then again, polling is being done by the CPU which is already under high load, so the polling shouldn't make any difference at all.
So something really weird is going on there.
Having the additional components (mainboard) simply connected shouldn't heat up the OMAP5 at all, unless it does something actively with them (which it shouldn't). Yes, the PALMAS needs to provide power for them, so that one might heat up a bit more, but the OMAP5 shouldn't, when everything is properly setup.
So for me, this raises the following questions:
- Why does the OMAP5 heat up when the mainboard is attached? It really shouldn't do that, unless it actively uses any of these added components.
That might be in the range of measurement precision (I haven't had the same starting temperature which might be influenced by the total temperature of the Palmas).
- Why does the MIPI stream produce THAT much more heat? Based on the temperature rising, it needs... almost the same amount as both cores under full load? That can't be right.
Well, we pull 24 bit video data with 720x1200x60fps. This is roughly 51 Mpx/s and 1.2Gbit/s or 155 Mbyte from RAM. These go through the memory controller, DSS and MIPI encoder. These are running in addition to the situation when there is no MIPI.
But if we assume that the scenario 1 has the highest energy consumption, it explains why it is more risky to run into power supply limits.
Yes, but raises the question why so much more energy is needed. It shouldn't really add much!
Is the software setup causing that? Could there be a hardware issue on the mainboard that could cause the OMAP5 to heat up for some reason?
That is what puzzles me as well. The mainboard here only has 2 I2C interfaces, MIPI, a handful of GPIOs and power.
This is the connection diagram of the adapter I use so that you can see which signals of the EVM go to the mainboard:
AFAIK the omap5-evm.dts does only initialize the I2C controllers and the GPIOs are in high-resistance-input-mode. And DSI is also disabled.
Realistically, the heating difference in my opinion shouldn't be more than 5 - 10 seconds.
In my opinion it should be 0 seconds. But is this more or less realistic?
And you even have a 70 seconds difference with the Pyra.dt setup and mainboard connected. That's WAY too high (and also explains why I always thought the prototype heats up way too fast).
Please note that you have a different mainboard in the Pyra (modernized and bug fixed version) than the old one I am using here. The one I have does not have all interfaces and does not even connect everything.
When doing absolutely nothing, it shouldn't really warm up at all, but it's clearly noticeable.
In idle the EVM goes to 50° which *is* noticeable. Even at the outside connectors which have ca. 30°C for an EVM w/o enclosure.
So something (hardware, software, whatever) on the mainboard causes the OMAP5 to heat up immensively, and we need to find that part and check what's wrong with it!
Ok, I did run a short comparison again, trying to keep the setup the same as much as possible (which isn't easy if OMAP cools down and heats up and commands are started manually):
a) EVM with omap5-uevm.dts with Mainboard 4 connected: 50°C in idle 75°C after 40s; Xorg with 0.7%, login process with 1%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
b) EVM with omap5-uevm.dts w/o Mainboard 4 connected: 49°C in idle 75°C after 37s; Xorg with 0.7%, login process with 1%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
So this time, they are essentially the same and I can't find any significant difference.
BTW: in both cases the ARM is mostly running @ 1GHz and only goes up to 1.5GHz for the high-load test.
From this I must conclude that this "effect" is an artifact by low precision of measurement and not a real effect.
And about the 50° idle temperature this is something we can not solve. Unless we change the SoC. Or make Xorg, sshd and interrupts go to 0%. So it would neither be hardware only a little kernel.
c) EVM with omap5-uevm+pyra.dts with Mainboard 4 connected (and panel active): 44°C in idle 75°C after 78s; Xorg with 0.7%, login process with 2.3%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
Everything is the same except the login process which tries to display battery status in this case adding some %.
And...
... this time measurement for heating up is crap. It heavily depends on initial temperature and that one depends on how long the board was powered down between measurements. I have repeated it and starting from 50°C it took 35s this time to get at 75°C. Exactly the same as with other DT and no Mainboard.
So please forget about this heat-up-time comparison. It does not tell us anything. Pure noise. No bug to find by this method.
In summary from my log-time results from yesterday and this morning, it remains that in one case the sawtooth stopped and temperature kept rising for several seconds which indicates that something broke in the kernel or OMAP.
If someone could shed some light on how this 100°C temperature limit of the OMAP5 works, it would be helpful.
BR, Nikolaus
On 21 September 2016 at 12:11, H. Nikolaus Schaller hns@goldelico.com wrote:
Could there be a hardware issue on the mainboard that could cause the OMAP5 to heat up for some reason?
That is what puzzles me as well. The mainboard here only has 2 I2C interfaces, MIPI, a handful of GPIOs and power.
The ssd will terminate the DSI lanes and make the transmitter consume a *lot* more power than when it is driving open lines.
Matthijs
Hi everybody !
I tried again to reach the promised 1.7GHz through this omap5.dtsi modification :
operating-points = < /* kHz uV */ 1000000 1060000 1500000 1250000 + 1700000 1290000 >;
Found those values here : https://github.com/omapconf/omapconf/blob/master/arch/arm/mach-omap/omap5/op...
I tested on both EVM and IGEP, 4.7.4 vanilla, and it now works (failed one year ago with IGEP's 3.8.x) : cpufreq stats: 1000 MHz:9.10%, 1.50 GHz:7.29%, 1.70 GHz:83.61%
$ time echo "scale=5000; a(1)*4" | bc -l @1.0 GHz : 1m26.008s @1.5 GHz : 0m56.667s @1.7 GHz : 0m50.420s
Under long make -j3 , the average temperature is only 2~4 °C more, but I have glued far better heatsinks on both my boards. No crash so far.
Thought this info may help here to expand ways of testing.
To add redundant information, I fuel the EVM with 12V and never encountered any crash @1.5GHz .
Cheers, LS
* Michael Mrozek EvilDragon@openpandora.org [160920 07:29]:
On September 20, 2016 7:45:01 AM GMT+02:00, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Except one thing: if there are power sinks at the USB ports which draw high current, switching might make glitches on the DC input. But I don't see how this should affect OMAP operation.
That theory has one problem: It doesn't crash while switching. If voltage you feed the EVM with is below 5.6V, it ALWAYS runs in that special 5V mode without any switching happening.
So it seems to have something to do with that mode, not with the switching.
What's interesting though: As it runs stable for you (without using HDMI or USB), it probably doesn't have anything to do with the AC adapter breaking down because of a too high power consumption. HDMI should not use as much power as running the OMAP5 with full power for a while!
Looks like my omap5-uevm runs stable with a bench power supply at 4.8V if I first rmmod ehci-omap (and the Ethernet). If I don't do that the blue LEDs near the power jack go dim starting load on both CPUs and it hangs.
Regards,
Tony
Am Mon, 19 Sep 2016 12:14:04 -0400 hat Roy Gillotti gillottir@gmail.com geschrieben:
Hi Roy,
as Nikolaus mentioned that he never connected HDMI to the board: Can you do the tests with HDMI disconnected?
That would tell us whether Nikolaus has a special EVM (or magic AC Adaptor) or whether the issue REALLY has something to do with HDMI.
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
Should be easy enough, I can get to this in several hours when I get home from work.
On Tue, Sep 20, 2016 at 12:02 PM, Michael Mrozek <EvilDragon@openpandora.org
wrote:
Am Mon, 19 Sep 2016 12:14:04 -0400 hat Roy Gillotti gillottir@gmail.com geschrieben:
Hi Roy,
as Nikolaus mentioned that he never connected HDMI to the board: Can you do the tests with HDMI disconnected?
That would tell us whether Nikolaus has a special EVM (or magic AC Adaptor) or whether the issue REALLY has something to do with HDMI.
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
Hi,
* Roy Gillotti gillottir@gmail.com [160919 09:14]:
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.
Sorry for the delay in responding. I'm just using typically either current mainline Linux or current Linux next.
5V power supply, two copies of dd=if/dev/urandom of=/dev/null running, hangs within a minute with temperatures below 68C. The power is actually 4.5V in this case. Just before hang I might get this on omap5-uevm:
hub 1-2:1.0: over-current condition
12V power supply, two copies of dd=if/dev/urandom of=/dev/null running, does not hang even with temperatures over 90C.
Also did a test with a bench power supply set to 5V. Two copies of dd=if/dev/urandom of=/dev/null running and it is stable. Lowering it to about 4.6V during the test makes it hang.
Then I also booted with a bench power supply set to 4.8V, started two copies of dd=if/dev/urandom of=/dev/null, and the blue LEDs near the power jack get dimmer and got "hub 1-2:1.0: over-current condition". This time it did not hang and after killing one of the dd processes stays running. Curiously after one hub over-current message two copies of dd kept running just fine at v4.8V.. Until I did rmmod ehci-omap as I'm using an initramfs.
Finally tried 4.8V, rmmod ehci-omap in initramfs, two copies of dd=if/dev/urandom of=/dev/null, and it seems to be running OK.
So yeah I must have moved my omap5-uevm from 12V to 5V rack shelf and that's why I started noticing hangs. And it seems something on the *hci bus is sucking power quite a bit, maybe the Ethernet?
And thanks for the detailed test log info :)
Regards,
Tony
Hi,
Am 20.09.2016 um 22:57 schrieb Tony Lindgren tony@atomide.com:
Hi,
- Roy Gillotti gillottir@gmail.com [160919 09:14]:
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.
Sorry for the delay in responding. I'm just using typically either current mainline Linux or current Linux next.
5V power supply, two copies of dd=if/dev/urandom of=/dev/null running, hangs within a minute with temperatures below 68C. The power is actually 4.5V in this case.
Seems to confirm that the 5V issue is mainly because of the combination of supply cable resistance and high load.
With higher supply voltage the real voltage is higher and not that critical.
Just before hang I might get this on omap5-uevm:
hub 1-2:1.0: over-current condition
Interesting!
12V power supply, two copies of dd=if/dev/urandom of=/dev/null running, does not hang even with temperatures over 90C.
Also did a test with a bench power supply set to 5V. Two copies of dd=if/dev/urandom of=/dev/null running and it is stable. Lowering it to about 4.6V during the test makes it hang.
Then I also booted with a bench power supply set to 4.8V, started two copies of dd=if/dev/urandom of=/dev/null, and the blue LEDs near the power jack get dimmer and got "hub 1-2:1.0: over-current condition". This time it did not hang and after killing one of the dd processes stays running. Curiously after one hub over-current message two copies of dd kept running just fine at v4.8V.. Until I did rmmod ehci-omap as I'm using an initramfs.
Finally tried 4.8V, rmmod ehci-omap in initramfs, two copies of dd=if/dev/urandom of=/dev/null, and it seems to be running OK.
So yeah I must have moved my omap5-uevm from 12V to 5V rack shelf and that's why I started noticing hangs. And it seems something on the *hci bus is sucking power quite a bit, maybe the Ethernet?
AFAIK, Ethernet is connected through HSIC3 to the LAN9730. And the USB ports are on HSIC2 for an USB3503.
Since the Ethernet chip should not be able to report any over-current condition, I think the USB3503 is reporting this.
Both are powered by 3V3 from U3 (another TPS54426PWPR). So this SMPS is independent of the Palmas SMPS. AFAIR, these chips are specified to work for 4.5V and above. So a DC_IN dropping below 4.5V might send hickups to the 3V3 supply which mangle up EHCI.
The USB3503 has an OCS_N input connected to the 5V rail. I don't know where the threshold is where it thinks there is an over current... Maybe if this line drops below 4.5V?
BR, Nikolaus
PS: Pyra has no Ethernet and HSIC3 is unused. It has the USB3503 on HSIC2, but this is powered from VSYS and uses the internal 3V3 LDO.
* H. Nikolaus Schaller hns@goldelico.com [160920 23:53]:
Am 20.09.2016 um 22:57 schrieb Tony Lindgren tony@atomide.com: Just before hang I might get this on omap5-uevm:
hub 1-2:1.0: over-current condition
Interesting!
..
AFAIK, Ethernet is connected through HSIC3 to the LAN9730. And the USB ports are on HSIC2 for an USB3503.
Since the Ethernet chip should not be able to report any over-current condition, I think the USB3503 is reporting this.
Yes seems to come from the hub kernel code.
Both are powered by 3V3 from U3 (another TPS54426PWPR). So this SMPS is independent of the Palmas SMPS. AFAIR, these chips are specified to work for 4.5V and above. So a DC_IN dropping below 4.5V might send hickups to the 3V3 supply which mangle up EHCI.
The USB3503 has an OCS_N input connected to the 5V rail. I don't know where the threshold is where it thinks there is an over current... Maybe if this line drops below 4.5V?
Yeah maybe then it starts sucking more power or something.
PS: Pyra has no Ethernet and HSIC3 is unused. It has the USB3503 on HSIC2, but this is powered from VSYS and uses the internal 3V3 LDO.
Might be still checking on Pyra if it behaves better with ehci-omap and ohci-omap3 unloaded.
Regards,
Tony
Hi,
Am 27.09.2016 um 18:44 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160920 23:53]:
Am 20.09.2016 um 22:57 schrieb Tony Lindgren tony@atomide.com: Just before hang I might get this on omap5-uevm:
hub 1-2:1.0: over-current condition
Interesting!
..
AFAIK, Ethernet is connected through HSIC3 to the LAN9730. And the USB ports are on HSIC2 for an USB3503.
Since the Ethernet chip should not be able to report any over-current condition, I think the USB3503 is reporting this.
Yes seems to come from the hub kernel code.
Both are powered by 3V3 from U3 (another TPS54426PWPR). So this SMPS is independent of the Palmas SMPS. AFAIR, these chips are specified to work for 4.5V and above. So a DC_IN dropping below 4.5V might send hickups to the 3V3 supply which mangle up EHCI.
The USB3503 has an OCS_N input connected to the 5V rail. I don't know where the threshold is where it thinks there is an over current... Maybe if this line drops below 4.5V?
Yeah maybe then it starts sucking more power or something.
PS: Pyra has no Ethernet and HSIC3 is unused. It has the USB3503 on HSIC2, but this is powered from VSYS and uses the internal 3V3 LDO.
Might be still checking on Pyra if it behaves better with ehci-omap and ohci-omap3 unloaded.
We have done measurements today and it does not make a visible difference, at least when rmmod-ing after boot.
But we have found a completely different explanation for the Pyra and EVM problems.
The first observation was that the cables between power supply and device/board have some resistance. It ist typically 0.5 - 1 Ohm. So this means a voltage drop of 0.5 - 1 V at 1A. If the system draws 2A (can happen @1.5GHz) the voltage drop is higher.
For the Pyra we use the bq24297 charger chip. What we have learned today is that it not only has a programmable current limitation (to comply with 100/500/900 mA standard USB sources and 1A/2A power supplies), but it also has a minimum voltage level where it switches to "supplement" mode. Then both the power supply and the battery provide energy to the OMAP5. This probably means that using standard USB cabeling it is not possible to charge the battery while the OMAP5 is running at 200% load.
Now, this minimum voltage is 4.36V by hardware default. If the OMAP draws too much current and the USB power cable has a high resistance (something which is very different between all the users), this voltage level is undercut. If we want to operate the system without battery, the bq24297 seems to switch off or cut off the current or whatever. This might just be a very short glitch so that the Palmas does not simply turn off but makes the OMAP5 hang.
We found this because the Pyra did boot and run stable if the power supply was raised to 5.6V or above... This is beyond USB specs of course but the bq24297 is forgiving.
The good thing is that we just have to patch MLO/U-Boot a little so that it not only increases the current limit wide enough but also reduces this minimum voltage.
The OMAP5 EVM has something similar. It uses some tps54426 DC/DC converter between the power jack and the Palmas power input. This is quite similar to what the bq24297 does.
Now the data sheet defines the tps54426 as 4.5V - 18 V converter (unfortunately it does not exactly define the lower limit and what happens if it is undercut).
But again we have a significant lower limit on input voltage which depends on power consumption of the OMAP5 board and the resistance of the supply cable! Here we know that it also helps to increase the input voltage as Roy has recently demonstrated.
So we only have to modify the Pyra U-Boot code to verify our theory.
And, if someone could please share the IGEP schematics or look into them how it derives the Palmas power input from the DC jack, we could cross-check why the IGEP appears not to show such problems if run from 5V supplies.
So I think we have found the hardware mechanism which can make the Pyra and EVM instable.
BR, Nikolaus
Here's the IGEPv5 hardware reference as attachment.
Hi,
Am 29.09.2016 um 21:51 schrieb openpandora@free.fr:
Here's the IGEPv5 hardware reference as attachment.<MAN-PR-IGEP0050-RBxx-001-IGEPv5_HARDWARE_REFERENCE_MANUAL-1.0-20131126.pdf>
Many thanks!
To quote:
"IGEPTM v5 must be powered with +5Vdc through P100 connector. This voltage follows two ways, one is used to power the USB Host and the other goes directly to U101, p/n: TPS53318 DC-DC Voltage regulator that generates the main system voltage is VSYS (3.7V)."
so it indeed also uses a DC/DC converter to go from the 5V input jack to VSYS.
But it is a third type of chips (compared to EVM and Pyra). After looking into the data sheet, this TPS53318 appears to be able to work from input voltages even below 3.7V so it can convert down or up as needed.
So it is far more independent of real input voltage than the converter used on the EVM.
This puzzle piece also seems to fit into our explanation.
BR and thanks, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160929 06:45]:
Am 27.09.2016 um 18:44 schrieb Tony Lindgren tony@atomide.com: Might be still checking on Pyra if it behaves better with ehci-omap and ohci-omap3 unloaded.
We have done measurements today and it does not make a visible difference, at least when rmmod-ing after boot.
OK so it seems ehci and the hub just cause extra power consumption and that's enough to make omap5-uevm fail for me at 4.5V supply.
But we have found a completely different explanation for the Pyra and EVM problems.
The first observation was that the cables between power supply and device/board have some resistance. It ist typically 0.5 - 1 Ohm. So this means a voltage drop of 0.5 - 1 V at 1A. If the system draws 2A (can happen @1.5GHz) the voltage drop is higher.
OK
For the Pyra we use the bq24297 charger chip. What we have learned today is that it not only has a programmable current limitation (to comply with 100/500/900 mA standard USB sources and 1A/2A power supplies), but it also has a minimum voltage level where it switches to "supplement" mode. Then both the power supply and the battery provide energy to the OMAP5. This probably means that using standard USB cabeling it is not possible to charge the battery while the OMAP5 is running at 200% load.
Might be still possible with a charging USB hub after charger negotiation :)
Now, this minimum voltage is 4.36V by hardware default. If the OMAP draws too much current and the USB power cable has a high resistance (something which is very different between all the users), this voltage level is undercut. If we want to operate the system without battery, the bq24297 seems to switch off or cut off the current or whatever. This might just be a very short glitch so that the Palmas does not simply turn off but makes the OMAP5 hang.
We found this because the Pyra did boot and run stable if the power supply was raised to 5.6V or above... This is beyond USB specs of course but the bq24297 is forgiving.
Oh OK that sounds like the root cause for the issue then.
The good thing is that we just have to patch MLO/U-Boot a little so that it not only increases the current limit wide enough but also reduces this minimum voltage.
AFAIK for USB, you should only increase the USB charger limit based on the charger and USB peripheral negotiation depending what you're connected to.
The OMAP5 EVM has something similar. It uses some tps54426 DC/DC converter between the power jack and the Palmas power input. This is quite similar to what the bq24297 does.
OK
Now the data sheet defines the tps54426 as 4.5V - 18 V converter (unfortunately it does not exactly define the lower limit and what happens if it is undercut).
But again we have a significant lower limit on input voltage which depends on power consumption of the OMAP5 board and the resistance of the supply cable! Here we know that it also helps to increase the input voltage as Roy has recently demonstrated.
Yes for many USB cables I've noticed they only provide current up to 600mA when charging. The cheapo $10/10€ USB charge monitors help debugging this :)
So we only have to modify the Pyra U-Boot code to verify our theory.
And, if someone could please share the IGEP schematics or look into them how it derives the Palmas power input from the DC jack, we could cross-check why the IGEP appears not to show such problems if run from 5V supplies.
So I think we have found the hardware mechanism which can make the Pyra and EVM instable.
OK good to hear!
Tony
Hi Tony,
Am 30.09.2016 um 19:09 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160929 06:45]:
Am 27.09.2016 um 18:44 schrieb Tony Lindgren tony@atomide.com: Might be still checking on Pyra if it behaves better with ehci-omap and ohci-omap3 unloaded.
We have done measurements today and it does not make a visible difference, at least when rmmod-ing after boot.
OK so it seems ehci and the hub just cause extra power consumption and that's enough to make omap5-uevm fail for me at 4.5V supply.
But we have found a completely different explanation for the Pyra and EVM problems.
The first observation was that the cables between power supply and device/board have some resistance. It ist typically 0.5 - 1 Ohm. So this means a voltage drop of 0.5 - 1 V at 1A. If the system draws 2A (can happen @1.5GHz) the voltage drop is higher.
OK
For the Pyra we use the bq24297 charger chip. What we have learned today is that it not only has a programmable current limitation (to comply with 100/500/900 mA standard USB sources and 1A/2A power supplies), but it also has a minimum voltage level where it switches to "supplement" mode. Then both the power supply and the battery provide energy to the OMAP5. This probably means that using standard USB cabeling it is not possible to charge the battery while the OMAP5 is running at 200% load.
Might be still possible with a charging USB hub after charger negotiation :)
Now, this minimum voltage is 4.36V by hardware default. If the OMAP draws too much current and the USB power cable has a high resistance (something which is very different between all the users), this voltage level is undercut. If we want to operate the system without battery, the bq24297 seems to switch off or cut off the current or whatever. This might just be a very short glitch so that the Palmas does not simply turn off but makes the OMAP5 hang.
We found this because the Pyra did boot and run stable if the power supply was raised to 5.6V or above... This is beyond USB specs of course but the bq24297 is forgiving.
Oh OK that sounds like the root cause for the issue then.
The good thing is that we just have to patch MLO/U-Boot a little so that it not only increases the current limit wide enough but also reduces this minimum voltage.
AFAIK for USB, you should only increase the USB charger limit based on the charger and USB peripheral negotiation depending what you're connected to.
Yes in normal operation.
This is also the reason why some smartphones or tablets do not charge if plugged into a standard PC USB port.
We do this increasing without negotiation only if there is no battery installed, which indicates a lab setup.
In normal operation some battery monitor could detect that the charger is going to its limits and the battery is still discharging and show an alert to check cables and wall charger.
This is what I have seen for some such devices.
The OMAP5 EVM has something similar. It uses some tps54426 DC/DC converter between the power jack and the Palmas power input. This is quite similar to what the bq24297 does.
OK
Now the data sheet defines the tps54426 as 4.5V - 18 V converter (unfortunately it does not exactly define the lower limit and what happens if it is undercut).
But again we have a significant lower limit on input voltage which depends on power consumption of the OMAP5 board and the resistance of the supply cable! Here we know that it also helps to increase the input voltage as Roy has recently demonstrated.
Yes for many USB cables I've noticed they only provide current up to 600mA when charging. The cheapo $10/10€ USB charge monitors help debugging this :)
In fact USB2 cables are required to support 500 or 900mA only. Only chargers must be able to carry a higher current. Or USB3 cables.
So we only have to modify the Pyra U-Boot code to verify our theory.
And, if someone could please share the IGEP schematics or look into them how it derives the Palmas power input from the DC jack, we could cross-check why the IGEP appears not to show such problems if run from 5V supplies.
So I think we have found the hardware mechanism which can make the Pyra and EVM instable.
OK good to hear!
We are still testing if it is indeed true...
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160930 10:17]:
Am 30.09.2016 um 19:09 schrieb Tony Lindgren tony@atomide.com: AFAIK for USB, you should only increase the USB charger limit based on the charger and USB peripheral negotiation depending what you're connected to.
Yes in normal operation.
This is also the reason why some smartphones or tablets do not charge if plugged into a standard PC USB port.
We do this increasing without negotiation only if there is no battery installed, which indicates a lab setup.
Yeah this seems like a good way to follow the USB spec.
Regards,
Tony
On Mon, Sep 19, 2016 at 12:54 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 19.09.2016 um 11:39 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
if somebody could share an SD image (or at least all the boot files, to eliminate any possible bootloader/MLO differences)
DEV=/dev/sdd ./makesd omap5432evm -f1 -b OMAP5432-uEVM/2016-05-10 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 xfce
Doesn't work ("unknown macro: xfce"), but worked when I removed the "xfce" argument.
And quite unsurprisingly it seems to be stable at 12V. I guess Roy has nailed it - at least some uEVMs have problems when powered by 5V supply. OMAP5 and/or it's PMIC are really picky on power delivery. As we live in imperfect world of imperfect 5V supplies and cables, looks like it's going to be difficult to make it stable on Pyra...
Gražvydas
Hi,
Am 20.09.2016 um 02:05 schrieb Grazvydas Ignotas notasas@gmail.com:
On Mon, Sep 19, 2016 at 12:54 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 19.09.2016 um 11:39 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
if somebody could share an SD image (or at least all the boot files, to eliminate any possible bootloader/MLO differences)
DEV=/dev/sdd ./makesd omap5432evm -f1 -b OMAP5432-uEVM/2016-05-10 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 xfce
Doesn't work ("unknown macro: xfce"),
Sorry. Should have been
DEV=/dev/sdd ./makesd omap5432evm -f1 -b OMAP5432-uEVM/2016-05-10 -k letux-4.8-rc6 -d letux-4.8-rc6 -f2 -m letux-4.8-rc6 -r xfce
but worked when I removed the "xfce" argument.
Then it defaults to lxde.
And quite unsurprisingly it seems to be stable at 12V. I guess Roy has nailed it - at least some uEVMs have problems when powered by 5V supply. OMAP5 and/or it's PMIC are really picky on power delivery. As we live in imperfect world of imperfect 5V supplies and cables, looks like it's going to be difficult to make it stable on Pyra...
At least if we want it to run without battery from arbitrarily chosen power supplies which just happen to have the correct connector.
BR, Nikolaus
-
Grazvydas Ignotas -
H. Nikolaus Schaller -
Linux-SWAT -
Matthijs van Duin -
Michael Mrozek -
openpandora＠free.fr
-
Roy Gillotti -
Tony Lindgren