Jetson Tk1 - issue with re-flashing the board and the mkgpt binary

I tried to run the flash.sh script on both armel and i386 Ubuntu 12.04 linux:
Currently I get the folowing result:

creating gpt(ppt.img)… ./flash.sh: line 994: ./mkgpt: cannot execute binary file

  • The file mkgpt is there and has execution rights.

What am I doing wrong ?

A silly question: Are you using “sudo” or running as root to do this? It may be required.

I just repeated untaring/flashing all on an i386 box with local storage and everything works fine.

I also tried to run the flash.sh script on the last version Linux for Tegra and I see
creating gpt(ppt.img)… ./flash.sh: line 994: ./mkgpt: cannot execute binary file: Exec format error creating gpt(ppt.img) failed. running us root

mkgpt must run on x86. Was this run from a standard Intel-format desktop linux?

Hello,

I am having the same issue with creating gpt(ppt.img) failing. I’m running on a host system Ubuntu 14.04 x86-64bit, just installed the Jetpack tooling which fails when trying to flash the target. I’ve also tried to run the flash.sh from the command line but it has the same failure.

I can see that under the Linux_for_Tegra folder the binary mkgpt is there. I also see there is a file ppt.img present. I don’t yet fully understand the whole build flow, any idea why this file is failing to build, or does it build but not build correctly?

Thanks for any replies,
–bruce

Error messages would help, as well as knowing which L4T version. The gist of the most common problems in such cases would be either permissions failed because of not using sudo (root authority) during unpacking rootfs and flash, followed by failure to get a loopback device during creation of the img files.

Which L4T version? Did you unpack rootfs with sudo or root? Is your host a regular linux install, or a VM (relates to file permissions)? What was your actual flash command? Are there some specific error lines from the flash output?

Thanks for the fast reply. Here is additional information.

I installed the toolchain as root, not sudo but root. The host is a stand alone Ubuntu 14.04 64bit workstation, not a vm. I am running the L4T version r21.4, it was installed as part of the Jetpack 1.2 (L4T r21.4). I will also note that I had to download all the Jetpack packages manually, all their sha1sum values were wrong if the installer downloaded them. I noted that others had this same issue. I don’t assume this is related since after I manually got the packages the install went fine.

I deleted the ppt.img file that was there and ran the flash command again:
./flash.sh -k 6 jetson-tk1 mmcblk0p1

This time I get the following errors:

copying flasher(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Existing flashapp(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/nvflash) reused.
*** Updating 6:LNX with boot.img ***
./nvflash --download 6 boot.img  --bl fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x340010017408c1431c0000000fff0280
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x000000017408c1431c0000000fff0280
   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)
bootloader status: Sdram Initialization failed (code: 32) message: nverror:0x3 (0x3) DownloadBootloader 910 flags: 0

Failed to flash ardbeg.

Is there additional information I can provide?

–bruce

This is very curious, there should not have been checksum errors from any downloads regardless of manual download or JetPack download.

