Having a weird issue with a B0492N camera module on a Jetson Orin Nano. The sensor ID keeps coming up as 0x0A56, but it should be 0x0354. The same exact camera works perfectly fine on my Raspberry Pi 5 — correct ID and everything. Anyone seen this before? Running JetPack 6.2.1 with the 4-lane driver. Feels like a driver problem but I’m not sure where to start digging.
That’s an interesting mismatch. Before we go too deep — can you share a bit more about your setup? Specifically which JetPack version you’re on and how you’ve got the camera wired up on the Orin Nano? Also, just to confirm, you’re using the same physical camera module on both boards, right? Not two different B0492N units?
Yeah, same physical module — I’ve been swapping it between the Pi 5 and the Jetson to rule out a bad camera. JetPack is 6.2.1, and I’m using the 4-lane driver config. On the Pi 5 it enumerates as 0x0354 every time, no issues. On the Jetson Orin Nano I get 0x0A56 consistently across reboots. The camera powers on and the I2C bus sees something, just the wrong ID.
That helps narrow things down. Since the same module works on the Pi 5, the camera hardware itself is probably fine. Next step — could you post a couple photos of your Jetson Orin Nano board, both the front and back? I’d like to see the physical setup, especially the camera connector area and which pins the ribbon cable is landing on. Sometimes a misalignment or a board revision quirk can cause odd I2C behavior.
Sure, here are the front and back of the board with the camera connected. The ribbon cable is seated properly in the CSI connector and the contacts look clean. Let me know if you need a closer shot of any specific area. I double-checked pin 1 orientation and it matches the silkscreen.
Thanks for those. Everything looks physically correct from what I can see — no obvious seating issues or pin mismatches.
Given that the same B0492N module reports 0x0354 on the Raspberry Pi 5 but 0x0A56 on the Jetson Orin Nano (JetPack 6.2.1, 4-lane driver), this points pretty strongly toward a platform-specific driver or device tree configuration problem rather than a hardware defect. The 0x0A56 value isn’t random — it corresponds to a different sensor ID entirely, which suggests the Jetson-side driver probe is either misreading the I2C response or the device tree is mapping to the wrong sensor driver. I’d start by diffing the device tree entries between the working Pi setup and what JetPack 6.2.1 is loading for the 4-lane CSI interface. The sensor driver binding might be pulling in an incompatible overlay or the I2C bus timing could be off just enough to corrupt the ID read on this platform.