FEL - Amlogic NO support

Development
300

There’s no need to always ask, try it yourself, it’s very simple, and then report your test results for others to use as a reference.

1 Like
301

Another one which should work better: 5.15_2.6_dovi_patched_fix_fel.ko (460.8 KB)

13 Likes
302

This seems fixed the crash issue for me. The crash previously occurred when I fast-forwarded, rewound, and resumed playback. Any technical details can be shared for this one-byte patch from if x == 1 to if x >= 1?

303

Black magic!

3 Likes
304

vpeter — thank you for the updated module. I tested it on my Ugoos AM9 Pro and wanted to give you a precise report, including a kernel panic backtrace that should pinpoint the issue.

*Environment**

  • Device: Ugoos AM9 Pro — S905X5 (“s6” family)
  • CoreELEC: 22.0-Piers*_nightly_*20260602 (Amlogic-no)
  • Kernel: 5.15.196 aarch64
  • Module: `dovi_gen_5_15_2026` (your latest build) at `/flash/dovi.ko`. Loads clean: `*** amlogic_dolby_vision_init dv: s6 ***` + `Creating DV mp success`.

**Behavior — big improvement for steady playback, but it hard-panics on seek**

  • *Steady* FEL playback is excellent with this build: on a Profile 7 FEL + HDR10+ title I got ~2.5 min of flawless playback — only the single startup `AMDV ERROR: bl(…) not found el` transient, zero dropped frames, smooth 24fps, both `amvdec_h265` channels decoding (BL+EL).
  • **The crash is triggered by seek/skip.** As soon as I skipped during FEL playback the box hard kernel-panicked and rebooted. It reproduces on a mid-stream DV metadata transition — I caught a `Dolby VSIF, switching signal to SDR` event in the log immediately before the panic, so the seek is forcing a fresh metadata parse mid-stream.

**Kernel panic (from pstore/ramoops)**

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: md_parser_evt_handler_cb+0x1b0/0x1b0 \[dovi_gen_5_15_2026\]
Call trace:
 dump_backtrace+0x108/0x154
 show_stack+0x24/0x40
 dump_stack_lvl+0x64/0x80
 dump_stack+0x1c/0x40
 panic+0x154/0x38c
 metadata_parser_release+0x0/0x64 \[dovi_gen_5_15_2026\]
 dv_md_parser_process+0x1fc/0x330 \[dovi_gen_5_15_2026\]
 metadata_parser_process+0x128/0x31c \[dovi_gen_5_15_2026\]
 parse_sei_and_meta_ext_v2+0xaf0/0xef0
 parse_sei_and_meta+0x104/0x1f8
 amdv_parse_metadata_v2_stb+0xa00/0x26ac
 amdv_parse_metadata+0x1a4/0x1e8
 amdv_update_metadata+0x98/0x158
 dv_toggle_frame+0x48/0xfc
 amvideo_toggle_frame+0xf18/0x243c
 video_toggle_frame+0x1bc/0xa74
 post_vsync_process+0x127c/0x2520
 vsync_isr+0x198/0x23c
 \__handle_irq_event_percpu+0xd0/0x288
 handle_irq_event+0x5c/0xcc
 handle_fasteoi_irq+0x118/0x218
 handle_domain_irq+0x7c/0xec
 gic_handle_irq+0x5c/0x11c
reboot reason = 12, kernel panic

**My read (for what it’s worth):** the stack-protector canary trips in `md_parser_evt_handler_cb`, reached via the metadata-parse path `amdv_parse_metadata_v2_stb → parse_sei_and_meta_ext_v2 → metadata_parser_process → dv_md_parser_process → metadata_parser_release`. Two things stand out: (1) the very large single-function offsets (`parse_sei_and_meta_ext_v2+0xaf0`, `amdv_parse_metadata_v2_stb+0xa00`) point to big on-stack buffers / deep frames in the SEI+RPU parser, and (2) this whole chain runs inside the **vsync ISR** (`vsync_isr → post_vsync_process → video_toggle_frame → dv_toggle_frame`), where stack headroom is tighter. So a seek that forces a fresh mid-stream metadata re-parse looks like it overruns the kernel stack in interrupt context. (Steady playback never re-parses that deeply, which is why it only crashes on seek.)

Happy to test a follow-up build, capture a 2–3s sample of the exact title, or pull any extra debug you’d find useful (full dmesg, the title’s RPU via dovi*_tool, etc.). Thanks again for the work on S905X5 FEL — steady playback is genuinely solid now; it’s just the seek path.*

