Platform: Odroid C1
Release: Trixie
Issue:
The debian package
linux-image-current-meson_26.02.0-trunk-dietpi5.deb 2026-03-12 12:31 37M
contains an older version of the linux image kernel (6.12.28) with respect to the previous one (6.12.74):
linux-image-current-meson_26.02.0-trunk-dietpi4.deb 2026-02-22 18:02 37M
Among other things this is breaking some dkms modules which are failing to compile on this older kernel 6.12 version.
Could you please give it a look?
Regards.
I recognized that Armbian froze the kernel to an older version “to keep HDMI in a working state”: https://github.com/armbian/build/pull/9465
I am also not super happy with it, but: HDMI indeed regularly broke on this board, so I can understand that for this old board with low support state keeping things functional with a frozen kernel is pragmatic. This was not done or approved by the official Armbian Odroid C1 board maintainer, though.
It should not break DKMS, as the headers are kept omin sync. The headers package was upgraded as well, right?
That said, we could unfreeze the kernel in our fork. But would be good if someone could test HDMI then.
I am currently using this SBC as headless server, I was not even aware that the HDMI support was there at all (it never worked for me in the past since the adoption of a mainline kernel, I stopped bothering about it long time ago).
In any case yes, I upgraded the headers file as well.
The dkms module that fails to compile with the latest kernel package is: https://github.com/lwfinger/rtw88, while it compiles fine with the previous one.
Out of curiosity I plugged in a mini-HDMI cable into the C1 and, as expected, i did not get any signal on the connected monitor (however I have now the kernel on-hold on the latest version that is working for me).
rtw88 is in mainline Linux, and Armbian patches support for some additional chips into it, supported in more recent Linux versions. Are you missing a particular sub driver that you need to compile it from source?
So you mean it does not work with v6.12.74? That is probably the very reason it got downgraded.
EDIT: Checking meson: freeze current kernel at 6.12.28 and fix HDMI PHY frequency limit by igorpecovnik · Pull Request #9465 · armbian/build · GitHub, actually I think I see where the problem is with the more recent version:
.max_hdmi_phy_freq now takes values in Hz instead of kHz, as can be seen from “1650000000” => “1650000” revert. The patch still uses kHz values, which will break things for affected chips. However, the Odroid C1 is meson8b, hence should not match the patched value, but instead the value present upstream. That patch is for other SBCs which we do not directly support. But I am still sure that this commit is the issue, would need to check other patches which do affect the Odroid C1.So if someone finds time to test:
.max_hdmi_phy_freq value of the patch to be in Hz, and in case fix other patches which were broken by this.I need the dkms module for a Wi-Fi dongle based on RTL8811AU. Currently this dkms driver worked pretty well.
My understanding is that the mainline driver is available only in kernel > 6.14.
Indeed, I just plugged in the HDMI cable connected to an external display: nothing showed up. I have not checked if anything needed to be changed in the settings or on the software side though…
At the moment I have marked the kernel/header for holding.
I will have physical board availability only for few days at the end of the week (then I will only have remote access for some time).
Unfortunately my setup is not ideal for troubleshooting, I also do not have always possibility of using an Ethernet connection and this make more difficult to experiment on the networking side.
What I would prefer honestly is not to remain blocked on an old kernel which might have other downsides long term…
The kernel has this patched, i.e. support for RTL8811AU backported: build/patch/misc/rtw88/6.12/001-drivers-net-realtek-rtw88-upstream-wireless.patch at 28862c7c0e0e914640a40286766030b3fba1bc41 · armbian/build · GitHub
And compared to vanilla Armbian, we do also enable it: mainline-kernel: align enabled WiFi drivers · MichaIng/build@8b9fc7e · GitHub
At least worth to test when you have physical access, e.g. by moving the DKMS driver out of the way, doing a reboot, and if WiFi is unexpectedly does not work anymore, move it back. But if it does as expected, you can remove DKMS.
I’ll at least prepare a v6.12.33 kernel build, and have a look into possible reasons v6.12.34 breaks HDMI on thay board.
Agreed a frozen version is not great.
Tried it today, unfortunately no joy.
When removing the dkms driver, after a reboot the dongle is still recognized by lsusb, however no driver is loaded at boot (dietpi-config is also not recognizing any wireless extension).
When searching for rtw8* in the available modules list, this is what I am getting (I do not see the rtw_8821au):
rtw88_8703b rtw88_8723de rtw88_8821c rtw88_8821cu rtw88_8822bs rtw88_8822ce rtw88_core rtw88_usb rtw89_8852a rtw89_8852b_common rtw89_8852ce
rtw88_8723cs rtw88_8723du rtw88_8821ce rtw88_8822b rtw88_8822bu rtw88_8822cs rtw88_pci rtw89_8851b rtw89_8852ae rtw89_8852be rtw89_core
rtw88_8723d rtw88_8723x rtw88_8821cs rtw88_8822be rtw88_8822c rtw88_8822cu rtw88_sdio rtw89_8851be rtw89_8852b rtw89_8852c rtw89_pci
After reinstalling the dkms driver and rebooting, the dongle got back on track.
Does this mean that the patch applied to the kernel is not working as expected?
How could we further proceed?
Uff, the patch was skipped due to a false name 
: patch: rtw88: fix patch names · MichaIng/build@68ae425 · GitHub
New build triggered: Armbian · MichaIng/DietPi@b1db9ae · GitHub
Once done, test with:
G_DEV_TEST_FIRMWARE
@MichaIng, thanks for your prompt support.
What is the expected effect of this command? I am not sure it worked correctly since I only got an SSH disconnection upon execution.
In any case, I installed the new packages set (kernel image, headers, firmware) and removed the dkms driver, unfortunately the Wi-Fi dongle is still not working after a reboot (“No WiFi adapter was detected on your device”).
On the newer kernel this is the dkms module compilation error:
Building module(s)
# command: KVER=6.12.28-current-meson 'make' all
make -j3 -C /lib/modules/6.12.28-current-meson/build M=$PWD modules
make[1]: Entering directory '/usr/src/linux-headers-6.12.28-current-meson'
warning: the compiler differs from the one used to build the kernel
The kernel was built by: arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
You are using: gcc (Debian 15.2.0-16) 15.2.0
CC [M] /var/lib/dkms/rtw88/0.6/build/main.o
CC [M] /var/lib/dkms/rtw88/0.6/build/led.o
CC [M] /var/lib/dkms/rtw88/0.6/build/mac80211.o
/var/lib/dkms/rtw88/0.6/build/main.c: In function ‘rtw_sband_dup’:
/var/lib/dkms/rtw88/0.6/build/main.c:1769:25: error: implicit declaration of function ‘devm_kmemdup_array’; did you mean ‘devm_kmalloc_array’? [-Wimplicit-function-declaration]
1769 | dup->channels = devm_kmemdup_array(rtwdev->dev, sband->channels,
| ^~~~~~~~~~~~~~~~~~
| devm_kmalloc_array
/var/lib/dkms/rtw88/0.6/build/main.c:1769:23: error: assignment to ‘struct ieee80211_channel *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
1769 | dup->channels = devm_kmemdup_array(rtwdev->dev, sband->channels,
| ^
/var/lib/dkms/rtw88/0.6/build/main.c:1776:23: error: assignment to ‘struct ieee80211_rate *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
1776 | dup->bitrates = devm_kmemdup_array(rtwdev->dev, sband->bitrates,
| ^
make[3]: *** [scripts/Makefile.build:229: /var/lib/dkms/rtw88/0.6/build/main.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [/usr/src/linux-headers-6.12.28-current-meson/Makefile:1949: /var/lib/dkms/rtw88/0.6/build] Error 2
make[1]: *** [Makefile:224: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.12.28-current-meson'
make: *** [Makefile:193: all] Error 2
I had to revert to the last compiling one: 26.02.0-trunk-dietpi4 (6.12.74).
Additionally, I noticed that the description of linux-image-current-meson (from 26.02.0-trunk-dietpi2 to 26.05.0-trunk-dietpi1) is:
Armbian Linux current kernel image 6.12.34-current-meson
Which is not matching the real version provided by the package.
It should download and install the meson image+deb+headers packages from here: Index of /downloads/binaries/testing
That kernel does contain the needed driver modules:
$ dpkg-deb --contents linux-image-current-meson.deb | grep rtw88
...
-rw-r--r-- root/root 24092 2026-04-11 02:26 ./lib/modules/6.12.28-current-meson/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8812a.ko.xz
-rw-r--r-- root/root 15548 2026-04-11 02:26 ./lib/modules/6.12.28-current-meson/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8812au.ko.xz
-rw-r--r-- root/root 23260 2026-04-11 02:26 ./lib/modules/6.12.28-current-meson/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8821a.ko.xz
-rw-r--r-- root/root 15448 2026-04-11 02:26 ./lib/modules/6.12.28-current-meson/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8821au.ko.xz
...
Step by step, first I assured the intended kernel modules are present, as this should render DKMS obsolete for you, and the bug with the wrong patch names affected all Linux 6.12 builds for all SBCs (on Linux 6.18 the patch is obsolete, would fail, which was never recognized as it was never applied due to the bug).
Regarding lifting the kernel version freeze: did you find time to test HDMI with this Linux 6.12.28? I just want to assure we do not try to debug why more recent Linux breaks HDMI, if it was broken before already. I do not trust Armbian commit/PR texts stating that this or that works or was fixed, as this has been quite often false, or a matter of more/other conditions, or incomplete conclusion logic. Hence better to test the actual state, before investing time.
@MichaIng, sorry I misunderstood how to test the newer packages earlier and I ended up using the version uploaded in the dietpi apt repository.
The command G_DEV_TEST_FIRMWARE apparently it is not working for me (it is just kicking me out of the SSH session). Anyhow, I have installed the .deb manually from the URL you provided:
), even if the built-in led is not blinking anymore by default (
).
).Great, so far so good.
Interesting, can you test this again in a subshell?
bash
G_DEV_TEST_FIRMWARE
And are you executing it as root or unprivileged user? It internally calls itself with sudo if executed as unprivileged user, but maybe this process has an oversight if e.g. the user has no sudo or so, that exits the shell instead of just returning the function.
The WiFi dongle has a builtin LED? Is that exposed at /sys/class/leds, i.e. in dietpi-led_control?
Interesting, are the characters themselves garbled, or is there heavy tearing, like horizontal pixel rows disarranged or similar? Maybe changing the resolution and/or frequency in /boot/boot.ini helps. It seems to be hardcoded to 1080p@60Hz. Hotplug-detection can be disabled there (to force output), maybe this helps to mitigate some init steps, if the HDMI signal is weak or flaky. Also I do wonder whether these /boot/boot.ini settings do all still work 
. E.g. does the monitor appear below /sys/class/drm and in dietpi-display, as DRM device?
sudo: G_DEV_TEST_FIRMWARE: command not found
$ G_DEV_TEST_FIRMWARE
[ INFO ] Root privileges required. Retrying with sudo: sudo -bash
usage: sudo -h | -K | -k | -V
usage: sudo -v [-ABkNnS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-ABkNnS] [-g group] [-h host] [-p prompt] [-U user]
[-u user] [command [arg ...]]
usage: sudo [-ABbEHkNnPS] [-r role] [-t type] [-C num] [-D directory]
[-g group] [-h host] [-p prompt] [-R directory] [-T timeout]
[-u user] [VAR=value] [-i | -s] [command [arg ...]]
usage: sudo -e [-ABkNnS] [-r role] [-t type] [-C num] [-D directory]
[-g group] [-h host] [-p prompt] [-R directory] [-T timeout]
[-u user] file ...
Connection to X.Y.Z.W closed.
The dongle has a small blue built-in led which was blinking when the connection was established with the dkms driver.
As far as I can see the led is not exposed:
$ ls -l /sys/class/leds
total 0
lrwxrwxrwx 1 root root 0 Apr 12 18:08 c1:blue:alive -> ../../devices/platform/leds/leds/c1:blue:alive
Seems more like the second scenario, not a problem of the characters themselves, but rather pixels shifted and/or not properly aligned. The monitor I used support correctly 1080p@60Hz.
$ ls /sys/class/drm
card0 card1 card1-HDMI-A-1 renderD128 version
Changing any setting in dietpi-display result in this error:
[FAILED] Boot configuration not found
Changing resolution in /boot/boot.ini also does not seem to work.
Yes that cannot work, since G_DEV_TEST_FIRMWARE is a shell function, not available in a non-interactive shell like sudo. You could do
G_SUDO G_DEV_TEST_FIRMWARE
A wrapper which loads dietpi-globals within a subshell. But that should not be necessary.
Oh, in case of a login shell it is -bash. A bug in G_DEV_TEST_FIRMWARE not detecting this case case of an interactive bash session. Fixed with dietpi-globals: G_CHECK_ROOT_USER: detect login shell correctly · MichaIng/DietPi@dcbbd76 · GitHub.
The reason why the session SSH session was exited is that the function, assuming it run within a script, runs exec sudo "$0" "$@", i.e. it replaces the parent shell with the sudo call. Good to avoid a nested subshell, but bad it the parent shell was not a script but interactive .
Okay, seems the mainline driver (version) does not support that LED. Actually it does: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/realtek/rtw88/led.c
But not Linux 6.12: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/realtek/rtw88/led.c?h=linux-6.12.y
I think this is too big to backport, and I don’t think anyone will do the efforts to port Odroid C1 to Linux 6.18. So if that LED is wanted, no way around DKMS, it seems, leaving again the compile issue and kernel version. So let’s focus on that now.
I thought so, i.e. some signal issue or so. Even if the monitor supports 1080p@60Hz, it is possible that the output signal is too weak, the cable too long, or so.
Maybe those only worked in a much older vendor kernel then. That it is exposed as DRM device is another indicator that all/most of those HDMI related boot configs are obsolete.
Oh, boot.ini is used only in case of Odroid C1 and Odroid XU4, hence I missed to implement support for that. This should do: dietpi-display: add support for Odroid C1/XU4 (boot.init) · MichaIng/DietPi@09d108f · GitHub
Will test tomorrow on my Odroid XU4.
Ah that is a pity! Thanks for the investigation and the effort spent up to now!
Do you think that the C1 will never move away from the 6.12.XX branch then?
Well, I would consider having the WiFi dongle’s led working, more like a nice-to-have rather than a strict requirement, surely not an high-priority task; indeed as you suggested it is more valuable to get rid of the dkms and compilation burden.
That said, I have no idea if it could be expected that the driver which was compiling fine on 6.12.74 is not with 6.12.28.
Chances are very low. That the kernel was frozen to a 2 years old version instead of fixing whatever broke HDMI in newer ones, is telling. The device is too old, with too low relevancy to invest a lot of time.
@MichaIng can we do any troubleshooting related to the kernel holding?
I suspect the kernel code to be too old for the DKMS driver code.
As a first step, I raised the frozen kernel version to 6.12.33, which, if my guess about the culprit commit breaking HDMI was correct, should still have functional HDMI: Armbian · MichaIng/DietPi@5cc81b5 · GitHub
Once done, please test again with
G_SUDO G_DEV_TEST_FIRMWARE
or manual download+install as before. However, the G_SUDO should workaround the bug you faced.
If this works, I’ll rebase the patches onto v6.12.34, and try to fix all breaking implications of the upstream commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=1017560.