Hello,
We are unable to reflash modules that were already working in the past.
Module version is: 699-83310-1000-D01 B
Flash test with Jetpack 4.4/BSP 32.4.2 from ubuntu 16.04 host.
Logs:
D01B-host-stall (21.8 KB)
D01B-target-stall (360 Bytes)
Please help before RMA.
Kind regards
Tanguy
As long as a VM is not involved, here is the FAQ on RMA:
https://developer.nvidia.com/embedded/faq#rma-process
Is this a custom board or devkit? Is it okay to move this module to devkit and test?
Though you said you are using jp4.4 to flash, but your directory name is cam5-flashing-32-3-1–v15. Which one is correct?
Hello,
Thanks linuxdev and Wayne for your replies.
I will come back to you as soon as I can test on a devkit (don’t have one next to me right now).
I did multiple tests:
Jetpack 4.4/BSP 32.4.2
Jetpack 4.3/BSP 32.3.1
Jetpack 3.3/BSP 28.2.1
I will come back to you with logs on the devkit.
Hello WayneWWW,
I’ve tried to reflash my module with Jetpack 4.5.1 on an original devkit as asked.
Flash hangs after following instructions as before:
tegrarcm_v2 --boot recovery
Applet version 01.00.0000
Please find sdk manager logs attached.
Kind regards,
Tanguy
sdkm-2021-06-08-15-43-47.log (209.3 KB)
NV_L4T_FLASH_TX2_WITH_OS_IMAGE_COMP.log (27.7 KB)
Hi,
Just want to confirm: how many D01 B TX2 boards do you have? Could you use other TX2 devkit or custom boards to validate if your host really can flash jetson devices?
Hello WayneWWW,
We have plenty of them, my host definitely can flash.
But we have a stock of modules that are causing problems, I am now in the process to test each of them to know if we need to RMA them.
For proof, I just reflashed on same devkit another working module with Jetpack 4.5.1.
Please find sdk manager new logs attached.
Kind regards,
Tanguy
sdkm-2021-06-08-15-43-47.log (598.8 KB)
NV_L4T_FLASH_TX2_WITH_OS_IMAGE_COMP.log (368.6 KB)
Hi,
Can you help take few problematic boards/modules and see if they are all the same kind? For example, maybe D01 boards have this kind of problem while other B0X/ C0X modules don’t.
Also, devkit can also dump the serial console log as your comment #1. Could you check if all of these boards get stuck in below line as your previous log?
[0043.556] I> Welcome to MB2(TBoot-BPMP) Recovery(version: 01.00.160913-t186-M-00.00-mobile-e33577f2)
[0043.565] I> bit @ 0xd480000
[0043.568] I> Boot-device: eMMC
[0043.778] I> sdmmc DDR50 mode
[0043.782] I> sdmmc bdev is already initialized
[0043.787] I> pmic: reset reason (nverc) : 0x50
[0043.794] I> Found 18 partitions in SDMMC_BOOT (instance 3)
Hi,
I’ve updated my posts with logs as in my comment #1.
I juste succeeded to flash another module of version: 699-83310-1000-D01 B.
Logs attached here:
NV_L4T_FLASH_TX2_WITH_OS_IMAGE_COMP.log (368.6 KB)
Hello,
Then can you check the UART log of these problematic boards/modules when flashing? Need to see if they are all stuck in the same lines.
Hello,
It seems that until now I only have one module exemplar that can’t be flashed (comment #1).
I will update this post if I find other problems in the problematic modules that were given to me.
Kind regards,
Tanguy
Also, you can try to share the uart log from current module on devkit too. The log from comment #1 sounds like a bug from custom board but not devkit, right?
Indeed, logs from comment #1 were from a custom board. I did reflash on devkit and got the UART logs and they seem to be the same:
[0193.282] I> Welcome to MB2(TBoot-BPMP) Recovery(version: 01.00.160913-t186-M-00.00-mobile-2814ffb8)
[0193.291] I> Boot-device: eMMC
[0193.510] I> sdmmc DDR50 mode
[0193.514] I> sdmmc bdev is already initialized
[0193.518] I> pmic: reset reason (nverc) : 0x40
[0193.525] I> Found 18 partitions in SDMMC_BOOT (instance 3)
Then I think this module can go to RMA.