A second curiosity is that recently someone with some custom hardware saw the 0x120002 “packet was nacked” issue as well (see https://devtalk.nvidia.com/default/topic/831539/embedded-systems/now-unable-to-flash-jetson-tk1/post/4528073/#4528073).

I just flashed without error. Here is the point where failure occurs on yours:

downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
download command failed NvError 0x120002

Here is what those lines should show:

downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin

Here is what my command line was:

flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

It’s perhaps important to know that the default boot loader in all recent L4T versions is u-boot. Despite this, fastboot.bin is still used during flash because it runs part of the recovery mode setup (fastboot.bin is not installed, but is still used for recovery mode even when u-boot is the boot loader choice). Although there is not enough information yet to make any conclusions, I’m wondering what your command line was because some options change the software used for recovery mode and the missing information concerns this point during the flash.

What was your exact command line? Within your Linux_for_Tegra flash directory is subdirectory boot loader. There should always be “bootloader/ardbeg/fastboot.bin”. Depending on flash parameters, a copy of some files (including fastboot.bin) would be placed at “bootloader/fastboot.bin” (versus “bootloader/ardbeg/fastboot.bin”). Do you see both “bootloader/fastboot.bin” and “bootloader/ardbeg/fastboot.bin”?

I read that others experienced this Jetpack installation issue, it actually what gave me the idea to manually download the packages. It was posted in the forum.

I’m using the TK1 eval board, nothing custom.

The flash command I used is:

./flash.sh -k 6 jetson-tk1 mmcblk0p1

Yes, the directory Linux_for_Tegra/bootloader exists. There is a copy of fastboot.bin under both /bootloader and /bootloader/ardbeg.

Also, I also deleted the file *.img under the bootloader directory and ran the flash.sh command again. This time it has been hanging for about 20 minutes at:

copying flasher(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Existing flashapp(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/nvflash) reused.
*** Updating 6:LNX with boot.img ***
./nvflash --download 6 boot.img  --bl fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x00000003000000020000000500000001

I read it can take some time to flash, is it possible some went wrong due to deleting those files. I assumed that would be similar to a clean build at that point.

thanks,
–bruce

This is the reason for failure, the “-k 6” option. When using fastboot it is necessary to name a partition for kernel placement, but when using u-boot kernels just go in the /boot directory. U-boot is the default. Remove the “-k 6” argument and it should work. If you want maximum file system size, add “-S 14580MiB”.

I ran the flash command as you described:

./flash.sh jetson-tk1 mmcblk0p1

The flash failed with the following output/errors:

copying bctfile(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg)... done.
copying bootloader(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)... done.
	populating kernel to rootfs... done.
	populating jetson-tk1_extlinux.conf.emmc to rootfs... done.
done.
Making system.img... 
	populating rootfs from /opt/JetPackTK1-1.1/Linux_for_Tegra/rootfs ... done.
	Sync'ing system.img ... done.
	Converting RAW image to Sparse image... 

---- Raw to Sparse Image Converter v1.0 ----------------------------

...

-- Total: -----------------------------------------------------------
1754 CHUNK 15032385536(3670016 blks) ==>  2369081940(578384 blks)

done.
system.img built successfully. 
copying dtbfile(/opt/JetPackTK1-1.1/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)... done.
copying cfgfile(/opt/JetPackTK1-1.1/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg... done.
creating gpt(ppt.img)... 

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag --- GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[     BCT] BH            0        16383       8.0MiB 
[     PPT] UH            0         4095       2.0MiB ppt.img
[      PT] UH         4096         8191       2.0MiB 
[     EBT] UH         8192        16383       4.0MiB u-boot.bin
[     LNX] UH        16384        49151      16.0MiB 
[     SOS] UH        49152        61439       6.0MiB 
[     NVC] UH        61440        65535       2.0MiB 
[     MPB] UH        65536        77823       6.0MiB 
[     MBP] UH        77824        90111       6.0MiB 
[     GP1] UH        90112        94207       2.0MiB 
[     APP] UV        94208     29454335   14336.0MiB system.img
[     DTB] UV     29454336     29462527       4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[     EFI] UV     29462528     29593599      64.0MiB 
[     USP] UV     29593600     29601791       4.0MiB 
[     TP1] UV     29601792     29609983       4.0MiB 
[     TP2] UV     29609984     29618175       4.0MiB 
[     TP3] UV     29618176     29626367       4.0MiB 
[     WB0] UV     29626368     29630463       2.0MiB 
[     UDA] UV     29630464     30773247     558.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
creating gpt(ppt.img) failed.

Do you have any additional insight or suggestions? At this point it would be nice to just recover the card to a working state.

thanks,
–bruce

I would try with the -S 14580MiB:

sudo flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

I would also want to know for certain you have enough disk space on the host, as flash takes a lot of disk (e.g., df -H).

Before you try flash, make sure that your host’s “/dev/loop0” exists. The script should have created this if it were missing, but only if sudo or root runs the flash (on some systems this will erase itself after a reboot and the script will recreate it…as root you can be sure with “losetup --find”).

You may want to also completely remove your “Linux_for_Tegra” host directory and recreate it. Be certain that when you unpack the sample rootfs to use root or sudo. Then apply_binaries.sh making sure again that you use root or sudo. Then of course actual flash using root or sudo.

I’m also still suspicious of earlier corrupt downloads under JetPack…here’s the R21.4 sha1sum I see from individual manual package download:

15da784ef2b6c6f4e5f1921257e83ee922cfd8bb  Tegra124_Linux_R21.4.0_armhf.tbz2
edaabb28d70c38c185e379c6277c7d8e6a04f7e6  Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2

…these match the release_sha_hashes.txt from the R21.4 page.

I verified I have plenty of room on the disk and the loop0 exists. Since there was a newer build of the Jetpack (1-1.2) I downloaded it, uninstalled my previous version 1-1.1. I have the issue with the Jetpack installer getting wrong sha1sum. The post I mentioned where others had tis issue is:

https://devtalk.nvidia.com/default/topic/793925/jetpack-download-page-not-found-repeats-downloading-driver-packages/

It’s a time consuming fix to cancel each file download, grab the url of the file, then paste it into a browser to download it. Is there a list of the url of all the files necessary so I can just wget them in a terminal?

I created a thread with the url links for anyone else that needs them:

https://devtalk.nvidia.com/default/topic/856487/embedded-systems/jetpack-installer-downloaded-files-fail-sha1sum/

I installed the latest JetPackTK1-1.2 and am at the same initial problem of not finding the ppt.img file. Since this is way off topic of the original thread, I will open a new thread for this issue.

thanks,

Keep in mind my references are all to R21.4. One thing I’d suggest is copy your original flash.sh to some name in the same directory like “alt_flash.sh”. Then edit this file, looking for “mkgpt” (line 939). See what the options are, add this new line just prior to mkgpt:

echo -e "\nExecuting mkgpt options \"${MKGPTOPTS}\"\n";

Then try flashing R21.4 again. Copy and save the options listed by this output. You may wish to log via something like:

sudo alt_flash.sh -S 14580MiB jetson-tk1 mmcblk0p1 2>&1 | tee flash_log.txt

Regardless of whether flash succeeds or not, the files generated for the flash should remain, e.g., bootloader/flash.cfg will remain; it should be possible then to manually run mkgpt with those options and see what the actual mkgpt is finding in error.

Some progress on why the script if failing at mkgpt. I was able to run the mkgpt binary with the arguments that flash.sh generated. After running the mkgpt I queried the return code and it was non zero. The flash.sh script errors out if the return code is non zero. I get a value of 255:

root@485006-mitll:/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader# ./mkgpt -c flash.cfg -P ppt.img -t 15766388736 -b 8388608 -s 4KiB -a GPT -v GP1 -V

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag --- GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[     BCT] BH            0        16383       8.0MiB 
[     PPT] UH            0         4095       2.0MiB ppt.img
[      PT] UH         4096         8191       2.0MiB 
[     EBT] UH         8192        16383       4.0MiB u-boot.bin
[     LNX] UH        16384        49151      16.0MiB 
[     SOS] UH        49152        61439       6.0MiB 
[     NVC] UH        61440        65535       2.0MiB 
[     MPB] UH        65536        77823       6.0MiB 
[     MBP] UH        77824        90111       6.0MiB 
[     GP1] UH        90112        94207       2.0MiB 
[     APP] UV        94208     29954047   14580.0MiB system.img
[     DTB] UV     29954048     29962239       4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[     EFI] UV     29962240     30093311      64.0MiB 
[     USP] UV     30093312     30101503       4.0MiB 
[     TP1] UV     30101504     30109695       4.0MiB 
[     TP2] UV     30109696     30117887       4.0MiB 
[     TP3] UV     30117888     30126079       4.0MiB 
[     WB0] UV     30126080     30130175       2.0MiB 
[     UDA] UV     30130176     30773247     314.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
root@485006-mitll:/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader# echo $?
255

Any insight into this?

I deleted the entire L4T directory, untared it fresh, copied in the rootfs, ran the apply_binaries.sh. Running the flash.sh script actually makes it through and starts to flash. I get output on the serial port console showing the flash progress. It dies at the point it is looking for the ppt.img file. Not sure why the different behavior if running the flash.sh script in a fresh L4T verses one that has already been built in, but something is different.

This is the output form the terminal where flash.sh is run and the serial port output:

terminal

./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1 2>&1 | tee flash_log.txt
copying bctfile(/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg)... done.
copying bootloader(/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)... done.
	populating kernel to rootfs... done.
	populating jetson-tk1_extlinux.conf.emmc to rootfs... done.
done.
Making system.img... 
	populating rootfs from /opt/JetPackTK1-1.2/Linux_for_Tegra/rootfs ... done.
	Sync'ing system.img ... done.
	Converting RAW image to Sparse image... 

---- Raw to Sparse Image Converter v1.0 ----------------------------

   ...

-- Total: -----------------------------------------------------------
1742 CHUNK 15288238080(3732480 blks) ==>  2372383172(579190 blks)

done.
system.img built successfully. 
copying dtbfile(/opt/JetPackTK1-1.2/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)... done.
copying cfgfile(/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg... done.
creating gpt(ppt.img)... 

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag --- GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[     BCT] BH            0        16383       8.0MiB 
[     PPT] UH            0         4095       2.0MiB ppt.img
[      PT] UH         4096         8191       2.0MiB 
[     EBT] UH         8192        16383       4.0MiB u-boot.bin
[     LNX] UH        16384        49151      16.0MiB 
[     SOS] UH        49152        61439       6.0MiB 
[     NVC] UH        61440        65535       2.0MiB 
[     MPB] UH        65536        77823       6.0MiB 
[     MBP] UH        77824        90111       6.0MiB 
[     GP1] UH        90112        94207       2.0MiB 
[     APP] UV        94208     29954047   14580.0MiB system.img
[     DTB] UV     29954048     29962239       4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[     EFI] UV     29962240     30093311      64.0MiB 
[     USP] UV     30093312     30101503       4.0MiB 
[     TP1] UV     30101504     30109695       4.0MiB 
[     TP2] UV     30109696     30117887       4.0MiB 
[     TP3] UV     30117888     30126079       4.0MiB 
[     WB0] UV     30126080     30130175       2.0MiB 
[     UDA] UV     30130176     30773247     314.0MiB 
[     GPT] UH     30773248     30777343       2.0MiB gpt.img
copying flasher(/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)... done.
Existing flashapp(/opt/JetPackTK1-1.2/Linux_for_Tegra/bootloader/nvflash) reused.
*** Flashing target device started. ***
./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: 0x340010017408c1431c0000000fff0280
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: 0x000000017408c1431c0000000fff0280
   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

- 59637/59637 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
file not found: ppt.img
failed executing command 2147483647 NvError 0x4
command failure/warning: create failed 
Failed flashing ardbeg.

serial port console:

[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.134] Downloaded bct successfully 
[0001.139] No Battery Present
[0001.142] Sdram initialization is successful 
[0001.154] Downloaded DTB successfully 
[0001.180] No Battery Present
[0001.250] Downloaded bootloader successfully 
[0001.254] CPU-bootloader entry address: 0x83d88000 
[0001.259] BoardId: 375
[0001.261] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0001.266] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0001.271] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0001.276] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0001.281] Platform-DebugCarveout: 0
[0001.309] CPU power rail is up 
[0001.311] Performing RAM repair
[0001.314] CPU clock init successful 
[0001.318] Starting CPU & Halting co-processor
NVRM Initialized shmoo database
NVRM CLOCKS: PLLX0:      696000 Khz
NVRM CLOCKS: PLLM0:      924000 Khz
NVRM CLOCKS: PLLC0:      0 Khz
NVRM CLOCKS: PLLP0:      408000 Khz
NVRM CLOCKS: PLLA0:      11289 Khz
NVRM CLOCKS: CPU:        696000 Khz
NVRM CLOCKS: AVP:        48000 Khz
NVRM CLOCKS: System Bus: 48000 Khz
NVRM CLOCKS: Memory Controller: 924000
NVRM CLOCKS: External Memory Controller: 924000
EEPROM instance-5: No slave at this instance.
EEPROM instance-0: No slave at this instance.
EEPROM instance-0: Querying board info from BCT.
EEPROM instance-0: No board info available for this instance in BCT.
EEPROM instance-1: No slave at this instance.
EEPROM instance-1: Querying board info from BCT.
EEPROM instance-1: Board info present in BCT is invalid.
EEPROM instance-2: No slave at this instance.
EEPROM instance-2: Querying board info from BCT.
EEPROM instance-2: No board info available for this instance in BCT.
EEPROM instance-3: No slave at this instance.
EEPROM instance-3: Querying board info from BCT.
EEPROM instance-3: No board info available for this instance in BCT.
EEPROM instance-4: No slave at this instance.
EEPROM instance-4: Querying board info from BCT.
EEPROM instance-4: Board info present in BCT is invalid.
EEPROM instance-5: No slave at this instance.
EEPROM instance-5: Querying board info from BCT.
EEPROM instance-5: Board info present in BCT is invalid.
EEPROM instance-6: BoardInfo: 0x0001:0x0007:0375:0000:03:E:00:0xff:0xff:0xff:0xff:0xff:0xff
EEPROM instance-7: No slave at this instance.
EEPROM instance-7: Querying board info from BCT.
EEPROM instance-7: No board info available for this instance in BCT.
Final BoardID: proc: 375 and pmu 375
ADJUSTED CLOCKS:
MC clock is set to 924000 KHz
EMC clock is set to 924000 KHz (DDR clock is at 924000 KHz)
PLLX0 clock is set to 696000 KHz
PLLC0 clock is set to      0 KHz
CPU clock is set to 696000 KHz
System and AVP clock is set to  48000 KHz
GraphicsHost clock is set to 163200 KHz
MSENC clock is set to  92400 KHz
Vde clock is set to 204000 KHz

