Can't get arducam imx477 to work

Graphics / Linux Linux
,
1

I am trying to get an Arducam imx477 camera to work with my new Jetson Orin Nano dev kit. I have it configured with jetson-io.py to imx477. I have not installed any Arducam drivers. I am using the Arducam B0466R01 (see Amazon.com: Arducam 12.3MP Raspberry Pi HQ Camera, 477M Pi Camera Module with 158°(D) M12 Wide Angle Lens, Compatible with Pi5/4B/3/3B+/Zero 2W : Electronics ). I have tried connecting to both cam0 and cam1, and get the same results (i.e. /dev/video0 is created, but I can actually capture any images).

I imagine it’s possible I need to install Arducam software/drivers, but I wanted to ask first, as the 477 is listed as natively supported, and it’s not obvious where the appropriate Arducam driver is (e.g. they have old listings on github and refer to jetson nano).

Can you please point me to installation instructions or what might be my issue?

Is there another inexpensive camera that should work out-of-the-box? I assumed (perhaps wrongly) that the RPi HQ camera was such an animal.

Thanks,
Hy

Details:

I do see /dev/video0. I get errors after I attempt to get images. For example:

cat go.image
gst-launch-1.0 nvarguscamerasrc num-buffers=1 sensor-id=0 !
‘video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1’ !
nvvidconv ! ‘video/x-raw, format=I420’ !
jpegenc !
filesink location=test_image_csi.jpg -e

bash go.image
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Pipeline is PREROLLED …
Setting pipeline to PLAYING …
New clock: GstSystemClock
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected…
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3840 x 2160 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 1920 x 1080 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 22.250000; Exposure Range min 13000, max 683709000;
GST_ARGUS: Running with following settings:
Camera index = 0
Camera mode = 1
Output Stream W = 1920 H = 1080
seconds to Run = 0
Frame Rate = 59.999999
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadExecute:734 NvBufSurfaceFromFd Failed.
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadFunction:245 (propagating)
Redistribute latency…
Got EOS from element “pipeline0”.
EOS received - stopping pipeline…
Execution ended after 0:00:04.004185463
Setting pipeline to NULL …
GST_ARGUS: Cleaning up
GST_ARGUS: Done Success
Freeing pipeline …

2

Hi @murveit,

I hope you are doing well!

Even though you can see the /dev/video0 created, that does not mean the driver module is loaded and ready for use.

Can you please run the following commands to troubleshoot:

  • Check if camera node is bound:
dmesg | grep imx
  • Check if module nv_imx477.ko is loaded with:
lsmod | grep imx

If it is not loaded you can try loading with: modprobe nv_imx477

  • List devices with v4l2. You should see your camera bound to /dev/video
v4l2-ctl --list-devices

You can also try capturing with v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=100

Let me know if this helps!

Best regards,
Nico
Embedded Software Engineer at ProventusNova

3

Nico, Thanks so much for responding!

Here are the dmesg and lsmod responses.

sudo dmesg | grep imx
[sudo] password for hy:
[ 10.375197] imx477 9-001a: tegracam sensor driver:imx477_v2.0.6
[ 10.676822] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx477 9-001a bound
[ 10.708677] imx477 10-001a: tegracam sensor driver:imx477_v2.0.6
[ 11.009629] imx477 10-001a: imx477_board_setup: error during i2c read probe (-121)
[ 11.009666] imx477 10-001a: board setup failed
[ 11.009740] imx477: probe of 10-001a failed with error -121

lsmod | grep imx
nv_imx477 24576 0
tegra_camera 217088 4 nvhost_isp5,nvhost_nvcsi_t194,nv_imx477,nvhost_vi5

As you can see, dmesg reports an error, and I’m unsure how to interpret the lsmod output. Please let me know what you suggest.

Should this be working without an Arducam driver? I recently found pointers to arducam drivers in https://docs.arducam.com/Nvidia-Jetson-Camera/Native-Camera/Quick-Start-Guide/#12mp-imx477-camera but when trying that, I found that their latest driver won’t install because it depends on Kernel version 5.15.148-tegra-36.4.4-20250616085344 and of course I have a more recent 5.15.148-tegra-36.4.7-20250918154033.

Further, I have a worry that even if we get this working, my orin nano will auto-upgrade to some new kernel version at some point and break these drivers (which is why I was hoping for something that was natively supported).

Anyway, please let me know what you recommend.

Hy

4

Sorry, forgot to add the responses to your suggestions:

“modprob nv_imx477” didn’t change anything.

> v4l2-ctl --list-devices
NVIDIA Tegra Video Input Device (platform:tegra-camrtc-ca):
/dev/media0

vi-output, imx477 9-001a (platform:tegra-capture-vi:2):
/dev/video0

Then I tried

v4l2-ctl -d /dev/video0 –stream-mmap –stream-count=100

and nothing happened. I control-c’d out of there, and then ran ‘sudo dmesg | tail’ and got a lot of lines like this:

