Instructions may vary with release. Which JetPack or L4T release are you using? On a running system you can refer to “head -n 1 /etc/nv_tegra_release” if you don’t know. The reason for asking isn’t that the kernel build is different so much as it is that some components may be installed differently. There will also be differences depending on carrier board, but if you are able to build USB audio as modules the only thing you will need to do is copy module files without any special install step.
Regardless of whether you cross compile (on a PC) or native compile (directly on the TX1 is easy) you will be asked to provide a configuration to start with. Often documents will say something like “make tegra_defconfig”, but this can be replaced with the current system’s actual configuration. If you boot a TX1 and save a copy of “/proc/config.gz”, then gunzip to decompress, and edit the “CONFIG_LOCALVERSION” correctly, the config will be a 100% exact match to your system. Building the kernel and modules at this point would be a perfect clone of current features.
Editing with this config in place (or after “make tegra_defconfig”) through one of the config editors (my favorite is “make nconfig”, be sure to first “sudo apt-get install libncurses5-dev”) to add a feature as a module (the “m” key while highlighting a feature enables as a module, and most features can be a module, but not all…“y” integrates and is not modular). If you safely save your “/proc/config.gz” from the original config you can always start with this. Renamed as “.config” and placed in the temporary output location this becomes the configuration of a build. “make tegra_defconfig” does the same thing, but it doesn’t guarantee a match for what you currently have.
The difference between cross compile steps (if tools are already in place) will be extra options for where to put build output and where to find the cross tools. For example, the “O=/some/where” places the temporary output there…a very good way to keep the original source pristine. Other parameters (perhaps by setting an environment variable) set up where the cross tools are and which foreign architecture you are building for. The official documents are for cross compile on an Ubuntu host PC and gives all of that information.
If you are interested in some background on how kernel source and build is arranged, see:
If you just want steps, then you can see the “documentation” download for your particular release. The earlier mentioned “head -n 1 /etc/nv_tegra_release” is the L4T release, and you can match to your L4T release from here (you will probably have to go here, log in, then go here again):
What you are looking at will be unlikely to involve the device tree just for a kernel feature, but FYI, if you do need device tree changes, then the particular carrier board changes the device tree. The stock device tree can’t be used with other carrier boards. This is what the third party carrier board board support package provides which will be different from the NVIDIA dev kit. If you see “BSP” or “board support package” referenced, think of the content which NVIDIA provides with the custom device tree on top of it. Kernel builds do not change device tree, but the two are related so you will see topics listing them together.
Here is an example of a module only build when native compiling (some thing for non-native foreign builds on a PC, but more options would be included, e.g., setting “ARCH” and naming cross tool location):
Here is a sample build from a TX2, which conveniently has the same architecture and uses the same cross tools:
(notice how extra options are used)