• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

[WIP]hdmi cec driver for H3
2 2

28 posts in this topic

Recommended Posts

Hi,

i'm working on a hdmi cec driver for H3 and i'm looking for some feedback how the driver works. I have tested the driver with OrangePi PC and a Samsung TV.

I have pushed my driver to github : https://github.com/jodamm/linux/tree/sun8i or here is a patch file that can be placed in userpatches for armbian toolchain.

The driver can be loaded with modprobe hdmi_cec .

I have modified libcec to work with this driver : https://github.com/jodamm/libcec or again a patch file for libcec.

Share this post


Link to post
Share on other sites

Is this the same that you did for sun4/7i?

If not, we should find some testers for it, too :P

Thanks

rellla

No it's a new one :P , but i will rewrite the one for sun4/7i to be compatible with this libcec changes and hopefully better timing. Now i can test it better with 2 different devices. With this driver i tried to use the cec hardware but either there is something wrong with how Allwinner integrated it in H3, how it is wired on my Orange Pi PC or there is still some secret register setting. I could only get the hardware to either send or receive. But for receiving messages they have to be ACKed so i came up with some sort of bit banging. If it is receiving, i count the received bits and when it comes to the ack bit, i switch from receiving to sending for 1 bit.

Share this post


Link to post
Share on other sites

Just a few small observations:

1. Could you change SUNXI_ADAPTER_PID to something else? On systems with imx6 patches also applied, libcec crashes (OpenELEC).

2. Your kernel patch from server doesn't apply cleanly due to different end of line marker. Patch downloaded from github works, though.

3. Documentation has a typo. It suggests using "cmake -DHAVE_SUNXI_LIB=1 .." while it should "cmake -DHAVE_SUNXI_API=1 .."

 

Great job otherwise! I will test it tomorrow hopefully.

Share this post


Link to post
Share on other sites

Just a few small observations:

1. Could you change SUNXI_ADAPTER_PID to something else? On systems with imx6 patches also applied, libcec crashes (OpenELEC).

2. Your kernel patch from server doesn't apply cleanly due to different end of line marker. Patch downloaded from github works, though.

3. Documentation has a typo. It suggests using "cmake -DHAVE_SUNXI_LIB=1 .." while it should "cmake -DHAVE_SUNXI_API=1 .."

 

Great job otherwise! I will test it tomorrow hopefully.

Thanks for your feedback.

1. hopfully fixed.

2. fixed.

3. No, it's not a typo, more a workaround. The bug introduced with this commit was never fixed.

Share this post


Link to post
Share on other sites

@Melanrz,

no, it works without board modifications. That is the beauty of it.

 

@jodamm,

while I couldn't test it due to bad TV CEC support but others did and they report that everything works if TV is already on. Once you turn off and on again TV, it stops working. I compared your kernel code with the imx6 one and I noticed that your code doesn't have "HDMI cable connect/disconnect" hooks. Do you think that is the reason?

Share this post


Link to post
Share on other sites

@jodamm,

while I couldn't test it due to bad TV CEC support but others did and they report that everything works if TV is already on. Once you turn off and on again TV, it stops working. I compared your kernel code with the imx6 one and I noticed that your code doesn't have "HDMI cable connect/disconnect" hooks. Do you think that is the reason?

 

I can reproduce this error, i will investigate it. But i think that something in HDMI driver overwrites registers when reconnecting.

Share this post


Link to post
Share on other sites

Just out of curiosity, how did you found HDMI_H3_PHY_CEC register at address 0x1003c?

You have posted it :D . In Orange Pi forum first hdmi_write in your code box.

 

I have found the cause of the problem with turning TV off and on. On reconnect init_hdmi is called and it overwrites two registers needed for my driver. I'm not sure how to fix it. Change the hdmi_init so that it wouldn't overwrite the registers or let the driver somehow know that it has to reset the registers.

Share this post


Link to post
Share on other sites

Uh, I was wondering what's that for. I didn't think it could be directly connected to CEC :wacko:

 

Currently I can't help you much. Maybe in a few days?

 

EDIT: Which registers exactly?

EDIT2: I see, I think it would be safe to call this function only at driver init, at least that mainline driver does. I will test once I will have time.

Edited by jernej

Share this post


Link to post
Share on other sites

I have found the cause of the problem with turning TV off and on. On reconnect init_hdmi is called and it overwrites two registers needed for my driver. I'm not sure how to fix it. Change the hdmi_init so that it wouldn't overwrite the registers or let the driver somehow know that it has to reset the registers.

 

