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

Autonomous Machines Jetson & Embedded Systems Jetson TK1
21

The file “bootloader/ppt.img” is generated by mkgpt, this is the “-P ppt.img” argument. When I look at the one generated on my system, I see this for permissions and size:

-rw-r--r--. 1 root root 2097152 Jul 15 16:11 ppt.img

For the “bootloader/ppt.img” you have, what permissions and size does it have?

I’m wondering if perhaps an old file is blocking creation of a new one, although running as root should prevent that issue (unless loopback is part of the issue). If there is an existing “bootloader/ppt.img”, try deleting this before flashing again. After this it might require tracking down mkgpt source and knowing how the error occurs.

22

I was able to move the file, I somehow thought I could not in my previous post, into the ardbeg folder, then I touched the file ppt.img in /bootloader so there would be an empty file. I ran the nvflash script again and this time it completed the flashing then it rebooted the target. This is good news. I’m still not clear on what is happening with the ppt.img file and why the script can’t do the copy as it needs to into ardbeg folder.

ll ardbeg/ppt.img 
-rw-r--r-- 1 root root 2097152 Jul 15 18:18 ardbeg/ppt.img

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

At this point I have the target contentiously trying to boot from a TFTP, which is not set up. Did I miss a setting to get it to boot from the internal flash?

I think it’s very close, any additional suggestions to get this to boot again and get to a login?

–

23

The “weird” problems quite often end up being some issue with needing root authority at some earlier point in time, like during unpacking, or with loopback. Since the “bootloader/ardbeg/” files are used to generate the “bootloader/” files the ardbeg versions should remain constant, and the bootloader ones generated each time. Permissions of directories or execution are high on the list of suspects, but it’s really hard to track because for example wrong permissions may cause something strange long after the actual command that uses permissions wrong. I think for a solid answer you’d need a debug version of mkgpt and run in gdb.

I have no idea how or why it would try to boot tftp, posting logs might help.

24

I have run the entire process as root, in a root shell, not using sudo. I verified all directories/files from Linux_for_Tegra down are owned by root.

The files present in the ardbeg folder are, note that this is the ppt.img I had to manually move here:

ll bootloader/ardbeg/
total 3096
drwxr-xr-x 4 root root    4096 Jul 15 18:47 ./
drwxr-xr-x 3 root root    4096 Jul 15 18:49 ../
drwxr-xr-x 2 root root    4096 Jun 25 18:37 BCT/
drwxr-xr-x 2 root root    4096 Jun 25 18:37 cfg/
-rwxr-xr-x 1 root root  594363 Jun 25 18:37 fastboot.bin*
-rw-r--r-- 1 root root     813 Jun 25 18:37 jetson-tk1_extlinux.conf.emmc
-rw-r--r-- 1 root root     821 Jun 25 18:37 jetson-tk1_extlinux.conf.nfs
-rw-r--r-- 1 root root     796 Jun 25 18:37 jetson-tk1_extlinux.conf.sdcard
-rw-r--r-- 1 root root     787 Jun 25 18:37 jetson-tk1_extlinux.conf.usb
-rw-r--r-- 1 root root 2097152 Jul 15 18:18 ppt.img
-rw-r--r-- 1 root root  440004 Jun 25 18:37 u-boot.bin

The output from the serial console during a boot is:

U-Boot SPL 2014.10-rc2-00002-g105d2f3 (Jun 25 2015 - 15:19:50)


U-Boot 2014.10-rc2-00002-g105d2f3 (Jun 25 2015 - 15:19:50)

TEGRA124
Board: NVIDIA Jetson TK1
I2C:   ready
DRAM:  2 GiB
MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

tegra-pcie: PCI regions:
tegra-pcie:   I/O: 0x12000000-0x12010000
tegra-pcie:   non-prefetchable memory: 0x13000000-0x20000000
tegra-pcie:   prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
���Ʌ��������邽���������Ɂ�b��ͥ����b����5R�tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, ignoring
tegra-pcie: probing port 1, using 1 lanes
In:    serial
Out:   serial
Err:   serial
Net:   RTL8169#0
Warning: RTL8169#0 using MAC address from net device

Hit any key to stop autoboot:  0 
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0...
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
** No partition table - mmc 0 **
(Re)start USB...
USB0:   USB EHCI 1.10
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008c80
4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found

USB device 0: unknown device
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 155.34.64.234 (1210 ms)
*** Warning: no boot file name; using '9B2240EA.img'
Using RTL8169#0 device
TFTP from server 0.0.0.0; our IP address is 155.34.64.234; sending through gateway 155.34.64.1
Filename '9B2240EA.img'.
Load address: 0x80408000
Loading: T T T T

Something I notice is that there is a bad crc warning at line 11. I feel something is totally wrong here, I’ve not read about others having such troubles, in fact it seems the opposite, that these boards flash and run easily. It’s like I have just a bootloader flashed and no kernel.

Any suggestions on this?

–

25

trying again to flash the board with the above ppt.img work around but it now fails as follows:

./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
sending file: ppt.img

ppt.img sent successfully
sending file: u-boot.bin
- 440016/440016 bytes sent
u-boot.bin sent successfully
sending file: system.img
| 2372383172/2372383172 bytes sent
system.img sent successfully
failed to verify partition
command failure/warning: create failed (bad data)

The serial console output is, I verified that no return chars are sent back frorm minicom while being programmed:

