Jetson TK1 board fails to boot

Hi all,
my board fails to boot at all; power etc. seems ok - LEDs are lit, fan is noisy, the board reacts to reset and power buttons; but no output on HDMI / serial / anything else

So I tried to flash the mmc with the instructions at the L4T quick start guide*, but the flash script gets stuck at the line

waiting for bootloader to initialize

At the serial console, I see that the bootloader initializes up to

Bootloader-AVP Init at: -1137693521 us
Dummy read for TPS65913
Board Id = 0x0
Unsupported Processor Board 0x0

and hangs…
What is the correct board ID? Where is it stored (EEPROM)? Is there any chance to resolve this issue without sending back the board?
Simon

*https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/l4t_quick_start_guide.txt

When did this start? Was the board doing this out of the box? If so, then I’d assume something’s wrong with the hardware.

That’s how I got it - so yes, a hardware issue sounds propable.

If parts of the config would be stored in an external eeprom or similar, I could check voltages and solder a workaround, if it’s not a bga chip.

I am just trying to evade a lengthy rma cycle…

The TK1 does have a JTAG port according to the spec: http://developer.download.nvidia.com/embedded/jetson/TK1/2014-03-24/JetsonTK1_ModuleSpecification_PM375_V1.0.pdf

Of course, getting a $400 JTAG debugger may not exactly be optimal even compared to an RMA.

There are many JTAG units available for much less than $400 for the Jetson.
It uses a standard ARM 20 pin JTAG so it doesn’t need any special type of debugger.

Can you point out the few models, (low cost, eBay…).

I also get the very unstable ubuntu graphical desktop. It hangs up all the times.
Dont know if I have a bad board or bad setup.
Can someone give the idea, that he/she is happy with it, so I can return the board.
Thanks much.

It’s not a matter of hardware nor price → https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY-H/, instead you would want to know which config parameter block to program into which device…

Maybe Nvidia tech support has an ear for me (btw, there is no appropriate Tegra K1 category when filing bugs on the Gameworks support site, or did I miss something?)

Hi everyone,

I also have the same problem. I got the Jetson TK1 out of the box and first there was nothing pre-installed on it. After I try to flash it following the instructions from L4T quick start guide* and as @svogl mentioned the flash script gets stuck at

waiting for bootloader to initialize

Any ideas how I might solve this without returning the board???

So far as I know, Jetsons all arrive these days with L4T R19.2 installed. When you say that the tk1 arrived with nothing pre-installed, how did you determine this? Did you use a serial cable and check serial console? This looks like something likely needing the nVidia support for.

When you went to flash it, did you have the mini-B cable connected (provided with Jetson), and did you boot with the recovery mode button held down? What flavor of host were you flashing from, e.g., ubuntu, fedora?

I purchased my board last week. Connected HDMI, network and power, the power light came on but that was all. I read in one of the tutorials that not all boards came pre-flashed, so I followed the instructions for flashing the board and have the same problem… It hangs with waiting for bootloader to initialize.

If I power off the board, I get an error:
USB Read Error 71: Protocol Error
Bootloader Failed NvError 0x0
command failure / warning: bootloader download failed
failed flashing ardbeg

BTW, the power button seems to do nothing. The power light stays on and the fan keeps running.

What should be used in place of ${BOARD} in the flash command?

Any thoughts or suggestions?

Thanks,

Glen

There are some details which are easy to miss during flash. Flash instructions leave a lot of it out…several threads on this forum about flashing. Some boards may actually require RMA, but there is a higher chance that one of those flash details is at fault. Instead of listing everything, let’s find out some of the more common issues.

FYI, the ${BOARD} is jetson-tk1. Also, any edit of the jetson config file for enabling USB 3 at boot should be avoided until things actually work, as USB 3 is not so simple because of firmware. And for video, if you used an adapter going to older 15 pin VGA, likely it will fail…monitor needs to actually be HDMI or DVI. VGA lacks the DDC channel used to tell the system about monitor specs.

Can we assume your host for the flash is running on a file system which works with linux file permissions? E.G., if you run on ext3 or ext4, this works…an NTFS partition cannot work.

Can we assume you unpacked any files for L4T as root, or sudo to become root? Lacking this corrupts things. Can we assume that any tar command included the option to preserve file permissions (I think it is -p, I’m not on linux at the moment, I’m doing it all from memory)? If you did not preserve permissions, strange things will happen.

Can we assume you ran the apply_binaries.sh as root or sudo?

What flavor linux host were you using, e.g., ubuntu, fedora? What is the output of “ls /dev/loop*”? Do you have /dev/loop0? If you run “losetup --find”, does it show loop0?

For your L4T directory, where flash.sh exists, look at your bootloader sub-directory. Does it now contain “system.img”? It should be betwee 8 GB in size and 15 GB.

What was your exact command line during flash? Did you hold down the reset button before and during application of power to the Jetson?

To answer your questions…

I am not enabling the USB 3.0
I have tried with the tk1 connected and not connected to a true HDMI monitor
I am running Ubuntu 14.04 on Ext4.
All extraction, apply binaries and flash were done with sudo
Yes I have /dev/loop0
The IMG file is 15.0GB
I have tried both of the command lines sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1 and …14GiB with the same results
I followed the instructions which are to hold the recovery button and press and release the reset button. I tried your method with the same results… Hangs waiting for bootloader to initialize

I use -S 14GiB, resulting in about 15 GB on system.img. 14GiB is known to work, 15GiB is known to be too much and fail (8GiB is very minimal, and risks being too small if there are customizations…default in flash.sh is 10GiB if size is not mentioned).

