NEED HELP: Updating the L4T from 21.4 to 21.5 on the eMMC fails

[MickPF]

Dear Sirs,

yesterday I got my Jetson-TK1, “played” a little bit with the preinstalled L4T-21.4 and started updating to 21.5 following instructions in the Users Guide. All steps run successfully but the system doesn’t boot anymore and the resulting filesystem on ‘/dev/mmcblk0p1’ seems to be unusable/corrupted. Some few checks from the u-boot prompt with the command “ext4ls mmc 0:1 <path to any known system file/directory>” display nonsense.

I don’t see any way to attached a (long) Log output at this place!

Please help me!!!

Kind Regards
Michael

[linuxdev]

Flash may need to be repeated, but I wouldn’t worry too much since flash doesn’t harm the Jetson.

It sounds like you already have a serial console set up, and this is very helpful. If possible, you could power off the Jetson, and set the serial console program to log, then post the log of what shows up on the console during power on.

Most likely you just need to flash again, in which case logging and debugging might just be extra work. In any case, you’ll want to verify a few things about the host you flashed from. Is the host a full Linux install, or a VM? How much disk space is available on the host (a lot of space is needed, perhaps 20+GB for the system.img files)? One way to see disk space is from the directory used run command “df -H .”. During flash, within the driver package directory (Linux_for_Tegra), there is a subdirectory, “bootloader”. See which system.img files are there, and what size are they:

# cd first to the bootloader subdirectory...
ls -l system.img*

[MickPF]

I flashed the system already several times with the same result.
I would place the console and the host output here (generated by the command “./flash.sh …”), but they are very long.
Can I place these outputs here as an attachment? Or send via email to you?
The image file “system.img” is present and about 2.4 GB! How can I check it’s content? Can I mount it?

[linuxdev]

The system.img file is the “sparse” file…essentially compressed. This was created from system.img.raw, the “raw” uncompressed file. It is the raw file size which is of interest, although knowing the sparse file exists guarantees that at some point the raw file was indeed created. If possible, what is the exact size of system.img.raw? How much space is available in that directory (“df -H .”)?

The log of flash is only large because of the “progress” notes about what percent of the system.img has been copied…that one line can be removed and the rest is small. You can extract the top of the log via this (assuming file is “log_file.txt”):

gawk '/^copying bctfile/,/^sending file[:] system.img/' log_file.txt

…the remaining part of the file after that long progress line can be extracted via:

gawk '/^system.img [^b]/,/^$/' log_file.txt

If those awk commands don’t work, then there may be errors in the flash which give text the awk commands are not expecting. As an alternative, you can simply filter out all of the lines with “bytes sent”, but this also eliminates the trivial (but useful) note of smaller images being sent:

cat log_file.txt | egrep -v 'bytes sent'

[MickPF]

I made the output log much shorter. I Hope, you’ll find all required informations

[mick@~/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra:521]$ sudo ./apply_binaries.sh
Using rootfs directory of: /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Extracting the NVIDIA user space components to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Extracting the BSP test tools to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Extracting the NVIDIA gst test applications to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Extracting the configuration files for the supplied root filesystem to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Creating a symbolic link nvgstplayer pointing to nvgstplayer-1.0
Creating a symbolic link nvgstcapture pointing to nvgstcapture-1.0
Adding symlink /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra/libcuda.so → /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra/libcuda.so.1.1
Adding symlink /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra/libGL.so → /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra/libGL.so.1
Adding symlink /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/libcuda.so → /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra/libcuda.so
Adding symlink /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra-egl/libEGL.so → /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/lib/arm-linux-gnueabihf/tegra-egl/libEGL.so.1
Adding symlinks for systemd nv.service and nvfb.service
Extracting the firmwares and kernel modules to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs
Extracting the kernel headers to /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/usr/src
Adding symlink /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/lib/modules/3.10.40-ga7da876/build → /usr/src/linux-headers-3.10.40-ga7da876
Installing zImage into /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/boot
Installing jetson-tk1_extlinux.conf* into /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/boot/extlinux
Installing the board *.dtb files into /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs/boot
Success!

