Capture issues on csi Jetson Xavier Nx

Hello
I’m developping a board using Jetson Xavier NX and I’m investigating on capturing from a camera source CSI. The chain is SENSOR → FPDLINK3 → JETSON, so the Csi data is coming out from a deserializer CSI (not directly from a sensor).
As for my analisys, seems that Deserializer do his work. I’m not facing errors on register and all the data I can get from registers stats are right. I’m working in RAW12bit mode.
The connection to Jetson is done using CSI0 and only 2 lanes and data rate at 800Mbps.

What I see is that

  • acquiring with gstreamer doen’t work (seems to not receive buffers).
  • acquiring with v4l2 seems to work only if I “boost” the clocks, but image seems to be blurred or similar
  • boosting the logs (as by Jetson/l4t/Camera BringUp - eLinux.org) I see
  1. without boost cloks
     kworker/0:3-1731  [000] ....  1324.095018: rtcpu_vinotify_error: tstamp:42012375142 tag:CHANSEL_NOMATCH channel:0x01 frame:3 vi_tstamp:42012374014 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.095020: rtcpu_vinotify_event: tstamp:42012375499 tag:CHANSEL_NOMATCH channel:0x01 frame:3 vi_tstamp:42012374014 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.095021: rtcpu_vinotify_event: tstamp:42012375628 tag:FE channel:0x00 frame:3 vi_tstamp:42012374287 data:0x00000020
     kworker/0:3-1731  [000] ....  1324.151016: rtcpu_vinotify_event: tstamp:42013422293 tag:FS channel:0x00 frame:4 vi_tstamp:42013393995 data:0x00000010
     kworker/0:3-1731  [000] ....  1324.207012: rtcpu_vinotify_error: tstamp:42015136698 tag:CHANSEL_NOMATCH channel:0x01 frame:4 vi_tstamp:42015135869 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.207015: rtcpu_vinotify_event: tstamp:42015456725 tag:CHANSEL_NOMATCH channel:0x01 frame:4 vi_tstamp:42015135869 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.207016: rtcpu_vinotify_event: tstamp:42015456873 tag:FE channel:0x00 frame:4 vi_tstamp:42015136141 data:0x00000020
     kworker/0:3-1731  [000] ....  1324.263013: rtcpu_vinotify_event: tstamp:42016473982 tag:FS channel:0x00 frame:1 vi_tstamp:42016155849 data:0x00000010
     kworker/0:3-1731  [000] ....  1324.263017: rtos_queue_peek_from_isr_failed: tstamp:42016805247 queue:0x0bcbb8b8
     kworker/0:3-1731  [000] ....  1324.319007: rtcpu_vinotify_error: tstamp:42017898622 tag:CHANSEL_NOMATCH channel:0x01 frame:1 vi_tstamp:42017897729 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.319009: rtcpu_vinotify_event: tstamp:42018169474 tag:CHANSEL_NOMATCH channel:0x01 frame:1 vi_tstamp:42017897729 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.319010: rtcpu_vinotify_event: tstamp:42018169607 tag:FE channel:0x00 frame:1 vi_tstamp:42017898002 data:0x00000020
     kworker/0:3-1731  [000] ....  1324.319011: rtcpu_vinotify_event: tstamp:42019186725 tag:FS channel:0x00 frame:2 vi_tstamp:42018917709 data:0x00000010
     kworker/0:3-1731  [000] ....  1324.375004: rtcpu_vinotify_error: tstamp:42020660420 tag:CHANSEL_NOMATCH channel:0x01 frame:2 vi_tstamp:42020659583 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.375006: rtcpu_vinotify_event: tstamp:42020882214 tag:CHANSEL_NOMATCH channel:0x01 frame:2 vi_tstamp:42020659583 data:0x00000589
     kworker/0:3-1731  [000] ....  1324.375007: rtcpu_vinotify_event: tstamp:42020882362 tag:FE channel:0x00 frame:2 vi_tstamp:42020659856 data:0x00000020
  1. when I boost clocks
 vi-output, mt9p-9071  [002] ....   170.913896: tegra_channel_capture_frame: sof:191.169990208
 vi-output, mt9p-9071  [002] ....   170.913902: tegra_channel_capture_frame: eof:191.202655776
     kworker/0:3-1696  [000] ....   170.953505: rtcpu_vinotify_event: tstamp:5975084479 tag:CHANSEL_PXL_EOF channel:0x23 frame:4 vi_tstamp:5975082928 data:0x02cf0002
     kworker/0:3-1696  [000] ....   170.953512: rtcpu_vinotify_event: tstamp:5975084612 tag:ATOMP_FRAME_DONE channel:0x23 frame:4 vi_tstamp:5975082945 data:0x00000000
     kworker/0:3-1696  [000] ....   170.953513: rtcpu_vinotify_event: tstamp:5975084764 tag:RESERVED_19 channel:0x23 frame:4 vi_tstamp:6519061952 data:0x02020211
     kworker/0:3-1696  [000] ....   170.953514: rtcpu_vinotify_event: tstamp:5975084894 tag:FE channel:0x00 frame:4 vi_tstamp:5975082992 data:0x00000020
     kworker/0:3-1696  [000] ....   170.953516: rtcpu_vinotify_event: tstamp:5975085044 tag:ATOMP_FE channel:0x00 frame:4 vi_tstamp:5975082993 data:0x00000000
     kworker/0:3-1696  [000] ....   170.953517: rtcpu_vinotify_event: tstamp:5975085171 tag:RESERVED_19 channel:0x23 frame:4 vi_tstamp:6519068256 data:0x00020211
     kworker/0:3-1696  [000] ....   170.953525: rtcpu_vinotify_event: tstamp:5975411400 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:6519075392 data:0x07020212
     kworker/0:3-1696  [000] ....   170.953527: rtos_queue_send_from_isr_failed: tstamp:5975482531 queue:0x0bcb2b38
     kworker/0:3-1696  [000] ....   170.953529: rtos_queue_send_from_isr_failed: tstamp:5975482676 queue:0x0bcb73a0
     kworker/0:3-1696  [000] ....   170.953530: rtos_queue_send_from_isr_failed: tstamp:5975482821 queue:0x0bcb8f20
     kworker/0:3-1696  [000] ....   170.953531: rtos_queue_send_from_isr_failed: tstamp:5975482962 queue:0x0bcb9ce0
     kworker/0:3-1696  [000] ....   170.953532: rtos_queue_send_from_isr_failed: tstamp:5975483100 queue:0x0bcbaaa0
 vi-output, mt9p-9071  [002] ....   171.002225: tegra_channel_capture_frame: sof:191.258369728
 vi-output, mt9p-9071  [002] ....   171.002232: tegra_channel_capture_frame: eof:191.291035456
     kworker/0:3-1696  [000] ....   171.013441: rtcpu_vinotify_event: tstamp:5977106854 tag:FS channel:0x00 frame:1 vi_tstamp:5976822762 data:0x00000010
     kworker/0:3-1696  [000] ....   171.013446: rtcpu_vinotify_event: tstamp:5977107010 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:5976822762 data:0x00000000
     kworker/0:3-1696  [000] ....   171.013447: rtcpu_vinotify_event: tstamp:5977107142 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:5976824054 data:0x00000001
     kworker/0:3-1696  [000] ....   171.013448: rtcpu_vinotify_event: tstamp:5977107295 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:6574777088 data:0x08020212
     kworker/0:3-1696  [000] ....   171.013450: rtcpu_vinotify_event: tstamp:5977107422 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:6574854688 data:0x10000000
     kworker/0:3-1696  [000] ....   171.013451: rtcpu_vinotify_event: tstamp:5977107570 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:6574863040 data:0x31000213
     kworker/0:3-1696  [000] ....   171.013455: rtos_queue_peek_from_isr_failed: tstamp:5977353511 queue:0x0bcbb8b8
     kworker/0:3-1696  [000] ....   171.013457: rtcpu_vinotify_event: tstamp:5978124061 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:5977844794 data:0x02cf0002
     kworker/0:3-1696  [000] ....   171.013458: rtcpu_vinotify_event: tstamp:5978124214 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:5977844810 data:0x00000000
     kworker/0:3-1696  [000] ....   171.013459: rtcpu_vinotify_event: tstamp:5978124345 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:6607441632 data:0x02020212
     kworker/0:3-1696  [000] ....   171.013460: rtcpu_vinotify_event: tstamp:5978124492 tag:FE channel:0x00 frame:1 vi_tstamp:5977844857 data:0x00000020
     kworker/0:3-1696  [000] ....   171.013461: rtcpu_vinotify_event: tstamp:5978124628 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:5977844858 data:0x00000000
     kworker/0:3-1696  [000] ....   171.013462: rtcpu_vinotify_event: tstamp:5978124774 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:6607447936 data:0x00020212
     kworker/0:3-1696  [000] ....   171.013463: rtcpu_vinotify_event: tstamp:5978124917 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:6607453440 data:0x07020213
     kworker/0:3-1696  [000] ....   171.013464: rtos_queue_send_from_isr_failed: tstamp:5978182037 queue:0x0bcb2b38
     kworker/0:3-1696  [000] ....   171.013466: rtos_queue_send_from_isr_failed: tstamp:5978182182 queue:0x0bcb73a0
     kworker/0:3-1696  [000] ....   171.013466: rtos_queue_send_from_isr_failed: tstamp:5978182326 queue:0x0bcb8f20
     kworker/0:3-1696  [000] ....   171.013467: rtos_queue_send_from_isr_failed: tstamp:5978182466 queue:0x0bcb9ce0
     kworker/0:3-1696  [000] ....   171.013468: rtos_queue_send_from_isr_failed: tstamp:5978182605 queue:0x0bcbaaa0

  • From V4l2 I see
ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'RG12'
	Name        : 12-bit Bayer RGRG/GBGB
		Size: Discrete 1280x720
			Interval: Discrete 0.017s (60.000 fps)