[ 7988.548318] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 7991.106408] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 7991.106434] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 7991.108042] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 7993.666606] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 7993.666630] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 7993.667879] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 7996.226458] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms

5

Hi @murveit,

Thanks for sharing the information!

  1. From the dmesg logs we do see the camera being bound. For comparison check my IMX464 bound to my Jetson Orin NX:
imx464 9-001a: tegracam sensor driver:imx464_v2.0.6
tegra-camrtc-capture-vi tegra-capture-vi: subdev imx464 9-001a bound
imx464 9-001a: Detected imx464 sensor

In your case, there is no imx464 9-001a: Detected imx464 sensorThis may suggest wrong communication with the sensor.

  1. Can you please share the output for the following command just for confirmation:
i2cdetect -y -r 9

This will tell us if that address is being used by the kernel, regardless it does not mean camera is ready for use.

  1. Also I did a little research and found this regarding the ARDUCAM camera(Taken from here: 12MP IMX477 ARDUCAM):
    ARDUCAM
    ARDUCAM923×430 41.8 KB

Check that the device tree overlay you loaded has support for 4-lane. Feel free to share the device tree file.

Regarding your questions:

  • The error you are seeing for imx477 at 10-001ais expected since you only have one camera connected. It seems you loaded a DTBO that gives support for two cameras. This should not affect the behavior for camera at 9-001a.
  • lsmod output confirms driver modules is loaded.
  • modprobe loads the module in case it was not loaded.

Let me know if this helps!

Best regards,
Nico
Embedded Software Engineer at ProventusNova

6

Thanks again Nico. Here are the answers to your questions:

i2cdetect -y -r 9
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – –
10: – – – – – – – – – – UU – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –

I’m not sure how to get the source of the device tree. If it is useful I’ve uploaded the binary file in /boot/dtb here: https://drive.google.com/file/d/15pd5rfh5E3l-yx11Q9xpNiNK3AQpmB0x/view?usp=sharing

Also, I ran

dtc -I dtb -O dts -o output.dts kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb

on that file and got a lot of output I didn’t know how to interpret, so I guess I’m leaning on you for that but let me know if you want the output.

If you know of another imx477 or similar quality M12 mount camera that would work, I’d be happy to try that too, or happy to answer questions to continue debugging this.

Thanks again,
Hy

7

Hi @murveit,

Sorry for the late reply!

Quick question, which JetPack version are you using?

Thanks for sharing the DTB. However, this DTB is the base DTB. Not the DTBO file for IMX477.

I suspect that you are using the overlay that supports IMX477 with 2-lanes. You should try using file: tegra234-p3767-camera-p3768-imx477-dual-4lane.dtbo located in /boot directory.

Can you try the following to test:

  1. Modify your /boot/extlinux/extlinux.conf to include your base DTB as well as the overlay you want to use. Add these lines to the file:
FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb
OVERLAYS /boot/tegra234-p3767-camera-p3768-imx477-dual-4lane.dtbo
  1. Reboot the board and test connecting the camera to both cam0 and cam1 and check if it works.

Please let me know if this helps!

Best regards,
Nico
Embedded Software Engineer at ProventusNova

8

Nico,

Thanks for your help. I’ve learned a few things.

  1. My camera was broken. I ordered another one (same camera) and this time I could get things to (sort of) work. Note–it wasn’t the flat cable, I tried that, it was the camera hardware itself. I am plugged in to cam0 and running the below os:

> cat /etc/nv_tegra_release

R36 (release), REVISION: 4.7, GCID: 42132812, BOARD: generic, EABI: aarch64, DATE: Thu Sep 18 22:54:44 UTC 2025

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

  1. I installed some software from Arducam, and then setup extlinux.conf as follows

LABEL JetsonIO477
MENU LABEL Custom Header Config:
LINUX /boot/arducam/Image
FDT /boot/arducam/dts/dtb/tegra234-p3768-0000+p3767-0005-nv-super.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=f54a2ab5-3e38-46f4-86f1-0b9330149176 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:off console=tty0
OVERLAYS /boot/arducam/dts/tegra234-p3767-camera-p3768-imx477-dual.dtbo

With this, I was able to access the camera without the dma error I was getting.

