Orin 32G massflash and boot panic

你好,我们使用Orin 32G模组并使用自研板载进行工厂批量生产160台,一共出现三块异常模组。
因为出现两种不同的异常情况,为了方便沟通,我们可以这样定义。
情况A,两块模组在批量刷机过程中出现panic,导致最终刷机失败。
情况B,一块模组可以正常批量刷机,但系统启动出现panic,启动异常。
经过NV代码与自研代码、自研板载与Devikit板载的交叉验证,目前现象如下。
情况A,使用NV的代码在Devkit底板上可以正常刷机,但使用自研的代码在Devikit和自研板载上批量刷机均出现panic,批量刷机过程中使用串口抓取设备日志如下。
massErrorLog.log (112.4 KB)

情况B,使用NV的代码在Devkit底板上系统启动正常,但使用自研代码在自研板载上出现panic现象导致无法开机,系统启动串口日志如下。

panic_b_boot.log (85.1 KB)

情况A和B,更换板载、模组反复刷机均出现panic,所以我们定位异常问题与模组直接关联,而使用自研代码在生产其他157台模组以及其他批次Orin 32G模组中均没有出现该问题,所以我们很困惑,非常需要NV的支持,谢谢!

另外,制作批量刷机包命令为
BOARDID=3701 FAB=500 BOARDSKU=0004 BOARDREV=G.0 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --network usb0 --massflash 6 jetson-agx-orin-devkit mmcblk0p1
刷机命令为
time sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0 --massflash 6 --showlogs

你們的board sku看起來一直是錯的, 量產用的module都是sku4, 不會是sku0. sku0是devkit module. sku4才是production module.

先把這個改正之後再做後面的試驗比較妥當

不好意思,刚刚发现是粘贴错误,真正使用的是下面个命令,其实是使用的sku4。
BOARDID=3701 FAB=500 BOARDSKU=0004 BOARDREV=G.0 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --network usb0 --massflash 6 jetson-agx-orin-devkit mmcblk0p1
那可以再给看一下吗?

我改個問法, 請問如果那片module不用initrd flash, 改成用flash.sh. 你們開機之後會碰上一樣的問題嗎?

不會的話麻煩把開機的uart log貼上來比對一下

我们是先讨论情况A吧,因为两种情况容易混淆,就先说initrd flash烧录异常的问题。
首先,initrd flash失败的模组,是没有烧录成功的,肯定是无法正常进去系统的。
flash.sh是正常可以烧录成功的,但是系统启动后立马出现panic情况,开机日志如下。
flashStartLog.log (134.9 KB)

正常模组使用flash.sh烧录后的系统启动日志如下。

startOKLog.log (132.4 KB)

我们试过将内核disable eth1后,initrd flash仍然出现和之前一样的panic。

[15:45:19:935] [ 31.914693] Unable to handle kernel paging request at virtual address 0039edd82f2ba1bf␍␊

可以跟你們確認一下你們跟NV kernel比較有改過哪些東西?

USB部分,去掉了PD controller 芯片,使用了一款TUSB322芯片来做替代;
网络部分,打开了千兆网接口,音频部分,内核文件改回NV的代码仍然出错。

這片module放在nv devkit上可以正常工作?

是的,使用nv的代码和devkit底板上可以正常。
如果是我们代码的问题,那么其他的157块orin模组以及其他批次的应该都会有问题,可偏偏这几块有问题,所以我们还是怀疑这模组本身出现了问题。

可以請你提供一下這片板子在NV devkit上正常開機時候的uart log嗎?

正常模组使用flash.sh烧录后的系统启动日志如下。

startOKLog.log (132.4 KB)
这个就是

請問你可以先把audio codec這部份disabled然後燒錄看看嗎?

请问是disable掉,还是将代码恢复到公版最开始的样子?

自研代码将aduio的内核代码恢复到公版后,异常模组的表现如下

在devikit板载上,initrd flash刷机会一直卡住,无法继续进行,如下图所示。

在我们自研板载上,也会出现问题如下图所示。


具体串口日日志如下
massflash_customcode.log (127.0 KB)

我们做了一些测试,希望对双方的分析有所帮助。
针对情况A,批量刷机异常的两块模组,使用NV代码与Devkit底板进行了深度测试,软件环境使用JetPack5.1.2原始Linux_for_terga,未做任何修改。
现象如下。

1、模组SN为1420823011771
使用NV(单刷)flash.sh刷机方式,刷机后首次正常启动,但reboot压测后出现概率性不低于10%的panic,日志如下。

SN1420823011771_flash.log (927.1 KB)

后使用initrd flash方法尝试,过程中出现了panic问题,该现象和使用自研代码类似,日志如下。

SN1420823011771_massflash.log (37.1 KB)

2、模组SN为1420823011866
使用flash.sh刷机方法,reboot压测未出现panic问题。
使用initrd flash尝试,刷机后首次正常启动,首次执行reboot后出现panic,日志如下。
SN1420823011866_massflash.log (217.0 KB)

所以初步定位这两块模组硬件本身的问题,请问这两块是否可以走RMA流程?

Hi,

