Hi everyone, sorry about my english.
I’ve just bought two new Jetsons boards, when I tried flash one of them I had an error on nvflash executing. I’ve tried flash 3 times and nothing changed, the error appears on command 26, it happened using different versions of Linux for Tegra (19.3 an 21.3) and different parameters on flash.sh
./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: 0x34001001740de0c9000000000d060240
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: 0x00000001740de0c9000000000d060240
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
- 57167/57167 bytes sent
tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
odm data: 0x6009c000
downloading bootloader – load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
ML execution and Cpu Handover took 1 Secs
Partition backup took 0 Secs
setting device: 2 3
deleting device partitions
creating partition: BCT
creating partition: PPT
creating partition: PT
creating partition: EBT
creating partition: LNX
creating partition: SOS
creating partition: NVC
creating partition: MPB
creating partition: MBP
creating partition: GP1
creating partition: APP
creating partition: DTB
creating partition: EFI
creating partition: USP
creating partition: TP1
creating partition: TP2
creating partition: TP3
creating partition: WB0
creating partition: UDA
creating partition: GPT
sending file: ppt.img
\ 2097152/2097152 bytes sent
ppt.img sent successfully
padded 8 bytes to bootloader
sending file: u-boot.bin
- 439872/439872 bytes sent
u-boot.bin sent successfully
sending file: system.img
/ 2369167788/2369167788 bytes sent
system.img sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
- 57167/57167 bytes sent
tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
sending file: gpt.img
\ 2097152/2097152 bytes sent
gpt.img sent successfully
Create, format and download took 190 Secs
failed executing command 26 NvError 0x120002
command failure/warning: sync failed (bad data)
bootloader status: Bct Write Failed (code: 22) message: nverror:0x40005 (0x140005) Sync 5550 flags: 0
Failed flashing ardbeg.
Any ideias?
Thanks
What was your command line? Did you unpack sample rootfs with sudo or as root? Was the supplied USB micro-B cable used? Run “ls -l” on “bootloader/system.img*” and show their sizes here. For my flash with R21.4 at “sudo flash.sh -S 14580MiB jetson-tk1 mmcblk0p1” I get:
-rwxr-xr-x. 1 root root 3052098420 Jul 15 16:01 system.img*
-rw-r--r--. 1 root root 15288238080 Aug 11 11:44 system.img.raw
I have tried two command lines
flash.sh jetson-tk1 mmcblk0p1
and with size
flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
I unpacked sample rootfs with sudo. Yes, I tried 3 different USB micro-B cables, all of them was supplied with Jetson and the output of ls -l is
-rwxr-xr-x 1 root root 2369102708 Ago 16 15:47 system.img
-rw-r–r-- 1 root root 15032385536 Ago 16 15:46 system.img.raw
Sorry for not giving enough information
What host are you using, e.g., Ubuntu and version? Is there anything special about the host, e.g., running on a VM?
It is Ubuntu 14.04.2 LTS 64 bits and it’s not a VM, and there isn’t nothing different with the host. I’ve installed L4T in an old Jetson in this same host and everything worked out.
One of the options for flash.sh is to re-use the old system.img using “-r” option. So if you successfully flash one Jetson, the leftover “bootloader/system.img*” can be used to exactly clone as many Jetson’s as you want. The fact that you have more than one Jetson gives you an opportunity, provided you don’t mind flashing the second Jetson as well.
To test, flash the working Jetson via something like:
sudo flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
Then, after you verify the first Jetson works, flash the second one using the exact same image (but using “-r” to re-use the system.img):
sudo flash.sh -S 14580MiB -r jetson-tk1 mmcblk0p1
I’m not actually sure if the “-S 14580MiB” needs repeating, but it shouldn’t hurt and might help. Use the same cabling and anything connected to the working Jetson should be connected on the second Jetson in exactly the same way (changing peripherals can change results).
Unfortunately, the “NvError 0x120002” is somewhat generic, and so it could be any number of issues…this should narrow it down to hardware versus software.
If you’re interested in cloning your other Jetson before using it for test flash, see this:
http://elinux.org/Jetson/Cloning
NOTE: Restoring from a clone of the working Jetson into the non-working Jetson would also be a good test.
It didn’t work, I did the clone of eMMC and tried to make a restore, but the same error appeared. So I downloaded the new version of L4T (21.4 which You are using), but the bugs remained. I think that can be something wrong with the boards (the other board keep turning on with recovery mode, I can not even flash it correctly). Do you have any idea? Should I send the boards to guaranty?
It sounds as though the host and install process have been verified as correct. At this point maybe the RMA people have something to test, but likely it is a hardware return. Check for RMA procedure near the top of this:
[url]https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/[/url]
Ok, Thanks a lot for help.