Bootloader-Cpu Init at (time stamp): -1548319613 us

Pinmux changes applied in kernel way

[bootloader] (version UNDEF_BUILD)
Platform Pre Boot configuration...
NvDdkUsbhBlockDevInit..
Initializing Display
The proc BoardInfo: 0x0177:0x0000:0x03:0x45:0x00
The proc BoardInfo: 0x0177:0x0000:0x03:0x45:0x00
This Pmu Module is not present.
The best display mode is 2560x1600/60Hz, pclk: 268627Khz

DSI PAD calibration done

DSI PAD calibration done

DSI PAD calibration done

DSI PAD calibration done
Entering NvFlash recovery mode / Nv3p Server

Nv3pServer Version 4.13.0000

***: DecodeCSD:
   : readBlkBits=9, readBlkSize=512 Bytes
   : nSectors=(CSIZE+1)*(2**(CSizeMult+2))=4096 * 512 = 2097152 Sectors
   : writeBlkBits=9, writeBlkSize=512 Bytes
   : ERASE_GRP_SIZE=31, ERASE_GRP_MULT=31
   : EraseGrpSize=(31+1)*(31+1)=1024 Sectors (524288 Bytes)
   : WPGrpSize=31744 Sectors (16252928 Bytes)
***: ReadExtCSD:
   : overriding USER Sectors = 30777344 Sectors
   : keep CSD EraseGrpSize = 1024 Sectors (524288 Bytes)
   : keep CSD WPGrpSize = 31744 wBlks (16252928 Bytes)
   : BootPartSize = 4194304 Bytes (8192 Sectors)
