Hi,
Am 18.09.2016 um 17:12 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
okay, I took the time today to look a bit at the stability issues we have. I didn't do any analysis, just tried different boards with different setups and wrote down what happened.
The analysis should happen when I visit Nikolaus with all the PCBs and various AC Adaptors and USB cables.
@Nikolaus: But of course, if you want me to run any other tests upfront, let me know.
First, here are some general things I found out:
- The Micro USB cable matters!
Indeed!
I've got a MicroUSB cable that, when connected to the Pyra, is not able to boot it. All I get is a short blinking of lights and then a reboot. The cable itself works fine for any other device (I use it to charge my smartphone each night)
What is the charging current of your smartphone?
and also works fine as data cable (I used it in the tests to connect the FTDI to the laptop)
- The same thing applies to the AC Adaptor: Some AC Adaptors work, some
simply cause the same reboot loop. So to get it to boot a proper combination between an AC Adaptor and USB Cable is needed.
Ah, you use different wall chargers with a standard USB socket and then attach an external USB-to-micro-USB cable?
This makes all depend on the question if the cable can carry 2 Amperes.
Usually such cables are for data use only and assume a maximum current of USB 1: 100 mA USB 2: 500 mA USB 3: 900 mA (!)
It is allowed that voltage at the device end of a cable drops to 4.4V.
Here is some discussion:
http://electronics.stackexchange.com/questions/170292/what-is-the-maximum-ph...
So unless you have an "PD aware cable" is likely to be too weak...
Then a too high resistance and 2A makes the voltage that arrives inside the Pyra too low for stable operation. Software could be able to detect this and print a warning like I have seen on some smartphones: "bad charging cable". But this works only if the device is up and running.
This all is different for pure chargers (i.e. not a combination of wall charger plus cable). If it is rated 2A the cable is designed for 2A and the encoding of the USB charging spec (D+ and D- according to the bq24297 table I recently referred to) allows the bq24297 to detect such a power supply and draw 2 Amperes.
Since we tamper with this detection in our u-boot if there is no battery installed, the bq24297 also tries to pull 2A through a weak cable from a potentially strong enough power supply and that can be the problem.
- Even with a proper cable, the USB port seems to be VERY unstable.
Just touching it or wiggling a bit can cause a freeze on the Pyra!
Seems to be a mechanical problem. Dust inside?
- When inserting a battery, the Pyra sometimes boots up immediately and
sometimes it doesn't. No idea when it does what and why.
That is also something I have observed. Maybe it depends on whether the Palmas RTC is still running and how the device was shut down last time.
There might be a bit within Palmas which can control the behavior.
- I didn't have a single freeze at MLO even though I always had the SD
Card in the slot already when I connected the power. So that issue Nikolaus had cannot be confirmed here (which is good :))
Okay, so much for the general info. Now take a look at the attached Excel sheet.
One significant observation: Linux letux 4.8.0-rc1-letux+
The -rc1 was known to have problems. Please update to -rc5 or -rc6.
These are some results I got from booting various boards under different setups. The display board I used is one with the SSD included.
Here is a summary of the results:
- Booting without a display board attached almost ALWAYS works fine.
Except for the first one or two tries. Regardless of whether I boot with an AC Adaptor, a battery or both.
- Booting WITH a display board attached makes the whole thing very
random. Often the board boots up fine but doesn't find the display board. This especially seems to happen when only powering from a battery.
- Booting WITH a display board but without battery causes the Pyra to
shut itself off when X is loading and the display should show something. This happens regardless whether my laptop or a 2A USB AC adaptor is used to power the unit. If the display board is not found, it doesn't shut itself off.
- Booting WITH a display board and powering ONLY from battery works
stable (once you managed to boot it, as most of the times it doesn't find the display board, as mentioned above).
- The best combination seems to be booting WITH a battery AND an AC
Adaptor connected. In that case, it finds the display board most of the time and also doesn't shut off when it's booted up. However, in case the battery is removed while AC is still being kept connected, the Pyra shuts off after a few seconds.
What does that tell us? I'm not sure. I doubt the LCD Cable itself is flakey, as it hasn't been touched during the reboots and once it found and initialized the display board, it worked stable.
But as it mostly works if both the battery AND the AC connecter is attached, it could be some power issue. Maybe at bootup, when the kernel initializes the hardware, the display board lacks the power to respond and therefore it's not being found?
It's a bit of a mystery, but the more power I pump into the system, the more stable it seems to run and find the display board as well.
It could still be a kernel bug. Detection of battery and or AC connector has different activities in the kernel so some things may boot in different order.
And generally DSI/MIPI and our hacked ssd driver is instable (these atomic timeout thing is an important hint). So these messages may indicate that the kernel is running through unexpected states which might have side-effects, even for power management.
This is why I think we should clean this up asap. Either by retiring the ssd2858 completely or fixing the ssd2858.ko kernel module. So that we do no longer see warnings from the DSS startup.
But: according to my memory the Pyra usually hangs much earlier before DSS is even initialized. It seems (I haven't made a statistics) hang shortly after initializing the bq24297 and before the audio subsystem.
Let's see if we can find out more in our planned working session.
BR, Nikolaus