Could someone help me?
Thanks

hello f.ortolano,

may I know which Jetpack release version you’re working with?

please refer to developer guide, you may check Jetson Virtual Channel with GMSL Camera Framework chapter since you develop camera solution with SerDes chips.

since you’re able to acquiring with v4l2 by “boost” the clocks, please also review serdes_pix_clk_hz, SerDes Pixel Clock settings, you must have proper data rate to enable the stream.
thanks

Hello
I use JP 32.7.2.

As for my experience, the same kernele modul (without modification) with the same hw on Jetson Nano works, and in that case I don’t set any “boost” to clocks. In that case, there wasn’t any ‘serdes_pix_clk_hz’ to specify.
I want to say, if I handle for myself externally throught command line all the settings to the deserializer, from a Jetson point of view doesn’t care who produces the frames, am I rgiht? I think that it’s important that the CSI produces a video at a determinated frequency (in my case 800 MHz), am I right? Another thing, I don’t want to use virtual channels, like I did in Nano.

hello f.ortolano,

that’s correct, just an FYI, there’s VC support for Xavier series.


it usually clock issue of driver porting from Nano to Xavier series, Xavier series is more critical to clock configuration.

Hello Jerry

yes I confirm that for Nano this 2 parameters doesn’t interact

					mclk_multiplier = "36";
					pix_clk_hz = "896000000";//"48000000";

