Bookworm 6.12.y for the uConsole and DevTerm

[white-round-square]

@Astrox

Like, can I not change any settings, or configs?

you can’t apply ‘custom settings’ during flashing – OS won’t boot – you need to flash image as it.

then you need to boot OS and wait till initial required reboot.

then you can change whatever you want however you want.

[snipeytje]

raspi imager custom setting requires the image to be very similar to official pi images, the changes required to make the uconsole work are too big so it overwrites some of the required settings when you tell it to do any customization like entering your wifi password already

[jose1711]

Hello,

I have encountered a new issue that likely lies in the kernel area. For work, I need WebAuthn configured with a YubiKey (in my case, a YubiKey 5 NFC plugged directly into USB-A).

On Debian Bookworm, FIDO2 functionality has become very unreliable: the browser almost never prompts for the PIN, making it practically unusable. I was able to reduce it to a minimal test case: requesting FIDO information via YubiKey Manager (ykman).

On stock Debian 11 (Bullseye), I get consistent output across multiple runs (10 invocations):

$ sudo ykman --log-level DEBUG fido info
2026-03-15T20:36:22+0100 INFO [ykman.logging_setup.setup:74] Initialized logging for level: DEBUG
2026-03-15T20:36:22+0100 INFO [ykman.logging_setup.setup:75] Running ykman version: 4.0.0a1
2026-03-15T20:36:22+0100 DEBUG [ykman.logging_setup.log_sys_info:46] Python: 3.9.2 (default, Jan 25 2026, 13:37:52)
[GCC 10.2.1 20210110]
2026-03-15T20:36:22+0100 DEBUG [ykman.logging_setup.log_sys_info:47] Platform: linux
2026-03-15T20:36:22+0100 DEBUG [ykman.logging_setup.log_sys_info:54] Running as admin: True
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:156] SEND: ffffffffREDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: ffffffffREDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:156] SEND: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [ykman.device.read_info:380] Read info: DeviceInfo(config=DeviceConfig(enabled_capabilities={<TRANSPORT.USB: 1>: <CAPABILITY.FIDO2|OATH|PIV|OPENPGP|4|U2F|OTP: 575>, <TRANSPORT.NFC: 2>: <CAPABILITY.FIDO2|OATH|PIV|OPENPGP|4|U2F|OTP: 575>}, auto_eject_timeout=0, challenge_response_timeout=15, device_flags=<DEVICE_FLAG.0: 0>), serial=10667718, version=Version(major=5, minor=2, patch=4), form_factor=<FORM_FACTOR.USB_A_KEYCHAIN: 1>, supported_capabilities={<TRANSPORT.USB: 1>: <CAPABILITY.FIDO2|OATH|PIV|OPENPGP|4|U2F|OTP: 575>, <TRANSPORT.NFC: 2>: <CAPABILITY.FIDO2|OATH|PIV|OPENPGP|4|U2F|OTP: 575>}, is_locked=False)
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:156] SEND: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:156] SEND: 01REDACTED
2026-03-15T20:36:22+0100 DEBUG [fido2.hid.call:176] RECV: 01REDACTED
PIN is set, with 8 tries left.

With Debian 12 bookworm it times out most of the time:

root@clockworkpi:~# ykman --log-level DEBUG fido info
2026-03-15T20:30:03+0100 INFO [ykman.logging_setup.setup:76] Initialized logging for level: DEBUG
2026-03-15T20:30:03+0100 INFO [ykman.logging_setup.setup:77] Running ykman version: 4.0.9
2026-03-15T20:30:03+0100 DEBUG [ykman.logging_setup.log_sys_info:48] Python: 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
2026-03-15T20:30:03+0100 DEBUG [ykman.logging_setup.log_sys_info:49] Platform: linux
2026-03-15T20:30:03+0100 DEBUG [ykman.logging_setup.log_sys_info:50] Arch: aarch64
2026-03-15T20:30:03+0100 DEBUG [ykman.logging_setup.log_sys_info:56] Running as admin: True
2026-03-15T20:30:03+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:03+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:03+0100 DEBUG [fido2.hid.call:156] SEND: ffffffffREDACTED
2026-03-15T20:30:08+0100 ERROR [ykman.cli.__main__.retrying_connect:102] Failed opening connection
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/ykman/cli/__main__.py", line 97, in retrying_connect
    return connect_to_device(serial, connections)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ykman/device.py", line 216, in connect_to_device
    conn = dev.open_connection(connection_type)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/ykman/hid/__init__.py", line 74, in open_connection
    return CtapHidDevice(self.descriptor, open_connection(self.descriptor))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/fido2/hid/__init__.py", line 109, in __init__
    response = self.call(CTAPHID.INIT, nonce)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/fido2/hid/__init__.py", line 157, in call
    self._connection.write_packet(packet.ljust(packet_size, b"\0"))
  File "/usr/lib/python3/dist-packages/fido2/hid/linux.py", line 41, in write_packet
    super(LinuxCtapHidConnection, self).write_packet(b"\0" + packet)
  File "/usr/lib/python3/dist-packages/fido2/hid/base.py", line 73, in write_packet
    if os.write(self.handle, packet) != len(packet):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: [Errno 110] Connection timed out
