Hi, I’m trying to get an Arducam camera working on a Jetson Nano (production model) that’s mounted in a QUARK carrier board. I’m on JetPack 4.6.2 and I ran the install script with:
./install_full.sh -m arducam
But it just bails out and prints:
Cannot find the corresponding deb package, please send the following information to [email protected]
Kernel version: 4.9.253-tegra-32.7.2-20220630-CTI-NANO-V002
Jetson type: UNKNOWN
It looks like the script doesn’t recognize my board and can’t match a package to download. Is there any way to get the Arducam working in this hardware setup? I can change the JetPack / L4T version if that helps.
And it’s a Jetson Nano production module on a QUARK carrier board, not the Developer Kit. The kernel is a custom one from the board vendor, that’s where the CTI-NANO part comes from. The install script reports Jetson type: UNKNOWN and then refuses to continue.
OK, that lines up with what I expected. The install script detects the board type by reading the board/platform identity from the Tegra tables. Because your kernel is a custom carrier-board kernel (-CTI-NANO-V002), that board ID doesn’t match anything the script knows about, so it falls through to Jetson type: UNKNOWN and can’t map a deb package to it.
So it’s not the arguments (-m arducam is correct) — the script simply can’t identify which official platform you’re on, so it has no package to download.
To be upfront: we currently only support official development boards. Third-party carrier boards like the QUARK are not supported at this time, which is exactly why the detection fails.
So from the docs it reads like JetPack 4.6.2 on Nano is supported, which is my exact software setup. Would flashing a different JetPack / L4T version change anything here, or is the carrier board the actual blocker regardless of which JetPack I run?
Good question, and I should have been clearer. That table means the official Jetson Nano Developer Kit running those JetPack versions — not a Nano module on a third-party carrier with a vendor kernel. Changing JetPack/L4T won’t help by itself, because whatever you flash still has to be the carrier vendor’s port with their own kernel (-CTI-NANO-...), and the board ID will still not match. The mismatch is at the board/platform detection level, not the software version level.
To be precise about where it breaks: the installer builds the expected platform string from the detected Jetson type, then looks for a matching deb. With UNKNOWN there is no match, so it stops with that message.
I see. Honestly a bit disappointed — I bought a small number of these cameras and Jetsons for a project and now I can’t use them together. Can you tell me how I could move forward? Is it possible to compile the driver and kernel myself? How would I even access the cameras without the prebuilt deb?
I understand, and sorry for the hassle. Some concrete paths you can look at:
The driver source is available (the Jetvariety driver sources and the device tree overlays are in our public repos). In principle you can build the kernel module yourself against your CTI kernel headers and load it manually, so the deb-based installer path isn’t strictly required. That’s the route most people take on unsupported carriers.
The catch is the device tree / overlays and the I2C + reset/power GPIO mapping come from the carrier board, not from us. You’d need the correct pin/GPIO definitions from your carrier’s kernel tree for the camera connector, otherwise the sensor won’t probe even if the module loads.
Build against the exact kernel you’re running (4.9.253-tegra-32.7.2-20220630-CTI-NANO-V002) — mismatched headers will usually give you insmod errors like invalid module format.
I have sent you a note via private message with the relevant repo pointers to start from.
Thanks, I’ll take a look at the sources. A couple of follow-ups:
Given the docs clearly list Nano + JetPack 4.6.2 as supported, could you update the documentation to make clear it’s only the official Developer Kit and not Nano in general on a carrier board? The current table makes it look like any Nano on 4.6.2 will work.
For self-compiling: what’s the minimum I need? Just the driver module + an overlay with the right I2C/GPIO pins for my carrier, or is there more (V4L2 registration, clock setup, etc.)? And if I get the module built but the sensor doesn’t probe, is the usual culprit the device tree?
Fair point on the docs — I’ll pass the feedback along, the table wording does make it look broader than it is.
For the minimum: a working setup is (a) the camera driver kernel module, (b) a device tree overlay that describes the sensor node — I2C address and bus, reset/power GPIOs, clocks — and (c) the media/V4L2 plumbing that the module registers. On the Nano there’s no single framework doing all of it for you like on newer platforms, so the overlay is where most of the work lands.
If the module loads but the sensor doesn’t probe, in my experience it’s the device tree almost every time — wrong I2C bus, wrong address, or the reset/power GPIO not matching the carrier’s pinout. dmesg | grep -i -E 'i2c|v4l|ov' right after insmod usually shows whether the sensor is even being talked to.
OK, that gives me a direction at least. So to summarize my current situation: the installer fails on my setup (Jetson type: UNKNOWN, no matching deb), and the reason is the QUARK carrier + CTI kernel, not my JetPack version. To make progress I’d have to build the driver myself against my kernel and write/adjust the device tree overlay for the carrier’s camera connector, with no guarantee it’ll probe. Is that a fair read, and is there anything on the official-support side you can offer for a board like this?
That’s a fair summary, yes. To restate the current conclusion clearly:
The failure is a platform-detection issue: ./install_full.sh -m arducam reports Jetson type: UNKNOWN because the Nano is on a third-party QUARK carrier running a vendor CTI kernel (4.9.253-tegra-32.7.2-20220630-CTI-NANO-V002), so no matching deb package exists.
Changing JetPack / L4T won’t resolve it — the board ID still won’t match an official platform.
Our official support scope is limited to official development boards; third-party carriers like the QUARK are not supported at this time.
On the practical side, self-compiling the driver against your exact kernel plus a carrier-specific overlay with the correct I2C/GPIO definitions is the realistic path, and it’s not something we can officially support end-to-end off an unsupported carrier. If you want to explore a custom/third-party board arrangement, reach out to our sales contact and describe the board and camera combo. I’ve also passed your documentation note along.