Interesting question. The dxf says the part in question is labeled ED1 besides CP18 and CP14. I found both CP18 and 14 in the schematics but ED1 not. Either mislabeled or I didn't catch it.

 

https://x.na4.eu/KOTu3/quzevoji80.jpg
 

OrangePi-Schematic of ZERO3.pdf

why edge kernels missing the dvb modules?

1 hour ago, thor2002ro said:

why edge kernels missing the dvb modules?

Probably because nobody had use for those until today. Feel free to send a PR adding whats missing.

Looks like both current and edge on sunxi64 are missing dvb support. Is this intentional? sunxi kernels include it, as do most other families.

49 minutes ago, sugatam said:

Is this intentional?

What you’re seeing is open-source maintenance in practice. It’s not centrally orchestrated. We only manage to do this for some key features while DVB support is present in some kernels, but it’s not guaranteed to be consistently enabled across all targets unless someone explicitly maintains this functionality.

-> https://github.com/armbian/build/pulls

I have a Orange Pi Zero 3 4GB Board. It uses a Micron LPDDR4X RAM and H618 Processor. I have tried a plethora of distros and tried to change Uboot and DTB but unable to make it work. Spent days on Gemini and Claude but no luck. Below is the output from UART debuggger:

 

The Highlight being  Unhandled Exception EL3.

 

U-Boot SPL 2025.04-armbian-2025.04-S3482-Pf089-H8869-V3d5b-Bb703-R448a-dirty (May 25 2025 - 14:46:18 +0000)

DRAM base address is defined as 0x40000000

DRAM has 16 b/raw, 10 b/col, 4 B/width, 2 #rank and 8 #bank

DRAM top address must be less than 0x100000000

DRAM: 4096 MiB

Trying to boot from MMC1

Unhandled Exception in EL3.

 

uart_opizero3.txt

Edited May 16May 16 by Jnanadarshan Nayak
File Added

# Orange Pi Zero 3 (1.5GB) Random Crashes — Root Cause Found & Fixed (No Recompilation Required)

 

**Board:** Orange Pi Zero 3 — 1.5GB LPDDR4 variant  

**SoC:** Allwinner H618  

**OS:** Armbian Trixie  

**Kernels tested:** 6.6.75-legacy, 6.18.33-current, 6.16.8-edge  

**Status:** ✅ SOLVED — 72+ hours stable uptime confirmed

 

---

 

## The Problem

 

My Orange Pi Zero 3 (1.5GB model) was randomly crashing every few hours under all three Armbian kernel branches. The symptoms were:

 

- System freezes with no response (SSH drops, ping still works briefly)

- Kernel oops logged: `kswapd0 → ext4_es_scan → paging request fault`

- Random segfaults on normal binaries (`sudo`, `curl`, `apt`)

- Corrupted library names in memory (e.g. `libGap-Jg.sK.0` instead of `libcrypto.so.3`)

- `memtester` passed clean (2 loops, 1GB)

- `badblocks` found zero bad blocks

- `fsck` found no filesystem errors

- Crashes happened even at full idle, with only ~200MB RAM in use

 

The crashes occurred on **all three kernel branches** — legacy, current, and edge — ruling out a kernel-specific bug as the root cause.

 

---

 

## Investigation

 

### What we ruled out (in order)

 

| Suspect | Test | Result |

|---|---|---|

| SD card physical failure | `badblocks -sv` | 0 bad blocks |

| Filesystem corruption | `fsck -f` | Clean |

| RAM hardware failure | `memtester 1G x2` | No errors |

| eth-optimize.sh (ring buffer 1024, txqueuelen 10000) | Removed from crontab | Extended stability but didn't fix |

| Kernel version | Tested 6.6.75, 6.18.33, 6.16.8 | All crashed |

| DRAM size detection bug | `dmesg \| grep Memory:` | Consistently showed 1572864K (correct 1.5GB) |

 

### The kernel oops — the real clue

 

```

kernel: Unable to handle kernel paging request at virtual address 14ae620800000018

kernel: CPU: 0 PID: 56 Comm: kswapd0

kernel: Call trace:

kernel: __es_tree_search.isra.0+0x20/0xa4

kernel: es_reclaim_extents+0x58/0xf0

kernel: ext4_es_scan+0xf0/0x29c

kernel: do_shrink_slab+0x174/0x298

kernel: shrink_slab+0xb4/0x2f0

kernel: kswapd+0x18c/0x3b8

```

 

The address `14ae620800000018` is in "address between user and kernel address ranges" — a classic corrupted/invalid pointer. This happens when the kernel accesses memory that physically doesn't exist or wraps around.

 

### DRAM address wraparound — the root cause

 

The H618 1.5GB LPDDR4 variant has a known DRAM address wraparound issue, documented in the linux-sunxi community (notably by **ag123** in Armbian forums and **Jernej Skrabec's** u-boot size scan patches):

 

> *"It is quite possible the addresses wrap around in the 1.5GB LPDDR4 DRAM chips and the 'test' for memory there returns a false positive."*

 

In this specific case, the **size** is correctly detected as 1.5GB — but the **upper address region** (above 1GB physical) exhibits wraparound behavior. When the kernel accesses the upper ~512MB region (via page cache, kswapd reclaim, or slab allocation), writes to those addresses silently corrupt data in the lower region — because the addresses "wrap" back.

 

This explains why:

- `memtester` passes (it tests sequentially in a contiguous region, doesn't trigger wraparound patterns)

- Size appears correct (1572864K = 1.5GB every boot)

- Crashes are random in timing (depends on when page cache/kswapd reaches the upper region)

- ALL kernels are affected (this is a u-boot/hardware level issue, not kernel-specific)

 

---

 

## The Fix

 

### Standard approach (requires u-boot recompilation)

The proper fix is `CONFIG_DRAM_SUN50I_H616_TRIM_SIZE=y` in u-boot, or Jernej Skrabec's adjusted size scan procedure (columns-first scanning). This correctly detects and excludes the wraparound region, allowing full 1.5GB usage.

 

### Our approach — kernel `mem=` parameter (no recompilation needed)

 

Since the wraparound occurs in the **upper address region**, we can simply tell the kernel to only use the safe lower 1GB:

 

Edit `/boot/armbianEnv.txt` and add `mem=1024M` to `extraargs`:

 

```bash

sudo nano /boot/armbianEnv.txt

```

 

Change:

```

extraargs=... existing params ...

```

To:

```

extraargs=mem=1024M ... existing params ...

```

 

Reboot and verify:

```bash

cat /proc/cmdline | grep -o "mem=1024M"

cat /proc/iomem | grep "System RAM"

free -h

```

 

Expected output:

```

mem=1024M

40080000-7fffffff : System RAM

              total used free

Mem: 974Mi ...

```

 

The `iomem` map confirms the kernel's physical RAM range is **exactly** `0x40080000–0x7fffffff` — stopping at the 1GB boundary. The upper wraparound region (`0x80000000` and above) is completely excluded from the kernel's memory map.

 

### Why this works

 

The wraparound region begins at or above `0x80000000` (1GB physical offset). With `mem=1024M`:

- Kernel allocator, page cache, slab, and all processes stay within `0x40000000–0x80000000`

- `kswapd` never reclaims pages from the problematic upper region

- The corrupted-pointer crash path is never triggered

 

### Tradeoffs vs. u-boot fix

 

| | mem=1024M | u-boot TRIM fix |

|---|---|---|

| Requires recompilation | ❌ No | ✅ Yes |

| RAM available | ~974MB | ~1.4GB |

| Works on all kernels | ✅ Yes | ✅ Yes |

| Fixes root cause | Workaround | Proper fix |

 

For SDR servers, home automation, and similar light workloads where ~974MB is more than sufficient (our system uses ~130–200MB), this is a perfectly viable permanent solution.

 

---

 

## Results

 

| Metric | Before fix | After fix |

|---|---|---|

| Uptime | 1–8 hours max | **72+ hours** (and counting) |

| Kernel oops | Multiple per session | **Zero** |

| Segfaults | Random, on any binary | **Zero** |

| `sudo apt update` | Crashed frequently | Runs perfectly |

| Memory corruption | Frequent bit-flips | **None observed** |

 

System configuration at time of testing:

- **Kernel:** 6.16.8-edge-sunxi64  

- **Kernel param:** `mem=1024M`  

- **CPU governor:** ondemand  

- **Workload:** OpenWebRX+, SpyServer, RTL-TCP (x2), radiosonde_auto_rx, Xray proxy

 

---

 

## How to apply

 

```bash

# Backup first

sudo cp /boot/armbianEnv.txt /boot/armbianEnv.txt.bak

 

# Add mem=1024M to extraargs

sudo sed -i 's/^extraargs=/extraargs=mem=1024M /' /boot/armbianEnv.txt

 

# Verify

grep extraargs /boot/armbianEnv.txt

 

# Reboot

sudo reboot

```

 

After reboot, confirm:

```bash

# Should show mem=1024M

cat /proc/cmdline | grep -o "mem=1024M"

 

# Should show ~974Mi total

free -h

 

# Should show System RAM ending at 0x7fffffff

cat /proc/iomem | grep "System RAM"

```

 

---

 

## References

 

- ag123's analysis of 1.5GB wraparound: Armbian Community Forums

- Jernej Skrabec's u-boot DRAM size scan fix: [linux-sunxi mailing list](https://www.mail-archive.com/u-boot@lists.denx.de/msg516769.html)

- H618 LPDDR4 support patch: [u-boot mailing list](https://lore.kernel.org/all/20231111091000.26744-2-iuncuim@gmail.com/T/)

- ag88's 1.5GB u-boot fix (alternative approach): GitHub

 

---

 

## Notes

 

This fix was developed and tested on a **1.5GB LPDDR4** Orange Pi Zero 3. The 1GB, 2GB, and 4GB variants use different DRAM configurations and may not be affected by this specific issue.

 

If you have a 1.5GB board and experience similar random crashes, try `mem=1024M` before spending time on kernel debugging or hardware replacement. It may save you days of investigation.

 

**Tested and confirmed working by:** Özgür Çetinoğlu  

**Location:** Athens, Greece  

**Setup:** 24/7 SDR server (OpenWebRX+, radiosonde tracking)  

**Date:** June 2026

 

26.12.2025 в 14:51, Refaz Saleem сказал:

This is totally offtopic from the thread, but looking for people who have the device to identify. I have an orange pi zero 3, 2GB variant. I absent mindedly plugged a 12VDC power supply. And I obviously fried the marked SMD. Can anyone help me with the part number? I am figuring out a way to revive the board.

 

Hello, have you found what is ED1 part? I have a fried board as well, and ED1 seems to be a culprit.

 

UPD: According to Orange Pi Zero2 schematics, it's JEB05DFC esd0402-6.

I just removed it and the board is working again.

Edited September 20Sep 20 by ValdikSS

On 9/19/2026 at 6:05 PM, ValdikSS said:

Hello, have you found what is ED1 part? I have a fried board as well, and ED1 seems to be a culprit.

 

UPD: According to Orange Pi Zero2 schematics, it's JEB05DFC esd0402-6.

I just removed it and the board is working again.

 

I also have an orange pi zero 3 which was fried due to 12V applied to the GPIO +5V pin (forgot to turn a potentiometer to lower the voltage).

 

What is the ED1? Is it a fuse or similar? Is there an equivalent for the GPIO 5V?

22.09.2026 в 19:24, robertoj сказал:

What is the ED1? Is it a fuse or similar?

JEB05DFC esd0402-6

https://www.jjm.com/profhqj4/

TVS Diode Array
ESD protective components are TVS arrays specially used for small-signal ESD protection or surge protection and are mostly used for multi-channel protection. It has the advantages of a small package size and high integration.

here is my working tree for orangepi zero 3 kernel and ffmpeg implementation, some highlights

https://github.com/thor2002ro/armbian_build

1. Video decoding: H.264 fixes, experimental 8K HEVC support, and VP9, VC-1, JPEG, CAVS/CAVS2, MPEG-4 and H.263 support.

2. Video encoding: H.264 and JPEG encoding, with DMA-BUF support for compatible transcoding pipelines.

3. FFmpeg: A separate build with V4L2 Request support.

4. Display and audio: HDMI audio, improved display processing, and HDMI YUV and 10-bit output support.

5. Power and cooling: CPU and GPU cooling, power-key support, and video engine autosuspend.

6. Reliability: IOMMU, Ethernet, USB, MMC and SPI fixes.

7. Diagnostics: Video engine load and stream counters, plus improved fault reporting.

8. DVB support 😂

9. extra dvb fixes for cxd2841er mn88472 mn88473 https://github.com/thor2002ro/linux-dvb-drivers-fixes

I use it as a headless server wired in so.... hdmi/emmc/wifi implementation is untested

Edited November 1Nov 1 by thor2002ro

@thor2002ro saw your post and started to play with agents to see if I could get it working with hw acceleration to play h264 and h265.

just building the image didn't provide smooth play, lots of frames were being lost, but after some work now it's working apparently flawlessly.
tested on a 2K monitor with audio output, still headless but direct play with mpv.
thought about sharing the findings directly on github, but as it's just ai slop maybe it's better to drop it here and you do with it whatever you prefer.

I'll update when testing in the final setup, a 1080p TV

also is pending to test 1080p h265, I grabbed a 4k h265 to do a quick test but it's too much I guess

(the "Clean Unpatched Kernel Module" refers to your repo compiled one, not directly from armbian)

# Orange Pi Zero 3 (Allwinner H618) Cedrus Hardware Video Decoding Fix

## 1. Problem Overview

Multiple attempts to achieve smooth 1080p hardware-accelerated video playback on the **Orange Pi Zero 3** (Allwinner H618 SoC, 4 GB LPDDR4, Cedrus VPU) failed due to two compounded issues:

### Symptom A: Kernel Timeouts and IOMMU Crashes

When playing H.264 video with hardware acceleration enabled via /opt/ffmpeg-v4l2-request or mpv, playback would frequently stall after a few seconds with:

```

[V4L2RequestContext] Failed waiting on CAPTURE buffer X

[dec:h264] Error submitting packet to decoder: Invalid argument

```

Immediately followed in dmesg by:

```

sun50i-iommu 30f0000.iommu: Page fault for 0x0000000000056000 (master 2, dir rd)

cedrus 1c0e000.video-codec: frame processing timed out!

```

### Symptom B: "Slow Motion" Playback & Audio Desynchronization (8.5 fps)

When falling back to --hwdec=v4l2request-copy, the video did not produce kernel timeouts, but playback ran at **~8.5 fps** on 24 fps content (taking ~40 seconds of wall-clock time to play a 10-second segment), with massive audio desync (A-V: +4.271 Dropped: 3).

---

## 2. Root Cause Analysis

### Hardware Root Cause: VE Clock Exceeds Fixed Board Voltage

The mainline H616/H618 Cedrus patch set mapped SoC fuse ID 0x2000 (the H618 on Orange Pi Zero 3) to:

- **648 MHz** for all decoders (CEDRUS_CODEC_DEC_ALL)

- **696 MHz** for all encoders (CEDRUS_CODEC_ENC_ALL)

However, the Orange Pi Zero 3 board design lacks dynamic voltage scaling (DVS) for the Video Engine (VE) power rail. Under heavy 1080p decoding loads, operating the VPU at 648 MHz causes a transient voltage drop. The VPU engine silently stalls mid-frame and drops its completion interrupt. When the 2-second kernel watchdog expires, the engine resets, leaving the Decoded Picture Buffer (DPB) corrupted. Subsequent reference frame lookups read invalid addresses, triggering the sun50i-iommu page faults.

An early attempt binary-patched sunxi-cedrus.ko to bypass error reporting and force macroblock count checks. This only masked the symptoms; frames that stalled still missed their interrupts, corrupted the DPB, and ruined playback.

The true hardware threshold: Frequency sweeps revealed:

- 648 MHz / 696 MHz: Immediate or frequent hardware timeouts

- 600 MHz – 624 MHz: Intermittent crashes on complex reference frames

- **576 MHz**: 100% rock solid across thousands of continuous frames

### Software Root Cause: Frame Copying vs Direct DRM Overlay

In v4l2request-copy mode, every 1080p NV12 frame is copied across system RAM into CPU space, then uploaded to the Mali-G31 GPU via EGL shaders to upscale to the display resolution. The CPU/RAM memory bus bandwidth on the SBC throttled the pipeline to ~8.5 fps.

Furthermore, stock mpv's zero-copy drmprime-overlay pipeline only checked for AV_HWDEVICE_TYPE_DRM, whereas the custom FFmpeg Cedrus build exposes AV_HWDEVICE_TYPE_V4L2REQUEST. Without patching mpv, native zero-copy decoding could not be instantiated.

---

## 3. The Solution

### Step 1: Cap the Cedrus VE Clock to 576 MHz

To fix the clock frequency at runtime across reboots, /etc/modprobe.d/cedrus-ve-clock.conf was created:

```ini

options sunxi_cedrus ve_rate_override=576000000

```

This restricts the Cedrus PLL to 576 MHz, keeping the VPU well within stable electrical tolerances.

For a permanent kernel build, the Device Tree clock policy table was patched in armbian_build so that SID 0x2000/0x2100 are capped at 576000000 (see sun50i-h616-cedrus-576mhz.patch).

### Step 2: Restore Clean, Unpatched Kernel Module

The binary-patched sunxi-cedrus.ko was removed and restored to the clean, stock compiled binary (sha256 717296c1...). At 576 MHz, all hardware error checks pass without modification.

### Step 3: Patch mpv for Zero-Copy V4L2REQUEST DRM PRIME

mpv v0.40.0 was patched in hwdec_drmprime.c and hwdec_drmprime_overlay.c to accept AV_HWDEVICE_TYPE_V4L2REQUEST alongside AV_HWDEVICE_TYPE_DRM. Decoded frames flow directly from the Cedrus V4L2 buffers via DMA-BUF into the Allwinner DE3.3 hardware overlay plane (plane 35).

### Step 4: Display & Interop Settings

When running DRM zero-copy on the native 2560x1440@60 display (H27T27), the DE3.3 display hardware scaler handles upscaling from 1080p to 1440p with **zero CPU and zero GPU shader overhead**.

Configured in ~/.config/mpv/mpv.conf:

```ini

vo=gpu

gpu-context=drm

drm-device=/dev/dri/card0

drm-mode=2560x1440@60

hwdec=v4l2request

gpu-hwdec-interop=drmprime-overlay

ao=alsa

audio-device=alsa/default

```

---

## 4. Benchmark Results

### 1080p H.264 (High-profile, 16 B-frames, 6-ch audio)

- **Frame Rate:** 1.00x exact realtime (24.000 fps)

- **Dropped Frames:** **0**

- **A/V Sync:** A-V: 0.000

- **CPU Utilization:** **8.3%** on a single core (> 92% overall system idle)

- **Kernel Logs:** **0 timeouts, 0 IOMMU faults**

### 4K UHD (3840x2160) 10-bit HDR HEVC (testh265.mkv, Main 10, P010)

- **Codec & Driver:** Decoded via Cedrus stateless V4L2-Request (V4L2_PIX_FMT_HEVC_SLICE) outputting drm_prime[p010] into KMS plane 35.

- **Hardware Decode Throughput:** **~15–16 fps** (speed ~0.65x realtime). The Cedrus VPU on the fixed-voltage H618 board operates stably at 576 MHz, but the immense data rate of 4K 10-bit HDR (8.3M pixels/frame, ~25 MB/frame) maxes out the VPU at 16 fps.

- **Tuning Applied in ~/.config/mpv/mpv.conf:**

```ini

vd-queue-enable=no

framedrop=vo

```

- Without this tuning, when a 24 fps 4K stream falls behind real-time audio, mpv's default decoder queue exhausts the V4L2 capture buffer pool (Failed waiting on CAPTURE buffer).

- With vd-queue-enable=no and framedrop=vo, mpv drops display frames cleanly, avoids V4L2 buffer deadlocks, and keeps audio synchronized without hanging.

sun50i-h616-cedrus-576mhz.patch

On 11/1/2026 at 12:50 PM, thor2002ro said:

here is my working tree for orangepi zero 3 kernel and ffmpeg implementation, some highlights

https://github.com/thor2002ro/armbian_build

1. Video decoding: H.264 fixes, experimental 8K HEVC support, and VP9, VC-1, JPEG, CAVS/CAVS2, MPEG-4 and H.263 support.

2. Video encoding: H.264 and JPEG encoding, with DMA-BUF support for compatible transcoding pipelines.

3. FFmpeg: A separate build with V4L2 Request support.

4. Display and audio: HDMI audio, improved display processing, and HDMI YUV and 10-bit output support.

5. Power and cooling: CPU and GPU cooling, power-key support, and video engine autosuspend.

6. Reliability: IOMMU, Ethernet, USB, MMC and SPI fixes.

7. Diagnostics: Video engine load and stream counters, plus improved fault reporting.

8. DVB support 😂

9. extra dvb fixes for cxd2841er mn88472 mn88473 https://github.com/thor2002ro/linux-dvb-drivers-fixes

I use it as a headless server wired in so.... hdmi/emmc/wifi implementation is untested

Hello

I see in the github, that ffmpeg 8.1 with patches by kwiboo were included.

Which kernel and debian/ubuntu version does this work with? Trixie? Noble?

I already saw this working well with some rare crashes in Bookworm, but I never saw it working in anything newer.

Can you separate the group of patches that implement the H264,H265 hardware decoding, and ffmpeg?

Edited Tuesday at 05:26 PM2 days by robertoj

1 hour ago, pepkov said:

@thor2002ro saw your post and started to play with agents to see if I could get it working with hw acceleration to play h264 and h265.

just building the image didn't provide smooth play, lots of frames were being lost, but after some work now it's working apparently flawlessly.
tested on a 2K monitor with audio output, still headless but direct play with mpv.
thought about sharing the findings directly on github, but as it's just ai slop maybe it's better to drop it here and you do with it whatever you prefer.

I'll update when testing in the final setup, a 1080p TV

also is pending to test 1080p h265, I grabbed a 4k h265 to do a quick test but it's too much I guess

(the "Clean Unpatched Kernel Module" refers to your repo compiled one, not directly from armbian)

sun50i-h616-cedrus-576mhz.patch

Why does the LLM output speak of experiments, failure modes and solutions as if it has done the experiments itself? It should be telling you where it is quoting that information from.

26 minutes ago, robertoj said:

Why does the LLM output speak of experiments, failure modes and solutions as if it has done the experiments itself? It should be telling you where it is quoting that information from.

So it was a bit of a disaster, at the begining I was working with argon but the guardrails stopped the conversation.

Then I had LongCat 2.5 (opencode through openrouter) go on with direct access through SSH, telling it to inspect the working directory in my laptop and go on. I usually output time to time the progress to md files so it understood pretty well. While doing other things I kept an eye in the monitor to check how it went. Run out of usage and nothing good at all came out of that.

Finally gemini3.8 flash got it right quite fast, went a bit over the task as it started installing some services that were in the plan but not at that point. Sincerely quite happy to get it working, I think is the first time I got HW acceleration on Linux in this board

5 hours ago, pepkov said:

So it was a bit of a disaster, at the begining I was working with argon but the guardrails stopped the conversation.

Then I had LongCat 2.5 (opencode through openrouter) go on with direct access through SSH, telling it to inspect the working directory in my laptop and go on. I usually output time to time the progress to md files so it understood pretty well. While doing other things I kept an eye in the monitor to check how it went. Run out of usage and nothing good at all came out of that.

Finally gemini3.8 flash got it right quite fast, went a bit over the task as it started installing some services that were in the plan but not at that point. Sincerely quite happy to get it working, I think is the first time I got HW acceleration on Linux in this board

Did you need to specify linux stable or edge, debian or ubuntu, in the armbian build script? Or does it work with all linux and debian/ubuntus?

9 hours ago, robertoj said:

Did you need to specify linux stable or edge, debian or ubuntu, in the armbian build script? Or does it work with all linux and debian/ubuntus?

both BRANCH=edge and RELEASE=trixie are required.

at extensions/ffmpeg-v4l2-request.sh

if [[ "${ARCH}" != arm64 || "${RELEASE}" != trixie ]]; then
    display_alert "Skipping FFmpeg V4L2 Request" "Requires trixie arm64; got ${RELEASE} ${ARCH}" "warn"
    return 0
fi

All of @thor2002ro new Allwinner H616/H618 multimedia work is only in edge (patch/kernel/archive/sunxi-7.3/series.conf)

thank you!

On 11/10/2026 at 5:44 PM, pepkov said:

@thor2002ro saw your post and started to play with agents to see if I could get it working with hw acceleration to play h264 and h265.

just building the image didn't provide smooth play, lots of frames were being lost, but after some work now it's working apparently flawlessly.
tested on a 2K monitor with audio output, still headless but direct play with mpv.
thought about sharing the findings directly on github, but as it's just ai slop maybe it's better to drop it here and you do with it whatever you prefer.

I'll update when testing in the final setup, a 1080p TV

also is pending to test 1080p h265, I grabbed a 4k h265 to do a quick test but it's too much I guess

(the "Clean Unpatched Kernel Module" refers to your repo compiled one, not directly from armbian)

sun50i-h616-cedrus-576mhz.patch

yahhhh I thought that would happen I pushed the codec chip to the max some chips wont be able to handle that, my chip can handle full speed no problem its a 4gb zero3 .... theres a manual override built into clock freq

check commit description here https://github.com/thor2002ro/armbian_build/commit/d54dd38b6bcc994a87b217bfc2e58a6c4bf91335

the PSU quality might matter also

PS: pleaase dont give LLMS access to ssh systems.... dont speed up Judgement day :)))))))

also for non technical ppl there are ready built kernels with ffmpeg in release

Edited 17 hours ago17 hr by thor2002ro

i just checked stock fw uses 648000000 for your sid ..... interesting yours crashes .... I'm leaning towards bad/insufficient PSU

https://github.com/thor2002ro/armbian_build/releases/tag/121126

there this might fix things