2026-03-15T20:30:09+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:09+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:09+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:10+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4
2026-03-15T20:30:10+0100 DEBUG [fido2.hid.linux.list_descriptors:72] Found CTAP device: /dev/hidraw4

There does not seem to be anything relevant in dmesg output or journal.

As the issue might be related to kernel - is there a way how to debug it further? Is there a way to downgrade it?

Update:

Here’s another test writing to the device. Script: ctaphid_write_test.py · GitHub

Debian 12, kernel 6.12.67

for i in $(seq 20); ./ctaphid_write_test.py; sleep 1; end
write ok
write ok
write failed: [Errno 32] Broken pipe
write ok
write ok
write failed: [Errno 32] Broken pipe
write ok
write ok
write failed: [Errno 32] Broken pipe
write failed: [Errno 32] Broken pipe
write ok
write ok
write ok
write ok
write ok
write ok
write ok
write failed: [Errno 32] Broken pipe
write ok
write failed: [Errno 32] Broken pipe

Debian 11, 5.10.17: 20x write ok

[jms1]

Totally guessing here, take this with a five-pound bag of salt … but maybe something was added between Debian 11 and 12 that tries to make things faster by “caching” an open connection somehwer, and it should be closing the connection between successive attempts?

As a suggestion, maybe try physically removing and re-inserting the Yubikey between attempts. I’m pretty sure this would forcibly close whatever connection handles are being cached, wherever that may be happening. (I know very little about libusb and HID, and not much more about Python - I’m an old school C/Perl guy.)

But if removing the Yubi makes it always work the first time after the Yubikey was inserted, that’s a troubleshooting data point that would be useful to somebody who’s more familiar with how this stuff works under the covers.

Good luck.

[jose1711]

Thank you. I too think something has changed. I tried removing and reinserting Yubikey countless times - didn’t make any difference. FWIW just tested the same script on Debian 12 running on Raspberry Pi 5, kernel 6.12.47 - no problem at all, all writes were successful.

Test with a spare USB-C Yubikey (connected via a USB-A adapter) on uConsole - just to rule out any hw issues did not bring anything new: still failing writes and ykman returning errors most of the time. Hopefully I’ll find some time to test on Trixie.

[white-round-square]

@jose1711

I tried removing and reinserting Yubikey countless times - didn’t make any difference.

smarcard doesn’t work very well in linux at all. it may brake on the same working system and then recover, so I wouldn’t blame debian version.

I do not use FIDO and only opengpg functionality, but it drives me crazy sometimes.

[jose1711]

@white-round-square I use YK mainly on my desktop computer (recent Arch) and it’s very reliable there. Anyway, this is just a single write to a HID device I am using as a test - it should always return without error.

Btw: I ran a test on a fresh install of Trixie (lite), kernel 6.12.67 - same write errors as with bookworm.

[jose1711]

OK, so now I know the issue is somewhere in kernel between version 6.12.34 (working) and 6.12.35 (broken). Was hoping that cross-compilation would be easier and I could easily bisect to a concrete commit. So far though the compiled kernel results in blackscreen Hopefully I’ll soon update with some success.

[Rex]

If you’re compiling from raspberry pis repo you’ll need to add the drivers and overlays for the uConsole to get the screen working.

[jose1711]

Thank you, I am probably doing something wrong. At least network connectivity still works so I can SSH to uConsole.

This is my workflow:

# prepare build environment (x86_64 running arch linux)
mkdir ~/tmp/uconsole
cd ~/tmp/uconsole
# source env.sh
source env_fish.sh

# env_fish.sh contains:
set -x ARCH arm64
set -x CROSS_COMPILE aarch64-linux-gnu-
set -x KERNEL kernel8

# get kernel sources
git clone --branch rpi-6.12.y https://github.com/ak-rex/ClockworkPi-linux.git
cd ClockworkPi-linux/

# pick 6.12.22 kernel
git checkout faa9140ce1086f

# cross-compile the kernel, modules and device tree blobs
make clean
make bcm2711_defconfig
make -j$(nproc) Image modules dtbs

