I just got my uConsole setup put together! I’ve been reading through the extensive posts here, which were incredibly helpful for getting the system up and running. I managed to get the OS running smoothly from the NVMe drive using Rex’s Debian Trixie (6.12.87) image.
Huge shoutout and thank you to @Rex for your impressive, extensive work on this!
I have a CM5 + HackerGadgets upgrade (RJ-45 USB3) configuration, but I am stuck on two main issues and would appreciate some advice on the latest recommended fixes:
Keyboard & Trackball Issues: The Space, Backspace, and Enter keys are not functioning, and the trackball is responding but not smoothly. What is the currently recommended firmware to fix this, and what is the best method to flash it?
Expansion Port USB 3.0 Not Working: The USB 3.0 port does not recognize thumb drives or wireless keyboard dongles. Interestingly, the stock USB 2.0 port and the RJ-45 Ethernet port on the expansion board both work perfectly. Any tips on getting the USB 3.0 port recognized?
Lastly, for a CM5 + HackerGadgets setup, is Rex’s Trixie image the community’s top recommendation, or should I be looking at a different configuration - Bookwarm?
usb3.0 not working means it’s an issue with the ribbon cable, that caries the usb3 lines, the usb2 stuff goes via the main board connector so that works even with a bad cable
Thank you @white-round-square .
I actually used wev instead of xev, but the keys weren’t returning anything at all. As it turns out, it was entirely my fault - I accidentally damaged the keyboard PCB.
Following your advice, I updated the keyboard firmware using QMK and noticed that the problematic keys were returning a string of random characters, which pointed to a hardware short. When I checked the back of the PCB, I realized the screws I used for the battery board mod were slightly too long. They had damaged two traces on the keyboard PCB and caused a short circuit. I managed to fix it by soldering the broken traces and covering them with insulating nail polish. The keyboard is working perfectly now, and the QMK firmware actually improved the trackball response as well!
To clarify, the original uConsole screws are fine; this only happened because I used longer ones for a custom modification to secure the extended lithium battery to the board (which actually turned out great!). I’ve since swapped them out for shorter screws, and everything is running flawlessly.
I’ve attached pictures of both the damaged PCB and the custom battery holder in case anyone else wants to secure their uConsole extended
I wanted to share some empirical findings from troubleshooting the USB 3.0 ports on my ClockworkPi uConsole running a Raspberry Pi Compute Module 5 (CM5) combined with the HackerGadgets Ethernet expansion board.
When I noticed that the USB 3.0 ports were completely unresponsive, I decided to flash a clean ak-rex’s Debian Bookworm image, hoping that the more mature and stable package base would provide better out-of-the-box hardware support. Unfortunately, the issue persisted.
If your USB ports are completely dead electrically on this setup while the Ethernet port works flawlessly, here is a summary of what has been tested, what works, and the dead-end we hit regarding the VBUS power line.
1. What Works (The Baseline)
Ethernet Connectivity: Fully operational. The system cleanly detects and interfaces with the network via the RP1 southbridge chip, proving the expansion board is communicating properly with the CM5 over PCIe.
OS & Stability: The system is completely stable, booting flawlessly from the SSD under Wayland/Bookworm.
2. What Was Tested & Failed (The USB VBUS Issue)
The core issue is that the USB 3.0 ports are completely unpowered (no 5V VBUS delivery to connected dongles/devices).
The Theory: On a standard Raspberry Pi 5 architecture, the RP1 chip uses GPIO pin 42 (USB_VBUS_EN) as a hardcoded internal trigger to enable the USB power regulator.
The Attempt: To bypass any potential kernel-level power management locks, I explicitly forced RP1 GPIO pin 42 into a permanent high state using a custom Device Tree Overlay (DT Overlay)
The Result: Querying the system via gpioinfo gpiochip0 confirmed that pin 42 successfully changed status from unused to [used] output active-high. However, the USB ports remained entirely dead.
Conclusion & Question for the Community
Because forcing RP1 Pin 42 to active-high did absolutely nothing to deliver power to the ports, it is highly likely that HackerGadgets did not route the USB VBUS power switch through the default RP1 pin 42 on this specific Ethernet expansion board. It is likely tied to a completely different GPIO pin, either elsewhere on the RP1 or directly from the CM5 main processor.
Has anyone successfully mapped the schematics for this specific expansion board? Which exact GPIO pin controls the USB VBUS power switch on the HackerGadgets Ethernet board? Any insights, schematics, or working .dtbo definitions would be highly appreciated!
@vileer@Rex I would highly appreciate your expert guidance on this if you have a moment.
GPIO pin 42 (USB_VBUS_EN) was not involved in the RJ45 & USB 3.0 expansion board. It uses individual power switches for the USB ports, and they were enabled all the way. Only the side USB ports support USB 3.0 (USB-A and USB-C). Please tell me which port didn’t work. If it’s the USB-A, please check the contact pins inside; it may be bent if the USB plug was not inserted correctly.
I’ve checked the connector and it seems that one of the connector pin was damaged or banded. Probably when I inserted the cable connector. Image attached.
