[HELP!] Configuring SSD & L4T Install & Boot Configuring

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

I have just received my SAMSUNG 850 EVO 250GB SSD and a 22 PIN SATA Power/Data Cable. I honestly need some help cause there is no documentation on what I’m doing and attempting this myself without any help isn’t going to work well. Plus I’m a newbie. I would like to have my OS “L4T” on my 250SSD this way my file system can build up on a larger drive other than the on-board 16GB of flash.

This is what I have done already. I would greatly appreciate some guidance here cause I know there are others who might want to do this as well.

I’ve plugged my SSD into the SATA 22 PIN header on the Jetson TX1 with the Power OFF. Click on the below link…
[url]http://i.imgur.com/OtsXHp8.jpg[/url]

Next I plugged in my TX1 and pressed the power button. After bootup and login I opened terminal and the application “Disks”. In terminal I typed

lsblk

The lsblk clearly showed that my SSD is being recognized as sda. “Disks” also showed my SSD. Click on the below link…
[url]http://i.imgur.com/0rxIZtv.jpg[/url]

At this point I’m lost on what I should do. I know that I need to format/partition this SSD some way and I’m confused on how exactly I should go about doing that. I see if I click on the gear icon in “Disks” it gives me the option to format and I assume there is a built in partitioning tool i can run from terminal. Click on the below link…
[url]http://i.imgur.com/YzXt0zV.jpg[/url]

I would assume that I would following the install guide located here [url]https://developer.nvidia.com/embedded/jetpack[/url]. However, I don’t understand how I suppose to tell it to flash my OS and install the jetpack tools to my SSD location and not the on-board flash. So to me the install guide is useless if I’m using the SSD.

Once my SSD has the image/file system on it I assume I need to tell my boot manager to boot into the SSD from this point forward. Have no idea how to do that either. I’m sure there are several other steps I must take.

This is a big post and I understand I’m asking alot here but would greatly appreciate some guidance so by Sunday I still have some hair left. Once this process is finished I will post a full documentary of my steps so the next newbie doesn’t have to struggle.

2

I just use command line, so I can’t tell you about GUI tools on Ubuntu. On either a host PC or the Jetson, use gdisk and create a partition (probably using default sizes to use the whole disk). The disk itself is shown already as sda, which means file “/dev/sda” is the disk. However, you need a partition to format, and thus the partition you would create becomes “/dev/sda1”. It is sda1 you format and populate with your root file system. Once sda1 exists you can format it as ext4. Assuming sda on the Jetson (device changes if you are on your desktop host…don’t format the wrong disk):

sudo mkfs.ext4 /dev/sda1

A heads up to aid you, you will have a much easier time if you have a serial console. This is trivial to set up, but you need the cable. See:
http://elinux.org/Jetson/TX1_Serial_Console

On a desktop computer you can use the BIOS to set boot disk, or else you’d be able to install something like a boot selection via the boot loader. None of this exists on an embedded system, but you still have a boot selection screen…the thing is that this screen is visible to a serial console, and not to the directly attached keyboard/monitor. Having serial console means you can set up a lot of different boot selection entries and pick at boot time the one you want. You could skip using an alternate entry and serial console, but if it fails, you’d be stuck flashing to get the system back.

Your existing Jetson install uses the u-boot boot loader. This boot loader reads the file “/boot/extlinux/extlinux.conf” on the eMMC. An entry in there names “root=mmcblk0p1” to refer to the eMMC root partition. The corollary on SATA you would be using would edit this and it would become “root=/dev/sda1”. Having a second extlinux.conf entry with a new label which has this edit means the original entry is still there and usable without changing the Jetson’s default. You would just need to select an alternate boot entry at boot start via serial console. If desired, then that entry could be made the default after you’ve tested.

The URL you gave contains what you want. You would download the driver package, plus sample rootfs. You need to use root (e.g., via sudo) on your desktop PC to unpack the sample rootfs into the rootfs subdirectory, and then running “sudo ./apply_binaries.sh” customizes that sample specifically for your Jetson in certain way. If you were to flash there would be some boot loaded edits made to this rootfs and it would flash this and other things to your Jetson. Since you are using an already working Jetson and only putting software on the SATA drive, most of this is not needed. Instead, as root (sudo), unpack sample rootfs to the SATA drive’s first partition. On Jetson it was “/dev/sda1”, but depending on what disks are on your host, you’ll have to use the different name, e.g., if your host has two hard drives already, and you add SATA, it’ll be “/dev/sdc1” instead of sda1. Mount this somewhere, unpack sample rootfs to it. The option to “apply_binaries.sh” to use an alternate path is “apply_binaries.sh -r /some/mount/point/for/sdc1”.