1 Like
305

Dear, I have the AM6B+ with NO and the previous module. To use this new module, do I need to do a clean install?

306

No need, just replace the dovi.ko module itself.

307

Perfect, I installed CoreElec on the internal memory of my AM6B+, in which folder can I find the dovi.ko file?

308
309

kyrunner, instead just AI analysis the solution to the problem would be better.

1 Like
310

Try with the newest dovi.ko provided and with this test build:
https://test.coreelec.org/Portisch/temp/CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603.tar

And a seoncd test build:
https://test.coreelec.org/Portisch/temp/CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603_v2.tar

2 Likes
311

Installed V2. When skipping FEL some movies get stuck for a few seconds and then the colors are totally green. AM9 pro

312

what is your source? nfs/smb/other?
is it fast enough?

313

SMB via NAS. Never had the problem before. Around 130MB/S. Went back to the latest nightly build. Same thing.

314

if this is Megabytes per second (1.04Gbps) - should be fine
if this is Megabits per second (16.25MB/s) - this is too slow

315

Megabytes. Ok tested all 3 dovi.ko files. Same problem with transformers rise of the beasts. Its the only FEL movie to give problems (tested tens). On my AM6B+ Rise of the beast plays just fine.

316

I tried Transformers - Aufstieg der Bestien DV P7 FEL, too. With Portisch v1 & v2 and newest dovi.ko. I have no problem here.
Also I tried some other P7 FEL, P8.1, P5, P7 MEL. No Problems, Fast Forward, Rewind, Chapter jump Forward and Back, No Problems.

I suspect your file is simply corrupted. Some AM6B Plus Builds works also with corrupted Files.

3 Likes
317

Thanks for your hard work and testing. Will check your sugestion.

318

***AM9 Pro (S905X5) — test build `Piers_nightly_20260603` + patched dovi.ko `5.15_2.6_dovi_patched_fix_fel.ko`: big improvement on seeks, but still kernel-panics — and the crash site has moved.**

Env:

  • Box: Ugoos AM9 Pro, S905X5, Amlogic-no
  • Build: `CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603`
  • Module: `dovi_gen_5_15_2026`, build hash `11509eb66696b72bbde0fcdbffa500e6f1764eec` (md5 of the .ko `111434c8839aa5f6ef374ef76ec0a607` — same module previously tested)
  • Note at module load: `dovi_gen_5_15_2026: disagrees about version of symbol __stack_chk_fail — please rebuild ko` (loads + inits DV fine: `amlogic_dolby_vision_*init dv: s6`, `Creating DV mp success`)

What I tested (P7 FEL title, dual-layer FEL confirmed: two `amvdec*_h265` channels, 4K BL + 1080p EL, `enable_fel 1`/`enable_mel 1`):

  • **Steady playback: flawless** — AMDV EL-pairing error count frozen at 1 (single startup transient), zero drops over ~15 min.
  • **Seeks: survived 5+ skip/seek operations over ~12 min** before crashing. On the previous build this module kernel-panicked on the *first* seek, so the parser-side corruption looks largely addressed.
  • Then at uptime ~890s it kernel-panicked during continued seeking.

**The panic backtrace moved off the metadata-parser path.** Previously (older build) it was:
`Kernel stack is corrupted in: md_parser_evt_handler_cb` (dv_md_parser_process → metadata_parser_process → amdv_parse_metadata_v2_*stb).

Now (build 20260603) it is the **DV register-commit path on the IRQ stack**:
```
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
Commit2DmKs+0xd10/0xd14 [dovi*_gen_5_15_2026]
Call trace:
panic+0x154/0x38c
Commit2DmKs+0xd10/0xd14 [dovi_gen_5_15_2026]
commit_reg+0x99c/0x2620 [dovi_gen_5_15_2026]
multi_control_path+0xdc8/0x170c [dovi_gen_5_15_2026]
amdv_control_path+0xbb4/0x13d8
call_on_irq_*stack+0x44/0x84
```

Read: looks like a stack overflow / canary smash in `commit*_reg`/`Commit2DmKs` while committing DV registers, running on the IRQ stack (`call_on_irq_stack`) — i.e. the vsync ISR path during a seek’s DV mode transition. The deep `+0x2620`/`+0x170c` offsets in `commit_reg`/`multi_control_path` suggest large on-stack buffers in that path overflowing the IRQ stack specifically.

Full console-ramoops + dmesg-ramoops available on request.***

2 Likes
319

Same for me , UGOOS AM6B+ :folded_hands: