Official LE13 Test Images for Amlogic (Kodi-22)

    Using some initial work from https://github.com/mczerski - Claude and I (mostly Claude) have made some progress on mainline DVB support: https://paste.libreelec.tv/moving-lab.log .. the above is from a WeTek Play2 box.

    Before anyone gets wildly excited, the vendor kernel demux driver that Marek started porting is a festering ifdef nightmare that looks like it needs a lot of work and I have no way to test DVB-C, DVB-T, or DVB-S things; so I have no clue if the now-showing-up adapters do more than look pretty. Marek appears to have more of a clue about DVB things than me so cross fingers :)

    NB: I plan to dig out the DVB-S module for WP2 and an old O2.cz box that I have in a cupboard somewhere and get those working next. Once that's done I'll clean up the smorgasbord of patches, push branches to GitHub, and share some updated images.

    Hi everyone,

    I’ve managed to get the Amlogic mainline DVB driver working using software PID filtering. Currently, on the SM1 (S905X3 mecool K5 and magicsee c500 pro), it successfully detects and operates all Amlogic DVB modules and frontends using a single dmx0 driver. I have developed this according to modern kernel architecture. No high cpu usages. but libreelec vdec mpeg2 does not decode mpeg4 hw accelerations. software based decoding mpeg2 ok. But the video quality is not very good. It has nothing to do with the dvb driver anyway. But it streams perfectly to devices on the network.

    However, I haven't been able to get dmx1 and dmx2 working yet, as I haven't identified the correct offsets. Once those are functional and stable, I intend to share the full driver with the community. It works flawlessly on single-frontend devices and is compatible with the upstream mainline kernel.

    I have also drafted a new driver version for hardware PID filtering based on the vendor kernel architecture. If I can get the HW PID filter operational, I will share that as well. I believe this version serves as a solid starting point for further development."

    taki Interesting! .. but I would ask that you push current working code to a GitHub repo as it would make a lot of sense for Marek (and likely others) to collaborate on a clean demux rewrite that could eventually be upstreamed, than get too far down the road of reworking vendor code.

    NB: I have been poking around in the vdec code recently and have one MPEG2 video that now decodes (badly) which I guess is an improvement on no videos decoding. I have a hunch the underlying issue is about alignment of buffers to frame dimensions, but neither I or Claude managed to spot the problem yet. It continues to be something I tinker with (among many things) though.

    I think we must decide how we approach this topic. The work I did was more like a proof of concept that it is even possible to have DVB working under mainline kernel. To make it real it must be merged into upstream.

    taki You said:

    Quote from taki

    I have developed this according to modern kernel architecture.

    Is that mean that You wrote it from scratch or did You take the vendor driver and adapted it like I did ?
    One thing is to write driver code according to mainline kernel infrastructure, other thing is to have this driver merged into upstream. I do not have expirience in pushing code to mainline kernel but I think that the code from my branch is far from this goal :D

    Ahh, rozpruwacz is Marek :)

    I now have the DVB-S and DVB-T tuners for the WeTek Play2 and the DVB-T tuner in the O2.cz box showing up in Tvheadend. I am able to run a scan without errors. However I have no Satellite dish or Terrestrial antenna to connect them to so all scans find zero services (as expected) so it's impossible to tell whether anything is really working :(

    I've pushed an updated set of images to my testing share. The WP2 image and 'box' image will boot the default WP2 device-tree which contains no DVB support, so you will need to edit extlinux.conf or uEnv.ini and change the dtb name to one of:

    • meson-gxbb-wetek-play2-atsc.dtb <= might not work, I didn't find the ATSC tuner module to test yet
    • meson-gxbb-wetek-play2-dvb-s.dtb
    • meson-gxbb-wetek-play2-dvb-t.dtb

    The O2.cz box (SML-5442TW) and the GTMEDIA GTT-2 box Marek has been using both have DVB support enabled.

    Once WP2 is rebooted with the correct device-tree file dmesg should show the cards, and you can install Tvheadend43 (or VDR) to scan for services. I'm a bit vague on the remaining process as (as mentioned) I can't test anything.

    rawnar I've also included a WeTek Hub image in the test share. Apologies for the long wait, I got a bit distracted.

    Of course, I didn't write the driver from scratch. I’m not a professional programmer or developer; I’m doing this as a hobby. You likely know coding much better than I do. That said, I’m not completely clueless about Linux and C++; it would be impossible to create a driver of this complexity without at least some understanding. My goal isn't to upstream anything; it’s simply to enable DVB streaming since USB tuner prices have become so expensive.

    Using the sti driver (from the Google Git kernel common) as a reference, I used DeepSeek to generate the backbone and developed the driver step-by-step by fixing numerous bugs. One of the biggest problems is that most of the demos and tuners used by amlogic devices are not available in the mainline kernel. While testing the driver, it was not possible to know whether the presence or absence of signal was due to the dvb driver or the frontend. Sometimes fake signal and i2c error etc. It was like looking for a needle in a haystack. Honestly, this could be a PhD thesis topic: creating a functional kernel module in a complex structure using guided AI. I conducted many tests, including address verification via devmem, etc.

    The final piece of the puzzle is AML_MEM_REQ_EN_SW—everything works with it. However, it fails with AML_MEM_REQ_EN_HW. The software driver works perfectly on the S905X3 because that’s the device I have for testing. I can't guarantee it will work for chips newer than the S905X3 without the hardware on hand, but I believe rozpruacz can make it happen. I actually got into this because of the 'S905X4 built-in DVB' topic on the CoreELEC forum. He helped me a lot; without his guidance, I probably wouldn't have started this.

    I had stepped away from Linux development for quite a while. To continue, I prepared this as a LibreELEC addon (similar to the avl6862 addon in CoreELEC) without touching the mainline kernel. The advantage is that you can add patches and compile easily without messing with Kconfig, etc. Plus, you can send the newly compiled driver and DTB to the device over the network for testing.

    I also have an old S905 Mecool K2 Pro. There are minor differences; it has demod and tuner signal lock, but it needs small offset corrections compared to the S905 for the TS (Transport Stream) to flow. In short, I’m currently working on the HW demux and will share it as soon as possible. Here, architecture comes into play again: whether the demod/tuner will connect directly or via the DTS driver. There are specific wait times for the Amlogic hardware to become active.

    Edited 2 times, last by taki (March 25, 2026 at 11:04 PM).

    I pushed my current working DVB patches branch to https://github.com/chewitt/linux/commits/dvb-7.0.y/

    I pushed current AMLGX working image changes to https://github.com/chewitt/LibreELEC.tv/commits/amlogic

    To make image packaging easier I have the Linux patchset I'm testing in projects/Amlogic/patches/linux and a separate set of DVB patches in packages/linux/patches/dvb as this makes it simple to regenerate each patchset independently (using a script) and then I can respin the image to test changes. Thanks to an ex-employer that went bust I'm lucky to have a 32x core build server so image respin time (only rebuilding the kernel) is around 2 mins; then I pull the image from the server to the current test device over scp and reboot to see what broke/changed/etc. and then give feedback to Claude. NB: If you ever wondered why I always hardcode a static version in all my test images; it means I can predict filenames on a remote server to make transfers easier.

    Quote from chewitt

    rawnar I've also included a WeTek Hub image in the test share. Apologies for the long wait, I got a bit distracted.

    Found it. :) You beat me to it. I almost had my old linux installation up and running again to build the image myself.

    I placed it on a SD-Card and booted the system. Attached you can find the output I recorded from the UART. Spoiler: No strange characters coming from the UART and the system has booted now several times without halting during boot. So, the fix you made 1 year ago works 8o.

    Other thinks you like to see tested on the Wetek Hub?

    To detect the reset power, i2c pin and active ts pins of the dvb driver, first connect to the android own software with adb and cat /sys/kernel/debug/pinctrl/*/pinmux-pins
    Get the device information with cat /sys/kernel/debug/pinctrl/*/pinmux-functions and edit the mainline dts accordingly. You may need to shut down some nodes or redirect them to the correct pin due to pin conflict. I gave the driver as an addon. Copy the AVL6862 folder under LibreELEC.tv/packages/linux-driver-addons/dvb/ and add PROJECT=Amlogic DEVICE=AMLGX ARCH=aarch64 ./scripts/create_addon AVL6862 compile. Of course, if the dts is not correct, the driver probe will not occur. Maybe you can take it one step further.good luck

    sample dts

    yaml

    Amlogic 5.15 kernel hw demux driver for s905x3 - HW section filter doesn't work in hardware on SM1, using DVR+SW path based on IRQs dmx irq (40/41/42) = 0 ← NEVER fires dvr irq (43/44) = increasing ← Only AsyncFIFO is working.

    taki Thanks for sharing the patches, they are interesting reading! .. once decrypted from Turkish to English :)

    Some of the comments you've made are valuable. I was seeing an attach issue with MxL608 behind an AVL6762 i2c repeater when working on my O2.cz box, and while trial and error with Claude eventually figured out a "fix" and theorised an explanation, one of your comments explains the actual problem and better/correct solution.

    taki it might be a bug that I found when porting vendor driver to mainline.
    In aml_dmx.c You will find sunch code:

    Change 1<<(NEW_PDTS_READY) to 0<<(NEW_PDTS_READY) and check if it helps.
    For some reason this NEW_PDTS_READY interrupt source triggers at a very high rate and the kernel disables it. Disabling this interrupt is only a workaround but I don't know how to fix that better. And by looking at the code this interrupt source is not relevant.

    The other thing is that when using tvheadend I also have no dmx_irqs (only dvr_irqs).
    But when using dvbv5-zap (dvbv5-zap -c dvb_channel.conf -r "Some channel") I get dmx_irqs:

    Code
    48: 308 0 0 0 GICv2 55 Edge dmx irq