Does “losetup --find” reply with /dev/loop0? The flash script is hard wired to loop0, so if something else uses loop0, you must edit. It isn’t unusual for someone to have loopback in use already. system.img is initially created with /dev/zero and dd, and then loopback mounted and formatted as ext4. Following this, it is populated with a clone of what will be flashed. system.img can be created but not work correctly if loop0 was in use. If system.img is ok, you should be able to loopback mount it, something like this:

sudo mount -o loop -t ext4 system.img /mnt

Actual flash with the whole filesystem takes quite some time, as it must load about 15 GB over the USB port…reading local hard drive and then writing flash.

Looks like you’ve done things right, but you might want to try specifying the u-boot boot loader. I’m not around my devel machine right now, so I have to go by memory. There is an option to name a specific boot loader, and the boot loader file is in bootloader/u-boot.bin (or very closely named; default uses fastboot.bin, in which case the -K 6 option must be used to place the kernel in the right partition…it doesn’t hurt to specify this anyway with u-boot since some byte offsets may require this space be used…installing a rootfs without a kernel could be considered a deal-breaker). FYI, zImage is used for u-boot.

If all this fails, it is probably time to ask nVidia for possible RMA.

You mention the -K option to place the kernel in the correct partition, but what is the correct partition?

Also, this hangs without error waiting for the bootloader to initialize. Is there normally a pause at this step?

I let the install sit at the waiting for bootloader point and it just sat there.

Does anyone have any suggestions?

Glen

The proper -K option is “-K 6”. The process takes a very long time…I have not done this in a while, I think it took well over an hour, perhaps 2. Once the installation is complete, you can cycle power if it hangs…just don’t hold down the button you’d normally use to start flash.

Were you able to loopback mount the system.img file? If you can’t do this, it is a smoking gun and definitively a problem for the flash process (when flashing filesystem…just kernel does not need this).

I gave up, returned it and got a new one. I plugged it in and it came up right away. I guess it was bad hardware.

Thanks for the help.

Glen

[quote=“linuxdev”]

I’ve had a different symptom during that same step:

codebender:Linux_for_Tegra paul$ sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1
copying dtbfile(/Volumes/MacHD_Dev/pkg/TK1/Linux/Linux_for_Tegra/kernel/dtb/tegra124-pm375.dtb) to tegra124-pm375.dtb… done.
Making system.img… /Volumes/MacHD_Dev/pkg/TK1/Linux/Linux_for_Tegra/rootfs 8589934592
mapping system.img to loop device failed.

codebender:Linux_for_Tegra paul$

Is there any work-around for this…? a nudge int he right direction would be greatly appreciated :-)

Thanks!
Paul++

Hi everyone,

Even for me the TK1 come with nothing pre-installed. First time I was connecting it I had HDMI connected to a monitor and Serial to USB connected to listen to serial port but nothing came up so I followed the instructions on the Quick start Guide for flash the board: https://developer.nvidia.com/sites/default/files/akamai/mobile/docs/l4t_quick_start_guide.txt.

Here is my configuration:

• I am also not enabling USB 3.0
• Same I have also tried TK connected to a HDMI and with no HDMI.
• I am running Ubuntu 12.04 LTS
• All extractions, apply binaries and flash are done with sudo
• I have used the following command to flash the TK1

sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1

Once the waiting for bootloader to initialize is shown on the terminal I get the following output from the serial console:

Bootloader-AVP Init at: 656982135 us
Dummy read for TPS65913
Board Id = 0x0
Unsupported Processor Board 0x0

I am little bit confused by the @linuxdev answer regarding the partition. I have the u-boot.bin and the fastboot.bin files. How to I call the -K 6 option?

Thanks everyone for your help. I would be very happy if I am able to solve this issue!!

Short answer: Just use “-K 6” and let flash.sh take care of how to use this, even if calling for “-L bootloader/u-boot.bin”. Explanation follows.

In some cases boot hands off to a fixed byte offset, and I have not studied where those offsets are…so I tend to stay on the side of caution and not re-order early partitions. Up until the end of the kernel partition used in fastboot is where I consider this possibility of partition re-order breakage to be an issue, although it may not actually be an issue.

With regards to kernel and boot loader options, the default of boot loader is fastboot via bootloader/fastboot.bin. Fastboot will always look for a kernel in partition 6, as per the flash.sh option “-K 6” (you could put this kernel anywhere, but fastboot would fail unless you made a custom fastboot.bin knowing the new location). Assuming the Jetson arrives with L4T pre-installed, this is where the booting kernel resides, with boot loader being fastboot.

In the case of u-boot, kernel is searched for in the /boot directory of , reading extlinux.conf there for parameters and kernel name (other .conf files for hard drive or network booting, so on…extlinux.conf applies to eMMC). Kernel type for u-boot is the zImage format, although it appears earlier versions depended on the vmlinux.uimg format (with current u-boot, this file can be removed or renamed or ignored…extlinux.conf refers only to zImage). To use u-boot during flash, one must specifically provide the option “-L bootloader/u-boot.bin”.

There is no issue with simultaneously using the “-K 6” option and the “-L bootloader/u-boot.bin”. Partition 6 would in the u-boot case be ignored…the purpose for keeping “-K 6” is what I mentioned before about the possibility that byte offsets would be incorrect if altering disk structure before the root partition. In any case, the flash.sh script does not appear to be optimized for such possibilities, and removing earlier partitions would require the flash.sh script to be optimized for this. Calling “-K 6” is the entire syntax of this option, its use is hard-wired as to how the partition is used.

Remember that flash.sh is used for other L4T devices as well, not just Jetson. This may account for some of the flash.sh structure and the possibility that adjustments specifically for Jetson not being optimized to remove partition 6 in the case of using u-boot (along with each case needing a custom fastboot.bin or u-boot.bin).