Then when this is connected to Jetson and becomes sda1 the extlinux.conf entry for this simply boots instead to SATA. No flash is required for this, although the apply_binaries.sh was used for preparing the sample rootfs on SATA instead of the flash software’s rootfs directory.

3

Thank you for this write up. Much appreciated. I will attempt this procedure without a serial console first and post any questions/errors that come up here. Should I need to resort to the serial console I will. Looks like its going to be a long night.

4

linuxdev

What is the way I should set up my partition scheme or can i just have one massive partition. I would think I would at very least need a Boot and root partition.

First Partition Bootable Partition
Second Partition rootfs

or…

First Partition Bootable Partition
Second Partition swap
Third Partition rootfs

or…

First Partition Bootable Partition
Second Partition swap
Third Partition rootfs
Fourth Partition home

I think i remember reading a thread that swap is not supported unless I recompile from source which I would like to re-frame from doing ;) unless its easy.

Lastly, when I’m creating these partitions using fdisk there isn’t any partition types that say “specifically” home,root,boot,swap. Here is the screen shot of what I have for options. Based on whatever correct scheme I use above what are the correct partition types I should be using.
[url]http://i.imgur.com/vU4f76l.jpg[/url]

5

The root partition, if on SATA, must be sda1…I believe limitations in u-boot will stop it from booting beyond that as root partition (somewhere I recall seeing that sda2 may not be available in u-boot stage). The normal install where extlinux.conf points at a root partition is itself on eMMC (mmcblk0p1), along with firmware DTB files and kernel. So a separate “/boot” partition would not do anything unless you reflash and tell it to point the boot loader elsewhere (the concept of where Jetson looks for u-boot binary is the first step, separate from where the u-boot binary will then find its extlinux.conf to load…which is in turn separate from the root partition unless it happens to point to the same root partition for files to load and everything else). To edit the proper extlinux.conf you must edit the one on eMMC/mmcblk0p1 even if there is a copy on SATA/sda1…this extliux.conf acts as a pointer to other files plus the kernel command line to pass on.

NOTE: You can use gparted, gdisk, or fdisk for partitioning. I believe gdisk/gparted is probably the modern way, this uses GPT partition schemes. Older BIOS scheme is limited and more or less going out of style. U-boot definitely has GPT support, this is what is used by default.

6

Success so far!

Jetson TX1 running a basic linux install

Created my partition sda1…
[url]http://i.imgur.com/73ri7tb.jpg[/url]

Formatted to ext4…
[url]http://i.imgur.com/mizzsnu.jpg[/url]

Changed extlinux.conf to…
root=/dev/sda1
[url]http://i.imgur.com/q68zNNd.jpg[/url]

HOST PC running Ubuntu 14.04

Downloaded latest Jetson TX1 64-bit Driver Package and unpacked it…
[url]http://i.imgur.com/rS3ZezV.jpg[/url]

Downloaded 64-bit Sample Root Filesystem, unpacked it, moved it into the rootfs directory and ran the apply_binaries.sh…
[url]http://i.imgur.com/B2POCMR.jpg[/url]

Still confused on what to do next. You indicated I should do two things…
1.) Mount ssd “sda1” and unpack Sample Root Filesystem

2.) Run apply_binaries.sh as such

apply_binaries.sh -r /some/mount/point/for/sdc1

I assume I have to attach the usb cable and have the board in “Force USB Recovery Mode” correct!? The part that confuses me is how is my host computer suppose to see the ssd “sda1” on my TX1?

What would the command look like for mounting the ssd. Is this done on the host or TX1?

You indicated I may need to change a copy of a extlinux.conf file that may exist on my SATA/sda1. Will there be two rootfs, one on mmcblk01 and one on sda1? I thought there would only be one which would be on sda1.

I’m apologize for these newbie questions and thank you so much for helping me out…

7

I am assuming you can attach the SSD to your host desktop. Once the first partition is formatted, it can be mounted, e.g., if the SSD is the second hard drive then its first partition is “/dev/sdb1”, or if it is the third drive, then its first partition is “/dev/sdc1”. On the assumption this is the third hard drive on your host PC, then after formatting as ext4 you can do this:

sudo mount -t ext4 /dev/sdc1 /mnt

…this makes the hard drive available on “/mnt”. I used “/some/mount/point/for/sdc1” as an illustration to the fact that the partition can be mounted anywhere you like (but “/mnt” is traditional).

