Thanks @MichaIng! I would be happy to do it, the only problem on my side is that now I will not have physical access to the board (and as a consequence to the HDMI connection) for a while, possibly even for some months.
Is there another way to test it remotely? I guess not. 
Since we don’t know a clear kernel error that indicates whether HDMI works or not, no way to test remotely. And it would be risky anyway without physical access, in case some kernel build breaks boot or network.
It is not that urgent IMO: The DKMS issue is likely a rare one, specific to your particular driver sources, and now that we found the unintentionally missing RTW88 backport patch, that WiFi chip is generally supported already. And there is always the possibility to downgrade to package version 26.02.0-trunk-dietpi4.
I’ll test HDMI as soon as I can connect a display to the board. Iit’s currently running headless. I’ll report back soon.
Following MichaIng’s request on GitHub issue #8144, I tested HDMI on kernel 6.12.33-current-meson on my Odroid C1.
Setup
- Device: Odroid C1 (Amlogic S805, armv7l)
- DietPi: v10.3.3 (Trixie)
- Kernel: 6.12.33-current-meson (linux-image-current-meson 26.05.0-trunk-dietpi5)
- Display: 4K monitor connected via HDMI
Result: HDMI works correctly ✓
The display initialized at 1920x1080 without any errors. Console output was visible on screen immediately after boot. Relevant dmesg entries:
[3.390489] meson-drm d0100000.vpu: meson_vclk_setup(target: 1, phy: 1485000, dac: 148500, venc: 148500, hdmi_use_enci: 0)
[3.498634] Console: switching to colour frame buffer device 240x67
[3.549942] meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device
No DRM/VPU errors in dmesg. The HDMI pipeline (meson-drm / VPU) initializes cleanly and produces a stable image on screen.
This confirms that the HDMI regression introduced somewhere above 6.12.33 is not present in this kernel version, which should be a good basis for MichaIng’s planned v6.12.34 with the faulty commit re-implemented. Looking forward to eventually getting the kernel version unfrozen and tracking latest 6.12.y again.
Great, many thanks for testing! I’ll start working on a v6.12.34 next week, after the DietPi release this weekend.
Hi @Michalng, I wanted to check if you still have intention to experiment on this topic. I might have again physical access to the C1 in around one month time.
Sounds good. Let me know a few days earlier, so I can prepare kernel builds.
Btw, another quick test of interest:
dmesg | grep -A 10 'with environment:'
We are settings a bunch of vendor-only kernel command-line arguments in the /boot/boot.ini, and I am not sure which ones are still effective with the recent kernel. Any non-recognized argument is passed through as environment variable to to the init system. If any of those arguments hence are listed in above output, we know that we can safely remove them.
Hi @MichaIng, just to let you know that you can go ahead with the test build if you have time.
Additionally I am sorry to have missed your last request: the dmesg search in not producing any output.
Give me a day or two if possible. Just on the way home from holiday trip.
I raised the kernel version to the one which does contain the suspected culprit commit, and updated two patches, one which was not updated at all by Armbian, declaring int kHz frequency variables, which need to be long long Hz values now: odroidc1: raise frozen kernel to suspected HDMI culprit · MichaIng/build@53cbf32 · GitHub
Some hunks even needed to be updated, hence I wonder how the 2nd patch could even successfully apply.
Build running: Armbian · MichaIng/DietPi@06e0eae · GitHub
Let’s see whether I still missed something.
EDIT: Ready for testing:
G_DEV_TEST_FIRMWARE
Thanks @MichaIng, so…
The board is booting with the experimental kernel:
Linux Odroid-C1 6.12.34-current-meson #1 SMP Thu Jun 19 13:32:38 UTC 2025 armv7l GNU/Linux
However, the hdmi output seems not to be working with my current configuration, I am getting a “no signal” message on the connected monitor.
This is an extract of dmesg: dmesg | grep -Ei "drm|vpu|meson|hdmi"
[ 0.000000] Linux version 6.12.34-current-meson (build@armbian) (arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP Thu Jun 19 13:32:38 UTC 2025
[ 0.000000] Kernel command line: root=UUID=cdf6c27f-7bc3-4923-ae06-27322b0fdbe4 rootfstype=ext4 rootwait rw console=tty1 console=ttyAML0,115200n8 consoleblank=0 fsck.repair=yes net.ifnames=0 vdaccfg=0xa000 dmfc=3 cvbsmode=576cvbs hdmimode=1080p m_bpp=32 vout=hdmi disablehpd=true hdmitx=cecf monitor_onoff=true max_freq=1536 usbhid.quirks=0x0eef:0x0005:0x0004 video=HDMI-A-1:1080p
[ 0.000000] Unknown kernel command line parameters "vdaccfg=0xa000 dmfc=3 cvbsmode=576cvbs hdmimode=1080p m_bpp=32 vout=hdmi disablehpd=true hdmitx=cecf monitor_onoff=true max_freq=1536", will be passed to user space.
[ 0.039616] /bus@d0000000/hdmi-tx@42000: Fixed dependency cycle(s) with /bus@d0000000/vpu@100000
[ 0.039767] /bus@d0000000/vpu@100000: Fixed dependency cycle(s) with /bus@d0000000/hdmi-tx@42000
[ 0.040347] /bus@d0000000/hdmi-tx@42000: Fixed dependency cycle(s) with /bus@d0000000/vpu@100000
[ 0.040619] /bus@d0000000/hdmi-tx@42000: Fixed dependency cycle(s) with /bus@d0000000/vpu@100000
[ 0.040729] /bus@d0000000/vpu@100000: Fixed dependency cycle(s) with /bus@d0000000/hdmi-tx@42000
[ 0.041217] /bus@d0000000/hdmi-tx@42000: Fixed dependency cycle(s) with /hdmi-connector
[ 0.041339] /hdmi-connector: Fixed dependency cycle(s) with /bus@d0000000/hdmi-tx@42000
[ 0.389468] irq_meson_gpio: 119 to 8 gpio interrupt mux initialized
[ 0.396664] meson-pwm c1108650.pwm: using obsolete compatible, please consider updating dt
[ 1.005424] soc soc0: Amlogic Meson8b (S805) RevA (1b - 0:B72) detected
[ 1.080213] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 26, base_baud = 9960937) is a meson_uart
[ 2.099893] [drm] Initialized lima 1.1.0 for d00c0000.gpu on minor 0
[ 2.139225] meson_wdt c1109900.watchdog: Watchdog enabled (timeout=8 sec, nowayout=0)
[ 2.154898] remoteproc remoteproc0: meson-mx-ao-arc is available
[ 2.161147] meson-mx-sdhc c1108e00.mmc: allocated mmc-pwrseq
[ 2.174321] remoteproc remoteproc0: powering up meson-mx-ao-arc
[ 2.204066] nvmem meson8b-efuse0: cell calib raw len 2 unaligned to nvmem word size 4
[ 2.211392] nvmem meson8b-efuse0: cell mac raw len 6 unaligned to nvmem word size 4
[ 2.410235] meson-drm d0100000.vpu: CVBS Output connector not available
[ 2.413020] meson8b-dwmac c9410000.ethernet: IRQ eth_wake_irq not found
[ 2.417907] meson8b-dwmac c9410000.ethernet: IRQ eth_lpi not found
[ 2.424036] meson8b-dwmac c9410000.ethernet: IRQ sfty not found
[ 2.430077] meson8b-dwmac c9410000.ethernet: PTP uses main clock
[ 2.436657] meson8b-dwmac c9410000.ethernet: User ID: 0x10, Synopsys ID: 0x37
[ 2.443067] meson8b-dwmac c9410000.ethernet: DWMAC1000
[ 2.448302] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported
[ 2.455702] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported
[ 2.463207] meson8b-dwmac c9410000.ethernet: COE Type 2
[ 2.468394] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported
[ 2.475410] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported
[ 2.481924] meson8b-dwmac c9410000.ethernet: Normal descriptors
[ 2.487774] meson8b-dwmac c9410000.ethernet: Ring mode enabled
[ 2.493559] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[ 2.888747] meson-drm d0100000.vpu: CVBS Output connector not available
[ 2.893556] [drm] Initialized meson 1.0.0 for d0100000.vpu on minor 1
[ 3.201401] meson-drm d0100000.vpu: meson_vclk_setup(target: 1, phy: 1485000000, dac: 148500000, venc: 148500000, hdmi_use_enci: 0)
[ 3.332232] meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device
[ 3.408180] hdmimode=1080p
[ 3.408191] vout=hdmi
[ 3.408203] hdmitx=cecf
[ 18.684895] rc rc0: meson-ir as /devices/platform/soc/c8100000.bus/c8100480.ir-receiver/rc/rc0
[ 18.692698] rc rc0: lirc_dev: driver meson-ir registered at minor = 0, raw IR receiver, no transmitter
[ 18.697305] input: meson-ir as /devices/platform/soc/c8100000.bus/c8100480.ir-receiver/rc/rc0/input0
[ 18.697801] meson-ir c8100480.ir-receiver: receiver initialized
[ 18.715524] debugfs: File 'HDMITX Capture' in directory 'dapm' already present!
[ 26.806481] meson8b-dwmac c9410000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 26.887179] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=43)
[ 26.897172] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found
[ 26.897245] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW
[ 26.908182] meson8b-dwmac c9410000.ethernet eth0: configuring for phy/rgmii-id link mode
Let me know if I can provide more supporting info/logs.
Thanks for the quick test. So something is still missing 
. That part at least looks correct now:
[ 3.201401] meson-drm d0100000.vpu: meson_vclk_setup(target: 1, phy: 1485000000, dac: 148500000, venc: 148500000, hdmi_use_enci: 0)
[ 3.332232] meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device
[ 3.408180] hdmimode=1080p
[ 3.408191] vout=hdmi
[ 3.408203] hdmitx=cecf
Interesting that the whole HDMI/DRM stack is tied with the VPU on this board, but it indeed is like that. The clock rates here are all correct: 1485000000=1.458 GHz PHY = 10x pixel clock, which is 148500000=148.5 MHz, matching exactly 1080p60 requirements. When things failed with vanilla Armbian, these were by the factor 1000 too low.
Can you show the full dmesg output, so we are not missing something? Also since I am still interested in with environment:. And a dedicated dmesg -l 0,1,2,3 to see errors explicitly would be good, too.
dmesg -l 0,1,2,3:
~$ dmesg -l 0,1,2,3
[ 2.181696] remoteproc remoteproc0: request_firmware failed: -2
[ 2.191281] nvmem meson8b-efuse0: cell calib raw len 2 unaligned to nvmem word size 4
[ 2.204514] nvmem meson8b-efuse0: cell mac raw len 6 unaligned to nvmem word size 4
[ 3.191442] meson-drm d0100000.vpu: meson_vclk_setup(target: 1, phy: 1485000000, dac: 148500000, venc: 148500000, hdmi_use_enci: 0)
[ 17.881110] debugfs: File 'HDMITX Capture' in directory 'dapm' already present!
Here is the full output: PrivateBin
Okay, so the meson_vclk_setup message is not actually an error. It is emitted whenever an meson8, meson8b, or meson8m2 compatible VPU was detected, as part of the Armbian patch. It should be usually an info or debug severity message, but was been given error severity most likely for easier debugging.
It says CVBS Output connector not available, hence MESON_VCLK_TARGET_CVBS is not 1, hence the PHY frequency is not reduced to 1296 MHz, that seems correct as well.
So from the logs I do not see the issue. Need to let Copilot go through the upstream commit, the Armbian patch, our patch of the patch, and the logs, to hopefully find a good hint.
The other interesting get from the logs:
[ 3.394973] Run /init as init process
[ 3.398308] with arguments:
[ 3.398317] /init
[ 3.398325] with environment:
[ 3.398330] HOME=/
[ 3.398337] TERM=linux
[ 3.398342] vdaccfg=0xa000
[ 3.398348] dmfc=3
[ 3.398354] cvbsmode=576cvbs
[ 3.398359] hdmimode=1080p
[ 3.398365] m_bpp=32
[ 3.398370] vout=hdmi
[ 3.398376] disablehpd=true
[ 3.398382] hdmitx=cecf
[ 3.398387] monitor_onoff=true
[ 3.398393] max_freq=1536
All those variables in the with environment block are not consumed by the kernel, hence are obsolete cruft in our boot.ini, ready for cleanup.
@MichaIng since I understand that troubleshooting the HDMI issue might require some time and since it is agreed not to be high-priority, could you please in the meantime (maybe by the next kernel re-build) amend/fix the package description which is reporting currently an incorrect version for the C1?
Package: linux-image-current-meson
Version: 26.08.0-trunk-dietpi1
APT-Sources: Index of /apt all/odroidc1 armhf Packages
Description: Armbian Linux current kernel image 6.12.46-current-meson
I am not sure where string is coming from, but seems incorrect also for other kernel images, like linux-image-current-meson64 for the ODROID N2.
That is interesting. I’ll have a look where this is coming from:
- The control file is written here: build/lib/functions/compilation/kernel-debs.sh at 109c1c8390d873a3526ca3872c60f28e9a13c824 · MichaIng/build · GitHub
- Hence the
$kernel_version_familyvariable. That is actually the same used for the/boot/vmlinuz-*,/boot/config-*, and/lib/modules/*directories, so it cannot be wrong.
@elv which command did you run to see this? … ah
root@micha:~# apt show linux-image-current-rockchip64
Package: linux-image-current-rockchip64
Version: 26.08.0-trunk-dietpi2
Priority: optional
Section: kernel
Maintainer: John Doe <john.doe@somewhere.on.planet>
Installed-Size: 135 MB
Provides: linux-image, linux-image-armbian, armbian-current, wireguard-modules, linux-dtb, linux-dtb-armbian, linu
x-dtb-current-rockchip64
Depends: initramfs-tools | linux-initramfs-tool
Breaks: linux-dtb-current-rockchip64
Replaces: linux-dtb-current-rockchip64
Download-Size: 68.3 MB
APT-Sources: https://dietpi.com/apt all/nanopim6 arm64 Packages
Description: Armbian Linux current kernel image 6.12.46-current-rockchip64
That one is actually Linux 6.18. Somehow the “6.12.46” seems to be hardcoded across all current branch builds. Also linux-image-edge-rockchip64 is outdated at “6.16.4”, while it is 7.1.2.
This seems to be a bug in APT. Here is the Packages file, the one and only truth where APT gets the package info and their Description: https://dietpi.com/apt/dists/all/odroidc1/binary-armhf/Packages
As you can see, 6.12.46 is from the first package version listed in this file. It seems like APT is taking this first description field for all versions of the package.
When you use dpkg -l linux-image-current-meson, you see the correct description of the locally installed package, coming from /var/lib/dpkg/status. So dpkg fetches and stores the correct info from the actually installed deb package, and they do contain the correct info in their control files. But APT fetches info by itself from the downloaded Packages files, and probably uses just the first description to safe time.