FPGA MIPI CSI-2 RAW8 input: STREAMON ok but no FS/FE/CHANSEL_PXL events on Jetson

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hi NVIDIA team,

We are bringing up a custom FPGA MIPI CSI-2 source on Jetson.

Current FPGA output:

  • CSI-2 D-PHY
  • 2 lanes
  • RAW8, data type 0x2A
  • Resolution: 1440x576
  • Frame rate: 25 fps
  • VC-ID currently assumed VC0
  • Continuous clock
  • Same FPGA/MIPI output can be captured correctly on another receiver board

Jetson setup:

  • Custom V4L2 sensor-style driver, no real I2C register programming
  • Manual insmod only
  • Media graph is created successfully:
    sensor → nvcsi → vi-output → /dev/video0
  • Tested GREY/Y8, BA81/BGGR8, and RAW12 probe
  • Tested serial_b/port1 and serial_c/port2
  • Tested lane_polarity 0/6, VC 0/1/2/3, cil_settletime 0/10/20/30, continuous/discontinuous clock

Observed behavior:

  • /dev/video0 is created
  • v4l2-ctl STREAMON succeeds
  • VIDIOC_DQBUF returns error buffers
  • timestamps are always 0.000000
  • output raw file size is 0 bytes
  • dmesg shows repeated tegra-camrtc-capture-vi request timed out after 2500 ms
  • override_capture_timeout_ms=-1 removes timeout messages but still no frames

Trace observation:

  • We do not see valid CHANSEL_PXL_SOF / CHANSEL_PXL_EOF.
  • We also do not see useful CHANSEL_NOMATCH / FS / FE events.

Questions:

  1. If D-PHY signal is present at Jetson CAM connector pins but no FS/FE/CHANSEL_NOMATCH/CHANSEL_PXL events appear, what are the most likely causes?
  2. Does Jetson NVCSI require strict CSI-2 FS/FE short packets, ECC/CRC, and exact word count before any trace event appears?
  3. Is there a recommended way to read NVCSI packet/parser error counters on Jetson Linux 5.15 / tegra-camrtc stack?
  4. For RAW8 DT=0x2A, 1440x576, 2 lanes, should DT use GREY/Y8 or Bayer BGGR8/BA81 for bring-up?
  5. Are there known limitations when FPGA is already continuously transmitting before Jetson STREAMON?
  6. What trace events should we enable to distinguish lane/PHY issue, CSI-2 packet decode issue, VC/DT mismatch, and VI channel select mismatch?

Any guidance on the next debug step would be appreciated.

2

I captured the enhanced trace suggested in a similar FPGA/CSI thread.

Additional hardware information:

  • The external camera/module and FPGA MIPI TX path have been checked on the hardware side.
  • The same FPGA/MIPI output can be connected to a HiSilicon DV300 receiver board and it displays images correctly.
  • So we currently believe the external source and cable/adapter path are basically working, and we are trying to understand why Jetson NVCSI/VI does not decode it.

Log directory from this test:
```text
/mnt/nfs/am001_logs/nvidia_trace_20260428_175654
```

Summary of this trace:

  • /dev/video0 exists.
  • STREAMON succeeds.
  • The driver set_mode/start_streaming callbacks are called.
  • NVCSI set_stream is enabled.
  • Current baseline is RAW8 DT=0x2A, VC=0, 1440x576, 2 lanes, continuous clock.
  • The captured raw file is still 0 bytes.
  • All DQBUF buffers have the error flag and timestamp 0.000000.
  • dmesg repeats: tegra-camrtc-capture-vi request timed out after 2500 ms.

Trace observations:

  • I see tegra_channel_set_stream for NVCSI enable/disable.
  • I see repeated VIFALC_TDSTATE / VIFALC_ACTIONLST events.
  • I still do not see CHANSEL_PXL_SOF, CHANSEL_PXL_EOF, CHANSEL_NOMATCH, CHANSEL_SHORT_FRAME, or rtcpu_nvcsi_intr.

