Flash hung up

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

Hi.

I tried to flash my TK1 with version 21.2. Iused the commandline in the readme file:

sudo ./flash.sh jetson-tk1 mmcblk0p1

I get the following ouput:

…
system.img built successfully.
copying dtbfile(/data/Projekte/jetson-tk1/21.2/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/data/Projekte/jetson-tk1/21.2/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg… done.
creating gpt(ppt.img)…

*** GPT Parameters ***
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
sector 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
copying flasher(/data/Projekte/jetson-tk1/21.2/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/data/Projekte/jetson-tk1/21.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: 0x34001001740990c710000000130205c0
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: 0x00000001740990c710000000130205c0
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

  • 56779/56779 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

But nothing will happen after hours…

I also tried the older Version 19.3. But I also got stuck:

System.img built successfully.
copying bctfile(/data/Projekte/jetson-tk1/19.3/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg) to bct.cfg… done.
copying cfgfile(/data/Projekte/jetson-tk1/19.3/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg… done.
creating gpt(ppt.img)…
*** GPT Parameters ***
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
sector 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(16 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 fastboot.bin
[ LNX] UH 16384 32767 8.0MiB boot.img
[ SOS] UH 32768 45055 6.0MiB
[ GP1] UH 45056 49151 2.0MiB
[ APP] UV 49152 8437759 4096.0MiB system.img
[ DTB] UV 8437760 8445951 4.0MiB tegra124-pm375.dtb
[ EFI] UV 8445952 8577023 64.0MiB
[ USP] UV 8577024 8585215 4.0MiB
[ TP1] UV 8585216 8593407 4.0MiB
[ TP2] UV 8593408 8601599 4.0MiB
[ TP3] UV 8601600 8609791 4.0MiB
[ UDA] UV 8609792 30773247 10822.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img
done.
copying bootloader(/data/Projekte/jetson-tk1/19.3/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Bootloader(/data/Projekte/jetson-tk1/19.3/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin) used as flasher.
Existing flash application(/data/Projekte/jetson-tk1/19.3/Linux_for_Tegra/bootloader/nvflash) reused.
making zero initrd…
done.
Making Boot image… done
*** Flashing target device started. ***
./nvflash --bct bct.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
chip uid from BR is: 0x34001001740990c710000000130205c0
rcm version 0X400001

Again waiting as long as you want will not change anything.

I hope someone can give me a hint what is going wrong…

2

What is your host machine? What is the result of

$ lsusb

on your host machine?

JetPack is an easier way to flash 21.2 on the Jetsons:

https://developer.nvidia.com/jetson-tk1-development-pack

3

USB seems to be OK:

dirk@Inferno:~$ lsusb
Bus 001 Device 024: ID 0955:7140 NVidia Corp.
…

I still use Ubuntu 12.04. Unfortunately the JetPack is not working under 12.04.

4

I assume that your host is an x86 PC. Have you flashed the Jetson before?

5

When building an image from scratch an install can actually take a long long time, although R21.x cut that requirement significantly. What I find most curious is that R21.x arrives with u-boot as the default, not fastboot…yet it looked like fastboot still had parts installed with what was shown as R21.2. This latter is not necessarily an issue since there are multiple files and parameters which are in common for either boot loader, but I have to wonder this question: What would happen if the install explicitly stated u-boot?

Tangram67, could you try this flash (and let it go for a couple of hours if needed):

sudo ./flash.sh -S 14580MiB -L bootloader/ardbeg/u-boot.bin jetson-tk1 mmcblk0p1

FYI building the system.img (in R21.x’s case system.img.raw) takes whatever time required to pad out an entire file system, format it, and then copy an entire operating system over to it. It takes much more time to copy this via the micro-B USB cable to Jetson’s eMMC, but R21.x first does a kind of “compression” where it sends only the parts of the file system that differ from empty (or at least this is how I’d do it…looks like the software calls this a “sparse” file versus a “raw” file), so this means much faster actual data copy…less data to copy. Still, that copy takes significant time. On R19.x it can take two hours…on R21.x I’d still find it plausible to take half an hour to an hour. If the installer used were actually R19.x and not R21.x it would make sense that the default install used fastboot and not u-boot, along with a mandatory long wait time of a couple of hours to install. I do believe the fastboot information from the log is probably ok though and likely just common files between both boot loaders…mainly I just wanted to emphasize that flash is not fast even when it works right.

6

@Kangalow:
I only flashed a modified kernel on the default installation via command line
sudo ./flash.sh -k 6 jetson-tk1 mmcblk0p1
This has worked before.

@linuxdev:
I also wondered why fastboot.bin is copied in version 21.2.
I will follow your suggestion to force u-boot and wait more than one hour
and I will come back with the result later…

7

Thanks for your help.

The reason why the flash hung up, was the USB port. I tried a different one (front port insted of USB port at the back) and the flash worked in less than 5 minutes!

Don’t know why there are problems with some USB ports…

8

My experience is that power management on many USB ports does not function correctly. The host normally provides a certain level of power to peripherals, and should be able to report when too much power draw is attempted…I believe that the reporting side of this is very common for failure. If that is the case then a powered HUB will take away the host side power provision issues and problems will just mysteriously vanish (also a powered HUB is designed to provide more power to peripherals as a whole, combined with complete removal of power provision by the host).

Owners of a PC often mistake having many USB ports from a motherboard as having multiple USB controllers with each one providing full power…it’s rare for a motherboard to actually have more than two root HUBs…many of the chassis connectors share a single HUB and thus cumulative power for all of those ports combined must be below a certain limit.