I am having trouble getting the TX2i to cross-compile using the desired kernel .config file. Using the Jetpack 3.3 flash.sh utility I am able to flash the kernel image successfully, but whenever I check the contents of /proc/config.gz it does not contain the changes I made on the host machine.
This is my pipeline for compiling and flashing the TX2i, starting with creating a fresh config file:
cd /home/user/Desktop/Jetpack_3.3/64_TX2/Linux_for_Tegra/sources/kernel/kernel-4.4
set -e
set -u
export TEGRA_BASE=/home/user/Desktop/Jetpack_3.3/64_TX2/Linux_for_Tegra
export TEGRA_KERNEL_OUT=$TEGRA_BASE/kernel
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
export ARCH=arm64
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH mrproper
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH tegra18_defconfig
I then modify the .config file located at $TEGRA_BASE/kernel/.config and enable the desired options. After that I compile and flash the TX2i:
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules_prepare
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH zImage
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH dtbs
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules_install INSTALL_MOD_PATH=$TEGRA_BASE/rootfs
cd $TEGRA_BASE
cp kernel/arch/arm64/boot/dts/*.dtb kernel/dtb/
./apply_binaries.sh
./flash.sh -t jetson-tx2i mmcblk0p1
After 10-30 minutes the flash completes and the TX2i boots up as expected, but it is not using the right kernel config. At this point I have to download the source onto the TX2i, change the kernel configuration, and recompile (directly on the TX2i). Only then, after restarting, do I see the desired changes.
Am I missing a step that tells the flash.sh utility what config file to use? If I remove the modified config file it complains about the config file not existing, so I know that it at least expects to find the config file where I am modifying it.
I don’t know enough to answer, but here are some points to consider…
A dtb will never update what you see for kernel config in “/proc/config.gz”. This only updates a device tree. You might want to distinguish or clarify if it is device tree or kernel you are wanting to update (or both).
If you look at the output of the flash command, then you will see which dtb is being used…be certain that the dtb you have in place is the one which is flashed. You can look for the log of the one flashed, and then reverse compile that dtb and see if the one flashed is actually the one you edited. To reverse compile a dtb:
dtc -I dtb -O dts -o reversed.dts original_being_reverse_compiled.dtb
To save a log of your flash:
./flash.sh -t jetson-tx2i mmcblk0p1 2>&1 | tee log_flash.txt
To clarify, I am adding a custom camera driver. It works as expected when I modify the kernel source directly on the TX2i by adding the driver files (to kernel/kernel-4.4/drivers/media/i2c), updating the i2c Kconfig and Makefile, enabling the driver in the kernel .config, then recompiling the kernel and restarting the TX2i. Then I flash the device tree from a host machine using flash.sh and I can communicate with the camera using gstreamer.
So yes, I am ultimately updating both the device tree and kernel but at the moment my problem is that I want to cross compile and flash the entire setup through jetpack, and the kernel configuration is not the same as the one I believe jetpack should be using. This means I have to go onto the TX2i and redo the kernel changes I had made on the host machine then recompile.
On the host, when I do “make tegra18_defconfig” I can see that my modifications to the Kconfig and Makefile for the i2c driver folder is successful due to the fact that there is a line in the produced config mentioning that the camera is not configured. It is my understanding that once you flash the kernel, you can see the kernel configuration used by viewing /proc/config.gz. I expect to find a line there along the lines of “CONFIG_VIDEO_=y”, as that is a line I add to the kernel configuration that jetpack should be using.
However, after a fresh flash /proc/config.gz does not even have a line referencing my camera.
I will save the flash log and see if there is some useful information there.
After a bit more debugging, I found that the Image being used by the flash utility was the incorrect image. It was copying the Image at $TEGRA_BASE/kernel/Image, but the updated Image file was actually being compiled at $TEGRA_BASE/kernel/arch/arm64/boot/Image
I fixed this by adding a step in my commands after compiling the Image to copy it from $TEGRA_BASE/kernel/arch/arm64/boot/Image into $TEGRA_BASE/kernel/
I also switched from making a zImage to an Image (though I’m not sure how this impacts the process).
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules_prepare
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH Image
cp $TEGRA_BASE/kernel/arch/arm64/boot/Image $TEGRA_BASE/kernel
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH dtbs
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules
make O=$TEGRA_KERNEL_OUT ARCH=$ARCH modules_install INSTALL_MOD_PATH=$TEGRA_BASE/rootfs
cd $TEGRA_BASE
cp kernel/arch/arm64/boot/dts/*.dtb kernel/dtb/
./apply_binaries.sh
./flash.sh -t jetson-tx2i mmcblk0p1
When Tegra went from 32-bit to 64-bit zImage was no longer used (Image is used, which is not compressed). I think U-Boot does not work correctly for decompression of 64-bit (one would probably have to update U-Boot for 64-bit).