Adding a Compiled Kernel to the Root File System

Hello,

I am studying “Tegra Linux Driver Package Developer Guide” for setting up the TX1 environment
1.
I confuse for the action in the “Adding a Compiled Kernel to the Root File System” step, the description is “copies the Image file to the internal eMMC root filesystem” but the message show in my terminal is “Installing zImage into …”
Are the two action copies and installing different or the same?
2.
In the “To configure a file system for U-Boot” step, we use a apply_binaries script to copy the image files, and in “To configure a file system installed in the internal eMMC” step, we use flash.sh automatically copies the Image file.
Are this two script do the same thing?

Thanks

How the kernel is installed depends on the boot loader. In earlier days fastboot was used, and fastboot required install by flash to a directorypartition owned by just the kernel. These days u-boot is used, and u-boot merely does a file copy to the “/boot” directory. During flash zImage is copied to your installer “rootfs/boot/” directory (along with a couple of other files for boot support). That directory as a whole becomes a loopback mountable image the size of the final root partition…and this is what gets copied to the Jetson (well, in reality a compressed “sparse” version gets copied, but as it gets uncompressed it becomes an exact copy anyway).

The sample rootfs is pure Ubuntu without any nVidia-specific hardware access files. The apply_binaries.sh script copies some nVidia-specific hardware access files into the rootfs. At the time when this occurs you could say the rootfs transitions from being purely Ubuntu to becoming Linux for Tegra (L4T). L4T is really Ubuntu, but it has been tweaked for the Tegra hardware.

If you’re developing your own kernel or customizing your own kernel under u-boot, you’d be copying it to “/boot” of the Jetson to install it. If flashing, then the parameters of the flash (such as naming “jetson-tx1”) determine what files to add for boot purposes to the rootfs. apply_binaries.sh must be run first because the flash script will not add these…they are expected to be applied prior to flash.

Naming “mmcblk0p1” in the flash command specifies the eMMC. Example command line:

# unpack sample rootfs into rootfs using sudo; then...
sudo ./apply_binaries.sh
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1

Note that the “-S 14580MiB” just makes sure you don’t waste any eMMC and puts all available space into the root partition.

Putting in an updated kernel is as simple as copying it to the running Jetson’s “/boot” directory (don’t forget to save a backup of the original before doing so).

Thanks @linuxdev

Hello,

I still confuse for the cases as below:

1.Whenever I build the kernel or device tree which I make some modification, should I also need to do the apply_binaries.sh script or just the flash.sh descript
2.I have some new TX1 module(not the JETSON TX1 development kit), and I find that there have nothing in the module, so I need to do the flash.sh in the recovery mode, did I need to do apply_binaries.sh?
3. When I need to flash the kernel, and we have already developed our environment for adding some function or install some tools like ROS, could I hold the environment as the same?

Thanks

  1. 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.

  1. 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.

  1. 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”.

Hi Linuxdev,

Thanks

Hello linuxdev,

1.In the sentence “apply_binaries.sh is necessary on a sample rootfs to add the NVIDIA-specific files which make it L4T instead of purely Ubuntu”, It means the new folder, files or kernel modification?

2.In the sentence"Should you “reuse” the old image on a command line flash", what kind of image you mention here?

Sorry to bother you all the time.

Thanks

“apply_binaries.sh” unpacks some archives of files into the “rootfs” subdirectory. This does not change the kernel, although kernel and boot options do get edited by the flash process (those changes are just not part of apply_binaries.sh). Note the nv_tegra subdirectory to the flash driver software…the main archive is the “nvidia_drivers.tbz2” file. You can read the apply_binaries.sh script since it is human-readable bash source code and see what it does, but to see the bulk of what is copied into rootfs:

tar --list -j -f nvidia_drivers.tbz2

During flash a complete image of the root partition is needed…this is copied bit-for-bit exactly to an offset in the eMMC. Either that data (the “image”) must be created by manipulating the rootfs (such as a recursive copy onto a loopback mounted raw file after formatting the file), or else the image can be provided by the user before starting and the image creation can be skipped. If you’ve flashed once already, then there is no need to take the time to create the raw image again…it’d just be the same thing and you’d spend time creating a 15GB file. Or, if you have backed up your Jetson by cloning the root partition, then this image works as well…a clone can be flashed with the “-r” option.

The actual commands to clone a TX1 differ somewhat from a TK1, but the information and concept is the same. See:
http://elinux.org/Jetson/Cloning

Some information on cloning a TX1:
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149

Just be careful to not overwrite an image you want to save by running a flash without “-r” when your only clone is where it’ll get overwritten.

Hi Linuxdev,

Thanks for your reply.