Meet NvBufSurfaceFromFd Failed when driving imx577 on Orin Nano

Okay I will try this, thank you very much

FYI,
you may ignore those messages since bwmgr has disabled for Orin series.

Actually I enable both camera before, and test them with --sensor-id=0 and --sensor-id=1, does it mean that I enable i2c@1 camera?

They both have the same error

Hi @JerryChang

I only enable the i2c@1, and try to see if IOCTL works

But the issue I meet before comes up, the dmesg --follow shows:

Maybe it‘s because the i2c@1 is using cfi4?Things are becoming wired

BTY,dose this mean I can get the video through some methods?

BTW, we are using a Orin nano(4G) on P3518, is there any successful example for it to driver imx477 or imx219

Do I need to set lane_polarity=6?Though I am using CSI2+3 and CSI4

@JerryChang

hello EmondCai,

since your v4l2 standard IOCTLs works. there should be something wrong in your device tree settings.
please also gather the VI tracing logs when access the stream via gstreamer.
for example,
$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),width=4056, height=3040, framerate=39/1, format=NV12' ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420' ! fpsdisplaysink text-overlay=0 video-sink=fakesink sync=0 -v

Thank you for your reply!

I got the VI tracing logs through the gstreamer:
VI.log (682 Bytes)

And when executing your gst command,I get the dambuf_fd -1 mapped entry not found issue, Which is similar to nvgstcapture

hello EmondCai,

there’s nothing happened in the tracing logs.
do you got positive results by running v4l2-compliance test? i.e. $ v4l2-compliance -d /dev/video<n>

The resule of v4l2-compliance -d /dev/video0 and v4l2-compliance -d /dev/video1 are here:
video1.log (3.3 KB)
video0.log (3.3 KB)

VI.log (433.7 KB)
Sorry maybe do something wrong gathering the log. I execute the gsteamer again and get the vi log

looks like a CHANSEL_NOMATCH issue

hello EmondCai,

I do see some correct stream patterns in the beginning,
for example, one pair of CHANSEL_EMBED_SOF/EOF for sending embedded metadata, and then there’s CHANSEL_PXL_SOF/EOF for sending a capture frame.
somehow, there’re lots CHANSEL_NOMATCH. this meant the coming signaling is mismatch with your device tree settings.

please also refer to Sensor Pixel Clock section to review sensor pixel clock settings.
if you’re using a SerDes chip, please check SerDes Pixel Clock section.

Hi @JerryChang , Really grateful for you time and reply!
One information I have’t say is that, the device tree is working successfully on Jetson Xavier NX to driver my imx577, Does that rule out some of the factors?

hello EmondCai,

so you’re porting the driver to Orin Nano and seen such failure?
may I also know what’s the output data rate, is it larger than 1.5Gbps?

So for my sensor mode 0, according to this I can caculate my pixel_clk_hz=4056 x 3040 x 40 = 493,209,600

According to this the output data rate= pixel_clk_hz * 10 / 8 = 493,209,600 x 10 /8 = 616,512,000


image

Does this make sense?

driver layer only consider serdes_pix_clk_hz if you’re using a SerDes chip, and serdes_pix_clk_hz should be larger than pixel_clk_hz settings.

Sorry but can’t actually understand how to caculate serdes_pix_clk_hz,is the “deserializer output data rate in hertz the same with Output data rate?”