1. Connected PC with TK1 via “USB-Serial converter” and serial cable
2. Connected an USB port of the PC with the USB port J1E1
3. Started Putty on /dev/ttyUSB0 with 115200,8,1,n, flow control XON/XOFF
4. Powered on Jetson TK1

---

	U-Boot SPL 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)


	U-Boot 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)

	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
	tegra-pcie: probing port 0, using 2 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
	In:    serial
	Out:   serial
	Err:   serial
	Net:   RTL8169#0
	Warning: RTL8169#0 using MAC address from net device

	Hit any key to stop autoboot:  2

---

5. Pressed and hold button , pressed and released button , released button

---

[mick@~/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra:534]$ sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1
[sudo] password for mick:
copying bootloader(/home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)… done.
populating kernel to rootfs… done.
populating jetson-tk1_extlinux.conf.emmc to rootfs… done.
done.
Making system.img…
populating rootfs from /home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/rootfs … done.
Sync’ing system.img … done.
Converting RAW image to Sparse image…

---- Raw to Sparse Image Converter v1.0 ----------------------------
0: RAW: 4239360( 1035 blks) ==> 28:4239372
1: SKP: 24576( 6 blks) ==> 4239400:24588
2: RAW: 6729728( 1643 blks) ==> 4239412:6729740
3: SKP: 26890240( 6565 blks) ==> 10969152:26890252
4: RAW: 11284480( 2755 blks) ==> 10969164:11284492
5: SKP: 85049344( 20764 blks) ==> 22253656:85049356
6: RAW: 8192( 2 blks) ==> 22253668:8204
7: SKP: 4190208( 1023 blks) ==> 22261872:4190220
8: RAW: 3350528( 818 blks) ==> 22261884:3350540
9: SKP: 4096( 1 blks) ==> 25612424:4108
10: RAW: 63111168( 15408 blks) ==> 25612436:63111180
11: SKP: 4096( 1 blks) ==> 88723616:4108
…
1690: RAW: 20480( 5 blks) ==> 2321551188:20492
1691: SKP: 4096( 1 blks) ==> 2321571680:4108
1692: RAW: 16384( 4 blks) ==> 2321571692:16396
1693: SKP: 4096( 1 blks) ==> 2321588088:4108
1694: RAW: 52166656( 12736 blks) ==> 2321588100:52166668
1695: SKP: 1594576896( 389301 blks) ==> 2373754768:1594576908
– Total: -----------------------------------------------------------
1696 CHUNK 8589934592(2097152 blks) ==> 2373754780(579525 blks)

