Is defining active_w and active_h necessary in dtsi file of camera sensor

Hi @JerryChang

Is it necessary to define active_w and active_h in dtsi file of camera sensor? Can it be different from what is actually being sent?
For example, below is the excerpt from dtsi file:

active_w = "3264"; /* actuHal value is 640*/
active_h = "2464"; /* actual value is 480*/

However, actual values sent by the sensor is 640x480.

Reason for asking is, my understanding is, MIPI receiver of Jetson knows when SoF, Start of Line, End of Line and EOF is and will accordingly acquire the video. So does defining active_w and active_h has any effect?

Currently getting the below output in traces, is it because the active_w and active_h values are differenet from what is actually being sent from the sensor? I do see SOF message in traces, does that mean Jetson is able to detect SOF?

     kworker/3:1-8782  [003] ....  5487.045182: rtos_queue_peek_from_isr_failed: tstamp:171747094817 queue:0x0b4b6398
 vi-output, ov56-9384  [003] ....  5487.162089: tegra_channel_capture_setup: vnc_id 0 W 3264 H 2464 fmt 20
 vi-output, ov56-9384  [003] ....  5487.162119: tegra_channel_capture_frame: sof:-549620698804.-270766660480
     kworker/3:1-8782  [003] ....  5487.165163: rtos_queue_send_from_isr_failed: tstamp:171750744076 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165167: rtos_queue_send_from_isr_failed: tstamp:171750744186 queue:0x0b4ab1a8
     kworker/3:1-8782  [003] ....  5487.165169: rtos_queue_send_from_isr_failed: tstamp:171750744294 queue:0x0b4acdd8
     kworker/3:1-8782  [003] ....  5487.165171: rtos_queue_send_from_isr_failed: tstamp:171750744404 queue:0x0b4ae958
     kworker/3:1-8782  [003] ....  5487.165172: rtos_queue_send_from_isr_failed: tstamp:171750744509 queue:0x0b4af718
     kworker/3:1-8782  [003] ....  5487.165174: rtos_queue_send_from_isr_failed: tstamp:171750744614 queue:0x0b4b04d8
     kworker/3:1-8782  [003] ....  5487.165176: rtos_queue_send_from_isr_failed: tstamp:171750744718 queue:0x0b4b1298
     kworker/3:1-8782  [003] ....  5487.165177: rtos_queue_send_from_isr_failed: tstamp:171750744823 queue:0x0b4b2058
     kworker/3:1-8782  [003] ....  5487.165180: rtos_queue_send_failed: tstamp:171750745388 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165182: rtos_queue_send_from_isr_failed: tstamp:171750750808 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165184: rtos_queue_send_from_isr_failed: tstamp:171750750925 queue:0x0b4ab1a8
     kworker/3:1-8782  [003] ....  5487.165185: rtos_queue_send_from_isr_failed: tstamp:171750751031 queue:0x0b4acdd8
     kworker/3:1-8782  [003] ....  5487.165187: rtos_queue_send_from_isr_failed: tstamp:171750751139 queue:0x0b4ae958
     kworker/3:1-8782  [003] ....  5487.165189: rtos_queue_send_from_isr_failed: tstamp:171750751244 queue:0x0b4af718
     kworker/3:1-8782  [003] ....  5487.165190: rtos_queue_send_from_isr_failed: tstamp:171750751349 queue:0x0b4b04d8
     kworker/3:1-8782  [003] ....  5487.165192: rtos_queue_send_from_isr_failed: tstamp:171750751454 queue:0x0b4b1298
     kworker/3:1-8782  [003] ....  5487.165193: rtos_queue_send_from_isr_failed: tstamp:171750751558 queue:0x0b4b2058
     kworker/3:1-8782  [003] ....  5487.165195: rtos_queue_send_failed: tstamp:171750751980 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165197: rtos_queue_send_from_isr_failed: tstamp:171750757617 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165198: rtos_queue_send_from_isr_failed: tstamp:171750757735 queue:0x0b4ab1a8
     kworker/3:1-8782  [003] ....  5487.165200: rtos_queue_send_from_isr_failed: tstamp:171750757843 queue:0x0b4acdd8
     kworker/3:1-8782  [003] ....  5487.165201: rtos_queue_send_from_isr_failed: tstamp:171750757950 queue:0x0b4ae958
     kworker/3:1-8782  [003] ....  5487.165203: rtos_queue_send_from_isr_failed: tstamp:171750758054 queue:0x0b4af718
     kworker/3:1-8782  [003] ....  5487.165205: rtos_queue_send_from_isr_failed: tstamp:171750758159 queue:0x0b4b04d8
     kworker/3:1-8782  [003] ....  5487.165207: rtos_queue_send_from_isr_failed: tstamp:171750758265 queue:0x0b4b1298
     kworker/3:1-8782  [003] ....  5487.165208: rtos_queue_send_from_isr_failed: tstamp:171750758369 queue:0x0b4b2058
     kworker/3:1-8782  [003] ....  5487.165210: rtos_queue_send_failed: tstamp:171750758796 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165211: rtos_queue_send_from_isr_failed: tstamp:171750761888 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.165213: rtos_queue_send_from_isr_failed: tstamp:171750761997 queue:0x0b4ab1a8
     kworker/3:1-8782  [003] ....  5487.165215: rtos_queue_send_from_isr_failed: tstamp:171750762104 queue:0x0b4acdd8
     kworker/3:1-8782  [003] ....  5487.165216: rtos_queue_send_from_isr_failed: tstamp:171750762210 queue:0x0b4ae958
     kworker/3:1-8782  [003] ....  5487.165218: rtos_queue_send_from_isr_failed: tstamp:171750762315 queue:0x0b4af718
     kworker/3:1-8782  [003] ....  5487.165220: rtos_queue_send_from_isr_failed: tstamp:171750762420 queue:0x0b4b04d8
     kworker/3:1-8782  [003] ....  5487.165221: rtos_queue_send_from_isr_failed: tstamp:171750762537 queue:0x0b4b1298
     kworker/3:1-8782  [003] ....  5487.165223: rtos_queue_send_from_isr_failed: tstamp:171750762644 queue:0x0b4b2058
     kworker/3:1-8782  [003] ....  5487.165224: rtos_queue_send_failed: tstamp:171750763551 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.221175: rtos_queue_peek_from_isr_failed: tstamp:171752094814 queue:0x0b4b6398
     kworker/3:1-8782  [003] ....  5487.389190: rtos_queue_peek_from_isr_failed: tstamp:171757094816 queue:0x0b4b6398
     kworker/3:1-8782  [003] ....  5487.557195: rtos_queue_peek_from_isr_failed: tstamp:171762094797 queue:0x0b4b6398
        v4l2-ctl-9383  [000] ....  5487.596954: tegra_channel_close: vi-output, ov5693 2-0036
 vi-output, ov56-9384  [003] ....  5487.681887: tegra_channel_capture_setup: vnc_id 0 W 3264 H 2464 fmt 20
 vi-output, ov56-9384  [003] ....  5487.681917: tegra_channel_capture_frame: sof:-549620698804.-270766660480
        v4l2-ctl-9383  [003] ....  5487.682165: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-9383  [003] ....  5487.682168: tegra_channel_set_stream: ov5693 2-0036 : 0x0
        v4l2-ctl-9383  [003] ....  5487.682181: tegra_channel_set_stream: 150c0000.nvcsi--1 : 0x0
        v4l2-ctl-9383  [003] ....  5487.682183: csi_s_stream: enable : 0x0
        v4l2-ctl-9383  [003] ....  5487.684263: tegra_channel_set_power: ov5693 2-0036 : 0x0
        v4l2-ctl-9383  [003] ....  5487.684275: camera_common_s_power: status : 0x0
        v4l2-ctl-9383  [003] ....  5487.684339: tegra_channel_set_power: 150c0000.nvcsi--1 : 0x0
        v4l2-ctl-9383  [003] ....  5487.684345: csi_s_power: enable : 0x0
     kworker/3:1-8782  [003] ....  5487.725121: rtos_queue_send_from_isr_failed: tstamp:171766992621 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.725126: rtos_queue_send_from_isr_failed: tstamp:171766992733 queue:0x0b4ab1a8
     kworker/3:1-8782  [003] ....  5487.725128: rtos_queue_send_from_isr_failed: tstamp:171766992842 queue:0x0b4acdd8
     kworker/3:1-8782  [003] ....  5487.725130: rtos_queue_send_from_isr_failed: tstamp:171766992949 queue:0x0b4ae958
     kworker/3:1-8782  [003] ....  5487.725131: rtos_queue_send_from_isr_failed: tstamp:171766993054 queue:0x0b4af718
     kworker/3:1-8782  [003] ....  5487.725133: rtos_queue_send_from_isr_failed: tstamp:171766993159 queue:0x0b4b04d8
     kworker/3:1-8782  [003] ....  5487.725134: rtos_queue_send_from_isr_failed: tstamp:171766993264 queue:0x0b4b1298
     kworker/3:1-8782  [003] ....  5487.725135: rtos_queue_send_from_isr_failed: tstamp:171766993371 queue:0x0b4b2058
     kworker/3:1-8782  [003] ....  5487.725138: rtos_queue_send_failed: tstamp:171766993954 queue:0x0b4a7698
     kworker/3:1-8782  [003] ....  5487.725139: rtos_queue_send_from_isr_failed: tstamp:171766997441 queue:0x0b4a7698


