How to flash new 24.1 kernel to emmc

I built new 24.1 kernel, replaced “image” and “zImage” in “Linux_for_tegra/kernel” with new ones from “arch/arm64/boot”, put TX1 in recovery mode and ran “sudo ./ -k LNX jetson-tx1 mmcblk0p1”. After reboot, I ran “dmesg” and “uname- a” and still got kernel date of “May 17”. Should I get new date for the kernel?

Thanks in advance.

For anything using u-boot (and these days everything uses u-boot) you wont use the “-k” option…this was for fastboot where kernel and some other binary data is put onto non-root partitions. For u-boot, this all goes in the root partition at “/boot”. You won’t always need to install firmware files (and in fact mostly won’t need to install new versions of this), but if you do the dtb files go in “/boot”, and there are other firmware files going in “/lib/firmware”.

When you do custom compile a kernel, remember to set CONFIG_LOCALVERSION. If the base kernel is the same and only modules change, use the existing “uname -r” suffix of “-tegra”. If the base kernel changes options which go beyond modules, use something like “-tegra_custom1”.

Flashing with “-k” means you will have to reflash without “-k” to put hidden partitions back in place for use with u-boot. I suggest this:

sudo ./ -S 14580MiB jetson-tx1 mmcblk0p1

Then with sudo:

cd /boot
cp Image Image-3.10.96-tegra
cp <wherever_your_new_kernel_is> Image-tegra_custom1
# edit "/boot/extlinux.conf/extlinux" with a custom entry for the new kernel.
# If CONFIG_LOCALVERSION changed, you need to install modules in new "/lib/modules/$(uname -r)/".
# If only modules changed you copy new modules into existing "/lib/modules/$(uname -r)/"

If you need to know more about extlinux.conf edits just ask. The best way to go depends on whether you have a serial console available or not. Serial console makes a boot loader menu available to pick whichever entry you want…not having a serial console means you have to make the test kernel default…failing may require flashing to put the old kernel back in if default kernel is incorrect and serial console can’t pick a different entry.

If interested in setting up serial console, see this:

Thanks for the very helpful post. I was used to fastboot for Shield Android TV which has kernel and rootfs in different partitions. The instruction “./ -k LNX jetson-tx1 mmcblk0p1” was from Jetson TX1 R24.1 documentation.

I’m wandering why Jetson TX1 documents do not include detailed instructions for flashing modified kernels which becomes essential to have camera, DMAs and many components working for TX1.

The documents which come with the R24.1 software shows the commands for flash with u-boot, but also shows fastboot about a paragraph below u-boot commands. I think fastboot is still used by some people for shipping final products, so both may be needed at different points in product life cycle.

Historically, fastboot came first, so fastboot documentation has always been there. It isn’t always obvious when transitioning from one product to the next that u-boot is used in some of the products (most any development board uses u-boot now, shield actually ships as a final/non-development product and intentionally avoids boot options…end users won’t be flashing shield the way developers will flash a Jetson).

I made my first mistake by renaming Image and zImage as Image.0 and zImage.0 in /boot and copied my Image and zImage to /boot.

TX1 won’t boot after that. “sudo ./ -k LNX jetson-tx1 mmcblk0p1” won’t recover it either.

I don’t want to overwrite my rootfs which I already have driver for FPGA card built natively and other SW installed.

I do have serial console set up following except I only used pins 6, 8 and 10 of J21 for Black(GND), Yellow(RD) and Orange(TD). uboot works for serial console.

What the best way to boot to original kernel?

Thanks in advance.

I copied L4T rootfs to external microSD card and tried to boot to external microSD. Before I figured out how to boot to external microSD, I typed “boot” in uboot and was able to boot to ubuntu. I’m not sure if uboot was so smart when it failed to boot from internal emmc, it automatically boot from external microSD.

I copied back original Image and zImage to /boot and was able to boot to ununtu without external microSD.

The big concern is that when you ran the “-k” version of flash you may have overwritten one or more partitions other than the root partition. In a worst case, this may have resulted in shifting other partitions, which would have destroyed the root partition…but I doubt that happened. If you can still use serial console to do file mv operations, you can just go to serial console and use sudo to put the correct kernel back in place.

Assuming you cannot operate normally, you will need to clone your root partition, edit the loopback mounted clone to put the kernel in place on the clone, and then re-flash while saying to reuse the existing image…that image will be from the repaired clone. Cloning is very slow, but it is also very reliable.

The JTK1 version of clone is described here, and mostly applies to the JTX1:

The commands specific to cloning a JTX1 are here:

If for example you cloned and produced file “clone.img.raw”, you could mount it at “/mnt” like this:

sudo mount -o loop cloe.img.raw /mnt

…from there you could cd to “/mnt/boot” and put kernel image back. Then cd out and “umount /mnt”.

Manual flash without JetPack has a subdirectory “bootloader” (the same directory would exist with JetPack since JetPack is just a front-end, but I’ve never used JetPack). During normal flash the equivalent of a clone image is generated using the sample rootfs and some boot loader recipes. This ends up as “bootloader/system.img.raw”, and a “sparse” image (which is basically a compressed image) becomes “bootloader/system.img”. Normal flash generates this and uses this. You can use the “-r” option to tell flash to reuse the system.img which is already there. Because flash works using either the sparse image or the raw image, it is ok to rename your clone.img.raw (or just copy it and keep original for backup) to “bootloader/system.img”, and then flash will restore your repaired clone (along with the invisible partitions being generated new).

Note that for clone operations you will need a lot of disk space. If your root partition is 15GB, then the clone itself will be 15GB. If you copy the clone somewhere temporarily as system.img, then that doubles it to 30GB. If the old system.img.raw is there, you could delete that, else you’re up to 45GB of space. Producing that much data may take hours, most of the time spent writing to disk.

This is more complicated than shield Android TV which has small partitions for main and recovery kernels in emmc, replacing kernel takes few seconds and has no impact on rootfs in other partitions.

Can TX1 be configured in the same way?

It appears “” hides many operations from user, e.g., it may load “fastboot.bin” to memory and use fastboot to flash uboot (there are many “fastboot.bin” commands in “”). It may be possible to replace kernel in the same way if kernel is in separate partition.

It isn’t changing the kernel which is slow…that’s just a file copy when using u-boot. The trouble is that the attempt to flash with the “-k” parameter may have messed up other partitions (the -k names a partition to overwrite…you may have needed what was overwritten for u-boot). Normally all you need is to copy a kernel to “/boot” and edit the “/boot/extlinux/extlinux.conf” file and it is done.

fastboot.bin is used during recovery mode for bootstrapping the device to where flash software can run. You will see mention of fastboot.bin even if you only use u-boot…as soon as you are out of recovery mode fastboot.bin goes away.

The normal command for flash:

sudo ./ -S 14580MiB jetson-tx1 mmcblk0p1

I finally figured out as linuxdev said, for uboot, I should not “flash” kernel but “copy” new kernels (Image) to /boot and edit “/boot/extlinux/extlinux.conf” with custom entries for the new kernels.

I copied “primary” entry in extlinux.conf, created 2 new entries “secondary” and “recovery” and changed “LINUX /boot/Image” in those new entries to my kernel images, e.g., “LINUX /boot Image.1” and “LINUX /boot/Image.0”.

Serial console is needed to select which kernel to use from uboot.

When I selected “Secondary” (2) in uboot, I was able to boot to my kernel (Image.1) and verified by using “uname -a”…