A bit of explanation of what is going on may help before trying to give specific instructions (and for a custom carrier board the manufacturer will probably need to give the instructions for how to modify flash).
In an embedded system there is no BIOS/UEFI, and so there is a lot of software in a flash which does “boot thing” that a normal PC wouldn’t have to do. This missing BIOS/UEFI content, plus the regular boot content, and the actual operating system gets added in.
Part of what gets flashed is content which tells drivers something about hardware layout. Mostly this is in the form of a “device tree”…basically arguments passed to drivers in some generic way that allows hardware vendors to keep their customizations out of the actual driver code and make the drivers more generic. Embedded systems which separate a System On a Chip (SoC) from more module carrier boards rely heavily on this in combination with the initial boot environment itself being custom. The custom boot environment starts things, and then Linux takes over with drivers set up with the device tree. Most of the “Board Support Package” (“BSP”) is customization of device tree, but it does involve other changes as well.
If you see a reference to device tree, the “.dtb” binary device tree file, or the “.dts” device tree source file, then more or less it is all talking about the same thing (though perhaps in different formats).
The device tree is how various pins of the SoC, when capable of becoming more than one function, sets up the specific function for that pin. If two carrier boards were to do exactly the same thing, but swap two pins for different layout, then the device tree would change. The BSP would contain that change.
When you flash, regardless of whether you use JetPack (and in the most recent release known as SDK Manager) or command line, the tools to do so come in the “driver package”. JetPack/SDKM are just front ends to this and download and prepare other software, but the subdirectory “Linux_for_Tegra/” (from inside of what either JetPack or SDKM installs) is the “driver package” component.
Within the driver package there is a “rootfs/” subdirectory (“Linux_for_Tegra/rootfs/”). This is empty except for a README file, and then the sample rootfs package is unpacked within this. That sample rootfs is 100% pure Ubuntu for aarch64/arm64/ARMv8-1 architecture (which works out well since that is the architecture of the Xavier). Then the “apply_binaries.sh” script is run (it can be run by hand with sudo, but JetPack/SDKM does this for you if you use that) and hardware drivers specific to the NVIDIA hardware is overlaid on top of that. This is still Ubuntu, but can be referred to at that point as “Linux for Tegra” (“L4T”). On a running system you can verify the NVIDIA-specific files via “sha1sum -c /etc/nv_tegra_release”, or see the release version via “head -n 1 /etc/nv_tegra_release”.
A bit-for-bit exact filesystem image is created mostly from this “rootfs/” subdirectory. During the flash (through script “Linux_for_Tegra/flash.sh”) some boot content is also added (the “/boot” content is mostly added based on arguments to flash.sh, but Xavier doesn’t necessarily use all of that content). Other images for other partitions (there are many…all of them are related to boot and not used after boot) are also created. “rootfs/” gets turned into the operating system’s partition, the rest more or less do the job of a BIOS and bootloader. Device tree content will be in a mix of boot and operating system partitions.
Think of software as something which runs hardware, but is not part of the actual hardware. Think of firmware which is actually loaded into some specific piece of hardware, e.g., into a WiFi device which needs to behave differently in different parts of the world due to regulations. If device tree doesn’t correctly point to a device, then firmware will fail to load since drivers can’t find the device. Some of the boot content is for the Xavier module, and will be the same even with custom carrier boards. Much of the content will differ based on layout of the custom carrier board.
Your carrier board will come with instructions to copy BSP content somewhere into the “Linux_for_Tegra/” subdirectories. That content will replace the “standard” device tree in places, and perhaps firmware as well. Once that is done, then the flash is itself exactly the same between using a custom carrier board or the default development carrier board. I do not know what instructions there will be for your carrier board, but the gist is that you’ll create the content of the “Linux_for_Tegra/” subdirectory (perhaps just by running JetPack or SDKM), and then copy or extract files somewhere in that (very likely somewhere in the “bootloader/” and/or “kernel/” subdirectories).
JetPack/SDKM are not installed to the Jetson. This is just a utility front end. The version of JetPack/SDKM installed to the host PC (try to not use a VM…they’re trouble if you don’t know how to permanently dedicate USB devices to the VM). If you’ve attempted to flash, then that content is already in place (just look for content to be in a “Linux_for_Tegra/” and “Linux_for_Tegra/rootfs/” subdirectory). The L4T version changes depending on JetPack/SDKM version. JetPack3.3 installs Ubuntu 16.04 LTS (via the driver package), SDK Manager4.2 (SDKM4.2/JetPack4.2) installs Ubuntu 18.04 LTS. Your BSP will be designed for working on a specific release. If the carrier board does not have a BSP for a specific release, then you’ll need to use an older release (but ask the carrier board manufacturer…they need time to create new BSP releases for each L4T/JetPack release).
You may find that sometimes it is useful to manually run “Linux_for_Tegra/flash.sh” after JetPack/SDKM downloads things. In that case there will generally be instructions to do so after the driver package has been unpacked.
JetPack/SDKM has basically two things it is front end to: (1), flash, (2) extra package installs. Flash does not install extras, e.g., it doesn’t install CUDA. The Jetson is in recovery mode for flash. After flash the Jetson reboots (and first boot from JetPack/SDKM4.2 requires you to log in once at the local Xavier to add a user account before continuing…this may be remedied in other releases in the future after 4.2). Once rebooted wired ethernet is used to add packages which JetPack/SDKM manages. In the past that wired ethernet was the actual ethernet port, but a virtual USB ethernet device was added to the USB-C connector (this runs only after the system reboots…recovery mode can’t use ethernet). Manual run of “flash.sh” will only flash and will not add packages. JetPack/SDKM can be told to just add packages and not flash, but you have to set that option at the start.
It is ok to completely delete your JetPack or SDKM directories on your host system and start over if not sure about procedures. I tend to check that I do not want temp content deleted (I use the temp content on command line when possible instead of JetPack/SDKM).
So probably the first thing you need to do is check for a board support package from the manufacturer of that carrier. Make sure to use JetPack/SDKM (or manual driver package flash.sh) based on the version the BSP supports. Make sure to use “sudo” only when it is correct, and to not skip using “sudo” in places it is needed. SDKM/JetPack will prompt for a password and use sudo as needed, but any manually operation requires “sudo” in the right places.
You can find a list of older JetPack versions or the current JetPack version within these URLs (you will probably need to go to the URL, login, and then go to the URL again since redirect does not work):
https://developer.nvidia.com/embedded/jetpack
https://developer.nvidia.com/embedded/jetpack-archive
Official documentation is provided for each release. Other downloads can be found here:
https://developer.nvidia.com/embedded/downloads
The information specifically for SDK Manager:
Installer: https://developer.nvidia.com/embedded/dlc/nv-sdk-manager
Instructions 1 (Download/Run): http://docs.nvidia.com/sdk-manager/download-run-sdkm/index.html
Instructions 2 (Install Software to Jetson): http://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html
Lots of good Xavier information is here:
https://www.jetsonhacks.com/category/jetson-xavier/
Whenever you read information about flash or software package versions keep in mind that usually it is for a specific version of JetPack/SDKM/L4T. You might find this sticky thread useful as well:
https://devtalk.nvidia.com/default/topic/1039020/jetson-agx-xavier/links-to-jetson-xavier-resources-amp-wiki/