I can’t help with most of this, but understand that SDK Manager is just a front end for downloading software, running the flash software (as a backend), and other dependency resolving. If you’ve used SDKM to flash once, then you will have this directory:
Linux_for_Tegra/” content is what you could have downloaded separately as the “driver package”. This is the true flash software. You don’t even need SDKM to download and unpack this, SDKM is just a convenience for this.
Linux_for_Tegra/” there is an initially blank subdirectory, “
Linux_for_Tegra/rootfs/”. When flashing, it is this content which makes up the root filesystem. The downloadable package for “sample root filesystem” is normally unpacked there (using sudo), and is an entirely 100% pure Ubuntu. This lacks some of the needed drivers for Jetsons, and so from “
Linux_for_Tegra/”, running command “
sudo ./apply_binaries.sh” adds those drivers. This allows NVIDIA’s content to be maintained separately and not be mixed with Ubuntu except when the end user chooses to do so.
flash.sh” command is normally how one would flash on command line, and this is in the “
Linux_for_Tegra/” directory which is installed when unpacking the driver package.
Flashing does not install any of the optional “extras”, e.g., no CUDA or samples. This is the part where SDKM helps as it can do this for you without many of the steps you might need to understand to add these packages yourself. This includes optional packages to both host PC and Jetson.
Most of what the jocover method does is simply from the host side without involving SDKM other than having the “
Linux_for_Tegra/” content. When he gets to this line it is the first time SDKM is involved, and then only for the purpose of downloading the “
sudo ./flash.sh jetson-xavier external
Do you have “
Linux_for_Tegra/”? If so, then you have no more requirements (within his post) for using SDKM. If you don’t have “
Linux_for_Tegra/”, then you could skip SDKM and separately download the driver package and sample rootfs, prepare with a single “
sudo apply_binaries.sh”, and from then on run as many flashes as you want without ever touching SDKM.
Note that during a flash the “
Linux_for_Tegra/rootfs/” content is almost exactly what is used to create the root filesystem on the Jetson. The exception to being an exact copy is from some of the “
/rootfs/boot” content being edited prior to flash, where the edits depend on the argument passed to
flash.sh. In this example the argument is “
external”, whereas normally it would be “
mmblk0p1”. Part of the changes from this argument change is that the “
rootfs/boot/extlinux/extlinux.conf” will be edited to point at your partition’s UUID instead of pointing at “
/dev/mmcblk0p1” during boot.
Special instructions are almost always referring to something within the “
Linux_for_Tegra/” directory. The other commands could be run from anywhere on the host PC for the first part of his instructions. The rest of the commands are from the running Jetson after flash completes and you’ve performed the first boot setup (it is hard to set up if you don’t have a user account, and this is part of first boot setup).