well, I’ll be damned.
it was a PEBCAK all along.
./shame
I am going to assemble it the right way right now. also, as the module is slightly tighter, I’ve been able to keep it alive even at 6%
thank you very much Rex
2 Likes
seems like I need to disassemble mine. I do not like you anymore 
3 Likes
You know you still love me… 
4 Likes
I’m gonna reference your post in my “useful links” thread.
I think there must be a couple of users with the same assembly issues.
5 Likes
Is anyone with a CM5 having any problem with the uConsole panel under the current kernel 6.12.22?
I am not sure what sort of problems you might be referring to, but i am running that kernel on my CM5 and everything seems fine.
1 Like
I was just checking, because upcoming shipments of the uConsole will have a new panel.
A new driver was added that supports both (old & new) panels, and in my testing the same driver worked with both the CM4&5 with the old (current) panel. So I’ve switched out the old panel drivers that needed one for the CM4 and one for the CM5, for the new driver that works with both. I’ve had one report of it not working with the CM5 but under Arch.
So I was just wanting some feedback on how the new panel driver is working or NOT working.
2 Likes
No problems here with the 6.12.22-v8-16k+ and a CM5 8GB lite.
3 Likes
Are the images linked above intended to be flashable to an SD card, and booted directly on a DevTerm with no pre-configuration? I’m finding that I get no display on the DevTerm internal panel, and if I disconnect that and boot with an external display, I see some boot messages, but never reach a desktop environment.
seems like you need to make an edit of config.txt and enable devterm line there.
you may also have issues with screen rotation, you can search in this topic by ‘screen’ keyword
1 Like
OK, but the config.txt file does not exist, it is a symlink to a missing file (/boot/firmware is empty).
I’ll take a look at the sections you mention and have another try, though. Thanks for the pointer.
that’s weird, people say it’s not mount sometimes for magic reasons, but then appears. wizardry 
https://forums.raspberrypi.com/viewtopic.php?t=361149
and do you use cm4 or cm5 in your devterm? (just pre-collect data for @rex)
1 Like
When you flash the SD card there will 2 partitions boot root in the boot partition you need to edit the config.txt. Comment out the uConsole and uncomment the DevTerm in each section. Make sure you don’t apply any custom settings to the image when flashing.
Is the panel the same one that the DevTerm comes with?
The screen will be rotated 90°, all the pre-configured rotations are for the uConsole.
1 Like
Thanks, for some reason the boot partition is not mountable on my Fedora 42 laptop (complains about partition type, although fdisk shows it as Win95 FAT); I managed to write another copy of the Parrot image on a MacBook, access the boot partition, and edit the config file!
Tried booting again, the LCD panel lights up but nothing is displayed. It’s the same physical size and resolution as the original and the ribbon fits but I admit it could be a different model, I’ll try the original again tomorrow.
On an external display, the boot messages whiz past and it clearly identifies as Parrot but the desktop also does not show up.
I’ll do some more tests tomorrow and I should be able to write to the CM5 eMMC then as well.
1 Like
Yeah if it’s not the same panel then the driver most likely wont work. I’m not sure about parrot but this Debian Bookworm image should show the extended desktop screen on HDMI if you wanna test that out.
2 Likes
A carrier board for the CM5 arrived today, so I flashed the Bookworm image to the eMMC and booted from that. The display panel works, but there is a line of corruption along the top edge. It booted into the nice customised first boot wizard and I was able to go through that and configure things; however, once it tried to restart, the screen is blank again. Progress though! I’ll keep persevering here.
Is that with the panel you got to replace the stock one or the stock panel?
Thanks Rex! I am not sure what new panel you mentioned. I still have a problem with orange charging Led which does not light up. Another one is a noise from speakers when operating in a very low battery (I believe this belongs to hardware limitation).
Kernel .22 with CM5Lite8GB. Thank you!
The last poster sourced a replacement screen for their DevTerm, that is not the same model as the stock screen. That’s what the last post was talking about.
There will also be a new panel being shipped with future uConsole shipments, but the updated driver for the uConsole will support it.
I’ll be working on figuring out that charge LED this coming week.
1 Like
The issue with the panel driver is mostly with probe ordering and timing – the driver gets probed and initialized before the supply voltage regulators are, so the first initialization sequence does exactly nothing. However, if, for example, your desktop environment blanks the screen and resets it when it starts up, or for some reason the display panel module is loaded extremely late, then this might work anyway.
I have no clue why this specific case kept happening on my hardware, but it’s not weird that timing issues behave like that. It could also be a result of not trying to boot into a desktop environment immediately, and thus no blanking and re-initialization (however, manually blanking the framebuffer also didn’t work for me – probably because the code in unprepare is all commented out). I’m also ~50% sure that almost all the panel initialization issues the uConsole has ultimately boil down to this probe timing. This is also why blanking the framebuffer and un-blanking it usually fixes the issue. In fact, all 3 of the old drivers (cm3, cm4, cm5) handled startup timing differently. And the CM4 driver didn’t even have the two voltage regulators defined before.
Here’s a pull request to fix up initialization ordering: drm: panel: cwu50: Fixup for probe ordering and initialization timing by PeterCxy · Pull Request #3 · ak-rex/ClockworkPi-linux · GitHub. I added the iovcc definition for CM4 too so that initialization order is somewhat fixed there as well. But I didn’t add vci because I’m not sure what that regulator maps to on the CM4 and I don’t have a real piece of hardware at hand to test with. My current Arch Kernel build contains the fix already.
3 Likes