Update TX1 kernel remote


I’m using kernel 3.10.67 on tx1. I need remote update kernel to 3.10.96. I did rebuild kernel image, dtb file, but I don’t know how to update kernel image only ( I don’t want reflash rootfs).
Please help me.


It’s fairly simple as it is just a file copy (if not for root account lock scp would work nicely for this from the host side without ssh askpass setup…if done from client side you can sudo scp and it should work without effort). If you look at “/boot/extlinux/extlinux.conf” (the configuration file for U-Boot) you’ll see some key/value pairs for each boot entry (there is one default boot entry “primary”). The LINUX key names the kernel image path. Just copy your image over “/boot/Image” and your kernel will be there after reboot.

Note that it is best to not overwrite your original kernel/dtb files if you are developing (or perhaps not even on a customer board if you want a way to revert). I always rename my Image file and add a different entry, perhaps setting the different entry as default (you need serial console to reach the stage of U-Boot where you can pick which MENU LABEL to boot when there is more than one). As an alternative you can save a copy of your original Image first to some name like “Image-original”. The same is true for dtb files.

Do note that recent L4T versions use the initrd (as shown in extlinux.conf). If your changed dtb file needs to be there at early boot then you may need to add it to the initrd.

Hi linuxdev,

how can i add it to the initrd ? as extlinux.conf file below, I see initrd file was the bin file, I can not modify it.

DEFAULT primary

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 pcie_aspm=off androo
idboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.securityy
=non-secure tegraid= ddr_die=2048M@2048M ddr_die=2048M@4096M section=22
56M memtype=0 usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@@
63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart822
50-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec={lp0_vec} nvduu mper_reserved={nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt androidd
.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 aa
ndroidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 nee
t.ifnames=0 root=/dev/mmcblk0p1 rw rootwait


I would test first to see if initrd matters…it could be this does not matter for your change.

An example of how to unpack an initrd:

cd /tmp
mkdir initrd
cd initrd
gunzip < /where/ever/intrd/is/at/initrd > initrd.cpio
sudo cpio -vid < initrd.cpio

Note that there is no “/boot” referred to in the most recent R24.2.1 L4T initrd, so anything going there won’t matter (dtb and Image do not care about initrd, and vice versa). The place where this starts to matter is if firmware files in “/lib/firmware/” need changing (which could happen when changing the dtb). So long as your dtb changes do not require matching firmware to change you should be ok without this step.

FYI, to zip this back up:

# ...make whatever changes you need...
sudo -s
find . -print | cpio -ov > ../initrd.cpio
cd ..
chown your_user_name initrd.cpio
rm -Rf ./initrd
gzip initrd.cpio
mv initrd.cpio initrd

Hi linuxdev,

Thanks for your support, but I can not use command gzip for my initrd file as below.

ubuntu@tegra-ubuntu:/boot$ gunzip initrd
gzip: initrd: unknown suffix – ignored


You have to follow the syntax I gave above…note that in my example I did not gunzip the file, I redirected file content into gunzip (you might want to mouse copy and paste into an editor, edit paths, and then mouse copy and paste to command line):

gunzip < ...

That “<” is important. I forgot to use “sudo -s” prior to that to stay in an sudo shell, but this could also help because some of the files need to be owned by root. You can unpack without sudo and when you repack it’s properly owned by root since the repack step had sudo, but it might be better in some circumstances to use root permission even for the unpack.

Hi Linuxdev,

Thanks for your support.