Hoping someone here can point me in the right direction. I’m trying to get two Arducam IMX477 cameras working on an NVIDIA Orin NX 16GB with JetPack 6.2. The carrier board is a Connect-Tech Hadron (third-party, not the NVIDIA dev kit). I’ve created a custom device tree based on Arducam’s overlays to integrate both cameras. The system boots fine, but both camera sensors fail to probe. Here’s the relevant kernel log:
[ 11.453398] arducam-csi2 9-000c: i2c bus regbase unavailable
[ 11.453405] arducam-csi2 9-000c: Could not initialize sensor properties.
[ 11.453407] arducam-csi2 9-000c: Failed to initialize tegra common for arducam.
[ 11.453411] arducam-csi2: probe of 9-000c failed with error -75
[ 11.453438] arducam-csi2 10-000c: i2c bus regbase unavailable
[ 11.453441] arducam-csi2 10-000c: Could not initialize sensor properties.
[ 11.453442] arducam-csi2 10-000c: Failed to initialize tegra common for arducam.
Both sensors at I2C addresses 9-000c and 10-000c show the same failure. For reference, the running device tree is here: tegra234-orin-nx-cti-NGX024-ARDU-IMX477-2CAM.dts
I’ve verified the I2C mux is working correctly on both CSI ports — sensors are visible on the bus before the driver tries to probe. Has anyone seen this “i2c bus regbase unavailable” error before on a non-NVIDIA carrier?
That’s a tricky one. The error code -75 maps to EOVERFLOW, but the real smoking gun here is “i2c bus regbase unavailable” — that means the Tegra I2C controller’s register base address can’t be resolved during the driver’s common initialization phase. The probe is blowing up inside the Tegra common init (Failed to initialize tegra common for arducam), which runs before the driver even gets to talk to the sensor seriously. This usually points to a device-tree mismatch: the Arducam overlay expects the I2C bus nodes to expose their register base in a way that matches the NVIDIA reference carrier board layout. The Connect-Tech Hadron board likely maps the CSI I2C resources differently in its base device tree. Unfortunately, since this is a third-party carrier board, we can’t provide specific guidance on how Connect-Tech structured their I2C bus nodes — you’d need to diff your Hadron base DTS against the NVIDIA reference to spot where the reg / reg-names properties diverge for the CSI I2C controllers.
Thanks for the analysis. I’ve spent some time comparing the Hadron base DTS with the NVIDIA Orin NX reference, and I can see differences in how the I2C bus resources are laid out. In the meantime, I decided to try different sensor modules — swapped the IMX477s for Arducam AR0234 and AR1820HS cameras and updated the device tree accordingly. Now I’m getting a slightly different failure. The I2C address has changed (now at 9-0037 instead of 9-000c), but it’s still a probe failure:
arducam-csi2 9-0037: probe failed.
I’ve double-checked that I2C communication with the sensor at 0x37 is working — I can talk to it from userspace just fine. The Enable signal from the device tree also looks correct — the sensor powers up and appears on the bus. So this isn’t a basic wiring or I2C addressing problem. Something deeper in the driver’s probe path is still failing and I’m running out of ideas.
Even though the I2C address changed from 0x0c to 0x37 — which confirms your device-tree modifications are taking effect — the underlying problem hasn’t changed. The fact that userspace I2C scans work and the Enable GPIO is toggling correctly tells you the physical layer is fine. But the probe failed without the full diagnostic trace you saw before (no “regbase unavailable” visible this time) might just mean the driver is failing at a different point in the same Tegra common init path, or the logging level changed. The core issue remains: the Arducam driver’s Tegra common initialization code can’t properly map the I2C controller’s register space when running on the Hadron base device tree. The fundamental gap is still how the Hadron’s CSI I2C bus nodes expose (or fail to expose) their reg / reg-names properties compared to what the arducam-csi2 driver expects. Until that’s resolved at the device-tree integration level, you’ll likely see probe failures regardless of which sensor model you attach.
Look, I’m doing kernel and device-tree integration professionally — I don’t need hand-holding through the basics. What I need is a specific hint about what exactly the arducam-csi2 driver is looking for during Tegra common init that it’s not finding. Is it expecting a particular reg-names entry from the I2C parent node? An iommus property? Something in the tegra-csi or tegra-vi plumbing? The sensors are on the bus, the enable works, the mux routes correctly — the hardware side is fine. I just need to know what the driver’s init is actually checking for so I can trace it back to the Hadron DTS. If this is going to remain a black box I’ll have to move to a different camera vendor.
I understand the frustration, and I appreciate that you’re working at the integration level. Let me be as direct as I can: the arducam-csi2 driver’s Tegra common initialization (tegra_common_init) calls into the Tegra camera platform framework to look up the I2C adapter’s underlying controller register base. On the NVIDIA reference carrier, the I2C bus nodes under the CSI block have well-defined reg properties that the framework uses to resolve the physical base address. On third-party carrier boards like the Hadron, those bus nodes may be structured differently — possibly with different address cells, different reg layouts, or the CSI I2C instance may be parented under a different node in a way that breaks the lookup. The driver isn’t doing anything exotic here; it’s walking the device tree to find the I2C controller’s base address through standard kernel OF helpers. The gap is specifically in how the Hadron base DTS represents the CSI-attached I2C bus controllers versus what the NVIDIA reference layout provides. I wish I could give you a single property to check, but it’s a structural mismatch that really requires diffing the two base trees side by side at the i2c@ nodes under the CSI/VI hierarchy. That said, I’ve sent you a private message with the specific kernel function trace and device-tree node path the driver traverses during init — hopefully that narrows down the diff for you.