Once the drive is mounted, it could also be unmounted (note that “umount” will fail if you have a logged in session which has “cd” into a directory of the SSD…this would cause the drive to be “busy” and refuse “umount”):

sudo umount /dev/sdc1

A drive which is mounted can have sample rootfs unpacked into it, as well as having the “apply_binaries.sh” script update that drive by naming its mount point in the “-r” option. So for example, if you just “sudo apply_binaries.sh”, you would update the sample rootfs in the “rootfs” subdirectory…this is not what you want…to instead update a partition mounted on “/mnt”:

sudo ./apply_binaries.sh -r /mnt

Understand that normally u-boot reads its extlinux.conf configuration, and then once configuration is read, u-boot ends its life by overwriting itself with the Linux kernel. The directory where u-boot gets its configuration is most often the same partition where the kernel loads its root partition. Those two do not have to be the same. As is, u-boot will find its configuration on “/boot” of the eMMC. Once the kernel is loaded, the kernel can continue reading from a different partition instead of the same one. Until the boot loader is completed, the extlinux.conf and kernel images are read from eMMC. When kernel execution begins based on “root=/dev/sda1” the mmcblk0p1 “/boot” used by u-boot no longer matters. extlinux.conf at that point (and “/boot” in general) no longer matters…u-boot which uses these files no longer exists. Installing a sample rootfs onto sda1 will create a boot directory there, but this is nothing more than unused space. You could edit the sda1 version of extlinux.conf and nothing would happen. You could mount eMMC somewhere, e.g., “sudo mount /dev/mmcblk0p1 /mnt”, and then edit “/mnt/boot/extlinux/extlinux.conf”, and this would be used by u-boot at next boot.

8

Having an issue here cd’n into the drive I mounted as it says ‘cd’ is not recognized. Maybe I can’t ‘cd’ into a drive versus a directory!!!..

I ran the following command…

sudo mount -t ext4 /dev/sdb1 /mnt

to mount my ssd.

After that I ran the following command to see if it mounted…

sudo cd /mnt

ls

I noticed the directory “lost+found” which I assume is my ssd as it wasn’t there before (Why is it called lost+found?)?
http://i.imgur.com/yu4O7aI.jpg

My question now becomes how do I go about unpacking my rootfs into it? I can’t ‘cd’ into this directory called lost+found as shown below so I assume there is another way I should be doing this?
http://i.imgur.com/Jr6g8uj.jpg

Lastly, I downloaded the 64-bit Jetson Driver Package and Sample Root Filesystem as shown…
http://i.imgur.com/xNs4AAh.jpg
You mentioned above that since I already have a working Jetson I only need to unpack the rootfs onto the ssd. So do I need the 64-bit jetson driver? I would think I do since it has the apply_binaries script in it as well as the rootfs directory that I must move my downloaded Sample Root Fileysystem over to in order to run sudo ./apply_binaries.sh.

In conclusion, I’m alittle unsure what the process looks like as far as what needs to move into what and what needs to get unpacked. Could you explain/layout what that process looks like and how this driver package comes into the picture?

I’ve only tried mounting the ssd ‘sdb1’ and ‘cd’ into it which failed like i mentioned above. However, this is what my understanding is thus far on what I should do. Therefore, hopefully you can tell me what I’m misunderstanding or what I’m getting right and what I’m getting wrong.

1.) mount ssd

sudo mount -t ext4 /dev/sdb1 /mnt

2.) Move both the downloaded tar packages for the driver and sample root file system into the mounted drive

sudo mv /home/shaneyost/Downloads/Tegra210_Linux_R24.1.0_aarch64.tbz2 /mnt/lost+found

sudo mv/home/shaneyost/Downloads/Tegra_Linux_Sample-Root_Filesystem_R24.1.0_aarch64.tbz2 /mnt/lost+found

3.) ‘cd’ into lost+found (which like i mentioned above I can’t do)

sudo tar xpf TheDownloadedDriver
sudo tar xpf TheSampleRootFilesystem

4.) Move TheSampleRootFilesystem into the rootfs directory thats in the Driver directory I untared

sudo mv TheSampleRootFilesystem TheDownloadedDriver/rootfs

5.) cd in the rootfs directory of the driver and run

sudo ./apply_binaries.sh -r /mnt

6.) unmount

9

If “/mnt” was root-only I’d expect that the cd into there via sudo would work until your regular user is given back non-root access…then it’d throw you back out. Try staying in a root shell via “sudo -s”…then you don’t need to prefix everything with sudo. When done “exit” to not be in the root shell.