hello jetuser,

yes. it’s camera stack side referring to active_w and active_h to setup the surface, and, it’s waiting for signaling (frame-height/line-length) to fill the buffer.
basically, there also include frame packet sanity check, for instance, it reports PIXEL_SHORT_LINE when there’s mismatch due to a line ends with fewer pixels than expected. (the expected value is your DT property settings)

there’re something wrong according to your VI tracing logs.
for example, the timestamps should not be a negative value, sof:-549620698804.-270766660480
and… it looks there’s no further frame packet received by VI engine, it should have logs reported by CHANSEL.

Thank you for the quick response.

Is there a way to modify active_w and active_h parameter without reflashing the Jetson TX2? Currently, if we do any modification in the dtsi file, I have to recompile everything and then flash the jetson.

Is there a quicker and efficient way?

PS: Yes, negative value of time stamp is solved. It was probably due to mismatch in defining active_w and active_h, when we were sending the exact resolution, timestamp was positive. However, we still see some error. We will come to this later.

hello jetuser,

since it loads the values via device tree, you may disassembler the dtb file into text file
for modification, and convert it as new dtb file to system usage.
here’s an example for your reference,
To disassembler the dtb file into text file, $ dtc -I dtb -O dts -o temp.dts tegra186-xxx.dtb
After modification has complete, you may convert the DTS to a new DTB, $ dtc -I dts -O dtb -o output.dtb temp.dts

