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