For Xavier, I found that using that parameters I don’t need to boost nothing…but the image still can’t be grabbed using gstreamer (libargus). Only with v4l2 but blurred, like the 12 bit of data will not be interpreted correctly (padding, shifting…cropping to 8 bit…I don’t know). The SAME hw connected to Nano works perfectly so I think, like also you said, that from Jetson point of view if I set the same registers on sensor and deserializer I will receive same CSI packets and same image… but this doesn’t work

Just to be complete:

  • sensor works at 48 MHz (clk is on the sensor, not from the Jetson)
  • FPDLINK3 for serdes
  • 12 bit mode, the frequency of data output seems to be 48x2/3x28 → 896
  • As conseguence, mclk_multiplier > pix_clk_hz /mclk, set to 36 (doesn’t change if this is 35 or 37)

From DS90UB954 datasheet

In RAW mode the DS90UB954-Q1 deserializer each Rx Port can support up to: • 12 bits of DATA + 2 SYNC bits for an input PCLK range of 37.5 MHz to 100 MHz (75 MHz for 913A-Q1) in the 12-bit, high frequency mode. 
Line rate = fPCLK × (2/3) × 28; for example, fPCLK = 100 MHz, line rate = (100 MHz) × (2/3) × 28 = 1.87 Gbps. Note: No HS/VS restrictions (raw)

