It stopped at the U-Boot console. This is before Linux starts (and you can’t run “dmesg” if Linux didn’t start). If a stray character is received during a short time within U-Boot, then U-Boot thinks you are wanting to stop in its console mode. Missing what it needs to continue boot could also do this. So when you see this line, type “boot” and hit the enter key…see if you can log more:
Tegra124 (Jetson TK1) #
It is looking like the boot environment is invalid. The only think you’d ever see on the HDMI (if anything) would be a brief showing of the NVIDIA logo. If “boot” does not get this going further, then I’d say something catastrophic has occurred, and that flashing again would be mandatory, but that perhaps the hardware may no longer accept a flash if it was an eMMC failure.
Odds are that your flash procedure missed something. Once we know what happens with “boot” we can go over flash procedure and see if that is the issue.
this is login after boot
putty.log (4.29 KB)
this is my reboot step:
1.download Tegra124_Linux_R21.5.0_armhf.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2 in windows and copy them to VM`s ubuntu:
2.sudo tar --numeric-owner -jxpf Tegra124_Linux_R21.5.0_armhf.tbz2
3.cd linux_for_tegra/rootfs
sudo tar --numeric-owner -jxpf …/…/Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
4.sudo ./apply_binaries.sh
5.sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1.
1.download Tegra124_Linux_R21.5.0_armhf.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2 in windows and copy them to VM`s ubuntu:
2.sudo tar --numeric-owner -jxpf Tegra124_Linux_R21.5.0_armhf.tbz2
3.cd linux_for_tegra/rootfs
sudo tar --numeric-owner -jxpf …/…/Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
4.sudo ./apply_binaries.sh
5.sudo ./flash.sh -S 14GiB jetson-tk1 mmcblk0p1
is this wrong?
it become a APX divice when i want to reboot it today! Is it still saved?
You would only need to use tar within the rootfs folder, not sure where you ran it the first time, but that plus apply_binaries.sh and flash are correct. If the Jetson now boots you are good to go. This would have flashed a new operating system from scratch.
Incidentally (just trivia), apply_binaries.sh just adds files from a tar file. The sample rootfs is pure Ubuntu, and the files from apply_binaries.sh is what makes the rootfs work on Jetson hardware. The same tar archive apply_binaries.sh unpacks can be directly unpacked within the Jetson “/” directory. When you run “sha1sum -c /etc/nv_tegra_release”, then mostly the checksums are from the apply_binaries.sh files.
my login is useful?
has it display the reason for it not work?
in windows and copy them to VM`s ubuntu:
We don’t support VM as a ubuntu host.
I hadn’t noticed the VM part…VMs lose USB as it disconnects and reconnects (the VM’s host tends to take the port). This would cause a flash failure somewhere in the middle of the procedure. It is best to use a native Ubuntu host PC install, e.g., dual boot. VMs can be made to work, but it might take a learning curve and some extra effort to guarantee the VM has complete ownership of the USB during disconnect/reconnect cycles, and to completely own networking during extra package installs if using JetPack.