done.
system.img built successfully.
copying dtbfile(/home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/home/mick/NVIDIA/Jetson_TK1/L4T-21.5/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 16871423 8192.0MiB system.img
[ DTB] UV 16871424 16879615 4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[ EFI] UV 16879616 17010687 64.0MiB
[ USP] UV 17010688 17018879 4.0MiB
[ TP1] UV 17018880 17027071 4.0MiB
[ TP2] UV 17027072 17035263 4.0MiB
[ TP3] UV 17035264 17043455 4.0MiB
[ WB0] UV 17043456 17047551 2.0MiB
[ UDA] UV 17047552 30773247 6702.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img
copying flasher(/home/mick/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/home/mick/NVIDIA/Jetson_TK1/L4T-21.5/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: 0x34001001741141021c00000017000380
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: 0x00000001741141021c00000017000380
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
  padded 4 bytes to bootloader
  sending file: u-boot.bin
• 439120/439120 bytes sent
  u-boot.bin sent successfully
  sending file: system.img
  / 2373754780/2373754780 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 208 Secs
  Time taken for flashing 210 Secs
  *** The target ardbeg has been flashed successfully. ***
  Reset the board to boot from internal eMMC.

[mick@~/NVIDIA/Jetson_TK1/L4T-21.5/Linux_for_Tegra:506]$

Output on the serial console during the flash process:

[0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.004] Reset reason: power on reset
[0000.008] Processing in recovery mode
[0000.011] Established communication link with host
[0001.095] Downloaded bct successfully
[0001.099] No Battery Present
[0001.103] Sdram initialization is successful
[0001.115] Downloaded DTB successfully
[0001.141] No Battery Present
[0001.218] Downloaded bootloader successfully
[0001.222] CPU-bootloader entry address: 0x83d88000
[0001.226] BoardId: 375
[0001.228] Vpr Carveout Base=0x0f4600000 Size=0x00ba00000
[0001.234] Tsec Carveout Base=0x0f2600000 Size=0x002000000
[0001.239] Lp0 Carveout Base=0x0f25ff000 Size=0x000001000
[0001.244] Xusb Carveout Base=0x0f2300000 Size=0x000200000
[0001.249] Platform-DebugCarveout: 0
[0001.276] CPU power rail is up
[0001.279] Performing RAM repair
[0001.282] CPU clock init successful
[0001.285] 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: Querying board info from BCT.
EEPROM instance-5: Board info present in BCT is invalid.
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: Querying board info from BCT.
EEPROM instance-4: Board info present in BCT is invalid.
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:B:00:0xff:0xff:0xff:0xff:0xff:0xff
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): 123862672 us

Pinmux changes applied in kernel way

[bootloader] (version UNDEF_BUILD)
Platform Pre Boot configuration…
NvDdkUsbhBlockDevInit…
Initializing Display
The proc BoardInfo: 0x0177:0x0000:0x03:0x42:0x00
The proc BoardInfo: 0x0177:0x0000:0x03:0x42: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=2097152
SD Alloc Partid=13, start sector=2110976,num=1024
SD Alloc Partid=14, start sector=2112000,num=16384
SD Alloc Partid=15, start sector=2128384,num=1024
SD Alloc Partid=16, start sector=2129408,num=1024
SD Alloc Partid=17, start sector=2130432,num=1024
SD Alloc Partid=18, start sector=2131456,num=1024
SD Alloc Partid=19, start sector=2132480,num=512
SD Alloc Partid=20, start sector=2132992,num=1715712
SD Alloc Partid=21, start sector=3848704,num=512
Region=0 SD Erase start 512B-sector=4096,512B-sector-num=4096
Start Downloading PPT
Parallel write enabled

End Downloading PPT
Time taken to download partition: 205 ms

Start Downloading EBT

End Downloading EBT
Time taken to download partition: 199 ms

Start Downloading APP

End Downloading APP
Time taken to download partition: 197980 ms

Start Downloading DTB

End Downloading DTB
Time taken to download partition: 17 ms

Start Downloading GPT

End Downloading GPT
Time taken to download partition: 205 ms
WriterThread: Exiting
Rebooting device after flashing.

U-Boot SPL 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)

U-Boot 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)

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
tegra-pcie: probing port 0, using 2 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
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…
(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… 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
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10

6. Powered off the TK1
7. removed the USB cable from J1E1
8. Powered on the TK1

---

Output on the serial console:

U-Boot SPL 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)

