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