And this are the parameters set in DTS

				status = "okay";

				compatible = "nvidia,mt9p031vs";

				/* I2C device address */
				reg = <0x5d>;

				/* V4L2 device node location */
				devnode = "video0";

				/* Physical dimensions of sensor */
				physical_w = "5.7";
				physical_h = "4.28";

				sensor_model = "mt9p031";

				use_sensor_mode_id = "true";

				mode0 { /* MT9P031_MODE_1280x720_60FPS */
					mclk_khz = "27000";
					num_lanes = "2";
					tegra_sinterface = "serial_a";
					phy_mode = "DPHY";
					discontinuous_clk = "no";//"yes";
					dpcm_enable = "false";
					cil_settletime = "0";

					active_w = "1280";
					active_h = "720";
					
					/* pixel_t = "bayer_grbg12"; DEPRECATED */ 
					mode_type = "bayer";
					csi_pixel_bit_depth = "12";
					pixel_phase = "gbrg"; //"gbrg"; "rggb"; /*"grbg";*/


					readout_orientation = "0";
					line_length = "2180";
					inherent_gain = "1";
					mclk_multiplier = "36";
					pix_clk_hz = "896000000";//"48000000";

					gain_factor = "16";
					framerate_factor = "1000000";
					exposure_factor = "1000000";
					min_gain_val = "16"; /* 1.00x */
					max_gain_val = "170"; /* 10.66x */
					step_gain_val = "1";
					default_gain = "16"; /* 1.00x */
					min_hdr_ratio = "1";
					max_hdr_ratio = "1";
					min_framerate = "2000000"; /* 2.0 fps */
					max_framerate = "60000000"; /* 60.0 fps */
					step_framerate = "1";
					default_framerate = "60000000"; /* 60.0 fps */
					min_exp_time = "13"; /* us */
					max_exp_time = "683709"; /* us */
					step_exp_time = "1";
					default_exp_time = "2495"; /* us */

					embedded_metadata_height = "0";
				};

hello f.ortolano,

what’s the blurred image looks like, could you please attach that for review.
could you please enable gst pipeline with nvarguscamerasrc plugin, and gather the latest VI tracing logs for checking,
please also share the settings within tegra-camera-platform {} for reference.
thanks

Hello

  1. Frames are attached. As you see, the same frame with different platforms results in something different…

Jetson Xavier