Hi @JerryChang ,

I am using a Jetson TX2i, the boot folder has following files:

:/boot$ ls
dtb                                                                   tegra194-p2888-0001-p2822-0000-adafruit-sph0645lm4h.dtbo
extlinux                                                              tegra194-p2888-0001-p2822-0000-adafruit-uda1334a.dtbo
grub                                                                  tegra194-p2888-0001-p2822-0000-csi.dtbo
Image                                                                 tegra194-p2888-0001-p2822-0000.dtb
Image.t19x                                                            tegra194-p2888-0001-p2822-0000.dtb.sig
Image.t19x.sig                                                        tegra194-p2888-0001-p2822-0000-fe-pi-audio.dtbo
initrd                                                                tegra194-p2888-0001-p2822-0000-hdr40.dtbo
initrd.img                                                            tegra194-p2888-0001-p2822-0000-m2ke.dtbo
initrd.img-4.9.299-tegra                                              tegra194-p2888-0001-p2822-0000-maxn.dtb
initrd.t19x                                                           tegra194-p2888-0001-p2822-0000-maxn.dtb.sig
initrd.t19x.sig                                                       tegra194-p2888-0001-p2822-0000-respeaker-4-mic-array.dtbo
kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb                      tegra194-p2888-0001-p2822-0000-respeaker-4-mic-lin-array.dtbo
results.txt                                                           tegra194-p2888-0004-e3900-0000-adafruit-sph0645lm4h.dtbo
tegra186-p3636-0001-p3509-0000-a01-adafruit-sph0645lm4h.dtbo          tegra194-p2888-0004-e3900-0000-adafruit-uda1334a.dtbo
tegra186-p3636-0001-p3509-0000-a01-adafruit-uda1334a.dtbo             tegra194-p2888-0004-e3900-0000-csi.dtbo
tegra186-p3636-0001-p3509-0000-a01.dtb                                tegra194-p2888-0004-e3900-0000.dtb
tegra186-p3636-0001-p3509-0000-a01-fe-pi-audio.dtbo                   tegra194-p2888-0004-e3900-0000.dtb.sig
tegra186-p3636-0001-p3509-0000-a01-hdr40.dtbo                         tegra194-p2888-0004-e3900-0000-dual-imx274.dtbo
tegra186-p3636-0001-p3509-0000-a01-m2ke.dtbo                          tegra194-p2888-0004-e3900-0000-fe-pi-audio.dtbo
tegra186-p3636-0001-p3509-0000-a01-respeaker-4-mic-array.dtbo         tegra194-p2888-0004-e3900-0000-hdr40.dtbo
tegra186-p3636-0001-p3509-0000-a01-respeaker-4-mic-lin-array.dtbo     tegra194-p2888-0004-e3900-0000-imx274.dtbo
tegra186-quill-p3310-1000-a00-00-base.dtb                             tegra194-p2888-0004-e3900-0000-respeaker-4-mic-array.dtbo
tegra186-quill-p3310-1000-as-0888.dtb                                 tegra194-p2888-0004-e3900-0000-respeaker-4-mic-lin-array.dtbo
tegra186-quill-p3310-1000-c03-00-base-adafruit-sph0645lm4h.dtbo       tegra194-p2888-0008-p2822-0000.dtb
tegra186-quill-p3310-1000-c03-00-base-adafruit-uda1334a.dtbo          tegra194-p2888-0008-p2822-0000.dtb.sig
tegra186-quill-p3310-1000-c03-00-base-csi.dtbo                        tegra194-p3668-all-p3509-0000-adafruit-sph0645lm4h.dtbo
tegra186-quill-p3310-1000-c03-00-base.dtb                             tegra194-p3668-all-p3509-0000-adafruit-uda1334a.dtbo
tegra186-quill-p3310-1000-c03-00-base-fe-pi-audio.dtbo                tegra194-p3668-all-p3509-0000-camera-imx219-dual.dtbo
tegra186-quill-p3310-1000-c03-00-base-hdr30.dtbo                      tegra194-p3668-all-p3509-0000-camera-imx477-dual.dtbo
tegra186-quill-p3310-1000-c03-00-base-hdr40.dtbo                      tegra194-p3668-all-p3509-0000-camera-imx477-imx219.dtbo
tegra186-quill-p3310-1000-c03-00-base-m2ke.dtbo                       tegra194-p3668-all-p3509-0000.dtb
tegra186-quill-p3310-1000-c03-00-base-respeaker-4-mic-array.dtbo      tegra194-p3668-all-p3509-0000.dtb.sig
tegra186-quill-p3310-1000-c03-00-base-respeaker-4-mic-lin-array.dtbo  tegra194-p3668-all-p3509-0000-fe-pi-audio.dtbo

For TX2i, the file is tegra186-quill-p3489-1000-a00-00-ucm1.dtb however, boot folder has only kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb, is this the correct dtb? As we have ‘kernel_’ before the file name, hence, the doubt.

I have verified the contents by disassembling kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb and the content seems to suggest this is the correct file. After I assemble it after modification, can i simply replace the original file the modified dtb file by keeping the file name same viz. kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb using the below command? or is there any other process?

sudo cp ~/kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb /boot/kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb

PS: I am doing this changes in Jetson TX2i board

Hi @JerryChang ,

Any update on this?

hello jetuser,

you may check… $ cat /boot/extlinux/extlinux.conf as well,
there’s FDT entry to indicate the device tree blob of your target were using.

Below is the output:

vte-developer@vtedeveloper-desktop:~$ cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

I believe it is loading fromkernel-dtb partition

Can you confirm if I can simply do this? sudo cp ~/kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb /boot/kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb

hello jetuser,

I see… it still loads device tree settings via kernel-dtb partition,
please revise extlinux.conf to add FDT entry for it loads device tree blob via file system.

or…
you may update kernel-dtb partition individually by running flash script.
please see-also developer guide, Flashing a Specific Partition.

I added the FDT entry and provided the file path in it, however, after reboot, Jetson is stuck in nvidia logo.

hello jetuser,

we may need to check error messages for root cause, please try setting up serial console to gather UART logs.

Hi @JerryChang,

Modified extlinux.conf to include FDT /boot/tegra186-quill-p3489-1000-a00-00-base-modified.dtb

I just copied the modified dtb file to /boot and then reboot the system.

Should I have signed it somehow?

I have attached the log from the serial port.
UART_Logs.txt (51.6 KB)

hello jetuser,

it looks it’s retrieving device tree via file system.

Retrieving file: /boot/tegra186-quill-p3489-1000-a00-00-base-modified.dtb 

it looks you’ve PHY timeouts, and it shows No working controllers found in the end to enter recovery mode.
so, did you have ethernet cable connected to your target before booting-up?

No working controllers found
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110missing environment variable: pxeuuid
Retrieving file: /boot/extlinux/pxelinux.cfg/01-00-04-4b-c7-9d-8d
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.c                                             fg/00000000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.c                                             fg/0000000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/000000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/00000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/0000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/000
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/00
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/0
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm-tegra186-p3636-0001
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm-tegra186
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Retrieving file: /boot/extlinux/pxelinux.cfg/default
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Config file not found
starting USB...
No working controllers found
ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@2490000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
phy_startup() failed: -110FAILED: -110Tegra186 (P3636-0001) #

Hi @JerryChang,

Yes, but looks like it failed.

Retrieving file: /boot/tegra186-quill-p3489-1000-a00-00-base-modified.dtb  # Add this line to load DTB via file system
Skipping primary for failure retrieving FDT
SCRIPT FAILED: continuing...

Yes, the ethernet cable was plugged in, however, the cable was not connected to any other PC. It was plugged in single ended. I removed the cable from Jetson and any other USB devices connected on the Jetson, however, I believe, I am still getting the same error. Attached is the latest log.
Jetsson.txt (27.3 KB)

Steps I followed to modify the dtb file:

  1. My actual dtb file, which I used during flashing was: tegra186-quill-p3489-1000-a00-00-ucm1.dtb, however, in/boot I could only see kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb, I am assuming this is my actual file.
  2. I disassembled kernel_tegra186-quill-p3489-1000-a00-00-ucm1.dtb and saved the file as tegra186-quill-p3489-1000-a00-00-ucm1-modified.dtb
  3. I compiled the modified dtb and copied it in /boot
  4. Used sudo reboot to reboot the system

Hi @JerryChang,

Hope everybody is safe.

In the logs, why does it say -110FAILED: -110Tegra186 (P3636-0001) # P3636 in the last line? Shouldn’t it be P3489?

hello jetuser,

did you have a comment behind FDT blob? for instance, # Add this line to load DTB via file system
please try to remove the comments (or, moving it above/below the line) and test again.

Hi @JerryChang,

How do i do that now? Do i need to reflash the jetson again?

How do i access extlinux.conf file? It is not possible through serial console, right?

hello jetuser,

please try re-flash the target for confirmation.
next time you should create a backup of the original kernel and add a new entry, so that the device can fallback to the original kernel.

Hi @JerryChang,

Currently, I do not have the environment setup for flashing Jetson immediately.

Is it possible that we can ignore the FDT entry and force jetson to boot from kernel partition? Can I do something from the serial console?

it’s indicate you should have create a backup.

so, you’re now have only 1 boot options?
there’s nothing you can do via serial console, please re-flash the target.