command failure/warning: bootloader download failed (bad data)
Having trouble with booting the Tegra K1. All voltages and clocks to the Tegra have been verified.
Custom tegra configuration:
Hardware:
eMMC: EMMC16G-S100
DDR3L: MT41K256M16HA-125
GPU: Tegra K1 CD570M
./nvflash --bct Micron_2GB_MT41K256M16HA_792MHz_0408.cfg --setbct --configfile flash.cfg --create --bl u-boot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x3400100174114103180000000a000480
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x0000000174114103180000000a000480
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
BCT sent successfully
sending file: tegra124-tk1-som.dtb
data send failed NvError 0x120002
sending dtbfile failed NvError 0x0
command failure/warning: bootloader download failed (bad data)
bootloader status: BCT is invalid or corrupted or SDRAM params may be wrong (code: 12) message: DownloadFile 1130 flags: 0
I’m uncertain what custom changes might do, but here is a reference to the nvflash error codes:
https://devtalk.nvidia.com/default/topic/831539/embedded-systems/now-unable-to-flash-jetson-tk1/post/4528073/#4528073
Within this:
0x00120002, "packet was nacked")
The comment for that block of error codes:
/* nv3p error codes */
I have limited knowledge of the 3p server, but it seems to be the initial recovery mode software required to provide access to other parts of the hardware (like a micro O/S for minimal bare metal access). On Jetson, even when using u-boot, the actual software used for this is fastboot (which is why there are comments during flash of fastboot even though u-boot is chosen).
Was nvflash called through flash.sh? This typically names fastboot during 3p option arguments.
Hi rskelton,
There are few things that you should try. First, it seems your hw config is different than mine as the bct and dtb file you are using are different and created by you, so please make sure they are correct.
Now, Can you try to flash with default script like this :-
./flash.sh jetson-tk1 mmcblk0p1
The flash command I get with this is :–
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
note that --bl should be specified with fastboot.bin
as both fastboot.bin and u-boot.bin are needed for u-boot.
Seem i have the same problem. Image is down, but 2nd part, writing the boot loader failed.
admin123@ubuntu:~/JetPackTK1-1.2/Linux_for_Tegra/bootloader$ sudo ./nvflash --rawdevicewrite 0 3849216 all.img --bl ardbeg/fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x340010017410b10000000000020285c0
rcm version 0X400001
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x000000017410b10000000000020285c0
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
download command failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
Tried many options - always the same result. Any idea ???
After this trial i tried a 2´nd one:
admin123@ubuntu:~/JetPackTK1-1.2/Linux_for_Tegra/bootloader$ sudo ./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x00000003000000020000000500000001
and hangs for ever … (until rest key pressed)
One thing that is important…if a flash was attempted…success or fail…then you must restart Jetson in recovery mode between every attempt. So the first question is if you completely restarted recovery mode each attempt?
yes of course. is only running once a time, 2nd time crashing.
So, anywhere i’ve seen, that NVRAM may(must?) set to read/write using special keystrokes
on a connected keyboard ???
Thats on the debug output (serial). Wondering, that the serial interface
are not allowed to perform some commands to the jetson …
.......[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.152] Unsupported Platform 0xffff
[0001.155] populate platform details failed with error 0x2 in DownloadBootloader func at 887 line
[0001.164] Downloading Bootloader failed with 0x2
[0001.168] Download Bootloader failed with error 0x2 in NvTbootServer func at 1386 line
[0001.176] Error is 2
I see it is a flash of an entire device via a clone image. What is the exact size of all.img?
For reference, here’s a continuation of what the log should look like from slightly before the error you had to completion:
RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: ../Linux_for_Tegra/bootloader/ardbeg/fastboot.bin
- 594363/594363 bytes sent
../Linux_for_Tegra/bootloader/ardbeg/fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
sending file: all_21-4_Sat-05-Sep-2015_12-09-03.img
/ 15766388736/15766388736 bytes sent
all_21-4_Sat-05-Sep-2015_12-09-03.img sent successfully
Time taken for flashing 1588 Secs
It’s probably a bad idea to try to run anything via serial console during this time, other than monitoring. For reference, my log of this differs from yours, and starts like this:
[0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.003] Reset reason: power on reset
[0000.007] Processing in recovery mode
[0000.010] Established communication link with host
[0001.143] No Battery Present
[0001.147] Sdram initialization is successful
[0001.253] Downloaded bootloader successfully
[0001.257] CPU-bootloader entry address: 0x83d88000
[0001.262] BoardId: 375
Note that the board I’m using shows BoardId of 375, which corresponds to the PM375 board surrounding Jetson. In your case the response is “Unsupported Platform 0xffff”. Is this board at all custom, or was the all.img cloned from something “not usual” for a Jetson? (the logs I show above are L4T R21.4)
@DressOla
Are you try this on Jetson TK1 PM375 board or your designed board ?
If you debug on your designed board.
1> Config the board ID information in boot loader as the board ID eeprom is empty.
2> The BCT file may be a issue if the memory part number is different with Jetson design.
i tryed it on a new nvidia TK1 board. There is no hdmi out, and i’m a little bit confused, thats doesnt work a little bit after connecting to hdmi screen. in different to other manufacturers developer kits, there is missing a quick start that works out of the box… because also missing some status led . i ordered two boards, so ll see whats doing the other one. The also ordered Android TV is also not booting …"
Is this specifically a Jetson? Board ID would need adjustment if not…the ID of 0xffff on a Jetson would probably mean hardware failure. In other cases it would mean other hardware based on Tegra K1.
SO there may be something wrong whit Jetson TK1 quality. i put the 1th board into the garbage and ordered
2 more : same issue : one running well, the other case the same problem. NvError 0x120002
Isn that easy to change the board based on the board ID ? Here is the BR_CID 0x340010017410b1022000000015fd0400
I don’t know about changing board ID, I assume you mean changing the “0” back to “375” on standard JTK1. Possibly you can change this in u-boot environment, but I’m not sure of how. It would still be useful to know if one of the failed boards is able to run u-boot (you’d only see this from serial console). Once a board fails, can it still get to u-boot? If the board can get to u-boot via serial console, can you paste the output of “bdinfo” and “printenv”?
Many boards failing this way seems odd since this is otherwise a fairly rare failure. The NvError itself for “data send failed NvError 0x120002” seems that it can occur if there are issues with the flash software itself. The 3pserver in the TK1 must essentially be booted by fastboot.bin from the flash software even when using u-boot for the post flash environment. So fastboot.bin being wrong would be an issue as well, although I would not expect failure to be at the board ID step. Just to compare, my L4T R21.4 bootloader subdirectory fastboot.bin has a sha1sum of:
f9a26ceba70e438aa85addebb4e04ce7a335c9d5
Although I know this is very unlikely, there is a tiny possibility of power issues getting in the way. During flash brownouts and power spikes which would otherwise be more or less a non-issue during normal operation would be magnified and become a problem. Of the failed flashes, are they using different power supplies? Power regulation should take care of many issues, but I’m curious if there is one power supply in common to all of the failed flashes.
I encountered the same problem.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_H5TC4G63CFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x340010017410c1062000000005fd0180
Rcm version 0X400001
Skipping boardID read at miniloader level
System Information:
Chip name: unknown
Chip id: 0x40 major: 1 minor: 1
Chip sku: 0x0
Chip uid: 0x000000017410c1062000000005fd0180
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
BCT sent successfully
Sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
- 59661/59661 bytes sent
Tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
Odm data: 0x6009c000
Downloading bootloader - load address: 0x83d88000 entry point: 0x83d88000
Download command failed NvError 0x120002
Command failure / warning: bootloader download failed (bad data)
Is your problem solved? I designed the TK1 board myself.
This is most likely a problem of the host. Packet was NAKed most often implies a USB communications error which is rare for a standard host and occurs often with a VM host. Is your host a VM, or is there anything unusual about the host?
I use the host. The operating system version is ubuntu 14.04 x64, connected to the USB 2.0 port. I follow the instructions provided by NVIDIA. I have recompiled all the files and still have this error. I designed the circuit board and the reference design is the same, but the size has changed.
Not VM, only ubuntu 14.04.
I refer to the document is:PM375_D10_OrCAD_schematics.pdf
The packet NAK error is basically a communications error (extreme likelihood of USB issues). Normally a VM is where you would see this (apparently they need a bigger buffer to handle smooth flow of data). I don’t know how the OrCAD schematic would be involved unless your design changed something on USB. If you have a USB HUB in the middle you might try a different HUB (if you don’t use a HUB you might try adding a HUB); if you have a different cable, then you might try a different USB cable. Typically the cable supplied with a Jetson TK1 does the job quite well, but if you have a custom board then perhaps you have a different USB cable. Experiment with how the USB connects the TK1 and the host.