49: 0 0 0 0 GICv2 37 Edge dmx irq
50: 0 0 0 0 GICv2 53 Edge dmx irq
51: 638 0 0 0 GICv2 51 Edge dvr irq
52: 0 0 0 0 GICv2 57 Edge dvr irq
    Quote from rozpruwacz

    taki it might be a bug that I found when porting vendor driver to mainline.
    In aml_dmx.c You will find sunch code:

    Change 1<<(NEW_PDTS_READY) to 0<<(NEW_PDTS_READY) and check if it helps.
    For some reason this NEW_PDTS_READY interrupt source triggers at a very high rate and the kernel disables it. Disabling this interrupt is only a workaround but I don't know how to fix that better. And by looking at the code this interrupt source is not relevant.

    The other thing is that when using tvheadend I also have no dmx_irqs (only dvr_irqs).
    But when using dvbv5-zap (dvbv5-zap -c dvb_channel.conf -r "Some channel") I get dmx_irqs:

    Code
    48: 308 0 0 0 GICv2 55 Edge dmx irq
49: 0 0 0 0 GICv2 37 Edge dmx irq
50: 0 0 0 0 GICv2 53 Edge dmx irq
51: 638 0 0 0 GICv2 51 Edge dvr irq
52: 0 0 0 0 GICv2 57 Edge dvr irq

    I will try.

    # Terminal 1 — dvbv5-zap
    dvbv5-zap -c /storage/.kodi/addons/service.tvheadend43/dvb-scan/dvb-s/Turksat-4A-42.0E \
    -r "TRT 1" &

    # (lock + scan)
    sleep 10

    # Terminal 2 — IRQ
    cat /proc/interrupts | grep -E "dmx|dvr"
    sleep 5
    cat /proc/interrupts | grep -E "dmx|dvr"

    If the DMX IRQ is increasing → the HW section filter is also working in SM1, and TVHeadend is preferring the DVR path.

    For testing, I tried kernel 5.15 on coreelec. I scanned dvbv5 channels on both frontends at the same time. I searched with ts0 avl6762demod +mxl 608 tuner GIC-0 55 Edge, ts1 avl6261 demo and av2018 GIC-0 37 Edge. bingo demux irq data increasing. Now it's time to focus on the mainline driver. The hardware was working.

    :)CoreELEC:~ # cat /proc/interrupts | grep -E "dmx|dvr"
    40: 360 0 0 0 GIC-0 55 Edge dmx irq
    41: 45 0 0 0 GIC-0 37 Edge dmx irq
    42: 0 0 0 0 GIC-0 53 Edge dmx irq
    43: 0 0 0 0 GIC-0 51 Edge dvr irq
    44: 0 0 0 0 GIC-0 57 Edge dvr irq
    CoreELEC:~ # cat /proc/interrupts | grep -E "dmx|dvr"
    40: 375 0 0 0 GIC-0 55 Edge dmx irq
    41: 57 0 0 0 GIC-0 37 Edge dmx irq
    42: 0 0 0 0 GIC-0 53 Edge dmx irq
    43: 0 0 0 0 GIC-0 51 Edge dvr irq
    44: 0 0 0 0 GIC-0 57 Edge dvr irq
    CoreELEC:~ # cat /proc/interrupts | grep -E "dmx|dvr"
    40: 485 0 0 0 GIC-0 55 Edge dmx irq
    41: 203 0 0 0 GIC-0 37 Edge dmx irq
    42: 0 0 0 0 GIC-0 53 Edge dmx irq
    43: 0 0 0 0 GIC-0 51 Edge dvr irq
    44: 0 0 0 0 GIC-0 57 Edge dvr irq
    CoreELEC:~ # cat /proc/interrupts | grep -E "dmx|dvr"
    40: 485 0 0 0 GIC-0 55 Edge dmx irq
    41: 350 0 0 0 GIC-0 37 Edge dmx irq
    42: 0 0 0 0 GIC-0 53 Edge dmx irq
    43: 0 0 0 0 GIC-0 51 Edge dvr irq
    44: 0 0 0 0 GIC-0 57 Edge dvr irq
    CoreELEC:~ #

    I think that TVHeadend is just requesting the whole TS stream that contains all of the channels to be able to provide all channels from one mux to multiple clients. And in such situation the demux driver does not have to do demuxing thus there is no dmx irqs. Does that make sense ?