tghewett
commented
8 years ago By old firmware I mean the libraries in /opt are old, but /boot is newer - March 2016. With that arrangement it works.
Closed tghewett closed 7 years ago
tghewett
commented
8 years ago By old firmware I mean the libraries in /opt are old, but /boot is newer - March 2016. With that arrangement it works.
popcornmix
commented
8 years ago The issue will almost certainly reside in the gpu firmware (i.e. /boot/start.elf and /boot/fixup.dat).
tghewett
commented
8 years ago The issue will almost certainly reside in the gpu firmware (i.e. /boot/start.elf and /boot/fixup.dat).
Perhaps there is a difference in the /opt/vc/lib software which provokes a GPU problem which was present beforehand, not provoked by older releases, with the core problem being in the GPU as you say. I find regressing the libs helps, the start.elf and mixup.elf seem to make little difference, similarly the kernel is fine.
I have just done a md5sum on the fixup.dat and start.elf (see below) and they are the ones taken from a recent Raspian image from raspberrypi.org post RP3 release.
[29/06/2016 23:40 raspberrypi:~] pi$ md5sum /boot/fixup.dat 92e44726dcf7d708b5cf36d3badf09ad /boot/fixup.dat [29/06/2016 23:40 raspberrypi:~] pi$ md5sum /boot/start.elf 0fcd3fb4e731c6d164e4b4c66fdaa2a7 /boot/start.elf [29/06/2016 23:40 raspberrypi:~] pi$
[EDIT: excuse my computer's automatic spelling correction, mixup.elf -> fixup.dat]
faxik
commented
7 years ago I'm experiencing the same issue.
Maybe it's related, maybe not, but the systems (with identical image) that experience the issue also sometimes have problems booting up with a display attached.
Does someone came with the solution to that?
Ruler2112
commented
7 years ago It seems to be related to the display. Multiple Pi units with the exact same configuration (done by script) work on some TVs and only intermittently on others. I move a Pi that has never had an issue to a TV that has, it'll have trouble and the one I moved to the TV without issues is instantly cured.
While not able to find the problem or fix it, I was able to find a workaround for it. In /etc/rc.local, I have display detection & set the resolution based off of the EDID reported. If I bypass this and set the resolution to a hard-coded value, the problem does not present itself:
if [ -e /home/pi/resx ]; then
_XRES=`cat /home/pi/resx`;
_YRES=`cat /home/pi/resy`;
_DEPTH=32;
printf "===> Resetting frame-buffer to %dx%dx%d...\n" $_XRES $_YRES $_DEPTH
fbset --all --geometry $_XRES $_YRES $_XRES $_YRES $_DEPTH -left 0 -right 0 -upper 0 -lower 0;
else
#Lots of EDID reading & resolution setting code
fiWith this code in /etc/rc.local, I can simply create 2 files - resx and resy in /home/pi - with only the number of the resolution in the respective files. (I know I could have done it in a different/more clean manner, but I wanted the problem to disappear quickly, no matter if the solution is right or not.) This seems to work, as the troublesome displays haven't had trouble since I implemented it.
Ruler2112
commented
7 years ago There are back-ticks around the two cat commands for those who are script-impaired. :)
pelwell
commented
7 years ago There are now triple back-ticks around the whole script for those who are Markdown-impaired. ;-)
Ruler2112
commented
7 years ago LOL... that does look better. If I cared, I'd look up what Markdown means in present context. ;)
popcornmix
commented
7 years ago @faxik
does: while : ; do tvservice -d /tmp/edid.dat; done
run forever or hang after a short while?
Does the problem also occur with a different display?
JamesH65
commented
7 years ago Closing due to lack of activity. Reopen if you feel this issue is still relevant.
My app used to be able to poll for the presence of a device on the HDMI bus but with more recent firmware it is no longer reliable. Quitting the app and using a related tool to view the HDMI device EDID capabilities results in it hanging in much the same way. Attempts to use the Broadcom
tvserviceutility, e.g.tvservice -salso sees that utility hang.The problem is only cured with a reboot.
This may or may not be related to some apparent kernel panics / crashes / oopss, I note the presence of the symbol
rpi_firmware_property_list: