Camera failing when secure boot enabled

Hi, I’m following up on Boosting clocks with disk encryption + secure boot - #8 by kjasper

The kernel changes seem to have no effect, when i run the camera application at boot it fails, but if it run it again it succeeds

The rates in /sys/kernel/debug/clk/isp/clk_rate and /sys/kernel/debug/clk/vi/clk_rate are not the same as set in the kernel, /sys/kernel/debug/clk/nvcsi/clk_rate is the same

hello kjasper,

did you meant it always failed by 1st time to launch the camera application, but it works after re-launch the app?

yes thats correct, and when the board isn’t fused it works first time

hello kjasper,

debug nodes were disabled after enabling Jetson security,
please try using different power modes, please have a mode definition to the file, $ /etc/nvpmodel.conf to define a custom power mode.

I don’t think I can control vi and isp clocks through the power mode file?

In Boosting clocks with disk encryption + secure boot - #8 by kjasper you gave me instructions to change these values in the kernel but it doesn’t seem to work

I’ve tested more and the issue is with argus not setting up properly, because the second run always succeeds. Running v4l2-ctl --stream-mmap -c bypass_mode=0 -d /dev/video0 works on boot so its not a hardware issue.

hello kjasper,

you have to review your device tree settings. especially the settings mentioned within Property-Value Pairs table.

is it due to sensor init sequence?
please also add set_mode_delay_ms to configure maximum wait time for the first frame after capture starts, the unit is in milliseconds.

v4l2-ctl captures normally on every run, so the issue is with argus

please double check the DT properties. Argus takes additional settings within Property-Value Pairs table to initial sensors.

even after increasing set_mode_delay_ms to 10000 i still get fence timeout on [ffffffc0e6484b40] after 1500ms

hello kjasper,

had you also review the pixel clock, i.e. pix_clk_hz.
BTW, you should also check the sensor operations in the driver side.
The common reason (v4l2 works but not Argus) is frame length is not as expected. Frame length varies due to exposure time. The issue looks like CSI port is expecting a set of exposure time/frame length but sensor is generating in another set. It may be why it fails in v4l2-ctl. In Argus stack, AE is running after sensor initialization, so the controls of setting exposure time and frame length are called, this may make the camera sensor generate the frame length that CSI port is waiting for.

But it always works the second time. The camera is hardware reset between every launch so the sensor output is always the same. And it works every time on an unfused module

don’t it works after the code snippets to configure VI and NVCSI rates at maximum has added?

sometimes it works but most times it doesnt work if i set the max clocks in the kernel

maybe 2/5 times it works

I investigated this further today and it appears to be a module issue… about 4/10 modules i tested had varying levels of failures, and 6/10 worked perfectly. With the exact same kernel/dtb/os/executable/carrier board/cameras.

I can continue trying to fix the broken ones with your suggestions or just RMA and see if the new ones work

hello kjasper,

just double confirm the Jetpack release version you’re working with.
according to… JetPack 4 Reaches End of Life,
please moving to the latest JP-4 release, i.e. JetPack 4.6.4 for verification.

I’m using 4.6.4, i’ve implemented some fixes but i still encounter now on the second run. Still a fence_timeout, I tried increasing it but getting: fence timeout on [ffffffc0b986ee40] after 7500ms

it might be caused by me sigkilling the argus process instead of gracefully ending it, but argus should handle this

hello kjasper,

may I have more details. did it meant it worked normally for the 1st run, but it failed due to you shutdown the app abruptly?
let’s have further narrow down this, can you restore the stream by restart nvargus-daemon service?
for example,
$ sudo pkill nvargus-daemon
$ sudo systemctl start nvargus-daemon

Was the jetson apt repo updated recently? On my working boards i see i have the nvidia-l4t-* version as 32.7.4-20230608211515, and on the repo they are 32.7.4-20230608212426