抱歉,由于我是中国人,我担心我使用中文回答你也用翻译看不太明白,所以我把中文翻译成了英语导致很多句子在英语里逻辑不流畅,我的意思是我昨天听取了技术人员的建议,刷机完成后板子自动关闭了恢复模式,但是前几天是无论做什么都无法关闭恢复模式,非常奇怪.
了解
因為其實並沒有所謂的 “刷机完成后板子自动关闭了恢复模式” , 所以我也不太確定你在說的是什麼
感覺這板子不太像真的nvidia devkit carrier board.
Got it.
Actually there is no such “disable recovery mode after reset the board”. So I am not quite sure what you are talking about.
I only feel that board is not a real nvidia devkit carrier board.
I did use nvidia devkit,a few days ago, after completing the normal burning and writing of the uboot, removing the jumper cap failed to turn off the recovery mode. I cannot determine if it is a hardware issue with the board, but when I finished burning the entire machine, the board turned off the recovery mode and removing the jumper cap can turn off the recovery mode normally.This makes me feel very confused
I did use nvidia devkit,a few days ago, after completing the normal burning and writing of the uboot, removing the jumper cap failed to turn off the recovery mode. I cannot determine if it is a hardware issue with the board
基本上沒有完整的log, 我們也無法判斷這段敘述的真偽. 很多時候這種狀況比較像是用戶自己"感覺" 或是猜想的. 比方說好了 如果有,從你燒uboot, 燒完之後完整的uart log. 我們就比較能判斷發生什麼.
或許software又觸發了一次recovery mode.
Basically it is hard to tell the truth if there is no log. In most of the time, users would “guess” or “feel” about what happened. But that could be wrong. For example, if we have the uart log since the starting of flashing uboot and until the flashed got done, then maybe we could tell what happened.
Maybe software side triggered another recovery mode.
我用翻译看不太懂这个使用说明,看样子好像就是连接J50的9,10引脚使用usb转串口putty连接小车通信,但是putty也无法在板子处于恢复模式下显示log,我不确定你们说的串口控制台是不是就是用putty终端通信的
Hi,
我前面已經說了 recovery mode的情況下確定uart.是不會印log的
這邊想要你做的事情是就讓板子進recovery mode (或是任何可以複製你碰到問題的那個情境).
既然它卡在recovery mode. 你就去燒錄它. 等它開始燒錄之後, 你的putty就會開始印log
正常來說你如果成功燒錄, 燒錄結束之後機器會重新開機. 如果你的機器真的跑進下一次recovery mode. 那你的log會印到一半就會停掉
你貼的這兩個說明 (接j50 pin 3,4,7) 就是用來抓uart log
pin 9跟10則是recovery mode用的.
這兩件事情沒有直接關連. 你可以在任何狀況下都用3,4,7 pin來抓log. 但只有需要燒機器的時候才需要接pin9 跟10.
I see. After listening to your method, I opened both the micro USB and serial debugging console at the same time. Now, there is no longer a situation where the board remains in recovery mode after burning the uboot. I used to only connect to the micro USB, but now I know that I can check the log of the putty terminal. I no longer have the situation where recovery mode cannot be turned off. Thank you for your suggestion
1 Like
I want to add that boot stages are their own operating system. Despite having its only purpose of setting up hardware and overwriting itself with Linux, boot has its own drivers and environment. This includes the serial console driver, network driver, memory access, so on. If you somehow edit the boot content wrong, and install that, then it can crash and burn for serial console even though Linux itself might function (this assumes that boot gets to load Linux; in that case serial console would have started functioning again at that stage, but it never got to Linux).
If you modify boot software and boot fails and loses serial console, it in no way means it is in recovery mode. Recovery mode itself is not changed by any software you might flash. I suppose there are some private i2c addresses which could render the Jetson unbootable and unavailable for flash, but you’d have to try really hard to do that.
Okay, I got it,thank you very much
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.