I think maybe the grounding issue is partially solved, so this question is about changing the extlinux.conf to point toward the nvme drive as the / (root) partition. I’ve tried the JetsonHacks suggestions but obviously foulded something up because I failed to get it to work and had to reflash the TX2 from scratch again.
Normally extlinux.conf is read by U-Boot prior to handing over to the kernel (this is how the kernel gets its arguments…U-Boot tells the kernel what its arguments are). If U-Boot can read exlinux.conf, then the “root=” should be the only change needed to send execution to a different root partition. U-Boot has its own drivers for reading Linux partitions and accessing eMMC…even if hand-off is successful the kernel will still need the features to read the NVMe drive. This means either modules need to be available in an initrd, or the feature must be integrated into the kernel as a non-module feature.
Thanks, @linuxdev. Before changing the root= variable, I copied everything over to the nvme. Some symlinks complained but they didn’t seem serious – maybe I was wrong about that. That didn’t occur to me until just now, but I can’t see how some incomplete symlinks could cause the whole system to fry. I looked the error messages over carefully but hey, obviously I did something wrong. :)
Maybe I should dd the emmc root files and then gparted the partition to expand it.
On your host PC you can mount the drive, unpack the sample rootfs there, and then run the apply_binaries.sh with option to point at the alternate mount location instead of the rootfs directory of the driver package. E.G.:
# ...drive is mounted as ext4 on "/mnt"...
sudo -s
cd /mnt
cp /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R27.1.0_aarch64.tbz2 .
tar xjf ./Tegra_Linux_Sample-Root-Filesystem_R27.1.0_aarch64.tbz2
rm Tegra_Linux_Sample-Root-Filesystem_R27.1.0_aarch64.tbz2
cd /where/ever/driver/package/is
./apply_binaries -r /mnt
umount /mnt
exit
The extlinux.conf on eMMC will be the one used, U-Boot won’t see “/boot” of this drive. Just name the root= from eMMC to whichever device your drive shows up as on the Jetson.
Hmmm. I’m going to have to ponder that a while, @linuxdev.
Why would you move the .tbz2 file over, rather than dd or cp the already loaded and expanded emmc root partition? Are the necessary drivers not already in the emmc boot partition?
And I’ve never heard of an “apply_binaries” process (task) - or - is that shorthand for “do what is necessary to copy those files recursively?” :)
cp is unreliable for archiving purposes (and may sometimes have unexpected results when operating on device special files without cpio). You could use rsync more reliably, I don’t trust cp as a backup mechanism. dd would work if the partitions are exactly the same size, but may not do as intended if moving from a smaller partition to a larger partition. Why copy all those files if you can just unpack the original tar archive?
The “apply_binaries.sh” script is what adds the drivers specific to the NVIDIA hardware. This is the script from the driver package in the “Linux_for_Tegra” directory, and is used during command line flash to apply NVIDIA drivers to the same rootfs (JetPack does this for you if using JetPack). The “-r” just tells the script the sample rootfs is in a non-standard location. When checking integrity of the NVIDIA files on a Jetson via “sha1sum -c /etc/nv_tegra_release” these are the files the checksum looks at.
Driver package (and thus apply_binaries.sh) is from here:
[url]https://developer.nvidia.com/embedded/linux-tegra[/url]
If you really want an exact copy of a Jetson which has been modified you’d want to clone:
[url]https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/[/url]
(you could then do incremental updates via rsync over time if backup is your purpose…the cloned image can later be used to directly flash a Jetson)
Sorry, guys, but I need to revisit this after studying it for a while.
-
Did not follow the tx2/cloning thread at all, especially since the (default?) flash.sh doesn’t have the -G option available. Further, I don’t know if the flash.sh copies the entire root partition or just a part of it. For this cloning does flash.sh run from the host or from the TX2?
-
I have the option of installing the nvme drive into the ubuntu host or leaving it in the tx2, for the “cloning.” Which way is better/easier?
-
The usb to tx/rx pins cable still hasn’t arrived so i still don’t have a serial console available, so I can’t make choices during boot. I could use patch cords from the TX2 to an RPi but I don’t have enough room for 2 separate monitors at that workstation. Always something, right?
Reminder: the goal here is to run off the nvme drive, since 32GB is too small. Since the TX2 can ONLY boot from the emmc, we have to do all this extra work to switch root partitions, during boot, from the emmc to the nvme (or SATA) drive and no longer need to access the emmc except for booting.
There is an update to flash.sh available here which provides the “-G” for cloning (I’m guessing this will be in the next L4T release):
https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/
If I were to create a system for mass production, I’d probably do the operation on the host for simplicity and speed. If I were to copy the root partition on the Jetson, then I’d probably use dd with some extra setup to make sure it it works right (though I’d still recommend cloning).
From the Jetson what I’d probably do is make a gpt partition on the SATA drive which exactly matches the existing “/dev/mmcblk0p1” partition. Then use dd to copy (adjust sda1 to your case, make sure sda1 is not mounted):
sudo dd if=/dev/mmcblk0p1 of=/dev/sda1 bs=4096
…then use “sudo gparted /dev/sda1” to resize. After that you could edit eMMC “/boot/extlinux/extlinux.conf” to create the new boot spec.