Meet NvBufSurfaceFromFd Failed when driving imx577 on Orin Nano

I am trying to drive imx577 on my Orin nano, my device tree source code is:
imx577.dtsi (21.9 KB)

The device can be detected by i2c:

But when I use nvgstcapture(nvgstcapture --sensor-id=0) to catch video stream, I meet a error like this:

Can not figure out what is the problem,need supports

hello EmondCai,

let’s narrow down the issue.
please check developer guide, Approaches for Validating and Testing the V4L2 Driver.
you may try fetch the camera stream with V4L2 IOCTL directly to verify basic camera functionality.
for example,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=4056,height=3040,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

may I know which Jetpack release you’re using now?
FYI, I do see some issue on r35.3.1 to stream 4-lane camera on CSI-C. please try enable your i2c@1 camera that’s using CSI-E at the moment.

the settings within tegra-camera-platform looks incorrect.

	tegra-camera-platform {
		num_csi_lanes = <4>;

the num_csi_lanes means the total active CSI lanes.
please configure num_csi_lanes = <8>; since you’ve two 4-lane cameras in your system.

I can’t get any log or result of: v4l2-ctl -d /dev/video0 --set-fmt-video=width=4056,height=3040,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

The jetpack I am using is r35.3.1

But I’ve looked at the inputs on each of the IMX577 pins with an oscilloscope and they are all good
,seems some have errors on some configuration

For CSI-E, do you mean to set the tegra_sinterface to “serial_e”? Can I directly set tegra_sinterface to “serial_e” on my i2c@2?

How can I confirm if I set correct value of parameter inside each “mode”? Maybe Wrong setting may cause the issue

hello EmondCai,

you may also setup a terminal to keep it running with $ dmesg --follow to gather the kernel logs.

note, I’ve examine your device tree sources.
it’s your i2c@1 camera that’s using CSI-E now.

I enable both i2c device, and the current dtsi is:
imx577.dtsi (16.7 KB)

I can detect both cameras on i2c:

I get this through dmesg --follow:

And still got the same error when executing:
nvgstcapture --sensor-id=0
nvgstcapture --sensor-id=1

I’m not sure why I can see tegra194 related things in my sudo dmesg --follow

hello EmondCai,

please refer to Topic 252259 to revise the symbol of nvcsi.
and… let’s follow below commands to boost all the VI/CSI/ISP clocks for testing.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

Thank you JerryChang!

I’m following Topic 252259. I am trying to execute /opt/nvidia/jetson-io/, but seems it can’t get any gui and the program auto exit(maybe because I dont have the imx219?).

By the way, I’m using the CSI2+3 as CAM1 and CSI4 as CAM2, so the CSI0 D1 and CSI1 D0 P/N swizzled issue may not happen to me right?

What should I do next after I change this

I have tried this but seems everything remain the same result.

What I do is:

  1. Change csi_chan@0 to channel@0 of tegra234-p3768-0000-a0.dtsi
  2. replace the dtb and boot, then boost all the VI/CSI/ISP clocks
  3. check whether nvgstcapture works
  4. Check the dmesg --follow logs

Everything seems no change

hello EmondCai,

please also follow the steps below to enable VI tracing logs.

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

you may start with v4l2 standard IOCTLs, and gather the VI tracing logs for reference,
for example,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=4056,height=3040,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

besides, please have disassembler the dtb file into text file, and sharing the file for examination.
for example, dtc -I dtb -O dts -o output.txt tegra234-p3767-0001-p3768-0000-a0.dtb

Hi @JerryChang !

I Change my dtb from tegra234-p3767-0001-p3768-0000-a0.dtb to /boot/kernel_tegra234-p3767-0001-p3509-a02.dtb, seems the log have changed:

The dmesg log shows:

The nvgstcapture still not work, and get the same error. Once I execute nvgstcapture, the 39.41fps doesnt show up(even I restart the nvargus-daemon.service) and the dmesg --follow have errors like this

Current output.txt here:
output.txt (421.0 KB)

I appreciate your help!

The result of VI tracing is like this:

this looks like v4l2 standard IOCTLs works.
FYI, each < indicate a success frame capture. is the output frame-rate (i.e. 39-fps) as meet your sensor capability?

you may enable VI tracing logs, and gathering the logs after you running camera use-case.

Yes the framerate is 40 for sensor mode 0, I guess 39.41 matches. Does it mean that I can get the video stream through v4l2 now?

The VI logs here:
VITRACING.log (299.4 KB)

hello EmondCai,

as mentioned in previous comment #3, please try enable your i2c@1 camera that’s using CSI-E at the moment.
you may revise tegra-camera-platform as following to leave only i2c@1 enabled for verification.
for example,

	tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";
		modules {
			module0  {
				badge = "imx577_rear";
				position = "rear";
				orientation = [31 00];

				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx577 10-001a";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@1/cam_1@1a";

Still need to know what is the “bwmgr API not supported” issue