So now I’m wondering — should I try rolling back my kernel to 5.15.148-tegra-36.4.4 to use that existing package? Or is there a build for 36.4.7 in the pipeline? Happy to be a beta tester if there’s something experimental I can try. Just want my 12MP frames.
Thanks for the detailed report — that’s actually really helpful.
The root cause here is pretty straightforward: our MIPI camera driver .deb packages are tied to a specific kernel build. They include precompiled kernel modules that have to match the exact kernel version string. The install_full.sh script looks up your running kernel and tries to fetch the corresponding package — and when there isn’t one, you get that error.
At the time you ran the script, we simply hadn’t built a package for 5.15.148-tegra-36.4.7 yet. The available packages only went up to 36.4.4. That’s why the script couldn’t find a match.
Rolling back to 36.4.4 is one option, but I wouldn’t recommend it — there are usually other fixes and updates in the newer L4T point release that you’d lose.
Let me check with our build team and see if we can spin up a 36.4.7 package. I’ll get back to you here once I have something.
Good news — we’ve built a new driver package targeting kernel 5.15.148-tegra-36.4.7.
I’ve sent you the download link for the .deb via private message (the file is: arducam-nvidia-l4t-kernel-t234-nx-5.15.148-tegra-36.4.7-20251023170635_arm64_imx477.deb).
So I’ve got the sensor working at full res, which is great, but I’m trying to squeeze more throughput out of the pipeline. The standard RG10 V4L2 format is unpacked — each 10-bit pixel takes up 2 bytes (16 bits), so there’s a fair bit of wasted bandwidth.
I’d like to propose a packed 10-bit raw format — let’s call it pRAA — where 4 pixels are stored in 5 bytes. That’s 37.5% more payload-efficient than the unpacked RG10 representation.
So for every group of 4 pixels you’re transmitting 5 bytes instead of 8. Over a 4032×3040 frame that adds up fast — faster sensor readout, less memory pressure, higher effective frame rate at the same MIPI lane speed.
My question: is there any chance Arducam would be interested in developing a V4L2 driver that exposes this pRAA format natively? If not, I’m planning to write it myself against your existing driver code, but I figured I’d ask before diving in.
Regarding the pRAA packed format — I can see the appeal for your use case. Reducing payload by 37.5% is nothing to sneeze at when you’re pushing 12MP frames around.
That said, implementing a custom V4L2 pixel format like this is outside our current development roadmap. Our focus right now is on core driver functionality and keeping up with L4T kernel releases for the broader user base — adding a bespoke pixel format doesn’t really fit into that at this stage.
The good news is that our drivers are fully open-source specifically for this reason. You’re absolutely welcome (and encouraged) to fork the code and implement pRAA yourself. The existing Bayer capture pipeline should give you a solid starting point — you’d essentially be adding a new fourcc, registering it in the format enumeration, and writing the packing/unpacking logic in the data path.
If you run into specific questions while hacking on it, feel free to post them here and the community (or we) can weigh in. But for a full driver implementation, you’re in the best position to tailor it to your exact throughput requirements. Good luck!