SIPL support in Jetpack 7.2/Jetson AGX Orin

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
, ,
1

Hi nvidia,

Does Jetpack 7.2 in Jetson AGX Orin supports SIPL/UDDF framework ?

4

Yes, JP7.2 support it.

Thanks

5

Hi nvidia,

Thanks for the reply. I am trying to stream imx623 camera sensor with max96717 serializer and max96712 deserializer combination through SIPL/UDDF stack. I am using jetpack 7.2 in Jetson AGX Orin dev kit.

I wrote the required json file. Eventhough, the json file got parsed successfully through nvsipl_query application, i am getting following errors while running the nvsipl_camera command.

My SIPL app command :

$ sudo nvsipl_camera -c R0SIM623S5RU1197NB3 -m 0x0001 -H -v 4 -N /var/nvidia/nvcam/settings/sipl/R0SIM623S5RU1197NB3.nito -Z -t ~/json/Sample.json

Error Snippet :

nvsipl_camera: Initializing master interface
Main: /dvs/git/dirty/git-master_linux/camera/fusa/sipl/src/core/pipelineMgr/CNvMCamera.cpp: 1712: Init: Entering
Operation returning failure: opcode = 0x18
Parse failed after 5 successful operations
nvsipl_camera: ERROR: NvSIPLCamera Init failed
nvsipl_camera: ERROR: Master initialization failed. status: 10
nvsipl_camera: Queue timeout
nvsipl_camera: Queue timeout
nvsipl_camera: Queue timeout
Main: /dvs/git/dirty/git-master_linux/camera/fusa/sipl/src/core/pipelineMgr/CNvMCamera.cpp: 5177: Deinit: Entering
Main: /dvs/git/dirty/git-master_linux/camera/fusa/sipl/src/core/pipelineMgr/CNvMCamera.cpp: 5206: Deinit: Exiting

I have attached the complete error log and the json file. Kindly, go through it and help us to solve the issue. Thank you.

Sample.json.txt (3.1 KB)

Error_SIPL.log (9.9 KB)

7

The JSON did parse. The failure is later, at NvSIPLCamera::Init (opcode = 0x18, status 10 = NVSIPL_STATUS_ERROR). So this is not the same class of bug as your YUV/Invalid Pixel Order case.

Compared to NVIDIA’s own smart_imx623_camera.json + transport_settings_concord.json, that Sample.json is a messy / mismatched HAL config.

What the log shows

  1. ParseJsonFile / GMSL module parse → OK
  2. GetImageAttributes for ISP0/1/2 → OK (raw12rj was accepted for buffers)
  3. Init → NvSci “Parse failed… opcode = 0x18” → master init failed

So query is fine; bring-up (HAL/VI/CSI/NvSci) fails.

Problems in that Sample.json (vs stock R0SIM623)

Sample.json Official R0SIM623 / Concord Risk
"phyMode": "cphy" (+ cphyRate) "dphy" + dphyRate High – wrong PHY mode on Orin CSI-AB
"linkMode": "…_6GBPS" …_3GBPS High – link rate mismatch
"serInfo": "MAX96717" MAX96717F Medium – wrong ser driver/name
No powerControlInfo TegraDeserPowerDriver + GPIO Medium – deser power not sequenced
No eepromInfo GT24C64D @ 0x54 Medium – R0SIM623 UDDF always creates EEPROM UBB
Nested legacy "deviceBlocks" with C2SIM623… Not used in HAL cameraConfigs Noise – ignored, but wrong schema
"i2cDevice": 9 Concord uses 8 Board-dependent
Extra "type": "GMSL" on platform entry Not in stock transport file Usually ignored

Likely root cause (practical)

Not “JSON can’t be parsed,” but config does not match the supported R0SIM623 + Orin transport profile, so Init fails when opening capture/HAL (NvSci 0x18 is a low-level attr/IPC failure during that bring-up).

Closest fix: start from stock files and only change board-specific bits:

  • Camera: camera/fusa/sipl/query/database/camera_system_config/smart_imx623/smart_imx623_camera.json
  • Transport: …/transport_settings_concord.json (dphy, i2cDevice, powerControlInfo)

Drop the nested deviceBlocks block entirely.

Minimal corrected shape (conceptually)

{

“platformTransportSettings”: [ /* like transport_settings_concord.json: dphy, powerControlInfo */ ],

“cameraConfigs”: [

{

“name”: “R0SIM623S5RU1197NB3”,

“type”: “GMSL”,

“serInfo”: { “name”: “MAX96717F”, “i2cAddress”: “0x40” },

“linkMode”: “LINK_MODE_GMSL2_3GBPS”,

“fsyncMode”: “external”,

“mipiSettings”: { “dphyRate”: 2500000, “phyMode”: “dphy” },

“sensorInfo”: [ { /* rggb, raw12rj, 1920x1536, emb 1/22 */ } ],

“eepromInfo”: { “name”: “GT24C64D”, “i2cAddress”: “0x54” }

}

]

}

Also check -N: log shows a .nito file as “NITO folder path”; pass the directory that contains the NITO if the app expects a folder.

Bottom line: Sample.json is not “too simple” — it’s a hybrid wrong profile (CPHY/6G/MAX96717 + dead deviceBlocks). Parse succeeds; Init fails because transport/module settings don’t match the supported R0SIM623 path.