這邊有幾點問題我提出來給您一下

  1. 你第一組給出來的log沒有完整. 第一份log已經開進去recovery boot了, 我們沒看到前面一開始怎樣crash掉的. 第二組的flash log也是不完整

、模组SN为1420823011771

  1. 可以請你這兩塊module先全部在devkit上使用flash.sh燒錄嗎? 我先不管massflash的狀況.
    可以開機的話請給我uart log + cat /etc/nv_boot_control.conf
    第二組module所說的 “使用flash.sh刷机方法,reboot压测未出现panic问题” 這件事情就有點暗示massflash本身的package可能不能在你這片module上使用. 需要花多一點時間研究 不然你換一片新module來只會碰上一樣的問題.

  2. 麻煩注意一下因為現在變成兩片module在討論, 1/30以前的討論全部都沒有參考的必要了. 麻煩丟上結果的時候要註明SN避免混淆

hi,
1、首先log信息我认为缺少的部分是非常必要的吗?抓取log是为了证明是确实panic,第一份log信息正是因为前面发生多次panic导致进入rcm模式,前面的panic没有存下,后面的panic信息也能参考,为什么非要纠结一开始是怎样cash的呢?
2、我是都在devkit上flash.sh烧录了,就像之前描述的一样,我是为了两种烧录都验证说明一下,因为有一个模组flash.sh烧录后无panic,但是massflash就有问题,这种还是要说明一下。
3、您说的暗示massflash本身的package可能不能在这片module上使用是什么意思,是说package的包的问题吗,那如果是包的问题那为什么其他150多块可以???
4、现在讨论的这两块就是之前讨论的情况A,刷机异常,只不过还有情况b,系统启动异常的模组,情况b还没有开始讨论。之前使用nv底板与代码测试的时候没有深度测试,刷机后首次启动正常便认为正常了,但压测发现不是。
5、现在已经投入很长时间在这个问题了,如果您觉得还需要我们再投入时间研究才给出RMA结论,我们就需要考虑其他方案了。
谢谢您

3、您说的暗示massflash本身的package可能不能在这片module上使用是什么意思,是说package的包的问题吗,那如果是包的问题那为什么其他150多块可以???

因為module本身會有PCN update. 有些狀況就是你這顆跟其他顆不一樣. 如果狀況是這樣, 那麼你未來拿到的新module都會有這個問題. 那這時候RMA也不會解決掉什麼問題.

我目前認為的現在是你的第一顆1420823011771有機會RMA. 但要請你配合我們
你的第二顆1420823011866 目前還需要看一下

如果你認為沒時間研究這些, 那你就直接聯絡當初的聯絡窗口說要進行RMA.

hi,

按照您说的,使用flash.sh进行烧录,具体信息如下。
(1) 模组SN为1420823011771
重启会有概率出现panic,从log日志中看出,panic后系统重新启动后正常进入。
SN1420823011771_uart.log (252.1 KB)

[10:51:35:422] [   13.665939] Unable to handle kernel paging request at virtual address 000b638512ae05ca␍␊
[10:44:45:270] mogo@mogo:~$ cat /etc/nv_boot_control.conf␍␍␊
[10:48:16:590] TNSPEC 3701-500-0004-L.0-1-1-jetson-agx-orin-devkit-␍␍␊
[10:48:16:596] COMPATIBLE_SPEC 3701--0004--1--jetson-agx-orin-devkit-␍␍␊
[10:48:16:601] TEGRA_LEGACY_UPDATE false␍␍␊
[10:48:16:601] TEGRA_BOOT_STORAGE mmcblk0␍␍␊
[10:48:16:607] TEGRA_EMMC_ONLY false␍␍␊
[10:48:16:607] TEGRA_CHIPID 0x23␍␍␊
[10:48:16:607] TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0␍␍␊
[10:48:16:612] TEGRA_OTA_GPT_DEVICE /dev/mtdblock0␍␍␊

(2) **模组SN为 1420823011866
重启也会有概率出现panic,从log日志中看出,panic后系统重新启动后正常进入。

SN1420823011866_uart.log (256.4 KB)

[12:30:53:590] mogo@mogo:~$ cat /etc/nv_boot_control.conf␍␍␊
[12:31:05:450] TNSPEC 3701-500-0004-L.0-1-1-jetson-agx-orin-devkit-␍␍␊
[12:31:05:459] COMPATIBLE_SPEC 3701--0004--1--jetson-agx-orin-devkit-␍␍␊
[12:31:05:464] TEGRA_LEGACY_UPDATE false␍␍␊
[12:31:05:464] TEGRA_BOOT_STORAGE mmcblk0␍␍␊
[12:31:05:467] TEGRA_EMMC_ONLY false␍␍␊
[12:31:05:467] TEGRA_CHIPID 0x23␍␍␊
[12:31:05:467] TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0␍␍␊
[12:31:05:472] TEGRA_OTA_GPT_DEVICE /dev/mtdblock0␍␍␊
[12:31:05:489] mogo@mogo:~$ 
[12:31:05:489] mogo@mogo:~$ cat /proc/device-tree/serial-number␍␍␊
[12:35:32:289] 1420823011866<break>
[12:35:32:289] <break>

請問這顆是哪個序號的?

1、nv_boot_control.conf如下所示