Hi, thanks for the feedback!
Am 20.09.2016 um 22:14 schrieb aTc atc@k-n-p.org:
First some good news :
pyra booting pyraos with a TILER enabled kernel.
It still needs a very ugly hack to keep the display on for more than 10 seconds, but at least the basics work.
Great!
(no display until it loads the kernel modules, which is why you don't see anything the first 19 seconds, and the annoying flashing leds are turned off by my led-config, the one "failed" message you see is just the sgx driver modules failing to load)
It's still quite a struggle to boot the thing though, but once it does, its fairly stable when both usb power and the battery are used. USB power alone tends to drop out when the load gets higher. Taking out the battery while on USB power also seems to cause a drop in brightness of the leds.
Yes, this is intentional (by texas instruments when designing the bq24297). The LEDs are operated directly from VSYS and VSYS voltage depends on USB and/or battery operation. If the battery is more than ~50% charged the voltage from battery is higher and hence VSYS.
Booting usually gets stuck on the u-boot "Starting kernel ..." message. Although sometimes it doesn't even get beyond the first two lines : "U-Boot SPL 2015.10-00064-g3a56b36-dirty (Apr 07 2016 - 22:35:27) OMAP5432 ES2.0 "
Yes, I have had that as well several times. It even does not load U-Boot in that case. Initially I thought that the SD interface could be a factor - but then it would not even have found the SPL (MLO).
The only solution was to remove all power (incl. battery) and retry.
This is something on my should-be-done-list to add debugging to SPL where it hangs and why.
It seems it gets easier to boot the longer you try, like something needs charging/warming up first :)
One candidate is the backup battery for the RTC. Or the Palmas stores some internal state from the last boot attempt which makes SPL hang.
I did take apart the entire thing, and after that booting does seem to have become slightly more reliable. Maybe it has something to do with that cpu board not beeing mounted properly in the second socket.
Could potentially be an issue. But this corner of the connector provides interface to the second SD slot and WiFi. So those would fail but nothing else.
At the angle it sits it's a miracle it works at all.
This should be solved with the new CPU boards.
Although I also took out the stuck shoulderbuttons. (not sure if they were pushing down on the buttons, but they didn't move anyway)
Another thing I noticed was a high pitched whine when plugging in usb devices.
This is the inductor of the DC/DC converter for providing 5V. It makes some noise. I have thought about choosing different one, but haven't found some small enough replacements with same parameters from a different manufacturer. All others are too big.
When using the letux makesd created image, there's a 3 minute delay halfway through booting, right after "[ 15.161997] wlcore: loaded" After the delay, it continues booting without problems.
I didn't really investigate what caused it, it doesn't happen when using the pyraos image (probably because that uses the much more parallel systemd)
This is likely induced by /etc/network/interfaces (waiting for dhcpd or something).
Also, devmem2 seems to be missing from the image, the package is there, but the executable isn't found, which causes some issues with the lcd script (which doesn't seem to be needed on my pyra anyway, since the display just works when using omap5-letux-cortex15-v5.1+pyra-v5.1.dtb)
Ah, ok. I had rebuilt the devmem2 package and my new build script did place it in /usr/bin/arm-linux-gnueabihf which is not in $PATH.
Unfortunately I could not test the latest image on a Pyra...
BR, Nikolaus