SDK Manager thinks Orin is not in recovery mode

[WayneWWW]

That only means your method to put board into recovery mode int those subsequent try is incorrect.

[jcharest1]

I didn’t change the method I used to put the board into recovery mode

[WayneWWW]

Hi,

Just want to clarify… you can do it in the first time today. You can do it yesterday and that was also the first time, subsequent try always failed.

Is that what you are talking about now?

[jcharest1]

Yes, but any subsequent tries immediately fail with the board not connected or not in recovery mode error.

[WayneWWW]

1. As I already said, if the board is already boot up, you need to use reset button + recovery button. If your power is not powered on, then you need to use power button +recovery button. You can always make the flash start probably means your first try was power on +recovery. It failed in flashing but the power is still already on, thus, you need to use reset button in your subsequent test.
   Or you just remove the power cable, plug it back and try again.
   I am not sure if you really understand what yourself is talking about. Your comment sounds like “It was okay yesterday, failed then, okay again today and failed then”. There is no magic trick here that your board could enter recovery mode again just because you put it idle for one night. It just means the method to do the subsequent test was wrong.

2. BTW, I need to see the full lines of this log. You shared it twice but both of them are truncated…

[ 0.003231] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-5.10/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/ps

[WayneWWW]

And can you use jetson-agx-orin-devkit instead of the maxn one in your flash command?

[jcharest1]

1. I know how to put the board in recovery mode. The board is in recovery mode. lsusb shows the nvidia device. The sdk manager recognizes the board and can connect. Sorry I did not make this clear: the issue is that the script thinks the board is not actually in recovery mode when it is. The issue is not that I cannot put the board into recovery mode.

2. You can see the full line in the non-truncated log that I posted here (reproduced below): SDK Manager thinks Orin is not in recovery mode - #35 by jcharest1

[    0.003098] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-5.10/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t23x/concord/kernel-dts/tegra234-p3701-0000-p3737-0000.dts

3. Running the jetson-agx-orin-devkit config instead of jetson-agx-orin-devkit-maxn ends in the same result.

[WayneWWW]

Hi @jcharest1

Can you help clarify

1. How many times have you seen the recovery mode really starting yet? Only once ? only twice? I mean in these days, not just today.

2. Could you clarify what “same result” is it? Not able to detect as recovery mode? Or the flash start but tells you not able to read board information?

[jcharest1]

1. I’m not sure I fully understand the question, but I see recovery mode start every time I press the button sequence which has been dozens of times, if that is what you are asking.
2. It results in unable to detect recovery mode.

[WayneWWW]

@jcharest1

Error: Return value -9
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Reading board information failed.

My question is how many times have you seen above log coming out your flash.sh instead of telling you recovery mode is not able to detected.

This indicates the recovery mode is really detected and flash started. Though it failed in the end. But this is totally different case as “cannot detect recovery mode”.

[jcharest1]

That has happened twice

[WayneWWW]

Ok, could you test if you can still operate with the uart console after you put the board into recovery mode?

[WayneWWW]

And when the flash started and failed with “failed to read board info” case, is the last log from uart still “instance 0 not supported for module 8”? Even with rel-35?

I know you may not able to get that log because you are still getting stuck in the recovery mode issue, just want to ask.

BTW, we only check the result of sudo ./flash.sh jetson-agx-orin-devkit mmcblk0p1 afterwards. The maxn should not be used.

[WayneWWW]

Also, are you using the v2 or v1 version of release?

[jcharest1]

The serial console doesn’t seem to work anymore after putting the board in recovery mode. I’m using v2

[WayneWWW]

How about trying the software method to put the board into recovery mode?

Boot up the board first and use the uart console to give “sudo reboot forced-recovery” on your jetson Orin. Try if flash.sh can see the board after this command.

[jcharest1]

Same result. The device shows up in lsusb but the flash.sh script still says that it is not in recovery mode

[WayneWWW]

Since recovery mode is pure hardware triggered event, if you still cannot flash 2 those modules. I can only ask you to RMA module.

I mean if your error is always “Make sure the target board is connected through USB port and is in recovery mode.”, then it is either hardware issue on jetson or usb problem or host side has some issues.

This is not related to the jetpack software itself.

[jcharest1]

Okay thank you