martiinsiimon Posted January 8, 2017 Posted January 8, 2017 Hello everyone, I've recently bought an OrangePI PC Plus with an intentions to make it (beside others) a multimedia center. Because of community and pretty good status of armbian on h3, I've downloaded and installed (a.k.a copied to sd) the latest armbian I found (5.20 with kernel 3.4.112). Everything went ok, I've got graphical desktop, hw accelerated h264 and h265 over hdmi to my tv. So the next step was to install kodi. An that's the point where my troubles started. After I installed kodi and probably updated the whole armbian (apt update && apt upgrade && apt dist-upgrade), I noticed that my TV turns off almost immediately I turn it on to hdmi source where the OPi is. I can see for a very short moment (like 1-4s) the desktop and then the TV goes off. But I don't know what caused this problem since I play with my OPi over ssh and start the hdmi/tv just from time to time. So I thought, it is caused by hdmi cec, therefore I went that way. I recompiled kernel with hdmi_cec module and libcec (from this forum), but beside the fact that the cec seems to be "working" now (i can play with cec-client), nothing changed in my problem at all. So I tried to turn cec at all. I turned it in tv everywhere, I unloaded the kernel module I created before, but again, no change. I investigated the logs, but I only find followings: $ dmesg | grep hdmi [ 0.981297] asoc: sndhdmi <-> sunxi-hdmiaudio.0 mapping ok [ 0.986916] [HDMI] power vcc-hdmi-18 [ 1.223449] #1: sndhdmi $ cat /var/log/Xorg.0.log | grep \(EE\) (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 9.279] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/lima_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/lima_dri.so: cannot open shared object file: No such file or directory) [ 9.280] (EE) AIGLX: reverting to software rendering [ 9.796] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 9.886] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied These are probably not related to the problem at all. Have you noticed this kind of problem before? Where can I get information about which process/setting turns the hdmi off? Or maybe, how can be the tv turned of (standby) over hdmi when cec is not active? I can provide full logs, if it could be helpful, but from the beginning I didn't want to spam this topic. Thanks in advance for any ideas! I really appreciate the work behind armbian and all the people around this forum.
martiinsiimon Posted January 8, 2017 Author Posted January 8, 2017 I uploaded the armhwinfo.log using the armbianmonitor script. It can be found here: http://sprunge.us/MbcB
jernej Posted January 8, 2017 Posted January 8, 2017 I'm dev behind OpenELEC fork for Oranges. I received a lot of complaints about CEC on PC Plus. Most of them says that CEC simply doesn't work while it works with other boards. My suspicion is ESD protection diode ESD20. Can you please check if it is populated (next to the HDMI connector)? Better yet, which ESDXX element is placed?
martiinsiimon Posted January 9, 2017 Author Posted January 9, 2017 I'm dev behind OpenELEC fork for Oranges. I received a lot of complaints about CEC on PC Plus. Most of them says that CEC simply doesn't work while it works with other boards. My suspicion is ESD protection diode ESD20. Can you please check if it is populated (next to the HDMI connector)? Better yet, which ESDXX element is placed? I've check visually the board and I can see that ESD17-20 are not placed and only ESD15 and ESD16 are (which are 5-in, 5-out). By quick look at the HDMI sheet it looks like all data channels are protected, but none of the "control", right? But if I burned the HDMI chip part, how is it possible that I get the screen working for a while? Shouldn't be that completely dead? And the other question - if the control wires are not bridged by ESDXX, it means that they cannot work, right?
jernej Posted January 9, 2017 Posted January 9, 2017 Everything you described seems to be in order. Removing ESD diodes also work, because they are mean to be connected to ground. If you remove them, there will be no protection, but otherwise should work just as well. Last chance - can you post deatiled photo of your board (top and bottom), so I can check if anything is out of order?
martiinsiimon Posted January 14, 2017 Author Posted January 14, 2017 Hi again, so I've tried to boot your OpenELEC fork, but I've ended in the very same situation - everything looks nice, but for only a few seconds, then the HDMI goes down with my whole TV. So I guess you were right and I successfully burnt out my HDMI part of a chip. Anyway, I add the requested picture, hope you can see something, but I don't.
Christos Posted January 14, 2017 Posted January 14, 2017 As I had some funny issues with HDMI once, I changed the (brand new) cable with another (differrent cable) and it works ok since. Just sayin..
jernej Posted January 15, 2017 Posted January 15, 2017 @martiinsiimon, unfortunately I don't see nothing wrong. You wouldn't be the first to burn HDMI part. Actually, I heard for many such unfortunate situations.
martiinsiimon Posted January 15, 2017 Author Posted January 15, 2017 @Christos I'll try that, but now I'm rather skeptical. Anyway, thanks for the point. @jernej So I can probably join the club of "burned HDMI's". One way or another, I really thank you for your willingness!
Ford Prefect Posted January 16, 2017 Posted January 16, 2017 Hi In the set up of your TV isn't it possible to disable cec function ?
martiinsiimon Posted January 16, 2017 Author Posted January 16, 2017 @Ford Prefect Yes, it is, and now I can see I missed the "off" word in my initial post: So I tried to turn off cec at all. I turned it in tv everywhere, I unloaded the kernel module I created before, but again, no change. In other words, it didn't helped at all, in fact nothing changed.
Blars Posted January 17, 2017 Posted January 17, 2017 Strange HDMI problems can be caused by differing ground levels. The video signals are differential, but the control ones aren't. In my case, running an extra ground wire fixed the problem, there was a 2v DC offset between the two. 1
Recommended Posts