如题所说：我们想把R35.1.0更新进64G版本的Orin核心板，我们发现R35.1.0版本不能够刷入到64G版本的Orin核心模组.
但是我们有这个需求，因为目前R35.3.1和R35.4.1版本SDK的camera 或者VI 或者RTCPU.img 存在BUG，会导致至少两个问题：1、CPU核心温度达到60-65度左右时，所有video设备会突然停止采集工作，2、只能打开最多12个videos设备，而经过我们测试，在R35.1.0版本（使用32GOrin 模组）可以打开16个以上videos设备，并且不存在CPU60-65度情况下所有video停止图像采集的问题。
所以我想知道怎样才能在R35.1.0版本下刷入64G Orin核心板，谢谢
hello 541449841,
I’m not sure what camera issue you’ve seen.
however, we’ve recently address some camera bugs for JP-5.1.2/l4t-r35.4.1
please see-also below threads to apply the bug fixes for verification.
for example,
Topic 268833, for camera firmware to update deskew algorithm, and also stability fixes,
Topic 268519, to fix memory corruption within libnvargus
谢谢你的回答。
我遇到的问题和DPHY没有关系，和libnvargus 也没有关系。
这里我在详细说明一下我们遇到的问题：我们购买了32G，64G，和开发者套件 三个版本的Orin核心板某组，并自制了载板，在此基础上开发基于CPHY camera 的图像采集产品。
在点亮多个camera的过程中遇到了以下问题：
1、我们使用R35.3.1/R35.4.1 版本SDK开发时，控制环境温度，模拟我们产品的实际工况，通过Jetson Power GUI 观察Orin 核心CPU 的温度变化，首先在CPU核心温度为45°左右时开启12个video设备的采集工作抓取图像，Orin可以正常连续采集图像，然后，我们增加了Orin 的工作负载来模拟实际的工作情况,CPU温度会随着工作时间上升，当CPU温度达到60-65度左右时，之前还在正常工作的12个video 设备抓图任务会同时停止，当我尝试关闭抓图任务时，Orin 的Ubuntu 系统就会崩溃。上面所说的抓图任务仅仅是通过命令行输入指令v4l2-ctl -d /dev/videox --stream-mmap 进行抓图而已，没有其他任何程序。
当CPU核心温度在68度以及以上的时候，再打开12个video 设备抓图，此时还可以正常工作，但是如果改变散热条件，加大风扇的转速，使CPU核心温度缓慢降低，在经过60度左右时，也会出现所有video设备抓图同时停止，并且不能恢复的情况，尝试关闭命令行并重启任务，也会导致Ubuntu 系统崩溃。
2、在R35.3.1和R35.4.1的SDK版本下，我最多只能打开12个video设备，当打开第13个video 设备时，Ubuntu 系统会崩溃。
对于这两个问题，我已经通过代理商反馈给Nvidia总部了：
对于问题1、代理商给我的反馈是Nvidia内部正在推进解决，并且在其他生态合作伙伴中也发现了相同的问题。但是我们发现，将L4T版本回退到R35.1.0 时，并不存在这样的问题，无论是CPU温度从45度上升到70度的过程，还是从70度下降到45度的过程中，都不会出现抓图停止的现象，而R35.3.1/R35.4.1版本在抓取12个4096x3072@30fps （CPHY）的工况下，一定会在CPU核心温度上升或者下降过程中经过60度左右时停止抓图，并且关掉抓图窗口会使ubuntu系统崩溃。
对于问题2、代理商反馈Nvidia内部认为这可能是由于达到了VI带宽的瓶颈导致的不稳定现象，但是我们不这么认为，理由是当我使用32G版本的核心板，刷机成R35.1.0版本的Jetpack，发现并不存在所谓的瓶颈，我能同时打开16个video 设备并且能够稳定运行，而不是在R35.3.1/R35.4.1版本只能最多打开12个（测试时均是使用同样的硬件设备，同样的camera配置，都是4个物理camera 每个camera 有4个VC ，分辨率4096x3072@30fps，CPHY camera），另一方面，从理论计算来说，16个4096x3072@30fps的图像数据也远远没有达到Orin VI 带宽的限制，大概只有最大带宽的一半左右。
it looks a follow-up of this discussion thread, Topic 266876, right?
let’s put efforts on camera issue with r35.4.1 instead of flashing Orin 64 GB version with r35.1.0
hello 541449841,
could you please based-on r35.4.1, and remove below mutex locks.
let’s try you could enable 13th camera stream.
for instance,
diff --git a/drivers/video/tegra/camera/tegra_camera_platform.c b/drivers/video/tegra/camera/tegra_camera_platform.c
index 78ad66433..a322b1c19 100644
--- a/drivers/video/tegra/camera/tegra_camera_platform.c
+++ b/drivers/video/tegra/camera/tegra_camera_platform.c
@@ -73,7 +73,6 @@ struct tegra_camera_info {
struct icc_path *icc_iso_path_handle;
int icc_noniso_id;
struct icc_path *icc_noniso_path_handle;
- struct mutex icc_noniso_path_handle_lock;
#endif
struct mutex update_bw_lock;
u64 vi_mode_isobw;
@@ -351,13 +350,10 @@ static int tegra_camera_open(struct inode *inode, struct file *file)
#if IS_ENABLED(CONFIG_INTERCONNECT) && IS_ENABLED(CONFIG_TEGRA_T23X_GRHOST)
/* For T194 and earlier chips Interconnect is not supported. */
if (tegra_get_chip_id() == TEGRA234) {
- mutex_lock(&info->icc_noniso_path_handle_lock);
info->icc_noniso_id = TEGRA_ICC_ISP;
info->icc_noniso_path_handle =
icc_get(info->dev,
info->icc_noniso_id, TEGRA_ICC_PRIMARY);
- mutex_unlock(&info->icc_noniso_path_handle_lock);
-
if (IS_ERR_OR_NULL(info->icc_noniso_path_handle)) {
dev_err(info->dev,
"%s unable to get icc path (err=%ld)\n",
@@ -396,10 +392,8 @@ static int tegra_camera_release(struct inode *inode, struct file *file)
info = file->private_data;
#if IS_ENABLED(CONFIG_INTERCONNECT) && IS_ENABLED(CONFIG_TEGRA_T23X_GRHOST)
if (tegra_get_chip_id() == TEGRA234) {
- mutex_lock(&info->icc_noniso_path_handle_lock);
icc_put(info->icc_noniso_path_handle);
info->icc_noniso_path_handle = NULL;
- mutex_unlock(&info->icc_noniso_path_handle_lock);
return 0;
}
#endif
@@ -588,11 +582,9 @@ static long tegra_camera_ioctl(struct file *file,
__func__, kcopy.bw, mc_khz);
#if IS_ENABLED(CONFIG_INTERCONNECT) && IS_ENABLED(CONFIG_TEGRA_T23X_GRHOST)
if (tegra_get_chip_id() == TEGRA234) {
- mutex_lock(&info->icc_noniso_path_handle_lock);
ret = icc_set_bw(info->icc_noniso_path_handle,
(u32)(kcopy.bw & 0xFFFFFFFF),
(u32)(kcopy.bw & 0xFFFFFFFF));
- mutex_unlock(&info->icc_noniso_path_handle_lock);
if (ret) {
dev_err(info->dev,
"%s: ICC failed to reserve %u KBps\n",
@@ -787,7 +779,6 @@ static int tegra_camera_probe(struct platform_device *pdev)
mutex_init(&info->update_bw_lock);
#if IS_ENABLED(CONFIG_INTERCONNECT) && IS_ENABLED(CONFIG_TEGRA_T23X_GRHOST)
info->icc_iso_id = TEGRA_ICC_VI;
- mutex_init(&info->icc_noniso_path_handle_lock);
#endif
/* Register Camera as isomgr client. */
ret = tegra_camera_isomgr_register(info, &pdev->dev);
好的 我先试试。谢谢
看起来并没有什么效果，Camera RTCPU gone bad! 与之前的测试一样。
[ 248.021316] misc tegra_camera_ctrl: tegra_camera_update_isobw: Warning, Requested ISO BW 14625000 has been capped to VI's max BW 10800000
[ 248.021322] bwmgr API not supported
[ 248.021454] bwmgr req failed for 8
[ 248.028683] misc tegra_camera_ctrl: tegra_camera_isomgr_request: ICC failed to reserve 10800000 KBps
[ 248.034537] [RCE] BUG: camera-ip/vi5/vi5.c:415 [vi5_check_falcon_failure] "VI FALCON FAILURE: 0x40000000"
[ 248.038067] misc tegra_camera_ctrl: tegra_camera_update_isobw: failed to reserve 10800000 KBps with isomgr
[ 248.047990] Debug 20231018: this is csi5_stream_set_config Michael : is_cphy=1 cil_settletime=30 lane_polarity =0 csi_lanes=3 stream_id=0 csi_port=0 mipi_clk=2800000
[ 248.125624] tegra186-cam-rtcpu bc00000.rtcpu: Alert: Camera RTCPU gone bad! restoring it immediately!!
[ 249.070669] tegra194-vi5 13e40000.host1x:vi0@15c00000: capture control message timed out
[ 249.079018] tegra194-vi5 13e40000.host1x:vi0@15c00000: vi_capture_control_send_message: failed to send IVC control message
[ 249.091202] [scsensor_start_streaming] debug info=======================================
[ 250.574551] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.574570] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.574669] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.574678] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.574683] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.574691] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.578541] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.578543] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.578549] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.578550] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.578559] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.578563] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.583696] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.583702] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.606532] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.611814] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.661446] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 250.667894] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.667896] tegra194-vi5 13e40000.host1x:vi0@15c00000: vi_capture_release: control failed, errno 1
[ 250.667898] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.667912] tegra194-vi5 13e40000.host1x:vi0@15c00000: vi_capture_release: control failed, errno 1
[ 250.667926] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.667961] video4linux video3: vi capture release failed
[ 250.667963] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.667975] video4linux video14: vi capture release failed
[ 250.667977] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.667986] video4linux video6: vi capture release failed
[ 250.667988] video4linux video11: vi capture release failed
[ 250.667990] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.667993] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.668021] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.668035] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.668046] video4linux video15: vi capture release failed
[ 250.668047] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.668076] video4linux video7: vi capture release failed
[ 250.668130] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.690538] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.712078] video4linux video12: vi capture release failed
[ 250.730539] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.762538] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.762541] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.762578] video4linux video13: vi capture release failed
[ 250.762580] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.770959] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.816075] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 250.817859] video4linux video5: vi capture release failed
[ 250.842125] tegra194-vi5 13e40000.host1x:vi1@14c00000: vi_capture_release: control failed, errno 1
[ 250.851597] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
[ 250.882631] video4linux video4: vi capture release failed
[ 251.077127] tegra-camrtc-capture-vi tegra-capture-vi: fatal: error recovery failed
我也将rtcpu.img 更新到这个版本了 依旧不能打开第十三个video设备
hello 541449841,
currently, we don’t have reference board with 16-cam for validation.
FYI, we only have camera board with 12-camera. we’ve also resolve multi-cam stability issues based-on that.
may I know the real use-case for running multi-cam? how many camera streams is requested?
Hello,Jerry
我们的实际使用场景是使用Orin采集Camera 图像，来测试CMOS芯片的性能，同时可用的camera数量减少意味着我们需要投入更多的Orin 设备来达到我们的测试需求，我们的测试设备的成本会成倍增加，这是无法接受的。
我们需要同时开启16个 camera streams进行测试。实际上是4个CMOS芯片，CMOS的出流配置为3段HDR曝光和1个VC的 PDAF数据流：short-exp+middle-exp+long-exp+PDAF。
如果方案验证结论是Orin 不能同时进行16个camera streams 的数据采集的话，那么对比其他采集方案将没有优势。
请问camera的分辨率是多少呢？如果能达到4096x3072@30fps 的话，我想能够成功复现第一个问题：随着CPU核心温度从45°上升到70°的过程中，会有一个瞬间所有视频流会同时停止，并且尝试关闭视频流会导致Ubuntu 崩溃这个问题。
我们做了大量测试反复确认了，这个现象在4096x3072@30fps 12个camera streams的情况下是必然会出现的。然而在R35.1.0 版本上却是可以稳定运行的，而且R35.1.0版本可以同时打开16个channel.所以我们认为，这并不是由于温度上升或者VI带宽能力达到瓶颈导致出流不稳定的现象，因为较低版本的SDK 是可以稳定工作的。而且根据Orin TRM 手册提供的spec来看，VI带宽能力有164Gbps,而4096x3072@30fps x 12 个 camera streams 的数据量为4096x3072x30x10x12 = 45.3Gbps, 就算给到50% margin 总的带宽也只有68Gbps左右，远远不到164Gbps。
需要注意，更小的分辨率可能不会出现以上问题，如果想要复现该问题，建议使用4096x3072@30fps或更大的分辨率。
hello 541449841,
let me have quick update, besides 16-cam video steams, 3 exposures HDR is currently not supported.
Hello,Jerry
我的意思是，我们只使用了4个物理上的CMOS芯片，需要同时点亮4个CMOS，但是这4个CMOS都需要工作在3 exposures HDR 模式，外加1个PDAF 数据通道，因此总共需要同时打开16个camera streams.
3 exposures HDR is working well,16-cam video streams didn’t
and rtcpu will crash at some point during the CPU temperature rise from 45° to 70°(It’s usually around 65°)
R35.1.0 is working well，but R35.4.1/R35.3.1 didn’t.