Unable to boot in Jetson TK1 after flashing with version R21.5

Robotics & Edge Computing Jetson Systems Jetson TK1
21

Hello again, i did the “mkfs.ext4 -O ^64bit,^metadata_csum /dev/whichever/it/is” but still not working. I am afraid if the external USB has something to do with.
About the result, this is part of what i got…

– Total: -----------------------------------------------------------
1790 CHUNK 15288238080(3732480 blks) ==> 2361672708(576575 blks)

done.
system.img built successfully.
copying dtbfile(/home/fabian/LT4/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/home/fabian/LT4/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(/home/fabian/LT4/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/home/fabian/LT4/Linux_for_Tegra/bootloader/nvflash) reused.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_H5TC4G63CFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x34001001740df2061400000019ff0580
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: 0x00000001740df2061400000019ff0580
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

  • 59661/59661 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
    \ 2097152/2097152 bytes sent
    ppt.img sent successfully
    sending file: u-boot.bin
  • 439776/439776 bytes sent
    u-boot.bin sent successfully
    sending file: system.img
  • 2361672708/2361672708 bytes sent
    system.img sent successfully
    sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
  • 59661/59661 bytes sent
    tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
    sending file: gpt.img
    \ 2097152/2097152 bytes sent
    gpt.img sent successfully
    Create, format and download took 145 Secs
    Time taken for flashing 147 Secs
    *** The target ardbeg has been flashed successfully. ***
    Reset the board to boot from internal eMMC.
22

If the USB port hosting a SATA drive changes modes between USB2 and USB3 at any point between U-Boot running and the kernel loading you’ll momentarily lose the device during re-enumeration…have you tried both USB ports? The larger port is capable of USB3, but runs only as USB2 when in U-Boot. The micro-USB port is purely USB2.

23

That would work, i will try. Furthermore, i saw a video in Youtube which explains all the flash process and there is a step where he changes one parameter of the “jetson-tk1.conf” doc to enable USB 3.0. The parameter is ODMDATA. Do you think i need to do that?

24

If you follow the steps for enabling USB3 and instead reverse it and keep it as USB2 then you should have continuity of service during boot and your USB hard drive should then work if all else is correct. You will need to specifically avoid USB3, though I haven’t gone through the steps under the most recent L4T…it used to be there was a parameter in the kernel args you could use to do the job…this may still work.

Look at your “/boot/extlinux/extlinux.conf” file and find the “APPEND” line (even if it line wraps it’s really just one very long line…don’t break it up). USB2 mode had been (and probably still is) “usb_port_owner_info=0”, while USB3 mode had been (and probably still is) usb_port_owner_info=2. If setting to “=0” works you don’t even need to bother with ODMDATA.

When you do a tree view of USB via “lsusb -t” you will see “480M” at the end of the line for USB2 mode, or “5000M” at the end of the line for USB3 mode (slower devices like keyboards tend to be “12M”). If you see “5000M” anywhere it implies the USB3 mode driver is installed…this will cause failure for your case, “480M” will allow your hard drive to work.

25

I checked and the port from hard drive is displaying the “480M” but still not working. I want to use the terminal console but i dont know how.

26

You would have to verify that 5000M does not show up on the root_hub as well for the root_hub which is part of the hard drive’s tree in “lsusb -t”.

Which console…serial console…or just console from a direct login? There are actually three consoles…ssh remote login…sitting at the keyboard after something like CTRL-ALT-F1, and serial console. Serial console is the one which is by far the most reliable even under failure conditions.

27

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 9, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 3: Dev 12, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
|__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 6: Dev 8, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 6: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 8: Dev 7, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M

As we can see, my hard drive is part of the root_hub “480M”.

I tried to see whats going on with the serial port but also fail. I used minicom and the serial device appeared me as “offline”

28

fabian@fabian-X555LB:~/LT4/Linux_for_Tegra/bootloader$ ls -l
total 4532740
drwxr-xr-x 4 1001 1001 4096 jun 7 2016 ardbeg
-rwxr-xr-x 1 root root 594363 ene 24 22:22 fastboot.bin
-rw-r–r-- 1 root root 4173 ene 24 22:22 flash.cfg
-rw-r–r-- 1 root root 2097152 ene 24 22:22 gpt.img
-rw-r–r-- 1 root root 5867 jun 7 2016 LICENSE
-rw-r–r-- 1 root root 5867 jun 7 2016 LICENSE.mkbctpart
-rw-r–r-- 1 root root 13123 jun 7 2016 LICENSE.mkbootimg_and_mkubootscript
-rw-r–r-- 1 root root 5867 jun 7 2016 LICENSE.mkgpt
-rw-r–r-- 1 root root 5867 jun 7 2016 LICENSE.mksparse
-rw-r–r-- 1 1001 1001 21752 jun 7 2016 LICENSE.u-boot_and_mkimage
-rwxr-xr-x 1 root root 486872 jun 7 2016 mkbctpart
-rwxr-xr-x 1 root root 441007 jun 7 2016 mkbootimg
-rwxr-xr-x 1 root root 485979 jun 7 2016 mkgpt
-rwxr-xr-x 1 root root 121996 jun 7 2016 mkimage
-rwxr-xr-x 1 root root 475945 jun 7 2016 mksparse
-rwxr-xr-x 1 root root 466091 jun 7 2016 mkubootscript
-rwxr-xr-x 1 root root 1307069 jun 7 2016 nvflash
-rw-r–r-- 1 root root 42545 ene 24 22:18 PM375_Hynix_2GB_H5TC4G63AFR_H5TC4G63CFR_RDA_924MHz.cfg
-rw-r–r-- 1 root root 2097152 ene 24 22:22 ppt.img
-rwxr-xr-x 1 root root 2306630276 ene 24 22:22 system.img <-----------
-rw-r–r-- 1 root root 15288238080 ene 24 22:21 system.img.raw <-----------
-rw-r–r-- 1 root root 59661 ene 24 22:22 tegra124-jetson_tk1-pm375-000-c00-00.dtb
-rw-r–r-- 1 root root 439120 ene 24 22:22 u-boot.bin

I was wondering, why would system.img and system.img.raw have not the same size?

29

The two image sizes will be vastly different. The .raw file is a pure bit-for-bit exact copy of the partition. The non-raw image is a “sparse” image…sort of a “poor man’s compression”…under sparse images places in the file system which are empty were instead labeled as such for later filling of the bytes…under raw images the bytes are actually there (a LOT of NULL bytes). The difference in size is approximately the amount of disk space on the image which was free. As the raw image is filled with content the sparse image size will begin to approach the raw image size.

Note that 15288238080 bytes (the .raw size) is exactly divisible by the 512 byte block size used by the eMMC. Note that 15288238080/(1024*2) == 14580, which is what the “-S 14580MiB” is. This validates most of the step of generating system.img.raw (filling content in the image could also fail, but the image itself is the right size).

The “sparse” file type is normally standard in Linux or Android…I believe the Jetson version is non-standard, normal tools seem unable to handle conversion from sparse back to raw. So far as I know the only tool to accomplish this is the Jetson itself in recovery mode during flash.

One thing I’m not positive about…whether the micro-USB or full-sized-USB connector are both capable of being used as a boot device. The full-sized connector can, but only if it doesn’t switch to USB3 (5000M won’t work). The micro-USB is available in U-Boot, but I’m not sure it can be used as a boot device when transitioning from U-Boot to Linux. Are you using the micro-USB? If so it may just indicate you need the full-sized port forced to USB2 mode. I’m fairly sure the full-sized port in USB2 mode will work as a boot device on the TK1…I’m positive that if that port is set to USB3 after boot it will not work as a boot device up through R21.6. This is why in the earlier post I mentioned the “usb_port_owner_info” edit in “/boot/extlinux/extlinux.conf” as a means of forcing this port to USB2 mode within Linux (the root_hub would show as 480M instead of 5000M via “lsusb -t”):
https://devtalk.nvidia.com/default/topic/1019737/jetson-tk1/unable-to-boot-in-jetson-tk1-after-flashing-with-version-r21-5/post/5234699/#5234699

Minicom can be difficult, it was designed for modems which use the old “AT command” set in addition to normal serial port settings. You would need to be sure it is not trying to work as a dial-out system, and it is at 115200 8N1 (software or CTS/RTS flow control). You have to verify it is naming the correct serial device (especially if it is a ttyUSB serial device) and that all settings are valid…things like “modem reset” do not apply since it isn’t a mode…it’d just be garbage going to the Jetson.

I prefer gtkterm, but this (and most old serial console programs) don’t like the “/dev/ttyUSB#” syntax and I have to manually name the tty since its dropdown menu doesn’t list anything ttyUSB. I start gtkterm something like this (well, I edited my .gtktermrc once I found my settings), which is just “115200 8N1”:

gtkterm -p /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A10171DT-if00-port0 -s 115200 -b 8 -t 1

You might want to also give the exact error text…it is subtle but different when it says no device was found, versus no file system was found.

30

Hi,
Sorry for taking long to answer, after several time i figured out how to solve the problem. Thank you very much for the support and the time it took. You were right about the deal with USB3/2, so at the end it worked. Alongside this time i learned so much and i think its the most important think about this. Thank u