Stuart Watt

That's very useful. I'm nowhere near as practiced with this, so it'll take some time to digest and plan a way forward. It does fit with what seemed to be the case, though: it's device-level issues. I'll start poking around in the specific device differences and see what shows. The great hint you've found is that this is likely affecting all CSI cameras, not just the IMX708. That's most useful. I'm not at all worried about networkmanager, because the only tweak I made in the custom build was to use systemd-networkd, which (for me, anyway) is more straightforward for embedded/minimal/CLI usage. What I haven't yet done, and probably should, is switch to debugging this in something more vanilla, like a Pi 4. At least then I can compile libcamera and friends directly on the device. The Zero 2W should be the same -- he says, hopefully.

Checking in on Armbian, the installed raspi-firmware is 1.20250915-1~bookworm: $ apt list -a raspi-firmware raspi-firmware/trixie,trixie,now 1:1.20250915-1~bookworm all [installed] raspi-firmware/trixie,trixie 1:1.20250430-4~bookworm all raspi-firmware/trixie,trixie 1:1.20250430-3 all raspi-firmware/trixie,trixie 1:1.20250430-1 all raspi-firmware/stable 1.20240424+ds-6 all I do note there were upstream issues in this: https://github.com/raspberrypi/linux/issues/6753, but that does not 100% match, as we do not get the logs that imply that cause. And the hashes: $ shasum /boot/firmware/bootcode.bin fa4cd59207022a61a2cc645b6dfdf1d481bba07b /boot/firmware/bootcode.bin $ shasum /boot/firmware/start.elf bbd038d812d408c209005c9f8c2801ef1affc501 /boot/firmware/start.elf $ shasum /boot/firmware/fixup.dat 75e5543a3834b3fec1c9f598e2e9e9ae13e5b334 /boot/firmware/fixup.dat Latest Raspbian is using newer firmware: $ apt list -a raspi-firmware raspi-firmware/stable,stable,now 1:1.20260521-3 all [installed] raspi-firmware/stable,stable 1.20240424+ds-6 all And the Raspbian files are all different. Maybe I should try the Ubuntu Armbian and/or a minimal sid build and see how they play out.

@eselarm Good question, not yet sure what to do. First off, new stock Raspbian worked (for me) out of the box, at least for both V4L2 and libcamera. I'd have yelled at them if they didn't, as that's Raspberry hardware and software up and down the stack, so they have no excuses. I mostly want to use libcamera, but for me, libcamera and V4L2 were in total agreement on both Raspbian and Armbian. On Raspbian, both detected the IMX708, and on Armbian, neither did -- or, rather, /dev/video0 never got set up, despite the module loading fine and dmesg logging it in Armbian. To add, also, with the zram swap system in place, I can't actually compile libcamera (or the apps) on the Armbian Zero 2W, due to lack of memory (!). I ran out the will to work around that at the time. So I built the Debian libcamera packages (all of them) on a Pi 5 and copied them over. Only the trixie-backports modules actually ran through okay, but they did. That seemed to work fine -- and as I said, neither V4L2 nor libcamera set up an accessible camera device -- and they agree -- so I think the issue is kernel-side, not in userspace. I suspect it's in the device tree somewhere. My guess is if we get V4L2 happy, then libcamera will be. The main advantage of V4L2 is that the device list is a clear tell for camera detection on boot, one that doesn't need a much installation work. Also, I didn't yet get to the rpicam apps framework. I will, because I actually use it for the cow I want to deploy. But that's an extra layer beyond libcamera itself. the standard libcamera-tools package contains the cam binary which is enough to detect devices. If I can get V4L2 happy, or if cam can capture an image, then I know the kernel side is fine, and it's all my problem. I'll be happy to take it from that point. Your point about raspi-firmware is very helpful. That would fit some of what I've seen here. I'll dig in and check on that. I would not assume it's using a Raspberry vendor kernel. I didn't try that. And Broadcom shenanigans apart, I hope I don't need to. What's weird is the IMX708 kernel module is definitely loaded and active and detecting the hardware on the Armbian Debian trixie. Most of the Broadcom stuff is there -- all the hardware encoders show up. Just not the camera itself. Many thanks -- I'll dig in today and see if I can progress.

I'm struggling to get the Pi Camera 3/IMX708 detected by the Zero 2W. It's an IMX708 sensor, and that is correctly showing in dmesg, but the V4L2 devices (/dev/video0, /dev/video1) for the camera are not set up. All the normal encoder devices are fine. I'm using a custom build but it's essentially minimal (and no desktop) current with trixie and no extensions, following the standard command for building an image. The dmesg log reads as follows: [ 10.719672] imx708 10-001a: camera module ID 0x0302 [ 10.719876] imx708 10-001a: ctrl(id:0x9f0902,val:0x232aaf80) is not handled [ 10.722275] imx708 10-001a: ctrl(id:0x9e0902,val:0x2b20) is not handled But I don't think this is problematic, as stock Raspbian shows precisely the same log messages, and it does correctly set up the devices. I've added the overlay and turned off (or tried to) the camera auto detection, but the imx708 messages were being logged even before I added the overlay, so I am not sure it was needed. In any event, nothing changed. Any thoughts on ways to get this up and running?

I am trying to get the ARM performance assessment setup working (I'm trying to get Mali profiling for OpenCL code) on the Rock 5B+, and I've hit a blocker. The main component to this is some kernel configuration (CONFIG_ARM_SPE_PMU) and a loadable module. Oddly, those work fine in a custom kernel build. What I am hitting appears to be some missing interrupt setup that renders all those components inert. (It has to be a custom build to get CONFIG_ARM_SPE_PMU set. The issue is that even with the kernel configured and the module loaded, the SPE component remains inactive. ARM has its own system report tool which analyzes a setup, and that tool is reporting an issue: And indeed, nothing seems to show in cat /proc/interrupts. The man page for the module suggests this is the issue: It says: KPTI is definitely disabled and the SPE PMU loads (it's in lsmod) but it still doesn’t show in /sys/bus/event_source/devices/. Nothing relevant seemed to show in dmesg either. Frankly, I have no idea where to look for the SPE interrupt, or how to set it up. If anybody has any pointers or suggestions, I'd be extremely grateful.

So I'm fairly new to Armbian (although I have already managed to successfully create a custom build with most of what I need). Sadly, I've very much hit a blocker. I really need to use linux-tools/perf on an RK3588 board with a vendor kernel (I'm using the Mali OpenCL, and the ARM packages are mostly locked) and I need to do some performance tuning. I cannot figure out how to get these tools deployed. 1. There are no linux-tools packages build -- which is fair enough, I'm probably in a minority. Some parts of the tools directories are culled during a cleaning process for the headers, I can see that 2. I am happy to copy over the kernel source and build on the device, but this is a patched vendor kernel. Can I just rsync across `cache/sources/linux-kernel-worktree`? Is that the patched kernel source tree? 3. There are some old allusions in the forums to using armbian-config to get sources -- I'm guessing that's long deprecated 4. Would it be appropriate at some point to create a .deb for the actual kernel sources, just in case -- or even, ideally, the linux-tools packages themselves? I am very happy to invest effort into helping make this happen, but I am starting from cold into this fairly complex build infrastructure, so any help or pointers I'd be extremely grateful.