“lost+found” is a place for automated repair utilities to put inodes (components of a node-based file system) when a corrupted file system is repaired. The idea is that an admin may be able to figure out what was lost. The use of journals prevents this from happening very often, but any node-based Linux file system from ext2 through ext4 will have “lost+found”. This directory will always be empty unless there is corruption the journal can’t figure out. If you lose part of your file system, this is where you can find it. Nothing should ever be here under normal operation.

The lack of a “cd” command is a serious problem. But…you don’t normally “sudo cd”, either you have permission to change to that directory or not. “sudo -s” will give you root authority even after the cd completes. I suggest “sudo -s” and then “which cd” to see if it finds it. If not, your host has some serious problems…you could do this for debugging:

echo $PATH

The driver package is mostly used for flashing, but it also has a utility in it to help with preparing a sample rootfs. When installing to the SSD, you can ignore most of flash. Assuming you have already “cd” into “/mnt” after “sudo -s”, you could do something like this to unpack (there are many ways to do this):

bunzip2 < ~/Downloads/Tegra_Linux_Sample-Root-Filesystem_R24.1.0_aarch64.tbz2 | tar xv

Then, from whereever you’ve unpacked the driver package, there will be a script “apply_binaries.sh”. You could find that, and then while still in “sudo -s”:

./apply_binaries.sh -r /mnt

…note that apply_binaries.sh defaults to working on the sample rootfs in the driver subdirectory…the “-d” tells it an alternate location.

You could then shut off the host, disconnect the SSD, and reconnect it to the Jetson. In the Jetson itself the extlinux.conf can then be edited to point at this SSD as mentioned in previous posts.

10

Awesome! I think I have succeeded but how do I check to see if it booted to my SATA SSD disk and not the on-flash mmcblk0p1?

I ran the lsblk command and the df command. Below is the output of that. Does it look like it worked?
http://i.imgur.com/GKdAQ4M.jpg
I also noticed in the “File” tool there is a 15GB volume that shows up under Devices. So I would assume that it is indeed working and the flash is being treated as a separate storage device.

It looks like the on-board flash /dev/mmcblk0p1 is still being used for something!? Is there a way I can clean up the on-board flash contents so I can read/write to it as data space?

I also wanted to see if I could compile a simple program using g++ but it indicated

bash: g++: command not found

Would I install JetPack like usual from this link…
http://docs.nvidia.com/jetpack-l4t/index.html#developertools/mobile/jetpack/l4t/2.2.1/jetpack_l4t_install.htm
When it asks to flash the OS I assume I want to deselect that option correct?

11

You already tried some of this, but to recap, “lsblk” should mention mountpoint next to the mmcblk1p1 entry (sda1 would be the SATA drive). Disk size should be consistent with the particular disk when running command “df -h -T /” (the “-h” makes it easier for human readability). It looks like your SATA drive is running rootfs.

If you look at the df output, you’ll see “mmcblk0p1” is automounted somewhere under “/media/ubuntu”…this is the eMMC. If you don’t want that automounted you could adjust the “/etc/fstab” to either not mount the partition or to mount it somewhere else.

About eMMC…you still have a full Linux operating system on the eMMC. This makes a nice rescue system if your SATA has problems. I suggest leaving it there unless you have other reasons to not do so. That file system still has lots of places you can use for general storage. Where to use eMMC for extra storage might be a personal preference…if you mention how you want to use this (e.g., music files) it might be easier to make suggestions.

Also about eMMC…during boot the “/boot” directory of eMMC is used by u-boot (prior to the kernel loading SATA is not used). You do not want to damage anything in the eMMC version of “/boot”. If you don’t care about leaving the system unable to boot without the SATA drive, then you can pretty much delete everything else on eMMC…just don’t touch the “/boot” directory.

L4T is just standard Ubuntu with some direct hardware access files installed. Package management is exactly as mentioned in all of the Ubuntu system administration type documents. To add packages from an existing repository, you’d do something like this:

sudo apt update
# optionally "apt search g++" to see g++ related packages...
sudo apt-get install g++

Different repositories can be added other than the base repo, but these are not enabled by default. If you look at “/etc/apt/sources.list” you’ll see what is there. If you were to uncomment all of them, then run “apt update” (which takes a snapshot of current repo package lists), you’ll have available every package from every repo in sources.list. There are multiple ways to add repositories.

