(04-13-2017, 02:36 AM)pfeerick Wrote: (1) Since that is the case (which it will be 9 times out of 10 with this sort of random and inconsistent issue)... I'll remind you yet again that in my instance... this is with the lithium battery connected to the pine64! So are you suggesting that the PMIC is also unable to instantaneously switch between the external input and the battery input as it designed to? I'm more than happy to entertain that thought, but want to know if that is what you are suggesting, or you have missed that detail?
(2) Do you think the HDMI being connected might simply be adding some extra capacitance and/or power, and helping smooth things out, be making the PMIC regulate slightly better since it has a bit more work to do?
In response to (1) above, I don't think so. I also have the battery plugged in all the time (J9 in vbatt) with filtered euler power feed. The PMIC seems to function 100% normally for me too; not a hitch, and I am not able to reproduce the 'powerdown' scenario with the hdmi unplugged. (its a mystery to me too)
As far as (2) above goes, I wish I knew. (I mean, I admit that I am totally guessing here) But again, I can't reproduce the failure. Yes, I think that its most likely a power issue and that the presence of the hdmi is smoothing things out a bit; but, having said that again, its really a wag... but most probable unless of course the later kernel's have introduced an hdmi bug that is new. I am still using 3.10.102 BSP on all of my machines; so, who knows. (?)
marcushh777
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
04-16-2017, 03:02 AM (This post was last modified: 04-16-2017, 03:19 AM by pfeerick.
Edit Reason: one final update
)
Well, it looks like my problem is somewhat related to the wifi driver. With Armbian 5.25 Xenial (so 3.10.104), booting with either hdmi connect or not connected made not difference whatsoever, pulling the wifi module out fixed it instantly. I am consequently thinking it is update related, as I had recently updated that image, so there may be some incompatibility with some other package upgrade. But it certainly looks like (as longlseep indicated) that the WiFi driver has something to do with it in my particular case. So I'll stop making noise in this thread for now!
For anyone wanting to see all the gory details... here are three boot logs... one without HDMI (which crashed badly), one with HDMI (which also crashed badly), and one without the WiFi module or HDMI (which worked fine, and I double checked by rebooting twice to confirm, as all previous boots had crashed).
Edit: One last bit of noise... before wiping the card and starting again, I thought I'd plug it into the ethernet and apply any current updates. The following packages were available for update: dnsmasq-base libmysqlclient20 libpci3 makedev mysql-common ntp pciutils wget, so I let it apply them, although most of them seem unrelated (except for the very first one), and tried rebooting again with the wifi module connected, and this time it is working... again... two reboots in a row, verses consistent lockups. Anyway, here is the final boot log now that it is working again... :/
And just to update, I got back to trying out different capacitors to see what worked... and even without them, what was a 100% repro crash is now infrequent.
I have no idea what has changed in my seteup - using same ethernet cable, hub port, power supplies, usb cable, and kernel, and suddenly it's good for 90%+ of boots.
Ah well, I'll stick my capacitor back on there for good measure (though I now have no evidence it's doing anything useful, it doesn't appear to cause any harm) and move on.
(04-17-2017, 12:52 AM)TinkerBear Wrote: And just to update, I got back to trying out different capacitors to see what worked... and even without them, what was a 100% repro crash is now infrequent.
I have no idea what has changed in my seteup - using same ethernet cable, hub port, power supplies, usb cable, and kernel, and suddenly it's good for 90%+ of boots.
Ah well, I'll stick my capacitor back on there for good measure (though I now have no evidence it's doing anything useful, it doesn't appear to cause any harm) and move on.
Jeah, we should rename that board to PAIN64. So many mystifying things happen on it
(04-17-2017, 02:45 AM)tommypine Wrote: Jeah, we should rename that board to PAIN64. So many mystifying things happen on it
No pain, no gain! :-P
But seriously, bit by bit all the weird gremlins and glitches are being worked out, and workarounds or "things to avoid" are starting to get documented. Any hardware niggles are hopefully making it into later revisions of the board so they become a non-issue for later runs of the board.
I am trying to boot 3.10.104-2-pine64-longsleep ubuntu 16.04 image in pine 64, but it is not booting .It structs in U-boot and not booting further. Need help on this. I have attached the picture of where its structs in u-boot. Kindly go through the picture and give me suggestion to solve this issue.