Jetson Nano

  1. tegra-camera-platform {} (same as NANO)
	tcp: tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";
		num_csi_lanes = <2>;
		max_lane_speed = <1500000>;
		min_bits_per_pixel = <10>;
		vi_peak_byte_per_pixel = <2>;
		vi_bw_margin_pct = <25>;
		max_pixel_rate = <240000>;
		isp_peak_byte_per_pixel = <5>;
		isp_bw_margin_pct = <25>;
		modules {
			cam_module0: module0 {
				badge = "porg_front_jetson_cam0";
				position = "front";
				orientation = "1";

				cam_module0_drivernode0: drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "mt9p031vs 6-005d";
					proc-device-tree = "/proc/device-tree/host1x/i2c@546c0000/mt9p031p0";
				};
			};
		};
  1. Log when capturing using V4L2 (only one cycle, I suppose 1 frame, it repeats the same…)
 vi-output, mt9p-9723  [003] ....   142.295024: tegra_channel_capture_frame: sof:158.799666848
 vi-output, mt9p-9723  [003] ....   142.295030: tegra_channel_capture_frame: eof:158.832332576
     kworker/0:2-1619  [000] ....   142.305427: rtcpu_vinotify_event: tstamp:4962823806 tag:FS channel:0x00 frame:1 vi_tstamp:4962488297 data:0x00000010
     kworker/0:2-1619  [000] ....   142.305431: rtcpu_vinotify_event: tstamp:4962823973 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:4962488298 data:0x00000000
     kworker/0:2-1619  [000] ....   142.305432: rtcpu_vinotify_event: tstamp:4962824115 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:4962489589 data:0x00000001
     kworker/0:2-1619  [000] ....   142.305433: rtcpu_vinotify_event: tstamp:4962824277 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:4180847680 data:0x08020001
     kworker/0:2-1619  [000] ....   142.305433: rtcpu_vinotify_event: tstamp:4963514545 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:4963510328 data:0x02cf0002
     kworker/0:2-1619  [000] ....   142.305434: rtcpu_vinotify_event: tstamp:4963514707 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:4963510350 data:0x00000000
     kworker/0:2-1619  [000] ....   142.305435: rtcpu_vinotify_event: tstamp:4963514847 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:4213514240 data:0x02020001
     kworker/0:2-1619  [000] ....   142.305436: rtcpu_vinotify_event: tstamp:4963515004 tag:FE channel:0x00 frame:1 vi_tstamp:4963510392 data:0x00000020
     kworker/0:2-1619  [000] ....   142.305436: rtcpu_vinotify_event: tstamp:4963515144 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:4963510393 data:0x00000000
     kworker/0:2-1619  [000] ....   142.305437: rtcpu_vinotify_event: tstamp:4963515302 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:4213534816 data:0x00020001
     kworker/0:2-1619  [000] ....   142.305438: rtcpu_vinotify_event: tstamp:4963515438 tag:RESERVED_19 channel:0x23 frame:0 vi_tstamp:4213552608 data:0x07020002
     kworker/0:2-1619  [000] ....   142.361394: rtos_queue_send_from_isr_failed: tstamp:4964210589 queue:0x0bcb2b38
     kworker/0:2-1619  [000] ....   142.361400: rtos_queue_send_from_isr_failed: tstamp:4964210743 queue:0x0bcb73a0
     kworker/0:2-1619  [000] ....   142.361401: rtos_queue_send_from_isr_failed: tstamp:4964210896 queue:0x0bcb8f20
     kworker/0:2-1619  [000] ....   142.361402: rtos_queue_send_from_isr_failed: tstamp:4964211045 queue:0x0bcb9ce0
     kworker/0:2-1619  [000] ....   142.361404: rtos_queue_send_from_isr_failed: tstamp:4964211193 queue:0x0bcbaaa0
     kworker/0:2-1619  [000] ....   142.417359: rtos_queue_peek_from_isr_failed: tstamp:4965995179 queue:0x0bcbb8b8
     kworker/0:2-1619  [000] ....   142.417373: rtcpu_vinotify_event: tstamp:4966330765 tag:FS channel:0x00 frame:2 vi_tstamp:4966321411 data:0x00000010
     kworker/0:2-1619  [000] ....   142.417374: rtcpu_vinotify_event: tstamp:4966330929 tag:ATOMP_FS channel:0x00 frame:2 vi_tstamp:4966321414 data:0x00000000
     kworker/0:2-1619  [000] ....   142.417375: rtcpu_vinotify_event: tstamp:4966331092 tag:CHANSEL_PXL_SOF channel:0x23 frame:2 vi_tstamp:4966322702 data:0x00000001
     kworker/0:2-1619  [000] ....   142.417376: rtcpu_vinotify_event: tstamp:4966331228 tag:RESERVED_19 channel:0x23 frame:2 vi_tstamp:4303507296 data:0x08020002
     kworker/0:2-1619  [000] ....   142.417408: rtcpu_vinotify_event: tstamp:4966331386 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:4303661536 data:0x10000000
     kworker/0:2-1619  [000] ....   142.417410: rtcpu_vinotify_event: tstamp:4966331522 tag:RESERVED_18 channel:0x23 frame:0 vi_tstamp:4303686976 data:0x31000003
  1. Output from v4l
Media controller API version 0.1.0

Media device information
------------------------
driver          tegra194-vi5
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  0.0.0

Device topology
- entity 1: 15a00000.nvcsi--1 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		<- "mt9p031vs 10-005d":0 [ENABLED]
	pad1: Source
		-> "vi-output, mt9p031vs 10-005d":0 [ENABLED]

