我使用了读卡器
然后我又读了版本
我目前已经格式化,并会再试一下烧写系统。
很奇怪,当我格式化nvme之后,再使用 sdkmanager 烧录,sdkmanager 显示烧写失败,并且当我用串口去接受,没有任何输出。是不是意味着出现之前状态的原因是一直没有烧写成功。
这可能是一个硬件问题吗?
你不附上log我怎麼知道為什麼失敗…
反正我猜大概是這個
你有照上面那個link裡說的關掉usb autosuspend嗎?
還有我試過一樣的workflow了
先flash 35.3.1,在不清空NVMe drive的情況下再flash 35.4.1是不會有問題的,我還是不知道為什麼你的bootloader和kernel版本會錯亂
我烧写系统的 Ubuntu 版本是 18.04, 但是我可以试一下。
在之前我用的很好,烧写没有任何问题,在最近我无法再烧成功,我不知道为啥会突然出现这种状态,这非常奇怪。
這是Orin系列的通病
你在forum上搜一下就會知道有非常多人遇過一樣的問題
这很让我头疼,看起来 orin 系列在 JetPack 6.0 开始是主要支持的系统。
我用了以下命令
sudo -s
echo -1 > /sys/module/usbcore/parameters/autosuspend
似乎状态跟之前有一些区别,但是并不能解决问题,下面是我新导出的sdkmanager 完整日志。
SDKM_logs_JetPack_5.1.2_Linux_for_Jetson_Orin_NX_modules_2024-01-17_13-46-48.zip (414.0 KB)
我试了4-5次,除了第一次似乎开始正确烧录系统,但是 sdkmanager 程序崩溃了。剩余的情况和我上面的日志是同一种状态。
那就跟你之前的問題一樣
請抓flash時候的serial console log才能知道為什麼timeout
你能不能換一條TTL線 或是換一個tool抓log
跟你有沒有格式化硬碟不應該有關係
是的,不好意思。我接线有些问题,现在解决了,下面是报告
cutecom.log (181.0 KB)
你的問題還是跟之前一模一樣…
你要不要換一塊module試試看
我真的不知道為什麼你的bootloader跟kernel的版本會錯亂
下面文件包含了我烧写所有日志,包括烧写后开机的一些信息
error.log (146.2 KB)
我会试试其他版本,我还有 orin nano 、agx orin 、xavier nx 、nano ,但是我没有第二块orin nx 核心板了。
我又想办法找了一套全新的 orin nx 官方套件,一切正常。
serial.log (278.7 KB)
但是还是想请你帮我想一想另一块 orin nx 为什么没办法使用了,我完全没有头绪为什么发生了这样的事情,你能给我建议解决这个板子问题?我这里环境、工具都是齐全的。所以不用担心调试的过程是否复杂
我們每天都在給各種不同module刷不同的版本,從來沒有遇過你這種問題
沒辦法複製的話基本上我們也很難幫忙
你真的想debug的話我能想到的辦法大概就是把整塊QSPI memory清空
但是步驟有點麻煩
先在板子進recovery mode的情況下跑下面這個指令
sudo ./flash.sh --no-flash --sign --no-systemimg <board> mmcblk0p1
接著去Linux_for_Tegra/bootloader/flashcmd.txt
這個檔案,把裡面的指令複製出來
然後把sign
替換成erase <partition name>
接著讓板子重新進recovery mode,然後用sudo執行你上一步抓出來的指令
但是這個方法一次只能清除一個partition,我記得QSPI memory上的bootloader有40幾個partition
所以你要重複40幾次
partition的清單你可以去Linux_for_Tegra/bootloader/t186ref/cfg/flash_t234_qspi.xml
這個檔案找
我是說你要把Linux_for_Tegra/bootloader/flashcmd.txt
這個檔案裡面的指令裡的sign
替換掉
不是原本那一串flash.sh裡的東西…
我原本也是认为flashcmd.txt这个文件里面替换,可是我没有在文件里面找到这个参数
后面我在 flash.sh 命令找到 sign,所以我就误解了
我确实对这个不是太了解,我把提取到的 flashcmd.txt 发给你看下,你能给我一个例子吗
flashcmd.txt (1.4 KB)