[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.128] Downloaded bct successfully 
[0001.132] No Battery Present
[0001.136] Sdram initialization is successful 
[0001.147] Downloaded DTB successfully 
[0001.174] No Battery Present
[0001.244] Downloaded bootloader successfully 
[0001.248] CPU-bootloader entry address: 0x83d88000 
[0001.253] BoardId: 375
[0001.255] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0001.260] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0001.265] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0001.270] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0001.275] Platform-DebugCarveout: 0
[0001.303] CPU power rail is up 
[0001.305] Performing RAM repair
[0001.308] CPU clock init successful 
[0001.312] 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): 32989271 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=3670016 
SD Alloc Partid=13, start sector=3683840,num=1024 
SD Alloc Partid=14, start sector=3684864,num=16384 
SD Alloc Partid=15, start sector=3701248,num=1024 
SD Alloc Partid=16, start sector=3702272,num=1024 
SD Alloc Partid=17, start sector=3703296,num=1024 
SD Alloc Partid=18, start sector=3704320,num=1024 
SD Alloc Partid=19, start sector=3705344,num=512 
SD Alloc Partid=20, start sector=3705856,num=142848 
SD Alloc Partid=21, start sector=3848704,num=512 
Region=0 SD Erase start 512B-sector=4096,512B-sector-num=4096 
Start Downloading PPT

End Downloading PPT
Time taken to download partition: 4 ms

Start Downloading EBT
Parallel write enabled

End Downloading EBT
Time taken to download partition: 190 ms

Start Downloading APP
WriterThread: Exiting

DownloadPartition failed. NvError 10 NvStatus 0
Time taken to download partition: 185397 ms

If I repeat the .nvflash command, sometimes it seems to get further than others, this is the ouput of an aditioan l attempt, it seems to get past sys.img but fails on the next part.

ppt.img sent successfully
sending file: u-boot.bin
- 440016/440016 bytes sent
u-boot.bin sent successfully
sending file: system.img
| 2372383172/2372383172 bytes sent
system.img 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
failed to verify partition
command failure/warning: create failed (bad data)
bootloader status: fatal failure to read / write to mass storage (code: 9) message:  flags: 0

Is there any additional information I can provide to help understand this?

26

Note that no “*.img” files should exist in the ardbeg folder. All .img files are generated. The fastboot.bin and u-boot.bin files are sources for copy to the bootloader directory (parent of ardbeg directory), but ppt.img, gpt.img, system.img, and system.img.raw are all generated. Copy of ppt.img to bootloader/ardbeg is probably just confusing things, though I doubt it has any effect.

The line 11 “bad CRC” note is actually normal and part of a correct boot. The log does however show what is an issue:

Scanning mmc 0...
** No partition table - mmc 0 **

Here is what it should have shown:

Scanning mmc 0...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
813 bytes read in 187 ms (3.9 KiB/s)
Jetson-TK1 eMMC boot options

One thing about Jetson which is mostly in common with desktop PCs is that if it fails to find bootable media onboard it then looks for other bootable sources. This is why it wants to boot other sources, it is because at least part of the eMMC was never flashed. This leaves two possibilities: Either flash failed or the eMMC failed.

If failure is because of eMMC going bad, there isn’t much else you can do except go for RMA. The tricky part is that even after all of the testing done, it may not prove that the flash process itself wasn’t flawed. At this point I tend to believe the flash procedure was correct, especially since you tried in a root shell and parts of the image writes worked, but only the one failed.

I do not believe that the ppt.img requires any Jetson activity to create on the host; failure to create ppt.img would still be a host issue. Failing to download ppt.img to the Jetson would be a Jetson issue. The new logs tend to indicate eMMC works where other images are downloaded, but it very much seems that you have failed eMMC specific to the memory range used for ppt.img.

The last lines generated by mkgpt run manually coincide with your logs and suggest mkgpt success:

[ UDA] UV 30130176 30773247 314.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img

One way to cross check if you are feeling energetic is to see if you can clone Jetson. Cloning won’t verify memory is writable, but it will verify it is readable and what is there. See:
http://elinux.org/Jetson/Cloning

Unfortunately, I think it is time to go to the RMA process. See “RMA Procedure” near the top of here:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/

27

Several things you mentioned made me rethink. The first was the permissions of files, the second was the *.img in the ardbeg folder. The first permissions issue was in fact a problem for me when trying to use the JetPack, when it extracted any files, e.g. the root file system, the virus scanner used here actually changed the ownership of the file to other than root. I happened to see one file like that. I was able to chown all files back to root.

The second issue was the *.img files, as soon as I understood that those files should not be in the ardbeg folder I removed them.

With the two changes mentioned I was able to properly flash the board with the flash.sh script, and have it boot into the Linux. No one likes to RMA…

I read through some documentation but have not really found a description of what gets flashed where, the boot loader used (uboot or fastboot), etc. Is there such documentation that goes with the release?

Thanks again for all your time and suggestions, you clearly understand how this process goes.

28

I had hoped that when you deleted and re-extracted everything again with a root shell that permissions wouldn’t be an issue…I’ve not seen a linux system with a virus scanner so I’ve never even remotely considered something else changing permissions beyond the user doing the file extraction. This is somewhat of a reminder of why sometimes linux running in a VM under windows does not always work, especially if the underlying NTFS file system is used instead of native linux file system. A virus scanner is a new one for me.

Personally, I think Jetson boards themselves hate to go through RMA…perhaps it felt a bit threatened and decided to behave itself during flash :P Obviously your Jetson board has a sense of humor.

The structure of the flash to eMMC does not seem to have public documentation, you kind of need to go through the partition listings in flash.cfg and study cloning to get an idea of how it goes together. Programs like nvflash provide useful clues from the parameters, but specifics are hard to find.

One thing to note if you are interested in how flash works is that in recovery mode Jetson does have a sort of bare metal minimal system, which needs fastboot.bin to run…once this happens, Jetson is truly in recovery mode. Thus if you flash with u-boot, mysterious listings of fastboot are correct…not because it is installing fastboot, but because fastboot is providing a way to talk to the bare metal.

29

excellent, thank you.

–