HDMI-CEC won't work on Buster Legacy (4.4.213-rockchip64)

[alsc]

Armbianmonitor:

http://ix.io/2Is3

Hello,

 

I own a RockPro64 and I'm using Armbian Legacy Buster 4.4.213-rockchip64. Everything mostly works, although I've had a pretty annoying issue. Reboot just doesn't work.

 

Every time I do a 'sudo reboot' (or any equivalent for that matter, as for example 'sudo shutdown -r now') it doesn't work. Although it apparently reboots, the TV monitor to which my box it's connected via HDMI lose connection and all, nothing actually happens. Both the red and the white leds of the RP64 turn on and keep on all time (instead of just one of them blinking, as expected) and then it will work only if I poweroff and on again, either by unplugging the power cable or pushing the reset button. That's pretty annoying, since for obvious reasons I can't remotely reboot the machine...

 

I noticed that it only happens with the legacy kernels (I've tried Armbian and Ayufan, both have the exact same behavior). Current kernels work properly, but I really need, at least for now, keep using legacy (I'm trying to use the tool provided by the developer JMCC in order to use Kodi and it doesn't work on mainline so fat).

 

I've googled for a while for this specifc issue and used the search from this forum but found nothing.

 

Any help would be very appreciated.

[TRS-80]

45 minutes ago, alsc said:

I'm trying to use the tool provided by the developer JMCC in order to use Kodi and it doesn't work on mainline so fat

 

Are you referring to the following (just announced today in fact!) or his previous version of same?

 

RK3399 Legacy Multimedia Framework

[alsc]

14 minutes ago, TRS-80 said:

 

Are you referring to the following (just announced today in fact!) or his previous version of same?

 

RK3399 Legacy Multimedia Framework

 

 

I'm referring to this newer one (that I installed as soon as I saw JMCC's post), although I was never able to soft reboot using legacy kernels no matter which one I used (and I don't think the use of this tool, either the old or the new one, would have made any difference on this matter anyway)..

 

In fact I had already given up trying to make a server with Kodi work with a legacy kernel. Mainly because of this reboot issue, but also because of the lack of HDMI-CEC support, that tried to enable on a customized kernel as described at the Armbian documentation, but wasn't successful. So I just gave up...

 

Then I saw the new tool JMCC released and decided to give it another try, imagining that maybe any new kernel release would have solved the cec and the reboot stuff, but apparently they're still not working.

[TRS-80]

1 hour ago, alsc said:

Then I saw the new tool JMCC released and decided to give it another try, imagining that maybe any new kernel release would have solved the cec and the reboot stuff, but apparently they're still not working.

 

Aah, sorry to hear that.  Yes this was my hope for you as well.

 

I had similar issue some time ago with some different board.  I had seriously considered plugging power supply into something like Tasmota or other internet controlled switched outlet as a hacky work-around in the meantime, but then the problem must have gone away because it never really became a priority to implement that.  Just an idea (especially if that's something you have laying around or might be interested in anyway)?

[JMCC]

2 hours ago, alsc said:

maybe any new kernel release would have solved the cec and the reboot stuff

I am not sure about the reboot issue, since I don't own a RockPro64. But I tested the CEC issue in my Rockpi4, and it is not working either. I will look into it with God's favor.

[alsc]

16 hours ago, TRS-80 said:

 

Aah, sorry to hear that.  Yes this was my hope for you as well.

 

I had similar issue some time ago with some different board.  I had seriously considered plugging power supply into something like Tasmota or other internet controlled switched outlet as a hacky work-around in the meantime, but then the problem must have gone away because it never really became a priority to implement that.  Just an idea (especially if that's something you have laying around or might be interested in anyway)?

In fact I'd never heard of these Internet controlled switches. I appreciate the suggestion and I'll Google it to see if I may adapt it to my needed. Thank you for your interest. 

[alsc]

15 hours ago, JMCC said:

I am not sure about the reboot issue, since I don't own a RockPro64. But I tested the CEC issue in my Rockpi4, and it is not working either. I will look into it with God's favor.

Believe me, it would be perfect if you could find a solution.

 

I tried to compile the kernel myself with cec as you suggested on the other thread (I still have the resulting generated deb files) but although it got installed without errors it made no difference. In fact a "uname -a" run after the installation and reboot showed what appeared to be the exact same kernel, as if no changes were made.. it was probably some mistake I made due to inexperience...

 

Again, a working cec support on these RP64 would be amazing.

[TRS-80]

9 minutes ago, alsc said:

In fact I'd never heard of these Internet controlled switches. I appreciate the suggestion and I'll Google it to see if I may adapt it to my needed. Thank you for your interest. 

 

Beside your current problem, they are super cool, anyway!  I mean, if you are into SBC, maybe you are (or will get) into these, too.  Many of us are doing Home Automation stuff, as well, with our SBCs! 

 

There is a whole world of different radios you can use, but for this the Wi-Fi based ones (searching Tasmota will get you started, but there are others, too) will probably fit your need best.

 

Wi-Fi switches (Tasmota especially) are even quite easy to get working these days, there is a pretty big community around them, etc.

 

[JMCC]

3 hours ago, alsc said:

Again, a working cec support on these RP64 would be amazing.

 

Can you please post the output of

apt install cec-utils -y -qq
ls -l /dev/cec*
cec-client -l

-

[alsc]

2 hours ago, JMCC said:

 

Can you please post the output of

apt install cec-utils -y -qq
ls -l /dev/cec*
cec-client -l

-

 

Sure. I'd already tried to install this cec-utils before, btw.

 

And sorry I didn't post it with the correct code indentation. I'm using the smartphone and it's kind of hard to write...

 

root@nostromo:~# ls -l /dev/cec*
crw-rw---- 1 root video 249, 0 dez 17 19:17 /dev/cec0

 

root@nostromo:~# cec-client -l
libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC
Found devices: NONE

 

[JMCC]

16 hours ago, alsc said:

Sure. I'd already tried to install this cec-utils before

It looks like it is a userspace problem, with Buster libcec not supporting the Rockchip interface. Can you please install the packages from here: https://users.armbian.com/jmcc/packages/libcec/

 

Then do the following tests, with your CEC monitor/TV plugged:

sudo cec-client -l

sudo apt install v4l-utils -y -qq
sudo cec-compliance -v -T -d0

(If the above fails with "Missing logical address", try the following and then repeat):
sudo cec-ctl --phys-addr=2.0.0.0 --playback
sudo cec-compliance -v -T -d0

 

For last, enable CEC in Kodi, and see if it works.

Thanks.

[alsc]

Hello,

 

Followed your instructions, but it still doesn't work.

 

Not sure what I should have expected, but what happens is that after doing what you told I both restarted just the Kodi proccess (systemctl restart Kodi-gbm) and then reboot the board itself, but there's no option on input peripheral to configure (which means that Kodi doesn't 'see' cec). Also the tv hdmi configurations shows no hdmi device connect (when I'm using LibreELEC I can see my device listed).

 

As I said I'm accessing my board remotely via smartphone and it's kinda hard to copy / paste, etc, so Im attaching the output of each of your suggested commands in separate files (in the order you told to do).

 

The weird part is that it doesn't seem to have error messages, which means that apparently it should be working...

 

Thanks for taking the time to look into problem.

 

01_cec-ctl 02_cec-compliance_after 00_cec_compliance_before

[JMCC]

7 hours ago, alsc said:

Followed your instructions

You forgot the output of "cec-client -l", that one is important! 

 

Install the new packages I created (file names are the same, but they are different):  https://users.armbian.com/jmcc/packages/libcec/

 

Then, post the output of

sudo cec-client -l
sudo cec-compliance -v -T -d0

 

And try Kodi again.

 

We are making baby steps, in order to identify the problem. Sorry, I don't own the board nor any CEC-capable monitor, so I cannot test myself. If it still doesn't work this time, don't worry, we still have two more steps that we need to check.

[alsc]

21 minutes ago, JMCC said:

You forgot the output of "cec-client -l", that one is important! 

 

Install the new packages I created (file names are the same, but they are different):  https://users.armbian.com/jmcc/packages/libcec/

 

Then, post the output of

sudo cec-client -l
sudo cec-compliance -v -T -d0

 

And try Kodi again.

 

We are making baby steps, in order to identify the problem. Sorry, I don't own the board nor any CEC-capable monitor, so I cannot test myself. If it still doesn't work this time, don't worry, we still have two more steps that we need to check.

 

 

Just to you to know, each time I install the packages you asked to (dpkg -i *.deb) I got the following message:

 

ldconfig: /lib/aarch64-linux-gnu/libGL.so.1 is not a symbolic link

 

 

And here you have it:

 

root@nostromo:/home/leonardocaldas# cec-client -l
libCEC version: 4.0.7, git revision: libcec-4.0.7+4-d6c8709~dirty, compiled on 2020-07-09 22:37:00 by root@localhost on Linux 5.4.0-52-generic (aarch64), features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC, 'i.MX6'
cec-client: symbol lookup error: /lib/aarch64-linux-gnu/libcec.so.4: undefined symbol: _ZN3CEC27CTDA995xCECAdapterDetection11FindAdapterEv

root@nostromo:/home/leonardocaldas# cec-compliance -v -T -d0
                CEC_ADAP_G_CAPS returned 0 (Success)
cec-compliance SHA                 : not available
                CEC_ADAP_G_PHYS_ADDR returned 0 (Success)
                CEC_ADAP_G_LOG_ADDRS returned 0 (Success)
Driver Info:
        Driver Name                : dwhdmi-rockchip
        Adapter Name               : dw_hdmi
        Capabilities               : 0x0000000e
                Logical Addresses
                Transmit
                Passthrough
        Driver version             : 4.4.213
        Available Logical Addresses: 4
        Physical Address           : 1.0.0.0
        Logical Address Mask       : 0x0010
        CEC Version                : 2.0
        Vendor ID                  : 0x000c03 (HDMI)
        OSD Name                   : Playback
        Logical Addresses          : 1 (Allow RC Passthrough)

          Logical Address          : 4 (Playback Device 1)
            Primary Device Type    : Playback
            Logical Address Type   : Playback
            All Device Types       : Playback
            RC TV Profile          : None
            Device Features        :
                None

Compliance test for device /dev/cec0:

    The test results mean the following:
        OK                  Supported correctly by the device.
        OK (Not Supported)  Not supported and not mandatory for the device.
        OK (Presumed)       Presumably supported.  Manually check to confirm.
        OK (Unexpected)     Supported correctly but is not expected to be supported for this device.
        OK (Refused)        Supported by the device, but was refused.
        FAIL                Failed and was expected to be supported by this device.

Find remote devices:
                MSG_POLL: Sequence: 181 Tx Timestamp: 29337.413s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 182 Tx Timestamp: 29337.472s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 183 Tx Timestamp: 29337.533s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 184 Tx Timestamp: 29337.592s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 185 Tx Timestamp: 29337.592s Length: 1
                        Status: Tx, Not Acknowledged (1), Max Retries
                MSG_POLL: Sequence: 186 Tx Timestamp: 29337.652s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 187 Tx Timestamp: 29337.711s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 188 Tx Timestamp: 29337.771s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 189 Tx Timestamp: 29337.830s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 190 Tx Timestamp: 29337.889s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 191 Tx Timestamp: 29337.949s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 192 Tx Timestamp: 29338.008s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 193 Tx Timestamp: 29338.068s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 194 Tx Timestamp: 29338.127s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 195 Tx Timestamp: 29338.186s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
        Polling: OK

Network topology:

Total: 1, Succeeded: 1, Failed: 0, Warnings: 0

 

As you can see, there's an error in the output of the first command that wasn't happening with the first bunch of packages I installed a couple of hours ago.

 

Edit: And by the way, now Kodi stopped working. I rebooted with no success...

[JMCC]

1 hour ago, alsc said:

there's an error in the output of the first command that wasn't happening with the first bunch of packages

Okay, new bunch of packages. Please do the same tests

[alsc]

16 minutes ago, JMCC said:

Okay, new bunch of packages. Please do the same tests

 

Whatever you did now it's almost working!

 

I mean, I got a different message to the first command:

root@nostromo:/mnt/Dados# sudo cec-client -l
libCEC version: 4.0.7, git revision: libcec-4.0.7+4-f9bb94a~dirty, compiled on 2020-07-09 22:37:00 by root@localhost on Linux 5.4.0-52-generic (aarch64), features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC
Found devices: 1

device:              1
com port:            Linux
vendor id:           0000
product id:          0000
firmware version:    0
type:                Linux

 

 

So now when I start kodi-gbm it now shows the popup telling that the CEC Pulse8 Peripheral was detected and also there's the option to configure the CEC options (this is the very first time I'm able to use this option on a Armbian legacy kernel).

 

And here goes the output of the second command:

 

leonardocaldas@nostromo:~$ sudo cec-compliance -v -T -d0
                CEC_ADAP_G_CAPS returned 0 (Success)
cec-compliance SHA                 : not available
                CEC_ADAP_G_PHYS_ADDR returned 0 (Success)
                CEC_ADAP_G_LOG_ADDRS returned 0 (Success)
Driver Info:
        Driver Name                : dwhdmi-rockchip
        Adapter Name               : dw_hdmi
        Capabilities               : 0x0000000e
                Logical Addresses
                Transmit
                Passthrough
        Driver version             : 4.4.213
        Available Logical Addresses: 4
        Physical Address           : 1.0.0.0
        Logical Address Mask       : 0x0002
        CEC Version                : 1.4
        Vendor ID                  : 0x001582 (Pulse-Eight)
        OSD Name                   :
        Logical Addresses          : 1 (Allow Fallback to Unregistered)

          Logical Address          : 1 (Recording Device 1)
            Primary Device Type    : Record
            Logical Address Type   : Record

Compliance test for device /dev/cec0:

    The test results mean the following:
        OK                  Supported correctly by the device.
        OK (Not Supported)  Not supported and not mandatory for the device.
        OK (Presumed)       Presumably supported.  Manually check to confirm.
        OK (Unexpected)     Supported correctly but is not expected to be supported for this device.
        OK (Refused)        Supported by the device, but was refused.
        FAIL                Failed and was expected to be supported by this device.

Find remote devices:
                MSG_POLL: Sequence: 1464 Tx Timestamp: 812.724s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1466 Tx Timestamp: 812.725s Length: 1
                        Status: Tx, Not Acknowledged (1), Max Retries
                MSG_POLL: Sequence: 1467 Tx Timestamp: 812.842s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1468 Tx Timestamp: 812.902s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1469 Tx Timestamp: 812.962s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1470 Tx Timestamp: 813.021s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1471 Tx Timestamp: 813.080s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1472 Tx Timestamp: 813.140s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1473 Tx Timestamp: 813.200s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1474 Tx Timestamp: 813.265s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1475 Tx Timestamp: 813.325s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1476 Tx Timestamp: 813.384s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1477 Tx Timestamp: 813.444s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1478 Tx Timestamp: 813.503s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
                MSG_POLL: Sequence: 1479 Tx Timestamp: 813.563s Length: 1
                        Status: Tx, Not Acknowledged (2), Max Retries
        Polling: OK

Network topology:

Total: 1, Succeeded: 1, Failed: 0, Warnings: 0

 

The only thing is that although Kodi detects the CEC structure, the remote still doesn't work.

 

I've tried to make a couple of changes both using that command line which changes the hdmi physical address and trying to change them (both the hdmi physical address and port) on the Kodi config options. But it didn't work. In fact, in the case of Kodi no matter which physical address I fill as soon as I restart it comes back to what I imagine is the default (1000).

 

[JMCC]

13 minutes ago, alsc said:

now it's almost working!

Good! We cleared out the libcec part.

 

Now, let us try some kernel tweaks. Install these kernel+dtb packages, reboot and try kodi again: https://users.armbian.com/jmcc/packages/kernel-rk64/

[alsc]

5 minutes ago, JMCC said:

Good! We cleared out the libcec part.

 

Now, let us try some kernel tweaks. Install these kernel+dtb packages, reboot and try kodi again: https://users.armbian.com/jmcc/packages/kernel-rk64/

 

It worked! As soon as I rebooted after installing this new kernel it immediately worked!

 

Thank you so very much for your invaluable help! After months of unsuccessful trials it's finally working. 

 

Is there a way these modifications you did (the kernel and the other patched packages) may become available by default on the RockPro64 Armbian image? It would make the Kodi part of your multimedia project even more complete and attractive to people with this specific board.

 

[JMCC]

3 minutes ago, alsc said:

(the kernel and the other patched packages) may become available by default on the RockPro64 Armbian image?

That was the intention, and the purpose of all the testing we did 

[test0x01]

Module dw-hdmi-cec is not enabled by default in legacy kernel for RK3399 chips. After enable this option in kernel, CEC starts working.

# CONFIG_DRM_DW_HDMI_CEC is not set

[JMCC]

Module dw-hdmi-cec is not enabled by default in legacy kernel for RK3399 chips. After enable this option in kernel, CEC starts working.
# CONFIG_DRM_DW_HDMI_CEC is not set

There are two different kernels for RK3399, which one are you talking about? I guess it is the rk3399, not he rockchip64. What is the board?

Enviado desde mi moto g(6) plus mediante Tapatalk

[test0x01]

On 12/22/2020 at 4:56 PM, JMCC said:

There are two different kernels for RK3399, which one are you talking about? I guess it is the rk3399, not he rockchip64. What is the board?

Enviado desde mi moto g(6) plus mediante Tapatalk
 

Yes, it is rk3399. My board is nanopct4.

[Werner]

56 minutes ago, test0x01 said:

Yes, it is rk3399. My board is nanopct4.

Misunderstanding. @JMCCasked for the kernel, not the SoC. Just look for uname -a if the output states rockchip64 or rk3399

[JMCC]

Misunderstanding. [mention=7899]JMCC[/mention]asked for the kernel, not the SoC. Just look for uname -a if the output states rockchip64 or rk3399

It's OK, nanopct4 has rk3399 kernel. It is good to know that it only needs kernel configs to be enabled, unlike the rockpi and rockpro64 that needed DT patches in the rockchip64 kernel

Enviado desde mi moto g(6) plus mediante Tapatalk

[alsc]

On 12/19/2020 at 9:04 PM, JMCC said:

Good! We cleared out the libcec part.

 

Now, let us try some kernel tweaks. Install these kernel+dtb packages, reboot and try kodi again: https://users.armbian.com/jmcc/packages/kernel-rk64/

 

Hello JMCC,

 

I've been using the legacy kernel with Kodi and your multimedia solution and it's been working very well (apart from that reboot problem, but... well... I just sort of got used to it, and all).

 

The issue I have is about lots of kernel error messages I'm getting. I sincerely don't remember if they already existed on the old kernel, although I believe not, since they are so many that would certainly got my attention, and I'm afraid it may be somehow corrupting data.

 

At first I get these messages:

[  656.941038] zram: Decompression failed! err=-22, page=12547
[  656.941050] zram: Decompression failed! err=-22, page=12547
[  656.942641] zram: Decompression failed! err=-22, page=12616
[  656.942656] zram: Decompression failed! err=-22, page=12616
[  656.946072] zram: Decompression failed! err=-22, page=3109
[  656.946370] zram: Decompression failed! err=-22, page=3109
[  656.946378] zram: Decompression failed! err=-22, page=3109

 

They keep repeating to the point that there's nothing more on dmesg but them.

 

Then, after a while I also get these messages:

[283017.217836] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC
[283055.643907] EXT4-fs error (device zram0): ext4_find_extent:916: inode #22: comm sshd: pblk 1635 bad header/extent: extent tree corrupted - magic f30a, entries 69, max 340(340), depth 0(0)
[283055.645528] EXT4-fs error (device zram0): ext4_ext_remove_space:2999: inode #22: comm sshd: pblk 1635 bad header/extent: extent tree corrupted - magic f30a, entries 69, max 340(340), depth 0(0)
[283055.646503] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC

 

And finally it gets to the point that the disk gets unavailable and only works if a reboot.

 

The messages refer to an external USB 3 disk and I know that it's working fine because if I switch to the LibreELEC sd card it never show these error messages.

 

A appreciate any help you could give me.

 

I believe it's somehow related to zram. I have the zram-tools package installed, but it's probably some issue on the kernel level.

 

[JMCC]

1 hour ago, alsc said:

I've been using the legacy kernel

Arre you talking about the tweaked kernel I linked above? That was just for testing. Now, the relevant changes are merged into the build script. So, if you are still using the testing version, just install a recently built kernel: either build your own debs with the build script, download it from beta, or wait for the next stable release.

 

The errors you show are not critical, it seems like probably EXT4 debug was enabled on that kernel. If after switching to the official kernel the problem persists, we'll look into it.