Maybe something like this: https://transfer.sh/12Ss3a/linux-011-disp2-keep-cec-signals.patch

It preserves HDMI_CEC_MASK and HDMI_CEC_MASK, doesn't make software reset in HDMI_MC_SWRSTZ register and doesn't disable clock in HDMI_MC_CLKDIS register. Only question remains if register at address 0x10020 could hurt this or not.

Share this post


Link to post
Share on other sites

Maybe something like this: https://transfer.sh/12Ss3a/linux-011-disp2-keep-cec-signals.patch

It preserves HDMI_CEC_MASK and HDMI_CEC_MASK, doesn't make software reset in HDMI_MC_SWRSTZ register and doesn't disable clock in HDMI_MC_CLKDIS register. Only question remains if register at address 0x10020 could hurt this or not.

That should work, a restart of cec-client was enough to communicate again. But i'm working on solution two, i wanted the plug and unplug events too for the cec driver.

Share this post


Link to post
Share on other sites

Ok, it seems best not to use that patch because it breaks suspend/resume. You are right that second solution is best. Where do you plan to make hooks? Iniside drv_hdmi.c, using function Hdmi_hpd_event() or hdmi_report_hpd_work()? The latter would need to be fixed on two places...

Share this post


Link to post
Share on other sites

It's hard to trace through Allwinner's code, but do you know by any chance why suspend and resume wouldn't work? It seems to me that you already have notification for that, but I'm not sure.

 

One user reports that CEC diagnostic would often crash OPi Plus board. Any thoughts on that? I really don't know how diagnostic looks like...

 

EDIT: It seems that hdmi suspend function is not called anywhere.

EDIT2: Or it is... Can you just check that suspending turns tv off?

Edited by jernej

Share this post


Link to post
Share on other sites

I had a buffer overflow in the last patch, maybe that is causing the CEC diagnostic to crash the OPi. I will release a new patch later, i will do some testing first.

 

When i poweroff openelec, the TV is not suspended or switched to other input, just signal will go off. Are there settings to change this behaviour?

I had it once that i could not get the OPiPC out off suspend with the power button, but after that i tested it at least 20 times without problems.

 

I will try to implement that the OPi can be waked up from the TV over CEC, but that will take some time to programm and test it.

With the screensaver i have no clue what settings i should try to test the issues the testers had.

Share this post


Link to post
Share on other sites

Thanks for looking into issues.

 

Power off in Kodi is actually suspend, not a proper shutdown. Otherwise it wouldn't be possible to wake it up. You can debug this issues with appending "no_console_suspend" in U-Boot kernel parameters and executing "echo 8 > /proc/sys/kernel/printk" in console. I think that at least some messages will be useful to you. There is also another bug at suspend. If you have USB hub connected to any port and that hub has some USB device connected to it, it will crash at suspending (watchdog timer). I tried to debug this issue, but I couldn't find what is wrong. You can do a proper shutdown from console with standard "shutdown now" commnad.

 

Don't mind screensaver issue. It might be because of buffer overflow you mentioned or some other thing. If it will still exist after your bugfix, I will check the code what is happening in that moment.

Share this post


Link to post
Share on other sites

I found the settings for CEC, if i turn the option "send TV to standby with kodi" to off, the TV will switch back to satellite. It seems it depends on the TV what will work and what not.

And i found a situation when the OPi will not come out of suspend. If OPi is in suspend and i turn TV off, OPi can only be reseted with unpluging powersupply. At least something i can debug the next days.

Btw i have a problem with setting ip address to manual, only off and dhcp will work. Where i can find the settings, so i can change it over ssh?

Share this post


Link to post
Share on other sites

Github repository and patchfile updated. Small change: wait for free cec line before sending messages and fix for wrong array sizes.

Share this post


Link to post
Share on other sites

One user reports constant freezes for 1-2 seconds after every button press and that suspend/resume cycle works only first time. Tested on LG TV if that helps anything.

Share this post


Link to post
Share on other sites

hello, thanks for patch i want to test it on my Orange Pi lite with armbian (controling with Domoticz)
i allready compiled patched libcec, but i have problems with compiling Driver...

anyone can help?

do i have to clone whole repo or patch somehow my kernel src files ?

thanks!

Share this post


Link to post
Share on other sites

Should be great to have a package to install :))))

 

I have compiled libcec but I don't really understand how to install the driver....

Toolchain is necessary ? I don't understand, I must install all the drivers the git repo contains ?

It should be great to detail how to do in command lines :))))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

2 2

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.