Unfortunately it seems like their driver is buggy, e.g. when I put it into 1920x1080, I seem to get the upper left quarter of the image. I can’t seem to get a native 1920x1080 image, even when I try a pipeline with nvarguscamerasrc sensor-id=0 sensor-mode=1 (see #3 below).

  1. So, I thought I’d go back to the NVidia drivers as we were trying, and that worked the same. To do that I ran the /opt/nvidia/jetsonio/jetson-io.py script and wound up with this:

LABEL JetsonIO
MENU LABEL Custom Header Config:
LINUX /boot/Image
FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=f54a2ab5-3e38-46f4-86f1-0b9330149176 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:off console=tty0
OVERLAYS /boot/tegra234-p3767-camera-p3768-imx477-dual.dtbo

Note that -4lane did not work, but -A or -dual were the same.

Do you know if there a way to get the full image from the hardware at 1920x1080?

  1. So perhaps Arducam just implemented the 1920x1080 mode by just returning the upper left part of the image, instead of binning pixels as they should have done. If so, then that’s disappointing.

  2. I ran an Arducam imx707 using similar Arducam drivers as above, and it doesn’t seem to have the “upper-left” issue.

That’s all for now, thanks for your help.

Hy

9

Hi @murveit,

Thanks for getting back to me.

The “upper-left” image output you’re seeing could be happening due to one of the following:

  1. Misconfiguration for mode 1 in the register table for the IMX477 driver.
  2. Cropping or scaling applied by the camera capture subsystem (nvarguscamerasrc) after capture.

My suggestion would be:

  1. Check the register table for the IMX477 driver to make sure the mode you’re using (1920×1080) is configured correctly according to the Sony IMX477 datasheet.
  2. Try capturing directly with v4l2-ctl to isolate whether the issue comes from the driver or from the Argus camera subsystem.

For suggestion #2, you can try the following:

  1. Query supported modes:
    v4l2-ctl --device=/dev/video0 --list-formats-ext

  2. Capture a test frame:
    v4l2-ctl --device=/dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=<PIXEL-FORMAT> --stream-mmap --stream-count=1 --stream-to=test.raw
    Note: PIXEL-FORMAT is extracted from step 1.

  3. View the image and see if it looks like the “upper-left” image you captured using nvarguscamerasrc.

If the image is still cropped, then the issue is most likely in the register table configuration of the driver.
If it looks fine under V4L2 but cropped under nvarguscamerasrc, then it’s more likely related to the Argus camera pipeline.

If you need any help for checking the register table or for testing, feel free to reach out for further support.

Best regards,
Nico
Embedded Software Engineer at ProventusNova

10

Nico, thanks for the help.

Here are the supported modes:
ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 Nov 4 16:04 /dev/video0
v4l2-ctl --device=/dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'RG10' (10-bit Bayer RGRG/GBGB)
	Size: Discrete 4032x3040
		Interval: Discrete 0.048s (21.000 fps)
	Size: Discrete 3840x2160
		Interval: Discrete 0.033s (30.000 fps)
	Size: Discrete 1920x1080
		Interval: Discrete 0.017s (60.000 fps)

Then when I try and capture a frame using v4l2-ctl

v4l2-ctl --device=/dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap --stream-count=1 --stream-to=test.raw

I get a file that’s too large:

ls -l test2.raw
-rw-rw-r-- 1 hy hy 24514560 Nov 4 17:05 test2.raw

In fact the frame is 4032 x 3040 x 2 bytes, so clearly it captured in mode 0. I think that is the issue. I am getting the upper left because it is not sending data in 1920x1080.

11

Hi @murveit,

Thanks for running those tests.

From your output, we can confirm that the “upper-left” cropping is being done by nvarguscamerasrc after receiving a full 4032×3040 frame. This means the IMX477 sensor is still outputting the full resolution, so the issue is within the IMX477 driver rather than the Argus layer.

To debug further, you can add dev_info()line inside the imx477_set_mode() function of the driver to verify which mode index is actually being set. This logs are printed into dmesg. For example, for checking mode index:

dev_info(tc_dev->dev, "IMX477: mode_index = %u\n", mode_index);

When requesting resolution 1920x1080, the mode_index should be 1 which corresponds to IMX477_MODE_1920x1080_60FPS on file imx477_mode_tbls.h.

Additionally, I checked the DTB file. I noticed this is set: use_sensor_mode_id = "true";.

From NVIDIA documentation:
use_sensor_mode_id

This is the reason why the --set-fmt-video command did not change the mode. The IMX477 driver does not implement a control for setting the mode via TEGRA_CAMERA_CID_SENSOR_MODE_ID. The driver then defaults into mode0 for capturing.

You can try changing this property in the device tree:

use_sensor_mode_id = "false";

and see if this fixes the issue. If the “upper-left” image still occurs, then the issue lies in the mode register table configuration.

Best regards,
Nico
Embedded Software Engineer at ProventusNova

12

Nico, I really appreciate your help on this. I wanted to let you know that I contacted Arducam support, and they were great. The really supported their product. We did a couple half-hour live video-conferenced debugging sessions where I demonstrated the problem using Google Meet, and they figured out that there was an issue with the .dtbo file (as you suspected, though I don’t believe it was the use_sensor_mode_id setting). They have updated their drivers online and I re-installed their drivers with the below, and now the 1920x1080 resolution is working!

wget https://github.com/ArduCAM/MIPI_Camera/releases/download/v0.0.3/install_full.sh
bash install_full.sh -m imx477

13

Hi @murveit,

Glad to hear you were able to capture with 1920x1080 resolution!

Feel free to reach out if you need any further assistance with your project – I’ll be happy to help.

Best regards,
Nico
Embedded Software Engineeer at ProventusNova