Couple of weeks ago I received my TX1 kit and I tried to flash the OS. Everything went ok, but it stopped on “determining IP address of target”. According to the bellow output, the flashing process has done successfully:
*** The target t210ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.
1
Finished Flashing OS
Determining the IP address of target...
JetPack is unable to determine the IP address of the Jetson Developer Kit
Please select which action do you want:
1. Retry
2. Manually enter IP address
Your option is <1/2>:
I stopped it after I could not make the network connection working. The strange thing is that after that, I was never able to see the TX1 booting again. It means nothing on the display (hdmi connected).
I tried different things including connecting both host and device to my router and flash it again. Every time I receive the same IP error. And no booting.
My question is how can I resolve this issue or at least recover the device to the initial state.
Thanks for your help in advance.
You may be able to ping the dotted-decimal IP address. Your router may give you that information if you assign via the router. ssh can fail if ssh keys change (keys may change upon flash; command line ssh would say so, try on the command line if ping works).
FYI, video can fail if the permissions of your sample rootfs were not correct, or if the apply_binaries.sh step was not complete prior to flash (JetPack probably does this for you if not doing a manual flash). Not seeing video would not necessarily mean the Jetson failed to boot…this only guarantees video does not work (though it could mean failed boot).
Questions which come to mind is if you used JetPack versus manual flash, and if your flash host has anything unusual about it, e.g., a virtual Linux?
If you have any means of seeing what shows up on the serial port, this would be useful. See:
[url]Jetson TX1 - eLinux.org
Thank you linuxdev
Actually, now I am less concerned about IP registration. Making sure that the kit is booting up is now more important.
The reason that I think it fails to boot is that my router does not show any assigned IP for TX1. The first time, I used Jetpack to flash it. Since nothing showed up, I also manually flashed with the same result. apply_binaries.sh also returned:
Adding target symlink /lib/modules/3.10.67-g458d45c/build --> /usr/src/linux-headers-3.10.67-g458d45c
Installing zImage into /boot in target rootfs
Installing Image into /boot in target rootfs
Installing the board *.dtb files into /boot in target rootfs
Success!
My linux machine is normal (not VM or …). How can I make sure that permissions are set OK? I granted sudo access before each command.
About serial port, I have no adequate wiring at the moment. But I will try to configure the UART if it helps.
Is there any way to use USB port to retrieve those information?
This also comes to my head that the HDMI port might be damaged? (I did nothing destructive though)
The reason the IP address is important is that if it exists, then you know the machine booted. Routers and caches have a nasty habit of causing various failures as well, I would not conclude immediately that no address was requested (just that it was not assigned). I would suggest (very strongly) that if you reset your router (such as power off and unplug for 10 seconds), then you will know for sure that there is no issue at the router side (to emphasize, almost all routers have cache issues at some point in their life, and reboot is so easy to do as a test…then check again for an address). There could also be an address conflict with another device.
It looks like flash was good, but what is the file size of the generated “bootloader/system.img.raw”? Mine is 15288238080 (in MiB, twice dividing by 1024, that is 14580, same as my “-S 14580MiB” used during the flash). If this file correct, then odds are high all parts of the flash were correct (based on your rootfs and apply_binaries.sh being run sudo).
The USB port cannot be used for serial console…but the fact that flash works probably says a significant part of the hardware is working correctly. The serial console is extremely effective at debugging situations like this…if you can get this, it would answer a lot of questions immediately.
HDMI ports can be physically broken sometimes…the traces and mounting are more delicate than what I’d like, but because of other issues with HDMI software I suspect your system works…the monitor fails far more often due to software. If you watch the monitor very closely, you may get just a short flash (a fraction of a second) of information such as scan speed error report…this would be a strong sign of a software issue. You could try the monitor on another computer (preferably with the same cable). You could perhaps also try another monitor…different scan speed capabilities may change results if software is the issue. Just make sure no 15-pin analog cable is ever used.
I restarted the router to make sure. But nothing happened. The LED on the router does not blink unless I put TX1 in the force recovery mode.
About the size of created image, it’s 8GiB as I passed in the flashing process.
I am also sure that my monitor is functioning by connecting it to another device. It was also working with TX1 before I started to flash it.
I think I should create a UART cable now to obtain more information on what’s going on.
Any suggestion in the meantime would help though.
I don’t think 8GiB will work…it might, but this is possibly the problem. Certainly this would leave no room for practical use of the JTX1. Can you try flashing again with “-S 14580MiB”? There is a possibility that the file system was filled with 8GiB.
And yes, the serial console is very important when debugging.
I am back with the serial output. I fixed the 8GiB size, BTW.
To my limited knowledge, it seems that there is no problem with booting the device except several failures. One for Ethernet and the other for display. It says “Display board id read failed”.
Could it be a sign of hardware damage? If yes, that is really unfortunate :(
Here is the serial output:
[0000.726] [TegraBoot] (version 23.00.2015.14-mobile-3a15407d)
[0000.731] Processing in cold boot mode Bootloader 2
[0000.736] A01 Bootrom Patch rev = 63
[0000.739] Power-up reason: on button
[0000.743] No Battery Present
[0000.746] Platform has Ddr4 type ram
[0000.749] max77620 disabling SD1 Remote Sense
[0000.753] Setting Ddr voltage to 1125mv
[0000.757] Serial Number of Pmic Max77663: 0x1e05f3
[0000.765] Entering ramdump check
[0000.768] Get RamDumpCarveOut = 0x0
[0000.771] RamDumpCarveOut=0x0, RamDumperFlag=0xe59ff3f8
[0000.777] Last reboot was clean, booting normally!
[0000.781] Sdram initialization is successful
[0000.785] SecureOs Carveout Base=0xff800000 Size=0x00800000
[0000.791] GSC1 Carveout Base=0xff700000 Size=0x00100000
[0000.817] GSC2 Carveout Base=0xff600000 Size=0x00100000
[0000.842] GSC3 Carveout Base=0xff500000 Size=0x00100000
[0000.848] GSC4 Carveout Base=0xff400000 Size=0x00100000
[0000.853] GSC5 Carveout Base=0xff300000 Size=0x00100000
[0000.858] BpmpFw Carveout Base=0xff2c0000 Size=0x00040000
[0000.863] Lp0 Carveout Base=0xff2bf000 Size=0x00001000
[0000.879] RamDump Carveout Base=0xff23f000 Size=0x00080000
[0000.884] Platform-DebugCarveout: 0
[0000.887] Nck Carveout Base=0xff03f000 Size=0x00200000
[0000.927] Using GPT Primary to query partitions
[0000.933] Loading Tboot-CPU binary
[0000.982] Verifying bootloader in OdmNonSecureSBK mode
[0000.992] Bootloader load address is 0xa0000000, entry address is 0xa0000258
[0001.001] Bootloader downloaded successfully.
[0001.005] Downloaded Tboot-CPU binary to 0xa0000258
[0001.010] MAX77620_GPIO1 Configured.
[0001.014] MAX77620_GPIO5 Configured.
[0001.017] CPU power rail is up
[0001.020] CPU clock enabled
[0001.024] Performing RAM repair
[0001.027] Updating A64 Warmreset Address to 0xa00002e9
[0001.044] Bootloader DTB Load Address: 0x83000000
[0001.061] Kernel DTB Load Address: 0x83080000
[0001.066] Loading cboot binary
[0001.160] Verifying bootloader in OdmNonSecureSBK mode
[0001.253] Bootloader load address is 0x8010fda8, entry address is 0x80110000
[0001.262] Bootloader downloaded successfully.
[0001.266] GPT: Partition NOT found !
[0001.270] Find Partition via GPT Failed
[0001.273] function NvTbootGetBinaryOffsets: 0x845208 error
[0001.279] Error in NvTbootLoadBinary: 0x845208 !
[0001.283] Next binary entry address: 0x80110000
[0001.288] BoardId: 2180
[0001.314] NvTbootI2cWrite(): error code 0x00045100 Error while starting write transaction
[0001.322] NvTbootI2cDeviceRead(): error code 0x00045001 Error while sending the offset to slave
[0001.330] NvTbootI2c: Read failed for slave 0xa2, offset 0x00 with error code 0x00045001
[0001.338] Display board id read failed
[0001.342] dram memory type is 3
[0001.346] WB0 init successful
[0001.372] Bpmp FW successfully loaded
[0001.375] Set NvDecSticky Bits
[0001.378] GSC1 address : ff700000
[0001.382] GSC2 address : ff600000
[0001.386] GSC3 address : ff500000
[0001.390] GSC4 address : ff400000
[0001.393] GSC5 address : ff300000
[0001.397] GSC MC Settings done
[0001.400] TOS old plaintext Image length 61440
[0001.406] *** Secure OS image signature not verified ***
[0001.411] Loading and Validation of Secure OS Successful
[0001.417] NvTbootPackSdramParams: start.
[0001.422] NvTbootPackSdramParams: done.
[0001.425] Tegraboot started after 116173 us
[0001.429] Basic modules init took 941318 us
[0001.433] Sec Bootdevice Read Time = 193 ms, Read Size = 8459 KB
[0001.439] Next stage binary read took 12218 us
[0001.443] Carveout took 251577 us
[0001.447] CPU initialization took 138721 us
[0001.451] Total time taken by TegraBoot 1343834 us
[0001.455] Starting CPU & Halting co-processor
64b[0001.591] LPDDR4 Training: Number of tables = 10
[0001.595] EMC Training (SRC-freq: 204000; DST-freq: 408000)
[0001.601] EMC Training Successful
[0001.604] EMC Training (SRC-freq: 204000; DST-freq: 665600)
[0001.610] EMC Training Successful
[0001.613] EMC Training (SRC-freq: 204000; DST-freq: 800000)
[0001.625] EMC Training Successful
[0001.628] EMC Training (SRC-freq: 204000; DST-freq: 1065600)
[0001.650] EMC Training Successful
[0001.653] EMC Training (SRC-freq: 204000; DST-freq: 1331200)
[0001.675] EMC Training Successful
[0001.678] EMC Training (SRC-freq: 204000; DST-freq: 1600000)
[0001.697] EMC Training Successful
[0001.701] Switching to 800000 KHz Success
[0001.734] LPDDR4 Training: Number of tables = 10
U-Boot 2015.07-rc2-geea3f71 (Feb 08 2016 - 17:37:49 -0800)
TEGRA210
Model: NVIDIA P2371-2180
DRAM: 4 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
tegra-pcie: PCI regions:
tegra-pcie: I/O: 0x0000000012000000-0x0000000012010000
tegra-pcie: non-prefetchable memory: 0x0000000013000000-0x0000000020000000
tegra-pcie: prefetchable memory: 0x0000000020000000-0x0000000040000000
tegra-pcie: 4x1, 1x1 configuration
tegra-pcie: probing port 0, using 4 lanes
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
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, retrying
tegra-pcie: link 1 down, ignoring
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 2 1 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
starting USB...
USB0: USB EHCI 1.10
scanning bus 0 for devices... 1 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
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra210
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
Tegra210 (P2371-2180) #
The “display board id failed” can be ignored. It looks like you are trying to PXE boot though, and have set it up to read boot files from a remote server rather than from local memory. With no ethernet set up, this will fail even if you have such a server. Were you setting this up for PXE boot on purpose?
Side note: Since I use Fedora and can’t use JetPack, I wonder if JetPack uses PXE boot during install? I do not know if perhaps JetPack does this, or perhaps this is just the default if the eMMC is missing a valid entry (i.e., a fallback secondary boot method).
I’m guessing JetPack uses PXE. For a normal non-JetPack flash, all you need is the micro-B USB connector. No network required. You could try manual flash…I think JetPack would have downloaded this anyway.
I also manually flashed but no difference.
My last try was to pass “bootloader/t210ref/p2371-2180/u-boot.bin” with -L option.
However, it now stops at line 17 in the block below:
[0000.869] Starting CPU & Halting co-processor
64b[0001.005] LPDDR4 Training: Number of tables = 10
[0001.009] EMC Training (SRC-freq: 204000; DST-freq: 408000)
[0001.015] EMC Training Successful
[0001.018] EMC Training (SRC-freq: 204000; DST-freq: 665600)
[0001.024] EMC Training Successful
[0001.027] EMC Training (SRC-freq: 204000; DST-freq: 800000)
[0001.039] EMC Training Successful
[0001.042] EMC Training (SRC-freq: 204000; DST-freq: 1065600)
[0001.064] EMC Training Successful
[0001.067] EMC Training (SRC-freq: 204000; DST-freq: 1331200)
[0001.089] EMC Training Successful
[0001.092] EMC Training (SRC-freq: 204000; DST-freq: 1600000)
[0001.112] EMC Training Successful
[0001.115] Switching to 800000 KHz Success
[0001.148] LPDDR4 Training: Number of tables = 10
I would not use the “-L” option for flash without a reason (in part because a boot loader binary may need NULL byte padding first, even if the binary is otherwise correct). For a manual flash, could you try:
It’s still trying to boot from network via PXE diskless boot. Unless this is done through JetPack (at least for dowload), I don’t know how default flash could result in attempting PXE boot. I hate to say it, but I suggest you delete your host’s install media and download just the driver package and sample rootfs separately, not touching JetPack. See R23.2 at:
[url]https://developer.nvidia.com/embedded/linux-tegra[/url]
There just shouldn’t be any PXE boot config used unless this was copied in as part of configuration for JetPack or by manual selection. Once a fresh manual download/install is done, it should not stick at PXE boot, and should not attempt this at all. It should just boot up after this using DHCP to ask for an address.
It might be strange but it gave me the same result.
I uninstall every thing from previous install and did the following steps:
steps:
1- $ mkdir JS-new & cd JS-new
2- $ wget http://developer.nvidia.com/embedded/dlc/l4t-jetson-tx1-driver-package-23-2
3- $ wget http://developer.nvidia.com/embedded/dlc/l4t-sample-root-filesystem-23-2
4- $ sudo tar -vxjf l4t-jetson-tx1-driver-package-23-2
5- $ cd Linux_for_Tegra/rootfs
6- $ sudo tar jxpf ../../l4t-sample-root-filesystem-23-2
7- $ cd ..
8- $ sudo ./apply_binaries.sh
9- Power up the board and put it into forced recovery mode
10- $ sudo ./flash -S 14580MiB jetson-tx1 mmcblk0p1
11- It finished successfully but the TX1 did not boot up.
I repeated the same steps for TX1 R23.1 version with no success.
i was looking at your output vs. my output and it stops being similar at
scanning mmc 0:1
for some reason yours jumps to a USB sequence while mine actually finds the config file and continues the boot. compare yours to mine here.
Interesting. But why? and how to fix it?
Could it be the matter of permissions?
Mine in the host side is:
-rw-r–r-- 1 root root 948 Mar 15 00:08 rootfs/boot/extlinux/extlinux.conf
There is still a question as to whether the fall back to PXE is simply because no valid boot information was found…this is typical of a boot loader design, it seems plausible. If the case is that flash never installed the required partitions and/or files, then here are some possibilities…
Several images are created or used during flash. Sometimes an image requires a loopback device to manipulate…if so, root authority is required in cases where a loopback device is created or mounted on the go. Lack of root authority (sudo) would break any such stage.
Copy of files occurs during flash (including copy of the entire sample rootfs into a loopback device). Copy or creation of device special files requires root authority…failure could cause the device special file to fail copy.
File permissions in the sample rootfs must be preserved during all stages, even unpacking. If you were to unpack onto a file system not supporting Linux permissions, e.g., NTFS, then there will be a massive set of failures which do not show up until trying to use the files. Lack of root authority to copy files and preserve attributes, even on a valid Linux file system, would cause a similar failure.
The USB port is the only required port during a manual flash. This port is also required under JetPack. If you are using a virtual host, and that virtual host does not control the port, flash will fail.
Some of the image files are padded to specific lengths before being used. If you name the non-padded file, there will be a failure at some point (thus the file is basically truncated, losing trailing NULL bytes…byte copy operations, e.g., dd, may be confused by this).