So it looks like VI/NVCSI are enabled, but the input is not decoded as valid CSI-2 image packets at all.

Does this point more toward CSI-2 packet validity, FS/FE short packets, header ECC / payload CRC / word count, VC-ID, or D-PHY LP/HS timing rather than a VI pixel format mismatch?

4

One more detail about the RAW8/GREY bring-up history:

On the original Jetson camera stack I used, the RAW8 path for our source was not complete for the formats we needed. At the beginning, the pixel format path did not correctly support our RAW8 GREY/Y8 or BGGR8 use case.

What I changed during bring-up:

  • In sensor_common.c, I extended the pixel_t parsing path for our RAW8 modes, including GREY/Y8 and later bayer_bggr8 / SBGGR8.
  • In camera_common.c, I added the missing format-table entries, including Y8/GREY and SBGGR8/BA81 mappings.
  • In vi/vi5_formats.h, I added the missing VI RAW8 GREY entry, for example Y8_1X8 → GREY, so that tegra_channel_update_format can get a valid fmtinfo.

There was an earlier kernel panic / hang during nv_am001 load when only part of the GREY/Y8 path had been added. The direct cause appeared to be that camera_common could parse/match GREY, but vi5_formats.h still did not have the Y8_1X8/GREY VI format entry. This left fmtinfo as NULL in the VI format update path.

After adding the missing vi5_formats.h RAW8 GREY entry and keeping the camera_common/sensor_common mappings consistent, that panic/hang was resolved:

  • /dev/video0 could be created normally.
  • GREY/Y8 could enumerate as 1440x576.
  • Later, bayer_bggr8 also enumerated correctly as BA81/SBGGR8, 1440x576, bytesperline=1440, sizeimage=829440.

So at this point the issue has moved past the earlier software format-registration problem. The current failure happens after STREAMON: buffers return with error and timestamp 0, the raw file is 0 bytes, and the enhanced trace still has no CHANSEL_PXL_SOF/EOF, CHANSEL_NOMATCH, CHANSEL_SHORT_FRAME, or rtcpu_nvcsi_intr.

7

Suppose the same with topic.

I think it could be the sensor output signal problem. You may need have scope to probe the signal to confirm.

Thanks

9

Hi everyone, thanks for looking into this. I wanted to provide some additional context and raise a couple of suspicions regarding this issue:

  1. Hardware is verified on another SoC
    MIPI CSI-2 packets are supposed to be highly standardized. We have already tested this exact same FPGA MIPI output on a HiSilicon Hi3516DV300 platform, and it correctly captures the video stream and outputs images perfectly without any issues. However, on the Jetson Orin NANO Developer Kit, there is absolutely no reaction (as shown by the missing SOF/EOF).

  2. Are there strict, Jetson-specific MIPI requirements?
    Given that the FPGA stream works perfectly on the HiSilicon SoC, I would like to ask: does Jetson’s NVCSI/VI engine have any specific, strict, or proprietary requirements for receiving MIPI-CSI2 packets? For example, does Jetson have stricter tolerances for LP-to-HS (Low Power to High Speed) state transitions, specific inter-packet gap requirements, or strict timings for Frame Start/Frame End packets that might cause it to silently drop the frames?

  3. L4T Version Anomaly (R36.4.7?)
    I also have a strong suspicion regarding the OS version. On the official NVIDIA JetPack/L4T archive, I only see releases for R36.4.4 and then a jump to R36.5. However, the default system that came flashed on my custom dev board is R36.4.7. Furthermore, I have been compiling my custom V4L2 driver natively directly on the board.

Could this undocumented/intermediate system version (R36.4.7), or the fact that I am compiling natively on it, be causing underlying incompatibilities or bugs within the CSI/VI subsystem?

Any insights or suggestions for debugging this further would be greatly appreciated!

11

You may post the whole trace log here to check.

modprobe rtcpu_debug

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 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace

v4l2-ctl --stream-mmap -c bypass_mode=0

cat /sys/kernel/debug/tracing/trace