***: SetBlockSize to 512 Bytes SKIPPED because CMD16 is illegal for DDR50...
***: SdGetDevInfo: PagesPerBlock = 32 pages (256 Sectors)
***: SdGetDevInfo: TotSecs=TotBlk(120288)*PgPerBlk(32)*SecsPerPg(8)=30793728
Region=1 SD Erase start 512B-sector=0,512B-sector-num=8192 
Region=2 SD Erase start 512B-sector=0,512B-sector-num=8192 
Region=0 SD Erase start 512B-sector=0,512B-sector-num=30777344 
SD Alloc Partid=2, start sector=0,num=2048 
SD Alloc Partid=3, start sector=2048,num=512 
SD Alloc Partid=4, start sector=2560,num=512 
SD Alloc Partid=5, start sector=3072,num=1024 
SD Alloc Partid=6, start sector=4096,num=4096 
SD Alloc Partid=7, start sector=8192,num=1536 
SD Alloc Partid=8, start sector=9728,num=512 
SD Alloc Partid=9, start sector=10240,num=1536 
SD Alloc Partid=10, start sector=11776,num=1536 
SD Alloc Partid=11, start sector=13312,num=512 
SD Alloc Partid=12, start sector=13824,num=3732480 
SD Alloc Partid=13, start sector=3746304,num=1024 
SD Alloc Partid=14, start sector=3747328,num=16384 
SD Alloc Partid=15, start sector=3763712,num=1024 
SD Alloc Partid=16, start sector=3764736,num=1024 
SD Alloc Partid=17, start sector=3765760,num=1024 
SD Alloc Partid=18, start sector=3766784,num=1024 
SD Alloc Partid=19, start sector=3767808,num=512 
SD Alloc Partid=20, start sector=3768320,num=80384 
SD Alloc Partid=21, start sector=3848704,num=512 
Region=0 SD Erase start 512B-sector=4096,512B-sector-num=4096