U-Boot 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)

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
tegra-pcie: probing port 0, using 2 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
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…
(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… 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
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again

Some checks from u-boot prompt:

Tegra124 (Jetson TK1) # ext4ls mmc 0:1 /

4096 . 4096 .. 16384 lost+found 1244 boot 0 bin 4096 dev 0 etc 1878 home 1151 lib 4096 media 4096 mnt 4096 opt 4096 proc 62 README.txt 4096 root 4096 run 12288 sbin 4096 srv 4096 sys 4096 tmp 4096 usr 0 var Tegra124 (Jetson TK1) # ext4ls mmc 0:1 /boot < ? > -493894144 rsion="1.0" encoding="UTF-8"?>

[linuxdev]

Ahh! I think I’ve seen this before. Long ago a friend/colleague and myself talked about classes of bugs. There is syntax error, the logic error, so on. Some bugs are “self-correcting” after a brief moment of agony. The bugs where I failed to see something obvious because it was too simple to see without a second pair of eyes was deemed the “well, duh!” bug class (I now consider “well, duh!” a real class of bug). This is one of those, and you are not the first person to have hit this, others have done exactly this same thing before.

I can guess you used wget or similar command line tool to download the sample rootfs. The flash program did exactly what it should do, but does not detect invalid rootfs files. So far as the flash program knows, all data in the system image (produced mainly by sample rootfs) is just random binary bytes.

So the first clue is that the boot loader is reverting to BOOTP. This should not happen if mmcblk0p1 has a valid ext4 file system and extlinux.conf to read. There is no valid ext4 file system, and no extlinux.conf.

The “little detail” which means so much is that when the kernel begins load, you see HTML, not executable code:

... rsion="1.0" encoding="UTF-8"?>
...
...DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//

Apparently this is the HTML web page rootfs is downloaded from, not the sample rootfs. You’ll need to use the actual web link to do the download, the javascript or other design of the page prevents a simple wget style tool from using the same URL that a mouse click would hit. All should be good once the sample rootfs is replaced and apply_binaries.sh is run again (your actual flash steps were correct).

[MickPF]

Hello …,
(I don’t know your name yet)

I’ve checked the root filesystem in the directory “<…>/Linux_for_Tegra/rootfs” - it’s neither corrupted nor damaged in any kind, it’s valid!
Meanwhile I prepared a sdcard: Installed archlinux on it and merged it with the driver package from L4T-21.5. It works and it boots. I did it already some months ago for my Shield tablet.
I found the following partition table on the internal eMMC:

Model: MMC SEM16G (sd/mmc)
Disk /dev/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 48.2MB 8638MB 8590MB ext4 APP hidden, msftdata
2 8638MB 8642MB 4194kB DTB hidden, msftdata
3 8642MB 8709MB 67.1MB EFI hidden, msftdata
4 8709MB 8714MB 4194kB USP hidden, msftdata
5 8714MB 8718MB 4194kB TP1 hidden, msftdata
6 8718MB 8722MB 4194kB TP2 hidden, msftdata
7 8722MB 8726MB 4194kB TP3 hidden, msftdata
8 8726MB 8728MB 2097kB WB0 hidden, msftdata
9 8728MB 15.8GB 7028MB UDA hidden, msftdata

Where can I find informations about/meaning of partitions 4 - 9?
Are partitions no. 2,3 mountable?
I’d like to create a swap partition of 2 GB on the eMMC! Is it possible?

Kind Regards,
Michael

[linuxdev]

The part where kernel execution should start shows instead HTML code (instead of the kernel executing, the serial console shows web page content). This should not be possible.

The sample rootfs is downloaded from here:
https://developer.nvidia.com/embedded/dlc/l4t-Jetson-TK1-Sample-Root-Filesystem-R21-5

This download should produce file “Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2”, which has sha1sum of:

sha1sum Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
edaabb28d70c38c185e379c6277c7d8e6a04f7e6  Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2

…and size is 648258132 bytes. Does this match what you have?

If this matches, then you should be able to see this (test to see if this is really bzip2 format of a tar archive):

bunzip2 < Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2 | tar --list | head -n 10
bin/
bin/rmdir
bin/fuser
bin/gzip
bin/uncompress
bin/bzip2
bin/setupcon
bin/whiptail
bin/touch
bin/tempfile

There is absolutely no way the boot loader should be printing HTML at the point it hands off to the kernel unless the content at that offset is HTML (and I have seen exactly that happen before). In the rootfs directory, is there “boot/extlinux/extlinux.conf”? This is the specific file which was not found as the first file to load from that particular partition.

If the rootfs directory is actually valid, then it seems the loopback creation of system.img would be invalid. The uncompressed “bootloader/system.img.raw” produced during flash, if not corrupt, could be mounted on “/mnt” and explored via:

sudo mount -o loop system.img.raw /mnt
cd /mnt
ls
cd boot/extlinux
cat extlinux.conf
cd
sudo umount /mnt

I do not have a list of partition descriptions, but often this is related to boot or referenced during boot. Boot itself has some documentation here:
http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
http://http.download.nvidia.com/tegra-public-appnotes/bct-overview.html

[MickPF]

I’ve checked these things:
The SHA1 sum is OK
The file size is OK
I can mount the image raw file, its content is OK

[linuxdev]

Something really odd is going on. Perhaps it was a copy and paste error when posting the log. If you look near the end of the log from serial console, look closely where it says “DOCTYPE” and UTF-8 encoding. This is absolutely the start of a web page’s source code (you couldn’t even mouse copy and paste this from a web page without viewing source code directly). Unless there was a copy and paste error, this is the exact content of the eMMC in the root partition from the first bytes read while trying to search for extlinux.conf for configuration.

As mentioned previously, the messages while in u-boot, prior to trying to hand off to other code, indicate that the search for a valid ext4 partition on mmcblk0p1 did not succeed. It would have been possible that the HTML code had been put in extlinux.conf instead of correct content, but if that were the case, then extlinux.conf would have been found and BOOTP type search would never have shown up…the partition itself is not ext4 at mmcblk0p1 even if the HTML was a copy and paste issue.

If the sample rootfs is unpacked in the rootfs subdirectory as root (or sudo), then this will show up as a nearly identical match to what you see in the loopback mounted system.img.raw. The apply_binaries.sh step and actual driver install add things to “rootfs/boot/”, none of which is HTML. I recommend checking the loopback mounted system.img.raw to see if it really contains “boot/extlinux/” subdirectory, and if within that “extlinux.conf” exists. If loopback of the raw image is valid, then failure had to be in creation of the sparse image from that raw image (I’m assuming the driver package “rootfs/boot/extlinux/” directory exists in the first place to have created this on the raw image).

If all else seems normal, here’s what I suggest:

1. Delete the driver package content in the rootfs directory..."cd rootfs", then "sudo rm -fR *"...just be very careful you are in the driver package rootfs directory.
2. Unpack the sample rootfs there again, e.g., cd into that rootfs directory, then "sudo tar -xjfv ../Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2".
3. cd ..
4. sudo ./apply_binaries.sh
5. rm -f bootloader/system.img*
6. # flash again, e.g., sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

If this does not solve it, then one of the other files involved in the flash has had its content replaced by HTML. If that happens, I’d delete the entire driver package and unpack it again, going through sample rootfs steps and such from a fresh install. I believe your steps are correct, and the hardware is performing as intended, but the data being flashed is from HTML and not from where it should be from.

[MickPF]

Hello ,

I gone an other way to determine the reason:
I booted Archlinux from a sdcard, mounted the partition ‘/dev/mmcblk0p1’ (1st partition of the eMMC).
The filesystem is completely valid!

I think, the u-boot.bin cause failures accessing ext4fs on the eMMC!

What do you think about this idea?

I could try to use the u-boot.bin from the driver package of L4T-21.4

Kind Regards
Michael

[linuxdev]

There are several parts of eMMC involved in boot, and several “.bin” files written during flash to hidden partitions (e.g., configuration for boot control). U-boot itself is correct, as boot reaches this. Since the mmcblk0p1 partition is valid, one of these other images must have been replaced with HTML (what u-boot is trying to load is HTML, not binary executable…one of those images used in flash must be corrupt).

In this case I believe you are better off completely deleting your driver package and unpacking it again…starting fresh. This would mean you don’t need to figure out which file was replaced with HTML…and even if you did find a file needing to be fixed, there might be others.

[MickPF]

Hello …,

Sorry for the late answer. I could not do it before.

I followed your advice several times, but always with the same result.
I could find the files with this “HTML” content in /usr/share/polkit of the eMMC!
I also tried to downgrade to R21.4: the same result as with R21.5!
Why boots it from a SD-Card and it fails from eMMC?

Kind Regards
Michael

[linuxdev]

What was the exact flash command? Also, HTML was an issue when it went to load the kernel from u-boot and instead found HTML. There are places in “/etc” which may be valid HTML, but those will not be visible until far into the init process.

Part of the issue seems to be that u-boot may not find a valid ext4 partition with extlinux.conf on mmcblk0p1…in which case it falls back to other searches, e.g., bootp, and other devices. Some of the hidden partitions take part in determining boot control prior to the Linux kernel ever taking over, so these may be involved, but it’s hard to say without actually examining those files to see if they are corrupt.

Here is one thought…not all u-boot vendors support ext4. The archlinux may have overwritten the nVidia version of u-boot and changed boot order due to not of understanding ext4 (not understanding ext4 and having corrupt ext4 are basically equivalent). Is it possible you did not flash using purely the nVidia images? Or alternatively, if you tried to flash but the boot image did not succeed and archlinux remained, this too could cause the wrong u-boot image to be present. If your host hard disk did not have enough space it is also possible to have truncated the flash images and not completing image writes even if commands were otherwise correct.

[MickPF]

Hello,

I used ‘./flash.sh jetson-tk1 mmcblk0p1’ as root from directory ‘…/Linux_for_Tegra’. I also tried it with size options “-S 8GiB” and “-S 16GiB”.
You’ll find “HTML” files with the content as described in my log above in ‘/usr/share/polkit’ only and no one in ‘/etc’ or in its subdirectories!
Archlinux could not overwite any thing on mmcblk0, because it hasn’t any installer like Ubuntu or Fedora! You must untar the rootfs on a device and configure some parts manual. As root user you get full control. By the way, the sd card with archlinux was rejected when I flashed mmcblk0 and the device started after flashing! I never installed Archlinux on mmcblk0, Only on the sd card and on a SATA harddisc! The harddisc in my host has about 200 GB free space and about 40 GB in the tmpfs!
I checked all files many times before flashing!

I think, your advice with some files loaded before u-boot is much better!

As I saw in the source code and in u-boot, you don’t support booting from a SATA device directly! Why?
One more questions: which device in ‘/sys/bus/i2c/devices’ is connected with signals “GEN2_I2C…” on the connector J3A1 (Display/Touch Expansion Header)?

Kind Regards,
Michael

[MickPF]

Could you send to me your original dump of the mmcblk0 (R21.4 or R21.5) made by command ‘dd if=… of=…’? Compressed by bzip2 or xz. I’d dump it to my mmcblk0!

[linuxdev]

The default flash size should work, but “-S 8GiB” is likely too small and will truncate (testing results with this are probably invalid), while “-S 16GiB” is too large (this size is a guaranteed invalid test). The parameter to use for not wasting any eMMC space is “-S 14580MiB” (this leaves room for the hidden partitions). I strongly suggest trying to flash again with “-S 14580MiB”.

About Using Root Permissions…Just to be Thorough (though not likely the issue)…
Flashing as root (or sudo) is correct, as there may be a need to create a loopback device during flash (only root can do this). There are also files in the sample rootfs which need to be copied during flash while preserving root permissions, so this too requires root. Device special files themselves typically cannot be created without being root. But…you must also be sure that the sample rootfs itself was unpacked with root authority. If the files were not unpacked as root, then permissions in sample rootfs will be wrong before flash ever copies those files. Sometimes people with a non-Linux file system underneath this have flash fail (or rather behave oddly) because non-Linux file systems imply not preserving permissions which are not understood by that other file system type (e.g., NTFS and VFAT are incapable of preserving Linux permissions). Lastly, the apply_binaries.sh script must be run as root since this unpacks files with root permissions into the sample rootfs. The only steps I didn’t see you verify as via root was unpacking sample rootfs and apply_binaries.sh…so to be thorough make sure those were also done as root.

About Boot Device Support…the LONG Paragraph…
So far as SATA or any other bootable device goes, booting from that device requires support in both the kernel and the boot loader. On a desktop system the BIOS (or UEFI) would provide standardized interfaces to what the motherboard wants to provide as bootable devices, so the boot loader itself does not need to have its own custom driver for those devices on a desktop system (the motherboard has those minimal drivers in firmware). In the case of embedded systems there is no such thing as a BIOS, so everything in the BIOS is custom programmed into the boot loader for that device. There are limits to the size of a boot loader, though I don’t know offhand what those limits are…but if you were to include support for things like an HDMI monitor, then you would have to put all that code into the boot loader. Things would grow, and writing bare metal applications (which the boot loader is) is very different and more difficult versus writing this with operating system support (though authoring a video driver with operating system support would still not be trivial).

So typically, unless someone needs that support while the boot loader runs, no such driver is added to the boot loader. In many cases a driver is added for basically a class of devices, such as mass storage, and the first one found is used…but unlike a desktop, that would preclude having more than one of that device class connected at once (u-boot would see only the first one in a search list even if the kernel sees them all). U-boot supports minimal additional devices for boot, but does not make provision for the SATA controller. It turns out that USB is supported, and USB mass storage is easy to deal with, so this is supported…but no driver to the SATA controller is added (the USB external hardware has its own controller, no need for controller code in u-boot when doing this). Both kernel and u-boot can see USB mass storage, but u-boot cannot see SATA controller devices.

Yes, it would be useful to add SATA controller support to u-boot, so perhaps one day this will go in. The workaround is to put extlinux.conf and boot information on eMMC, and when the boot loader hands off to the kernel, the kernel sees both SATA and USB, so root file system can go anywhere (even SATA…the trick is you can’t use SATA for boot loader config files, but this does not restrict root partition location). Related to all of this, you may find you can boot from a USB thumb drive or a USB external disk drive, but if both are connected while booting the boot loader may ignore one of them…adding a menu for booting to each separate USB device in extlinux.conf would not do any good.

So…would it be possible for you to try to flash with “sudo ./flash.sh -S 14580MiB mmcblk0p1 jetson-tk1”, and to see what serial console shows when it boots using those specific parameters?

FYI, the file “bootloader/system.img.raw” should be an exact copy of what went onto the root partition of the Jetson during flash. You can use cloning to essentially dd copy not just the root partition, but any partition, or all partitions in a single file. See:
http://elinux.org/Jetson/Cloning

The trick is that the only partitions which are not binary data are the partition table and the root file system partition. You can view the partition table with a text editor, or just “cat” the file. The raw root partition can be loopback mounted and examined…and in fact you could take a checksum of the kernel image from the root partition clone and compare it to the checksum of the kernel in the sample rootfs and the loopback mounted system.img.raw…they should all match.

The raw root partition image is about 15GB, I don’t have a practical means of posting such a file. The binary clone of the whole eMMC is 16GB.

Someone else may be able to answer the i2c question, I have not experimented with i2c on the JTK1.

[MickPF]

Hello,

I tried with the size parameter “-S 14580MiB”. You can guess the result…
Could you compressed the image of the eMMC, upload it to a public server and send me the link to the file? I’d download it within few Days.

T Android is shit OS. It changes m

[linuxdev]

If you have a place that will allow me to upload a multi-gigabyte file I can do that although this is unlikely to change anything.

However, I went back and did notice something…you are using PuTTY during flashes. Normally I would not expect someone to use PuTTY under Linux, but the part which may be significant is that serial console could interfere with flash…this interface is normally not used during flash. Assuming serial console only reads data and does not send anything it should not hurt flash…but on occasion there is something similar to a phantom key stroke during startup which can interfere. I would try flashing with the serial console disconnected as a final test.

Also, after the “-S 14580MiB” flash, be sure that file “bootloader/system.img.raw” is exactly 15288238080 bytes (14580 * 1024 * 1024). Is this the exact file size for you? For the sake of testing make sure neither SD card nor USB storage is active during flash or boot.

[MickPF]

Hello,

I’ve got a NAS harddisc with Cloud Function, but I couldn’t get it running as the Internet Cloud space!
So, I don’t habe any other possibility for uploading files. Sorry!

Kind Regards
Michael