[Orange Pi 3] CEC no longer turns off TV on power off in 12.2.1 (worked in 12.0.2)

    Hi,

    After updating my Orange Pi 3 from LibreELEC 12.0.2 to 12.2.1 (via the GUI, LibreELEC-12.2 update channel), CEC no longer turns off the TV when I select "Power off" in Kodi. The Orange Pi itself shuts down normally, but the TV stays on.

    On 12.0.2 this works reliably with the exact same hardware, cabling and settings. I restored my 12.0.2 backup and the feature works again, so this looks like a regression in 12.2.x on H6.

    Setup:

    - Board: Orange Pi 3 (Allwinner H6), booting from SD card

    - Image: LibreELEC-H6.arm-12.2.1-orangepi-3 (updated from 12.0.2)

    - TV: Panasonic

    - Connection: direct HDMI to TV

    What works / doesn't work in 12.2.1:

    - Powering off LibreELEC from the GUI: TV does NOT turn off

    I noticed a similar report from a Pine H64 user (also H6) where CEC stopped switching off the TV after moving to 12.2, so it may affect H6 boards in general.

    I'm happy to test patches or nightly builds if that helps.

    Thanks!

    Quote from LaySoft

    I'm happy to test patches or nightly builds if that helps.

    I have no input on anything Allwinner, but the first action is always to test the latest available dev image and see if the issue persists or has magically fixed itself. Also check HDMI-CEC options in Kodi as the libCEC versions have bumped.

    Quote from chewitt

    I have no input on anything Allwinner, but the first action is always to test the latest available dev image and see if the issue persists or has magically fixed itself. Also check HDMI-CEC options in Kodi as the libCEC versions have bumped.

    Thanks for the reply!

    I tested the latest nightly (nightly-20261024-96d9f0f, 13.0, kernel 7.3.0)
    on a fresh SD card. CEC doesn't work there either, and it's actually
    worse: the EDID isn't read at all, so Kodi only offers 640x480, 800x600,
    848x480 and 1024x768 (the kernel's no-EDID fallback modes) and 1080p
    can't be selected.

    Regarding libCEC: I don't think this is a libCEC/Kodi settings issue,
    because the problem is visible at the kernel level, below libCEC. The
    kernel CEC adapter never gets a valid physical address, so libCEC can't
    allocate a logical address no matter what is configured in Kodi. I
    checked the Kodi CEC settings and tried the physical address override
    with 0 (auto) and 1000 - no change. Setting it via cec-ctl is refused
    by the driver ("The CEC adapter doesn't allow setting the physical
    address manually").

    Comparison on the same board, TV (Panasonic TX-P42U20E plasma) and cable:

    12.0.2 12.2.1 13.0 nightly
    Kernel 6.6.71 6.16.12 7.3.0
    HDMI status connected connected connected
    EDID size 256 256 0
    Physical Address 1.0.0.0 f.f.f.f f.f.f.f
    Logical Address 4 (Playback) Not Allocated Not Allocated
    DRM connector 51 53 -
    Max resolution 1080p 1080p 1024x768

    On 12.2.1 the EDID is read correctly and contains a valid CEC physical
    address, but it's not passed on to the CEC adapter:

    $ edid-decode /sys/class/drm/card0-HDMI-A-1/edid | grep -i "physical address"
    Source physical address: 1.0.0.0

    On 13.0 the EDID isn't read at all. There are no EDID read errors in
    dmesg, only empty ELD warnings:

    hdmi-audio-codec hdmi-audio-codec.3.auto: HDMI: Unknown ELD version 0
    /connector: Fixed dependency cycle(s) with /soc/hdmi@6000000

    So it looks like the HDMI/EDID -> CEC chain of sun8i-dw-hdmi on H6 broke
    with the newer kernels (6.16 and 7.3), while 6.6.71 works fine.

    Side note: Ethernet doesn't work on 13.0 either (enabling it in the GUI
    doesn't stick). The PHY isn't found:

    mdio_bus stmmac-0: MDIO device at address 1 is missing.
    dwmac-sun8i 5020000.ethernet eth0: cannot attach to PHY (error: -ENODEV)

    Full dmesg from 13.0: https://paste.libreelec.tv/unradioactive-magnolia.log

    I'm back on 12.0.2 for now, but I have spare SD cards with 12.2.1 and
    13.0 and I'm happy to test patches or new nightlies.

    Edited once, last by LaySoft (October 26, 2026 at 4:11 PM).

    Update / correction:

    Sorry for the confusion about the resolution issue in my previous post.
    After the 13.0 test, even 12.0.2 only offered 1024x768. Power-cycling
    the TV (unplugged for a few minutes) fixed it, so the "EDID = 0" result
    on 13.0 was caused by something getting stuck in the TV's HDMI/CEC
    controller, not by LibreELEC. After the TV power cycle, 13.0 also runs
    in 1080p and CEC works there.

    I retested everything after the TV power cycle (same board, TV
    Panasonic TX-P42U20E plasma, same cable):

                         12.0.2           12.2.1           13.0 nightly
    Kernel               6.6.71           6.16.12          7.3.0
    libCEC               not checked      7.1.1            8.1.7
    EDID size            256              256              256
    Physical Address     1.0.0.0          f.f.f.f          1.0.0.0
    Logical Address      4 (Playback)     Not Allocated    4 (Playback)
    CEC                  works            doesn't work     works
    Ethernet             works            works            doesn't work

    1) CEC issue in 12.2.1 (kernel side)

    The EDID is read correctly on 12.2.1 and contains a valid physical
    address:

    $ edid-decode /sys/class/drm/card0-HDMI-A-1/edid | grep -i "physical address"
    Source physical address: 1.0.0.0

    but the CEC adapter (sun8i-dw-hdmi, kernel 6.16.12) never gets it.
    Additional tests on 12.2.1, all after a TV power cycle:
    - The CEC adapter is attached to the right connector: connector_id of
    card0-HDMI-A-1 is 53, same as "DRM Connector Info" in cec-ctl.
    - "echo detect > /sys/class/drm/card0-HDMI-A-1/status" and physically
    re-plugging the HDMI cable don't help, physical address stays f.f.f.f.
    - With Kodi stopped (no libCEC involved), "cec-ctl --playback" alone
    still gives physical address f.f.f.f / Not Allocated.
    - Setting the physical address manually is refused by the driver ("The
    CEC adapter doesn't allow setting the physical address manually").

    So it's not a libCEC or Kodi settings issue: the physical address from
    the EDID doesn't reach the CEC adapter with kernel 6.16.12. It works
    again with kernel 7.3.0 in the 13.0 nightly. Any chance of a fix in a
    12.2.x release?

    2) Ethernet regression in the 13.0 nightly

    On 12.2.1 the PHY is found:
    eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
    On 13.0 (nightly-20261024-96d9f0f, kernel 7.3.0) the same PHY at
    address 1 is missing, so enabling Ethernet in the GUI doesn't stick:
    mdio_bus stmmac-0: MDIO device at address 1 is missing.
    dwmac-sun8i 5020000.ethernet eth0: cannot attach to PHY (error: -ENODEV)
    Full dmesg from 13.0: https://paste.libreelec.tv/unradioactive-magnolia.log

    I'm staying on 12.0.2 for now, but I keep SD cards with 12.2.1 and 13.0
    and I'm happy to test patches or new nightlies.

    Quote from jernej

    CEC was fixed few weeks ago in master. I don't think we'll release any 12.2 images, so it won't be backported. I'll check ethernet issue.

    Thanks for the quick answer! Good to know CEC is already fixed in master, I'll stay on 12.0.2 until 13.0 is released. Let me know if you need anything tested for the Ethernet issue, I have a spare SD card ready for new nightlies.

    Quote from jernej

    LaySoft please replace original dtb file with one from attached zip on FAT partition (small one) on 13.0 nightly image and check if ethernet is fixed.

    Thanks! I replaced /flash/sun50i-h6-orangepi-3.dtb with the one from
    your zip (13.0 nightly-20261024-96d9f0f), but Ethernet still doesn't
    work, the PHY is still not found:

    mdio_bus stmmac-0: MDIO device at address 1 is missing.
    dwmac-sun8i 5020000.ethernet eth0: cannot attach to PHY (error: -ENODEV)

    The new dtb is definitely loaded: extlinux.conf points to
    /sun50i-h6-orangepi-3.dtb (md5 differs from the original), and the
    running DT has phy-supply and phy-io-supply in the emac node, and
    reset-gpios / reset-assert-us / reset-deassert-us in the ethernet-phy@1
    node. Both PHY supplies are enabled according to regulator_summary
    (vcc33-audio-tv-ephy-mac 3300mV, gmac-2v5 2500mV).

    Full debug output (dtb md5sums, extlinux.conf, running DT nodes, dmesg,
    ip link, regulator summary):
    https://paste.libreelec.tv/columellar-santos.log

    GPIO / pinmux state:

    $ cat /sys/kernel/debug/gpio | grep -E "gpio-102 |gpio-110 "
    gpio-102 ( |gmac-2v5 ) out hi

    $ cat /sys/kernel/debug/pinctrl/300b000.pinctrl/pinmux-pins | grep -E "\(PD([0-9]|1[0-4]|19|20)\)"
    pin 96 (PD0): device 5020000.ethernet function emac group PD0
    ...
    pin 101 (PD5): device 5020000.ethernet function emac group PD5
    pin 102 (PD6): GPIO 300b000.pinctrl:102
    pin 103 (PD7): device 5020000.ethernet function emac group PD7
    ...
    pin 109 (PD13): device 5020000.ethernet function emac group PD13
    pin 110 (PD14): UNCLAIMED
    pin 115 (PD19): device 5020000.ethernet function emac group PD19
    pin 116 (PD20): device 5020000.ethernet function emac group PD20

    So all RGMII pins are muxed to emac and gmac-2v5 (PD6) is enabled, but
    PD14 (reset-gpios of ethernet-phy@1) is UNCLAIMED. Maybe the PHY is
    kept in reset: the reset GPIO of the PHY node is only handled after the
    PHY is detected on the MDIO bus, but it can't be detected while it's in
    reset?

    Happy to test another dtb.

    Here are two more test DTBs (please rename them properly when testing). Test A undoes most likely change which caused the issue (adding analog audio support) and test B tests another possible fix (adding PHY ID explicitly).


    EDIT: For each, please post dmesg | grep -iE 'mdio|stmmac|dwmac|eth0|ac200|gmac' and whether Ethernet gets a link.

    PD14 being unclaimed is expected (the reset GPIO is only taken after the PHY ID is read), but on OPi3 the PHY reset line also has its own RC pull-up, so it shouldn't stay in reset because of that.

    Quote from jernej

    Here are two more test DTBs (please rename them properly when testing). Test A undoes most likely change which caused the issue (adding analog audio support) and test B tests another possible fix (adding PHY ID explicitly).


    EDIT: For each, please post dmesg | grep -iE 'mdio|stmmac|dwmac|eth0|ac200|gmac' and whether Ethernet gets a link.

    PD14 being unclaimed is expected (the reset GPIO is only taken after the PHY ID is read), but on OPi3 the PHY reset line also has its own RC pull-up, so it shouldn't stay in reset because of that.

    Thanks! Both work. Results on 13.0 nightly-20261024-96d9f0f:

    Test A (AC200 disabled): Ethernet works, 1Gbps link, gets an IP address.

    [   10.284346] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
    [   10.284382] dwmac-sun8i 5020000.ethernet: IRQ sfty not found
    [   10.295594] dwmac-sun8i 5020000.ethernet: PTP uses main clock
    [   10.405859] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
    [   10.405895] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
    [   10.405900] dwmac-sun8i 5020000.ethernet: COE Type 2
    [   10.405906] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
    [   10.405913] dwmac-sun8i 5020000.ethernet: Normal descriptors
    [   10.405917] dwmac-sun8i 5020000.ethernet: Chain mode enabled
    [   10.780496] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [   10.783073] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
    [   10.784058] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
    [   10.784096] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
    [   10.784888] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
    [   10.784926] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-txid link mode
    [   14.853314] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

    $ ip addr show eth0
    3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
       link/ether 02:07:66:5a:16:5d brd ff:ff:ff:ff:ff:ff
       inet 192.168.111.134/24 brd 192.168.111.255 scope global eth0

    Test B (explicit PHY ID, AC200 enabled): Ethernet works as well,
    1Gbps link, gets an IP address, and AC200 is probed.

    [    0.550375] ac200 1-0010: AC200 rev 101 in package 1
    [    0.554124] platform ac200-codec: DMA mask not set
    [    1.155817]   #1: ac200-audio
    [   10.359765] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
    [   10.359800] dwmac-sun8i 5020000.ethernet: IRQ sfty not found
    [   10.362898] dwmac-sun8i 5020000.ethernet: PTP uses main clock
    [   10.363909] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
    [   10.363947] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
    [   10.363952] dwmac-sun8i 5020000.ethernet: COE Type 2
    [   10.363959] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
    [   10.363966] dwmac-sun8i 5020000.ethernet: Normal descriptors
    [   10.363971] dwmac-sun8i 5020000.ethernet: Chain mode enabled
    [   11.820193] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [   11.824499] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
    [   11.825511] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
    [   11.825543] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
    [   11.826122] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
    [   11.826155] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-txid link mode
    [   14.880904] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

    $ ip addr show eth0
    3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
       link/ether 02:07:66:5a:16:5d brd ff:ff:ff:ff:ff:ff
       inet 192.168.111.134/24 brd 192.168.111.255 scope global eth0

    So Test B seems preferable, since it fixes Ethernet while keeping the
    AC200 analog audio enabled. Happy to test the final image when it's
    ready.

    Quote from jernej

    Great! Now please do a last test from attached dtb file (don't forget to rename!). It will show if phy reset is enough, or it really needs also regulator fix.

    After that, I'll make PR for nightly image.

    Test C on 13.0 nightly-20261024-96d9f0f: Ethernet works too, 1Gbps link,
    gets an IP address, AC200 is probed.

    $ dmesg | grep -iE 'mdio|stmmac|dwmac|eth0|ac200|gmac'
    [    0.543689] ac200 1-0010: AC200 rev 101 in package 1
    [    0.547667] platform ac200-codec: DMA mask not set
    [    1.157489]   #1: ac200-audio
    [   11.153655] dwmac-sun8i 5020000.ethernet: IRQ eth_wake_irq not found
    [   11.153689] dwmac-sun8i 5020000.ethernet: IRQ sfty not found
    [   11.154277] dwmac-sun8i 5020000.ethernet: PTP uses main clock
    [   11.159463] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
    [   11.159488] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
    [   11.159493] dwmac-sun8i 5020000.ethernet: COE Type 2
    [   11.159501] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
    [   11.159507] dwmac-sun8i 5020000.ethernet: Normal descriptors
    [   11.159513] dwmac-sun8i 5020000.ethernet: Chain mode enabled
    [   11.801226] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [   11.804375] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
    [   11.805385] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
    [   11.805418] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
    [   11.810090] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
    [   11.810131] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-txid link mode
    [   14.854127] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

    $ ip addr show eth0
    3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
       link/ether 02:07:66:5a:16:5d brd ff:ff:ff:ff:ff:ff
       inet 192.168.111.134/24 brd 192.168.111.255 scope global eth0

    $ grep -E "gmac-2v5|ethernet-phy-io" /sys/kernel/debug/regulator/regulator_summary
    gmac-2v5                         1    1      0 unknown  2500mV     0mA  2500mV  2500mV
       5020000.ethernet-phy-io       1                                 0mA     0mV     0mV

    So the explicit PHY ID alone is enough, regulator-always-on on gmac-2v5 is not needed (use count is now 1 instead of 2, only the PHY keeps it enabled). Thanks for the quick fix, I'll test the nightly with the PR when it's available!