# with sd card mounted in /run/media/jose/{rootfs,bootfs}
# copy the generated files
sudo make INSTALL_MOD_PATH=/run/media/jose/rootfs modules_install
sudo cp arch/arm64/boot/Image /run/media/jose/bootfs/kernel8.img
sudo cp arch/arm64/boot/dts/broadcom/*.dtb /run/media/jose/bootfs/
sudo cp -r arch/arm64/boot/dts/overlays/ /run/media/jose/bootfs

eject + try booting in uconsole

update: apparently it’s not just screen that is not working - nothing shows up in dmesg output when YubiKey is inserted, shutdown -h now logs me out but the power LED is still green, there are probably other things.

[Rex]

Did you add the overlays into you config.txt or are you already using my image?

[jose1711]

I did not touch the config.txt that came with Trixie lite. But now that I am looking inside it.. it is referencing clockworkpi-uconsole overlay but I have no idea where it should come from.

[Rex]

In the image they’re at /boot/firmware/overlays
In the kernel folder structure it’s ClockworkPi-linux/arch/arm/boot/dts/overlays/ you’ll need the dtbo files that get compiled.

[jose1711]

The main issue during my earlier testing was that I was not applying the ClockworkPi kernel patches when testing older kernels.

Once I consistently applied the patches, I was able to compile and boot older kernels without issues.

Revised how-to (for reference):

 # prepare environment (x86_64 running arch linux)
mkdir ~/tmp/uconsole
cd ~/tmp/uconsole
# source env.sh
source env_fish.sh

# env_fish.sh contains:
set -x ARCH arm64
set -x CROSS_COMPILE aarch64-linux-gnu-
set -x KERNEL kernel8

# get raspberry pi kernel sources and clockwork 6.12 kernel patch from rex's repo
git clone https://github.com/raspberrypi/linux.git
wget -O clockworkdrivers1.patch https://github.com/ak-rex/ClockworkPi-linux/commit/5633aedcb3fd632d64c54db0184880d1954de62b.patch
wget -O clockworkdrivers2.patch https://github.com/ak-rex/ClockworkPi-linux/commit/4b5b5fe35abbbf4193ddbeab149833172096066b.patch
cd linux

# pick 6.12.34 kernel
git checkout b2873db65

# apply the patches
git apply ../clockworkdrivers*.patch
# pick a different commit if the patches fail to apply

# cross-compile the kernel, modules and device tree blobs
make clean
make bcm2711_defconfig
make -j$(nproc) Image modules dtbs

# with sd card mounted in /run/media/jose/{rootfs,bootfs}
# copy the generated files
sudo make INSTALL_MOD_PATH=/run/media/jose/rootfs modules_install
sudo cp arch/arm64/boot/Image /run/media/jose/bootfs/kernel8.img
sudo cp arch/arm64/boot/dts/broadcom/*.dtb /run/media/jose/bootfs/
sudo cp -r arch/arm64/boot/dts/overlays/ /run/media/jose/bootfs

Also, I was able to bisect to the specific commit that introduced the issue and reported it at usb: dwc2: regression in split interrupt handling breaks FIDO (YubiKey) behind hub · Issue #7282 · raspberrypi/linux · GitHub.

@Rex Is there any chance you could build a separate .deb kernel package with 5329a41 reverted (until a proper solution is found)? Thanks.

[Blaze]

Hello Rex

Ibought a CM5 without emmc yesterday，but when i flash my tfcard and power on，the screen wasnt light.I had other display with hdmi and it had some issue like pic.I try to exchange tf card and another uconsole.it not good

[snipeytje]

did you read the section on CM5 eeprom edits in the first post?

also trixie is the more updated debian variant

Trixie 6.12.y for the uConsole and DevTerm

Debian 13 Trixie Now Available! Debian is one of the oldest operating systems based on the Linux kernel, and is the basis of many other Linux distributions. The Debian Project is an association of individuals, sharing a common goal: We want to create a free operating system, freely available for everyone. Now, when we use the word “free”, we’re not talking about money, instead, we are referring to software freedom. Features: ClockworkPi-Trixie-6.12.y Desktop and Lite images available. Image bu…

[Blaze]

I used bookwrom . I know what you mean.but if i wanna change config about eep ，I should start up cm5 first

snipeytje <notifications@clockworkpi.discoursemail.com>于2026年5月1日 周五上午1:35写道：

[white-round-square]

@Blaze

I should start up cm5 first

try another sdcard (or carrier board if you have one)

you need to update EEPROM to “enable” all sd cards.

EEPROM config and the CM5 lite

With the upcoming release of NVME capable adapter boards from @vileer & @lululvlv I have changed up the EEPROM config to be able to use them. If you have a CM5 lite and are having problems with the sd card booting or have already updated the config but plan on getting a NVMe board. You need to edit your EEPROM and your CM5 lite has to have updated firmware that was released after 2025-01-06. Check using vcgencmd version to update sudo rpi-eeprom-update sudo rpi-eeprom-config -e To edit the eep…

[mabrown]

Using the Trixie build from the top of this topic, with updates installed, I’m seeing an issue if I leave my uConsole on and idle for a period of time (maybe 30 minutes?). The screen shuts off, the green light on the power button goes off, and I am unable to get the deck to boot unless I plug it into external power. Pressing the power button results in a flash of the green light (on, then off in less than a second), no flash from the display, and no boot activity. An extended press of the power button (8-15 seconds) also has no effect. Once external power is applied the deck powers on normally by pressing the power button. The batteries are still nearly fully charged (81% with the most recent incident). My uConsole has the AIO v2 installed and the SDR, LoRa, and GPS radios turned on.

Is anyone else seeing this issue? Is there a fix? Thanks for any help the group can provide.

[TheNavyBear]

Sounds like your batteries are not of the capacity they should be,and are telling the OS they are mostly full when they aren’t.

You can also try reinstalling the battery board and double checking that the connections, they are flakey sometimes.