[SOLVED] [L4T21.1] problem booting from SATA

Hello,

I have read all posts on this forum regarding booting Jetson from SATA SSD. However I’m not able to flash jetson tk1 so that it has rootfs at SATA drive.
I would kindly ask you for any help.
These are the steps that I have performed :

partitioned my SSD in a way that first partition is 14GiB

downloaded L4T 21.1 from this link http://developer.download.nvidia.com/mobile/tegra/l4t/r21.1.0/Tegra124_Linux_R21.1.0_armhf.tbz2

downloaded sample rootfs from this link http://developer.download.nvidia.com/mobile/tegra/l4t/r21.1.0/Tegra_Linux_Sample-Root-Filesystem_R21.1.0_armhf.tbz2

extracted L4T21 with tar xpf …

extracted sample rootfs into rootfs subdirectory with tar xpf

run sudo ./apply_binaries.sh

copied content of rootfs to the 1st partition of the SSD with cp -a …

unmount SSD and connected it to the TK1

connected TK1 to the HOST PC and started it in recovery mode

performed sudo ./flash.sh -S 14GiB jetson-tk1 sda1

it took 15 seconds to complete without reporting any error and informing me to reboot jetson

disconnected usb from jetson

reset the jetson and nothing happens - black screen

I have no clue what I’m missing here. The only idea that crosses my mind is to provide additional -L parameter specifying fastboot.bin.

Can you please assist me with this matter ?

many thanks
Mirko

Since 21.1, you can’t do that anymore. uBoot is configured for internal flash, usb or sd only.
Actually, i’m running Debian SID installed on the internal flash with /home on a S-ATA SSD.
I don’t know if uBoot can boot on S-ATA.

Yes, I want to know why you can’t boot from a SATA SSD as well!

UBoot certainly can’t be the issue, since I have a WANDBoard with UBoot, and I can boot Linux from a SATA SSD just fine (and Linux runs much, much, faster from it than the built-in flash).

