Are you sure with my build it’s the screen that doesn’t power on, or is it that the kernel just doesn’t boot? You can test this by putting something like a pre-generated NetworkManager config in the rootfs and see if it ends up connecting to your Wi-Fi.
Make sure you are using the overlays from my repo and have them in the config.txt also. Each version of the CM has its own overlay. You can check out the default config.txt for my images here in the kernel folder:
@YoelFievelBenAvram I took a look at the kernel package produced by your PKGBUILD, it’s missing the CWU50 panel driver because it’s also missing from the old 6.6.y kernel config (it’s probably under a different name for that old kernel). You need at least
CONFIG_DRM_PANEL_CWU50=m
CONFIG_DRM_PANEL_CWU50_CM3=m
CONFIG_DRM_PANEL_CWU50_CM4=m
(the CM4 one is actually retired from the latest 6.12.y branch because CM4/CM5 now shares the same CWU50 driver)
But then again, I have all of these in my kernel build. I have no clue how mine doesn’t boot (or the display doesn’t power on, either way). FWIW there should not be any significant difference between the package built with your PKGBUILD and mine, save for config differences (but then again that’s just the Debian package’s config anyway).
1 Like
I was just writing that out
I had pulled the sd card, chrooted in and ran dmesg. It appears to have booted okay. @Rex the config.txt seemed to be right. This is what I’m using
[pi4]
dtoverlay=clockworkpi-uconsole
dtoverlay=vc4-kms-v3d-pi4,cma-384
dtparam=spi=on
enable_uart=1[all]
ignore_lcd=1
max_framebuffers=2
disable_overscan=1
dtparam=audio=on
dtoverlay=audremap,pins_12_13
dtoverlay=dwc2,dr_mode=host
dtparam=ant2
kernel=vmlinuz-linux-clockworkpi-git
initramfs initramfs-linux-clockworkpi-git.img followkernel
No, this doesn’t mean anything. dmesg gives you the kernel messages on the host… chrooting is irrelevant here. You need to test if it does anything else. It should probably also have written something into, for example, /var/log, if it did boot.
I just checked your kernel pkg and @PeterCxy is right you are missing the panel driver.
You’ll need to add that to your kernel config and compile it.
I hadn’t realized that. Maybe it didn’t boot. I don’t see anything in /var/log. Now to figure out why it isn’t booting…
Are you using the same rootfs when you tried my kernel build and yours? What if you kept everything the same and only replaced the kernel package (and the corresponding kernel= and initramfs in config.txt)? Because for what I can tell there should be exactly no difference here, except my package has the CWU50 driver and yours had it missing due to a different config.
Oh, @YoelFievelBenAvram I just realized (cc @mterencelao too?) that due to the nonstandard kernel naming, you probably do need
arm_64bit=1
in your config.txt in order to boot my kernel on a CM4 (ref: Raspberry Pi 4 doesn't auto-switch to 64bit mode based on kernel image filename · Issue #1193 · raspberrypi/firmware · GitHub, it only auto-switches if the kernel is named kernel8.img). The one you posted just above doesn’t have it, while the one included in your own kernel package repo has it. This is not a problem on CM5 because it boots 64-bit all the time, and this is not a problem on Rex’s Debian image because it uses kernel8 naming.
1 Like
No, I tried mine on potato’s image and yours on a fresh build. I’ll try the adding the driver to my config and try again.
Maybe try adding arm_64bit=1 to your config.txt when booting my kernel too 
1 Like
That did it! I have booted and logged in root. Thanks a lot. I can go ahead and burn my books.
1 Like
Thanks for confirming! I updated my INSTALLATION.md to add that to the config.txt example as well.
Funnily enough, the RaspberryPi documentation claims that this flag
Defaults to 1 on Raspberry Pi 4, 400 and Compute Module 4, 4S platforms. Defaults to 0 on all other platforms. However, if the name given in an explicit
kerneloption matches one of the known kernels thenarm_64bitwill be set accordingly.
So I have no clue how this didn’t default to 1 when booting my kernel build. I bet they wrote a match based on the kernel name and just reset everything back to 0 when it’s not something already known.
2 Likes
Just installed this on top of potato’s image that I’ve been daily driving and it seems to be working fine. With stock wpa_supplicant btw.
Thanks for patching the timing issue. It wasn’t so much an issue with the binary package but the one built from the pkgbuild was giving me trouble.
It’s alive, it’s alive! Your kernel is alive!
You may confirm that your kernel works with the CM4 as well. I’d still be on the lookout for strange behavior. But for now, I’m happy to report that the display (built-in and HDMI), the I/O and networking are functional. I can test for the LTE module as well, but I bet that it would work too is a no-brainer.
I guess we can definitely say I’m running @Rex’s kernel now. Thank you for your diligence in supporting the ClockworkPi 3.14 boards. And thanks, @PeterCxy for making the effort to bring the kernel to Arch ARM.
UPDATE: Kernel broke audio. Patch Additional package definitely brought it back.
There’s a systemd service he put in there that fixes the audio.
1 Like
There’s now a workaroud in my package that fixes it in device tree for CM5, without needing a userspace service. Unfortunately CM4 and CM3 handle audio differently (CM5 has the RP1 chip) and since I don’t have a device to test, I don’t know if the same can be done on CM4 and CM3.
My gut feeling is on CM4 and CM3 we either need to fix the BCM2835 sound driver (on CM5, RP1 audio ends up routed through a simple-audio-card driver, which can do this kind of switching natively), or we need to bring back @PotatoMania’s simple-amplifier-switch.
2 Likes
You mean, version 6.12.22.r1316782.202504250215.aff0059-1? I can disable your systemd service for a while to test.