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