Same problem here. I own lots of ARM devices and never had problems with booting from sata (cubox, goflex, etc.). What`s the issue here?

Does somebody know how to define default uboot hush script? I don’t have an usb-serial cable right now and I really would like to use uboot netconsole, but I’m not able to change the uboot environment. I tried

./flash.sh -L bootloader/u-boot.bin -s boot.script ...

boot.script should activate netconsole, but nothing changed… :-(

It seems U-Boot of L4T R21.1 cannot access SATA.
So I did load kernel from internal mmc and mount SATA HDD in ‘/’.
It is not “boot from SATA storage”, but it works like boot from SATA storage after boot.

At first, install L4T R21.1 to internal mmc.
Then, download sample file system and copy it to SATA storge.

wget http://developer.download.nvidia.com/mobile/tegra/l4t/r21.1.0/Tegra124_Linux_R21.1.0_armhf.tbz2
wget http://developer.download.nvidia.com/mobile/tegra/l4t/r21.1.0/Tegra_Linux_Sample-Root-Filesystem_R21.1.0_armhf.tbz2
sudo tar -vxjf Tegra124_Linux_R21.1.0_armhf.tbz2
cd Linux_for_Tegra/rootfs
sudo tar jxpf ../../Tegra_Linux_Sample-Root-Filesystem_R21.1.0_armhf.tbz2
cd ..
sudo ./apply_binaries.sh
sudo mount /dev/sda1 /mnt/jetson
cd rootfs
sudo cp -a * /mnt/jetson && sync
umount /mnt/jetson

Login to Jetson TK1.

cd /boot/extlinux
sudo cp jetson-tk1_extlinux.conf.usb extlinux.conf
sudo shutdown -h now

(When you boot internal mmc, copy jetson-tk1_extlinux.conf.emmc to extlinux.conf)

Connect SATA storage to Jetson TK1.
Then, you boot Jetson TK1 and you will get ubuntu from SATA storage.

When U-Boot try to boot linux, it scan and read extlinux.conf.
extlinux.conf has path to kernel file and boot arguments.
Boot argument “root=/dev/sda1” writen in jetson-tk1_extlinux.conf.usb means /dev/sda1 is mount as root filesystem.
If USB storage is connect, /dev/sda1 corresponds to USB storage.
If SATA storage is connect, /dev/sda1 corresponds to SATA storage.

Many thanks for all answers. Demotomohiro, I will try your setup procedure tonight and will let you know how it goes.

Demotomohiro, thank you very much ! I have made it to place rootfs on SSD :) Thank you very much

Great! This worked really nice. I managed to setup an ubuntu core system on my ssd and it’s really fast… :-D

demotomohiro’s solution also worked for me, thanks!

I have successfully reflashed the TK1 Jetson board with L4T R21.4.
I have also downloaded the whole TK1 Jetson pack including CUDA dev kit and examples.
It has taken up ~7GB on the eMMC and another ~7 GB is free.

Now a SATA HDD with a 64 GB ext4 partition (blank) is connected to the board and I want to use it as the boot + work drive.

Can I copy the complete eMMC contents to the SATA partition using some methods like Live Boot or GParted boot and directly copy paste the whole eMMC mmcblk0p1 drive to the SATA ext4 partition (shown as /sda4 in Partition Table)? Is this possible and correct way?

If the file system gets copied (entire system backup) into the HDD, then can I edit
/boot/extlinux/extlinux.conf and add “root=/dev/sda4” to “root=/dev/mmcblk0p1”?

If this does not work and the system stops working, how can I recover the boot from eMMC again without any reflash?

Thanks in advance,

Here’s what I’d suggest. Add a copy of the default entry in /boot/extlinux/extlinux.conf. Change the name of that entry. Change the “root=” to “root=sda1”. If you select this entry at boot from serial console, the eMMC /boot will still be used, but the rest of the root file system is your SATA drive’s first partition. I’m not sure if u-boot is capable of using other partitions, e.g., it might or might not support naming sda2 through sda4. However, by leaving your original entry in extlinux.conf, you can dual boot to this entry (default) or to SATA and test without risk.

Any method which copies the original eMMC root partition to the SATA drive should work fine and function as a clone of the original. If you were not concerned with some customization of the original file system, you could do something simple like mount the drive on your host and unpack sample rootfs there, followed by apply_binaries using the the “-r PATH” option to name wherever your SATA drive is mounted.

Should you be satisfied, you could make this alternate extlinux.conf entry the default. In this case you would still need the /boot directory on eMMC but nothing else would be required.

There is how to clone partition on Jetson tk1 and how to mount image file of it on this site.
http://elinux.org/Jetson/Cloning
Mount system.img file and copy files on it to SATA HDD with “sudo cp -a src/* dst” command on host PC.
Then, boot jetson tk1, open extlinux.conf and change “root=/dev/mmcblk0p1” to “root=/dev/sda4”.

I’d suggest a recovery SD card as alternative way.
U-Boot on Jetson tk1 boot from a SD card if it has extlinux.conf and kernel.
If U-Boot couldn’t boot from a SD card, it will try to boot from eMMC.
If you want to know whether jetson is boot from sd card or eMMC, try ‘df -h’ commant to see size of root file system or ‘cat /proc/cmdline’ to see kernel command line.
It will work without serial console and host PC, if it works fine.

When you copy files on eMMC to SATA HDD, insert SD card to jetson tk and boot from it.
Then, mount eMMC and SATA HDD and copy files from eMMC to SATA HDD.

mkdir emmc
mkdir hdd
sudo mount /dev/mmcblk0p1 emmc
sudo mount /dev/sda4 hdd
sudo cp -a emmc/* hdd
#open emmc/boot/extlinux/extlinux.conf and change "root=/dev/mmcblk0p1" to "root=/dev/sda4"
sync
umount hdd
umount emmc

Even if you failed something, you can boot from SD card, mount eMMC or HDD and edit files on them.

Here is how to make recovery SD card.
You can do this from Jetson tk or other linux machine.

wget http://developer.download.nvidia.com/embedded/L4T/r21_Release_v4.0/Tegra124_Linux_R21.4.0_armhf.tbz2
wget http://developer.download.nvidia.com/embedded/L4T/r21_Release_v4.0/Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2

sudo tar -vxjf Tegra124_Linux_R21.4.0_armhf.tbz2
cd Linux_for_Tegra/rootfs
sudo tar jxpf ../../Tegra_Linux_Sample-Root-Filesystem_R21.4.0_armhf.tbz2
cd ..
sudo ./apply_binaries.sh
mkfs.ext4 /dev/mmcblk1p1
mkdir /mnt/sd
sudo mount /dev/mmcblk1p1 /mnt/sd
cd rootfs
sudo cp -a * /mnt/sd && sync
umount /mnt/sd

What I wrote in this post is not tested by myself.
There might be some mistake.