- entity 4: mt9p031vs 10-005d (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev1
	pad0: Source
		[fmt:SRGGB12_1X12/1280x720 field:none colorspace:srgb]
		-> "15a00000.nvcsi--1":0 [ENABLED]

- entity 6: vi-output, mt9p031vs 10-005d (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
	pad0: Sink
		<- "15a00000.nvcsi--1":1 [ENABLED]

  1. String gst
gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=1280, height=720, format=NV12, framerate=21/1' ! nvoverlaysink
  1. Log gst
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:740 No cameras available
Got EOS from element "pipeline0".
Execution ended after 0:00:00.003440490
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
  1. Log dmesg
[ 1197.360905] mt9p031vs 10-005d: mt9p031vs_power_on: power on
[ 1197.371702] [RCE] Configuring ISP GoS.
[ 1197.371711] [RCE]   VM GOS[#0] addr=0xc2100000
[ 1197.371718] [RCE]   VM GOS[#1] addr=0xc2101000
[ 1197.371724] [RCE]   VM GOS[#2] addr=0xc2102000
[ 1197.371730] [RCE]   VM GOS[#3] addr=0xc2103000
[ 1197.371736] [RCE]   VM GOS[#4] addr=0xc2104000
[ 1197.371741] [RCE]   VM GOS[#5] addr=0xc2105000
[ 1197.384231] mt9p031vs 10-005d: mt9p031vs_power_off: power off
[ 1197.387321] mt9p031vs 10-005d: mt9p031vs_power_on: power on
[ 1197.410610] mt9p031vs 10-005d: mt9p031vs_power_off: power off
  1. Log from trace
  nvargus-daemon-10448 [000] ....  1197.360822: tegra_channel_open: vi-output, mt9p031vs 10-005d
  nvargus-daemon-10448 [000] ....  1197.360834: tegra_channel_set_power: mt9p031vs 10-005d : 0x1
  nvargus-daemon-10448 [000] ....  1197.360841: camera_common_s_power: status : 0x1
     kworker/0:1-10239 [000] ....  1197.371677: rtos_queue_peek_from_isr_failed: tstamp:37933744323 queue:0x0bcbb8b8
     kworker/0:1-10239 [000] ....  1197.371682: rtcpu_start: tstamp:37933747854
     kworker/0:1-10239 [000] ....  1197.371684: rtos_queue_send_from_isr_failed: tstamp:37933774341 queue:0x0bcb2b38
     kworker/0:1-10239 [000] ....  1197.371686: rtos_queue_send_from_isr_failed: tstamp:37933774493 queue:0x0bcb73a0
     kworker/0:1-10239 [000] ....  1197.371687: rtos_queue_send_from_isr_failed: tstamp:37933774646 queue:0x0bcb8f20
     kworker/0:1-10239 [000] ....  1197.371688: rtos_queue_send_from_isr_failed: tstamp:37933774793 queue:0x0bcb9ce0
     kworker/0:1-10239 [000] ....  1197.371689: rtos_queue_send_from_isr_failed: tstamp:37933774938 queue:0x0bcbaaa0
     kworker/0:1-10239 [000] ....  1197.371691: rtcpu_string: tstamp:37933775397 id:0x04010000 str:"Configuring ISP GoS.
"
     kworker/0:1-10239 [000] ....  1197.371709: rtcpu_string: tstamp:37933775573 id:0x04010000 str:"  VM GOS[#0] addr=0xc2100000
"
     kworker/0:1-10239 [000] ....  1197.371715: rtcpu_string: tstamp:37933775825 id:0x04010000 str:"  VM GOS[#1] addr=0xc2101000
"
     kworker/0:1-10239 [000] ....  1197.371722: rtcpu_string: tstamp:37933776066 id:0x04010000 str:"  VM GOS[#2] addr=0xc2102000
"
     kworker/0:1-10239 [000] ....  1197.371728: rtcpu_string: tstamp:37933776315 id:0x04010000 str:"  VM GOS[#3] addr=0xc2103000
"
     kworker/0:1-10239 [000] ....  1197.371734: rtcpu_string: tstamp:37933776547 id:0x04010000 str:"  VM GOS[#4] addr=0xc2104000
"
     kworker/0:1-10239 [000] ....  1197.371739: rtcpu_string: tstamp:37933776779 id:0x04010000 str:"  VM GOS[#5] addr=0xc2105000
"
  nvargus-daemon-10448 [000] ....  1197.384051: tegra_channel_set_power: 15a00000.nvcsi--1 : 0x1
  nvargus-daemon-10448 [000] ....  1197.384056: csi_s_power: enable : 0x1
  nvargus-daemon-10448 [000] ....  1197.384211: tegra_channel_close: vi-output, mt9p031vs 10-005d
  nvargus-daemon-10448 [000] ....  1197.384217: tegra_channel_set_power: mt9p031vs 10-005d : 0x0
  nvargus-daemon-10448 [000] ....  1197.384223: camera_common_s_power: status : 0x0
  nvargus-daemon-10448 [000] ....  1197.384299: tegra_channel_set_power: 15a00000.nvcsi--1 : 0x0
  nvargus-daemon-10448 [000] ....  1197.384301: csi_s_power: enable : 0x0
  nvargus-daemon-10448 [000] ....  1197.387264: tegra_channel_open: vi-output, mt9p031vs 10-005d
  nvargus-daemon-10448 [000] ....  1197.387272: tegra_channel_set_power: mt9p031vs 10-005d : 0x1
  nvargus-daemon-10448 [000] ....  1197.387278: camera_common_s_power: status : 0x1
  nvargus-daemon-10448 [000] ....  1197.410454: tegra_channel_set_power: 15a00000.nvcsi--1 : 0x1
  nvargus-daemon-10448 [000] ....  1197.410458: csi_s_power: enable : 0x1
  nvargus-daemon-10448 [000] ....  1197.410594: tegra_channel_close: vi-output, mt9p031vs 10-005d
  nvargus-daemon-10448 [000] ....  1197.410598: tegra_channel_set_power: mt9p031vs 10-005d : 0x0
  nvargus-daemon-10448 [000] ....  1197.410603: camera_common_s_power: status : 0x0
  nvargus-daemon-10448 [000] ....  1197.410675: tegra_channel_set_power: 15a00000.nvcsi--1 : 0x0
  nvargus-daemon-10448 [000] ....  1197.410677: csi_s_power: enable : 0x0

Hello
ok I found my mistake. I copied all from Nano, but on Nano I2C and platform tree at the end was different (this is because, for run my sensor, I modified the imx219 DTS from jakku that supports 2 cameras with a i2c-mux). At the end I corrected the last lines to

				cam_module0_drivernode0: drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "mt9p031vs 10-005d";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@0/mt9p031vs_a@5d";
				};

I changed:

  • devname from " 6-005d" to “10-005d” (in Xavier, Cam0 is routed from I2C2 to I2C9 and 10 with cammux)
  • device tree in “proc-device-tree = “/proc/device-tree/cam_i2cmux/i2c@0/mt9p031vs_a@5d””

As for this modifications, I am able to capture rightly with Xavier NX using nvgstcapture-1.0. It remains only the strange behaviour using V4L2 directly. In that way I continue to see artifacts over the image as the pixels are not rightly readed.

hello f.ortolano,

log for capturing using V4L2 looks correct, it shows you got start-of-frame and end-of-frame,
you may also try with below two commands,
for example, to capture headless raw file.
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=GB12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw
or,
access the stream directly, it’ll report < for each capture buffer below the command-line.
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=GB12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

it looks very high gain values has applied, and some of the pixel overflow.
do you have tuning files? you should have re-generate the tuning file for Xavier series.

Hello, no this part I don’t know what you refer to… tuning for? and how to/where?
For about the gains, it’s strange becouse using gst (libargus) the frame seems correct…I will try your pipes for v4l2.

Ok, opening this file seems all ok, thanks. A question: the pixels (12 bit lenght) are stored in 2 bytes of 16 bits, is right? What I mean, they are not packed in 2x3 (2 pixels in 3 bytes), this is what I’m facing. It’s right?

don’t forget to explain me also what you refer to tunig

hello f.ortolano,

that’s ISP tuning file used by camera stack to tune the image quality, please check whether you’ve files under /var/nvidia/nvcam/settings/.

I’m a little confused, don’t you capture image through gst in comment #8? please share the commands you’re used.

that’s correct, please do notice that [RAW Memory Formats]. Xavier series is using T_R16 formats, there’ll be MSBs replicated bits.

Yes, using that pipeline… I’m wrong to say that using gst with nvarguscamerasrc is not like using libargus?

And Nano? Maybe this is the difference

Ok I see that there is a file called nvcam_cache_1.bin, but how to edit, verify this file?

hello f.ortolano,

  1. gst with nvarguscamerasrc should be same as libargus.
    you may try exclude format=NV12 from the command-line, please try again to capture image as following.
    for example,
    $ gst-launch-1.0 nvarguscamerasrc num-buffers=1 ! 'video/x-raw(memory:NVMM), width=1280, height=720' ! nvjpegenc ! filesink location=sample.jpg

  2. Xavier and Nano are having different formats, Nano is using T_R16_I for raw memory formats.

  3. nvcam_cache_1.bin it’s cache file for camera stack, you may try delete that and restart camera service.
    however, I am now wondering this is not related to image quality tuning issue.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.