If you ever “apt-get upgrade” to set packages up to date and want to see if the nVidia-specific files are still correctly in place do this:

sha1sum -c /etc/nv_tegra_release
12

hi friends,

I’d like to use L4T on my SSD disk,but…

I can’t boot with my 250 ssd disk !!

could you help me ?

  • I format disk,

    sudo mkfs.ext4 /dev/sda1

  • mount ssd disk as /mnt

  • copy unpacked TX1 64-bit Driver Package CONTENT in ssd disk root, with sudo command

  • copy rootfs content in rootfs ssd directory

  • sudo ./apply_binaries.sh -r /mnt

  • sudo gedit /mnt/boot/extlinux/extlinux.conf

  • change to root=/dev/sda1

  • reboot

It doesn’t work !! bios stops before Ubuntu !!

Any help friends ? What did I do wrong ?

Thanks in advance,

Vincent

13

I assume the “root=/dev/sda1” was on the eMMC version of extlinux.conf, but please verify if so.

When you say it stops before Ubuntu, there are a lot of things which can go wrong and stop display output without Linux itself actually failing. Do you have a serial console? This would be very useful since it is immune to most failures. If possible, a serial console log would be very helpful.

Btw, there is no bios on an embedded system. All of that functionality is instead programmed directly into the boot loader. Since there is no video driver in the boot loader serial console works wonders…it’s just a stream of characters.

If you need information on serial console, see this:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]

If no serial console is found, an exact quote for the last few lines prior to failure would be useful.

14

hello,
thanks for your quick answer.

Here is exactly what i do :

format my ssd250GO disk with 2 partitions, second for backup and first as dev/sda1, in ext4, named
neo_jetson (as system)

  • I put linux for tegra contents to sda1 root (with sudo cp)

  • I uncompress 64-bit Sample Root Filesystem in sda1 rootfs dir

  • sudo ./apply_binaries.sh -r /dev/sda1

  • sudo gedit /mnt/boot/extlinux/extlinux.conf

  • change root boot from “mmcblk0p1” to “sda1”

  • close file and reopen to check file : “root=/dev/sda1 rw rootwait”

  • OK

  • I shutdown TX1 board, and power on waiting for boot…

15

Is the partition type “gpt”? I think u-boot might understand old style BIOS partitions, but is intended to work with gpt. As long as u-boot sees the partition this should not be an issue…inability to see the partition might be caused by a non-gpt partition type not being supported (the kernel understands BIOS and GPT…but it is u-boot which hands off to the kernel and so u-boot must also see the root partition).

For putting contents onto sda1 I’d recommend directly unpacking the tar archive onto sda1 (I normally use “tar xpfj”, under some circumstances you might need to also use “–numeric-owner”). Nothing from the driver package should touch the drive unless apply_binaries.sh does this.

cp can of course work for copy (but don’t use both sample rootfs and tar unpack…tar unpack is the master copy cp came from). If cp preserves permissions of copy of an already-extracted rootfs it might work, but it is an accident looking for a place to happen if cp starts copying special files (e.g., imagine copying the content of “/dev/null” to another directory…the copy has to know “/dev/null” is not a real file…there are many non-real files).

Don’t use apply_binaries.sh to name a device special file (don’t use “/dev/sda1”, this is the device driver, not the mounted file system). Mount your sda1 somewhere (such as “/mnt”…the mount command uses the device special file name as the source), and name the mount point as your apply_binaries.sh target, e.g., assuming on your host the target drive is “/dev/sdb” (on a host “sda” would be the host’s own drive):

<b>sudo -s</b>
# Use gdisk or gparted to partition "/dev/sdb".
mkfs.ext /dev/sdb1
mount /dev/sdb1 /mnt
cd /mnt
# "--numeric-owner" is usually optional, it depends on host weirdness.
# Root by default uses "-p", you can explicitly use the "-p" option.
tar xjf --numeric-owner /whereever/the/file/is/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
cd /wherever/your/L4T/is/Linux_for_Tegra
./apply_binaries.sh -r /mnt
umount /mnt
exit

Unless you actually flashed with “mmcblk1p1” (not recommended) the edit to “/mnt/boot/extlinux/extlinux.conf” will have no effect. A normal flash looks for the boot loader and its parameters on eMMC. You’re interested in changing the root partition after system boot starts, not before u-boot runs. You can boot a normal install and edit the eMMC version of “/boot/extlinux/extlinux.conf” for the “root=/dev/sda1” change.

16

Yeah
Thank you very much.
It works !!!

I think it was a gpt problem

I can work, now.