My thanks to all concerned for your help. I’ll contact support to arrange RMA. At least I learnt a little about how these boards get up and going.
Hello to all.
This thread is a bit old, but I hope someone has found the reason for this problem, and a potential fix.
I have a Jetson TK1 Development board, and it has now failed with the exact problem described in this post.
The bootloader is successfully sent to the board, along with the system image and all other files. However, when it comes time for the board to reboot, it just sits there. Manually rebooting does nothing, as no input or output is accepted. The only thing I can do at this point is put the board back on recovery mode and retry the JetPack install - unsuccessfully.
The actual installation was run on a full install of 64-bit Ubuntu 14.04 as required by JetPack. No virtual machines were involved in the process. Also, all options were defaulted directly from JetPack, without any external modifications to configuration or any other files. Different USB cables do nothing to remedy the problem; the original cable included in the box was used in the first place, and only after the problem existed did I try different cables of shorter lengths.
Unfortunately, I am unable to RMA this board, as my previous board had already been RMA’d with the EXACT SAME ISSUE. The strangest part is that in both cases the problem happened when upgrading to a newer version of JetPack released by Nvidia.
Is this an issue with the eMMC, memory or other hardware external to the JTK1 SoC? Has anyone found a way to revive these failed boards?
Thank you for your help.
Do you have serial console set up? This is the easiest way to see what goes on because it works even in the boot loader stage and regardless of whether most of the software functions or not. If you do, the settings are 115200 8N1 (you can use CTS/DTS flow control, or software flow control).
I’m thinking perhaps the board and flash were working, but video is not (having video not configured is common…getting to the point in flash you made it to and not actually running is uncommon). Along those lines can you check your router logs (or host logs if host is acting as a router) and see if an address was requested? If so, then you may be able to ssh in.
Note that you can test eMMC by cloning it (this takes a very long time if you include the root partition, but something small like partition table is very fast). See:
[url]http://elinux.org/Jetson/Cloning[/url]
Thank you for your help. I apologize for the long delay on my side.
I have finally been able to connect to my Jetson TK1 through the serial console, and the resulting output has me puzzled. Here is the output using “minicom” on Ubuntu Linux 14.04:
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Jan 1 2014, 17:13:19.
Port /dev/ttyUSB0, 21:55:49
Press CTRL-A Z for help on special keys
U-Boot SPL 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)
No matter how long I leave the board connected for, no other output message is seen.
However, upon attempting to clone the eMMC as you requested, I see a similar error as Bob4xv. From a linux console I issued the command:
sudo ./nvflash --getpartitiontable table --bl ardbeg/fastboot.bin --go
With the resulting printout being:
Nvflash 4.13.0000 started
BR_CID: 0x34001001740db0c20000000005008480
rcm version 0X400001
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x00000001740db0c20000000005008480
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: ardbeg/fastboot.bin
- 594363/594363 bytes sent
ardbeg/fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader failed NvError 0x0
command failure/warning: bootloader download failed (bad data)
bootloader status: device failure (code: 2) message: flags: 0
Meanwhile, on the serial console through minicom the output reads:
[0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.004] Reset reason: power on reset
[0000.008] Processing in recovery mode
[0000.011] Established communication link with host
[0001.162] No Battery Present
[0001.166] Sdram initialization is successful
[0001.360] Downloaded bootloader successfully
[0001.364] CPU-bootloader entry address: 0x83d88000
[0001.369] BoardId: 375
[0001.371] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0001.376] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0001.381] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0001.387] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0001.392] Platform-DebugCarveout: 0
[0001.428] NvTbootI2cWrite(): error code 0x00045005 Error while starting write transaction
[0001.436] NvTbootI2cDeviceWrite(): error code 0x00045001 Error while writing
[0001.442] NvTbootI2c: Read failed for slave 0x80, offset 0x00 with error code 0x00045001
[0001.450] FAILURE in NvTbootConfigureCpu
[0001.454] Error is 45001
Instead of Bob4xv’s “45100” (I2c slave not started) error, I see “45005” (Master not able to get the control of bus) at the first “NvTbootI2cWrite()”.
To test a bit further, I decided to try it with a SD card attached. The output on the serial console after issuing the same NVFLASH command shown above is:
0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.004] Reset reason: power on reset
[0000.007] Processing in recovery mode
[0000.011] Established communication link with host
[0001.156] No Battery Present
[0001.159] Sdram initialization is successful
[0001.341] Downloaded bootloader successfully
[0001.345] CPU-bootloader entry address: 0x83d88000
[0001.350] BoardId: 375
[0001.352] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0001.357] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0001.362] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0001.367] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0001.373] Platform-DebugCarveout: 0
[0001.575] NvTbootI2cClearBus(): error code 0x00000005 Bus clear timeout
[0001.582] NvTbootI2cDeviceWrite(): error code 0x00000005 I2c Open Failed
[0001.588] NvTbootI2c: Read failed for slave 0x80, offset 0x00 with error code 0x00000005
[0001.596] FAILURE in NvTbootConfigureCpu
[0001.599] Error is 5
This time, the “NvTbootI2cClearBus()” times out with error “00005” (not completed in the expected time) error, as does the “NvTbootI2cDeviceWrite()” command.
Is there anything I can do to bring this board back to an operational state?
I hate to say it, but unless there is a host issue from something like running on a VM, that’s fairly solid evidence of a hardware failure. NvTboot is a part of booting which occurs prior to the boot loader, and I believe this is also required to bootstrap the flash process itself. Someone correct me if I’m wrong, but I think with NvTboot gone recovery mode can’t succeed in flashing.