- apply_binaries.sh is only needed on a running installation if this fails:
sha1sum -c /etc/nv_tegra_release
…kernel changes will not have any effect on this. Normally an unexpected package dependency from “sudo apt-get upgrade” is the only way this happens (and not often). There are firmware files applied via apply_binaries.sh, but a normal kernel install does not need firmware files changed, thus overwrite is not common.
To see what is in the apply_binaries.sh go to your driver package on your host, then subdirectory nv_tegra. In this is file nvidia_drivers.tbz2. The contents of this file reflect the apply_binaries, and can be viewed via:
bunzip2 < nvidia_drivers.tbz2 | tar --list
FYI, it does not hurt unpack this into the root of a running Jetson…unpacking with sudo from “/” of the Jetson itself would mostly just replace files with exactly the same thing which is already there…this is harmless. When “sha1sum -c /etc/nv_tegra_release” fails, unpacking with sudo from the root of the Jetson is a fix.
- When flashing there are essentially two parts. The first part prepares the sample rootfs as a binary image, the second part is the actual flash of that image. apply_binaries.sh is necessary on a sample rootfs to add the NVIDIA-specific files which make it L4T instead of purely Ubuntu. If using JetPack this is part of the JetPack front end to silently do this. If doing this on command line it must be run with sudo prior to starting the flash.
Should you “reuse” the old image on a command line flash (such as to restore from a clone or just to save time when you want to flash exactly the same as the previous flash), then you don’t need to apply_binaries.sh again…the image being flashed would already reflect this step for that case.
- Under U-Boot you don’t need to flash to put in a new kernel…flashing was from “the old days” (I’m not a day over 1000 years old!). Under fastboot the kernel had its own hidden partition, U-Boot merely copies the file to “/boot” and is done. U-Boot understands how to read ext4 file systems…fastboot did not and read raw binary data from a partition.
The environment the kernel operates in depends on the APPEND key/value pair in “/boot/extlinux/extlinux.conf”. That contains what is passed to the kernel command line on boot.
Note that when building a kernel you need the “CONFIG_LOCALVERSION” set to match the original suffix in “uname -r”, else modules will be looked for in the wrong place (it isn’t really the wrong place if you know this and have copied all modules into the new place…an example of a good reason to do this is for a debug build or alterations in the base kernel which changes what modules are valid).
An example for CONFIG_LOCALVERSION is to use “-tegra” if a 3.10.96 kernel previously replies to “uname -r” as “3.10.96-tegra”.