I can verify that your system (which fails mkgpt) and mine are using the exact same mkgpt options. I can also verify that if I run the mkgpt command manually with those parameters that I get a success return value of 0x0. Because the mkgpt command is running only on the host and creating images in the bootloader subdirectory without ever touching Jetson, we know it is a host issue.

I’ve found most odd issues like this are tied to permission or loopback issues; however, I do not believe loopback is involved with any of the mkgpt command, so it is back to more traditional issues like permissions or disk space. In this case flash.cfg is an input that could conceivably fail, but we executed flash.sh with the same command line and I believe this is fine (thus we should both be using the same flash.cfg).

So something which caught my eye which otherwise probably wouldn’t be considered is where you said:
get output on the serial port console showing the flash progress

The reason this may matter is that normally having the serial port connector present during flash would in no way interfere, but if you have some sort of a terminal program running (like minicom, gtkterm, so on) these programs may sometimes send data over the connection without you knowing (e.g., control characters). I’m thinking perhaps you are watching the serial console and might instead need to completely exit any program which has a possibility of touching that serial port during the flash. Having the port connected isn’t an issue, but I’m wondering if the program you use to monitor it is doing something odd. Try flashing again after completely exiting any serial console program. If this doesn’t fix it, it might be time to compare flash.cfg.

EDIT: I’m thinking more about the output of “mkgpt --help”. It does indicate something about “target device” and that it might be a loopback device, but there is no target device on the command line. Knowing what the default is when no target device is specified may be required.

Excellent reply, thanks for that. I exited minicom and retried the nvflash, same error about not finding the ppt.img. I tried to copy that file into the ardbeg folder, thinking maybe it needed to be there, and was not able to actually access the file. The ppt.img file is present, but even as root I cannot read it, copy it, or move it. I can only delete it and regenerate it with the mkgpt. the file has the right permissions, but can’t get at it for some reason.

Doing a standard file command to the ppt.img yields:

file ppt.img 
ppt.img: writable, regular file, no read permission

Suggestions?