How to Update kernel version from 3.10.40 to 3.18.20 in L4T
Hello, i am new to jetson tk1 board. i am trying to change the kernel version(3.18.20) in my jetson tk1 board. i know L4T 21.6 default version of kernel is 3.10.40 after i flashed R21.6 L4T in my tk1 board. so i am trying it. unfortunately, i don't know where i start it. please let me know step by step
Hello, i am new to jetson tk1 board. i am trying to change the kernel version(3.18.20) in my jetson tk1 board.
i know L4T 21.6 default version of kernel is 3.10.40 after i flashed R21.6 L4T in my tk1 board.
so i am trying it. unfortunately, i don't know where i start it.
please let me know step by step

#1
Posted 01/30/2018 08:36 AM   
I don't know if that kernel will work or not. It might depend on how much of a working default kernel's config can be matched on the 3.18 version, and whether the NVIDIA drivers can just drop in and work without edit. If you are going to test I'd start by copying a reference of "/proc/config.gz" somewhere, and attempting to use that as a starting configuration (gunzip the copy, then copy to file name ".config" in your kernel build area...then something like "make nconfig" to edit). See if it builds. Note: You'd want to add package "libncurses5-dev" before starting in order to use "make menuconfig", "make nconfig", or any of the curses based configuration editors: [code]sudo apt-get install libncurses5-dev[/code] I would also get a serial console cable...every failed attempt where you overwrite the default kernel will require a flash...if you use a serial console cable you can add multiple test entries in "/boot/extlinux/extlinux.conf" and just pick the one you want at boot time (and one would be the original kernel and boot config). The kernel itself is just a file copy into "/boot", plus there are modules in "/lib/modules/$(uname -r)/". You can see if you can build kernels and modules without serial console, but you don't want to replace an existing boot configuration with a possibly unbootable configuration without the serial console. If you build directly on the Jetson it is just like any other kernel build. If you build on your PC host, then you do need to set up for cross-compile. Once cross-compile is set up though it is mostly the same as any other kernel config/build.
I don't know if that kernel will work or not. It might depend on how much of a working default kernel's config can be matched on the 3.18 version, and whether the NVIDIA drivers can just drop in and work without edit.

If you are going to test I'd start by copying a reference of "/proc/config.gz" somewhere, and attempting to use that as a starting configuration (gunzip the copy, then copy to file name ".config" in your kernel build area...then something like "make nconfig" to edit). See if it builds.

Note: You'd want to add package "libncurses5-dev" before starting in order to use "make menuconfig", "make nconfig", or any of the curses based configuration editors:
sudo apt-get install libncurses5-dev


I would also get a serial console cable...every failed attempt where you overwrite the default kernel will require a flash...if you use a serial console cable you can add multiple test entries in "/boot/extlinux/extlinux.conf" and just pick the one you want at boot time (and one would be the original kernel and boot config). The kernel itself is just a file copy into "/boot", plus there are modules in "/lib/modules/$(uname -r)/". You can see if you can build kernels and modules without serial console, but you don't want to replace an existing boot configuration with a possibly unbootable configuration without the serial console.

If you build directly on the Jetson it is just like any other kernel build. If you build on your PC host, then you do need to set up for cross-compile. Once cross-compile is set up though it is mostly the same as any other kernel config/build.

#2
Posted 01/30/2018 01:25 PM   
Thank for previous advice!!. unfortunately, i still have problem. i struggle to do cross-compile. presently, i know kernel 3.18.2 version to provide with tegra tk1 configuration(tegra_defconfig file in ~/linux-3.18.2/arch/arm/configs) so i build them result is that "kernel: arch/arm/boot/Image is ready, arch/arm/boot/zimage is ready, building moudles, stage2, MODPOST 8 modules" probably... i think process of building is well...???(i'm not certain.) after this situation. what i have to do for changing kernel version(3.18.2) on my jetson board?? e.g) how to change kernel,install module, dtb on my jetson board please give me wisdom about process of cross-compile
Thank for previous advice!!. unfortunately, i still have problem. i struggle to do cross-compile. presently, i know kernel 3.18.2 version to provide with tegra tk1 configuration(tegra_defconfig file in ~/linux-3.18.2/arch/arm/configs) so i build them
result is that "kernel: arch/arm/boot/Image is ready, arch/arm/boot/zimage is ready, building moudles, stage2, MODPOST 8 modules"
probably... i think process of building is well...???(i'm not certain.)
after this situation. what i have to do for changing kernel version(3.18.2) on my jetson board??
e.g) how to change kernel,install module, dtb on my jetson board

please give me wisdom about process of cross-compile

#3
Posted 02/02/2018 07:13 AM   
You should know that if you do this wrong you will need to flash the system. If you have a serial console you can simply add the alternate kernel as an option during boot...serial console can select any of several boot entries. This is recommended. The information for adding options to multiple boot entries also explains how to install the kernel. Hopefully this can be a reference for other people wondering the same thing. The file "/boot/extlinux/extlinux.conf" names where the kernel is searched for, along with other options. Normally you will see this as extlinux.conf: [code]TIMEOUT 30 DEFAULT primary MENU TITLE Jetson-TK1 eMMC boot options LABEL primary MENU LABEL primary kernel LINUX /boot/zImage FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt[/code] The "LABEL primary..." is a boot entry. Since the DEFAULT is "primary", this is what will run if you don't use serial console to pick something else. If you wanted to add a possibility of manually picking the SD card then you'd add a blank line at the end, then place a slightly altered copy of the "LABEL" in it naming rootfs as mmcblk1p1 instead of mmcblk0p1: [code]TIMEOUT 30 DEFAULT primary MENU TITLE Jetson-TK1 eMMC boot options LABEL primary MENU LABEL primary kernel LINUX /boot/zImage FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 [b]root=/dev/mmcblk0p1[/b] rw rootwait tegraboot=sdmmc gpt LABEL [b]sdcard[/b] MENU LABEL [b]SD Card[/b] LINUX /boot/zImage FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 [b]root=/dev/mmcblk1p1[/b] rw rootwait tegraboot=sdmmc gpt [/code] An important note is that the "APPEND" line is one very long line without breaks. It line wraps in most editors, but it is just one line. In the above everything would be the same with the sdcard boot not being used unless you manually pick it at boot time via serial console. You'll see each entry has a line with "LINUX /boot/zImage". This is where the kernel is stored. When a boot entry is used this is why it searches at "/boot/" for file "zImage". I recommend not replacing the original. You could, and if it works this is fine. If it doesn't work, and you have replaced this file, then you probably need to flash to get it working again. I'll suggest adding an alternate entry with a new name for zImage so you can pick this and test it...and if it fails, you just use the other entry and fix it. Here is an example which assumes you copied your new zImage to "/boot/zImage-testing" (the alternate name is to not overwrite the original zImage): [code] LABEL primary MENU LABEL primary kernel LINUX /boot/zImage FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt[/code] The "LABEL primary..." is a boot entry. Since the DEFAULT is "primary", this is what will run if you don't use serial console to pick something else. If you wanted to add a possibility of manually picking the SD card then you'd add a blank line at the end, then place a slightly altered copy of the "LABEL" in it naming rootfs as mmcblk1p1 instead of mmcblk0p1: [code] LABEL [b]testing[/b] MENU LABEL [b]test kernel[/b] LINUX /boot/zImage[b]-testing[/b] FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt[/code] The only thing different here is changing the LABEL and MENU LABEL, then naming a new zImage name in the LINUX line. Picking this at boot using serial console means the original entry is still there and works as a backup if anything fails. The kernel zImage gets copied into "/boot", and so long as an extlinux.conf entry points at it, then this is what will be booted. Note that the command "[b]uname -r[/b]" will give the kernel version plus a suffix which is the "[b]CONFIG_LOCALERSION[/b]" used when the kernel is built. So if CONFIG_LOCALVERSION is "-gb271e8f", and if the base kernel version is "3.10.40", then "uname -r" will be "3.10.40-gb271e8f". This kernel will look for its modules in [b]"/lib/modules/$(uname -r)/"[/b], or "/lib/modules/3.10.40-gb271e8f/". If your "uname -r" differs in your new kernel, then you must also add all of the modules to the new directory. If "uname -r" did not change, then your new kernel will look for modules in the same location as the previous kernel. If you did build new modules, or if you added one, then this is still just a file copy to "/lib/modules/$(uname -r)/". Failing to get modules in place usually won't stop a system from booting, but it wouldn't be unusual for only text mode console to work. [b][u]In your particular case:[/u][/b] Assuming kernel version 3.18.20, with CONFIG_LOCALVERSION set to "-testing"... Copy the new zImage to "[b]/boot/zImage-3.18.20-testing[/b]". This will imply "uname -r" of "3.18.20-testing". Your module directory will be at "/lib/modules/3.18.20-testing/". You will need to do the "make modules" step (don't for the the "O=/some/where") and the recursive copy of those modules into a new directory "[b]/lib/modules/3.18.20-testing/[/b]" (the old modules were for a different version so you can't reuse them). The extlinux.conf entry would be something like this: [code]LABEL [b]3.18.20-testing[/b] MENU LABEL [b]3.18.20-testing[/b] LINUX /boot/zImage[b]-3.18.20-testing[/b] FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt[/code] A word of caution in module copy: The "make O=/some/where modules_install INSTALL_MOD_PATH=/some/where/else" puts in a symbolic link "build" which points at the source which was used to create the modules. You do not need this, but if you just do a recursive copy of the INSTALL_MOD_PATH to the Jetson and don't remove the "build" symbolic link from the location named in INSTALL_MOD_PATH it'll copy the complete kernel source as well. This doesn't hurt anything, but it wastes a lot of disk space. If you don't use serial console you can still edit the extlinux.conf as shown and replace the "DEFAULT primary" with "DEFAULT 3.18.20-testing". Be sure to create the "/lib/modules/3.18.20-testing/" directory and content first.
Answer Accepted by Forum Admin
You should know that if you do this wrong you will need to flash the system. If you have a serial console you can simply add the alternate kernel as an option during boot...serial console can select any of several boot entries. This is recommended.

The information for adding options to multiple boot entries also explains how to install the kernel. Hopefully this can be a reference for other people wondering the same thing.

The file "/boot/extlinux/extlinux.conf" names where the kernel is searched for, along with other options. Normally you will see this as extlinux.conf:
TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt


The "LABEL primary..." is a boot entry. Since the DEFAULT is "primary", this is what will run if you don't use serial console to pick something else.

If you wanted to add a possibility of manually picking the SD card then you'd add a blank line at the end, then place a slightly altered copy of the "LABEL" in it naming rootfs as mmcblk1p1 instead of mmcblk0p1:
TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

LABEL sdcard
MENU LABEL SD Card
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk1p1 rw rootwait tegraboot=sdmmc gpt


An important note is that the "APPEND" line is one very long line without breaks. It line wraps in most editors, but it is just one line. In the above everything would be the same with the sdcard boot not being used unless you manually pick it at boot time via serial console.

You'll see each entry has a line with "LINUX /boot/zImage". This is where the kernel is stored. When a boot entry is used this is why it searches at "/boot/" for file "zImage". I recommend not replacing the original. You could, and if it works this is fine. If it doesn't work, and you have replaced this file, then you probably need to flash to get it working again. I'll suggest adding an alternate entry with a new name for zImage so you can pick this and test it...and if it fails, you just use the other entry and fix it. Here is an example which assumes you copied your new zImage to "/boot/zImage-testing" (the alternate name is to not overwrite the original zImage):
LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt


The "LABEL primary..." is a boot entry. Since the DEFAULT is "primary", this is what will run if you don't use serial console to pick something else.

If you wanted to add a possibility of manually picking the SD card then you'd add a blank line at the end, then place a slightly altered copy of the "LABEL" in it naming rootfs as mmcblk1p1 instead of mmcblk0p1:
LABEL testing
MENU LABEL test kernel
LINUX /boot/zImage-testing
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt


The only thing different here is changing the LABEL and MENU LABEL, then naming a new zImage name in the LINUX line. Picking this at boot using serial console means the original entry is still there and works as a backup if anything fails.

The kernel zImage gets copied into "/boot", and so long as an extlinux.conf entry points at it, then this is what will be booted.

Note that the command "uname -r" will give the kernel version plus a suffix which is the "CONFIG_LOCALERSION" used when the kernel is built. So if CONFIG_LOCALVERSION is "-gb271e8f", and if the base kernel version is "3.10.40", then "uname -r" will be "3.10.40-gb271e8f". This kernel will look for its modules in "/lib/modules/$(uname -r)/", or "/lib/modules/3.10.40-gb271e8f/". If your "uname -r" differs in your new kernel, then you must also add all of the modules to the new directory. If "uname -r" did not change, then your new kernel will look for modules in the same location as the previous kernel.

If you did build new modules, or if you added one, then this is still just a file copy to "/lib/modules/$(uname -r)/". Failing to get modules in place usually won't stop a system from booting, but it wouldn't be unusual for only text mode console to work.

In your particular case:

Assuming kernel version 3.18.20, with CONFIG_LOCALVERSION set to "-testing"...
Copy the new zImage to "/boot/zImage-3.18.20-testing". This will imply "uname -r" of "3.18.20-testing". Your module directory will be at "/lib/modules/3.18.20-testing/". You will need to do the "make modules" step (don't for the the "O=/some/where") and the recursive copy of those modules into a new directory "/lib/modules/3.18.20-testing/" (the old modules were for a different version so you can't reuse them).

The extlinux.conf entry would be something like this:
LABEL 3.18.20-testing
MENU LABEL 3.18.20-testing
LINUX /boot/zImage-3.18.20-testing
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt


A word of caution in module copy: The "make O=/some/where modules_install INSTALL_MOD_PATH=/some/where/else" puts in a symbolic link "build" which points at the source which was used to create the modules. You do not need this, but if you just do a recursive copy of the INSTALL_MOD_PATH to the Jetson and don't remove the "build" symbolic link from the location named in INSTALL_MOD_PATH it'll copy the complete kernel source as well. This doesn't hurt anything, but it wastes a lot of disk space.

If you don't use serial console you can still edit the extlinux.conf as shown and replace the "DEFAULT primary" with "DEFAULT 3.18.20-testing". Be sure to create the "/lib/modules/3.18.20-testing/" directory and content first.

#4
Posted 02/02/2018 06:21 PM   
always thank for giving me advice. according to your recommendation, i try to edit my ~/L4T/roofs/...../extlinx... entry after i change the kernel(3.18.20) zImage, jetson-tk1 dtb file (i would build them) and install moudles to lib in ~/L4T/roofs. and i flash it using emmc. but board is not booted and does't print boot log . where do i fix part??? sorry i can't do englisj well...
always thank for giving me advice. according to your recommendation, i try to edit my ~/L4T/roofs/...../extlinx... entry
after i change the kernel(3.18.20) zImage, jetson-tk1 dtb file (i would build them) and install moudles to lib in ~/L4T/roofs. and i flash it using emmc. but board is not booted and does't print boot log .
where do i fix part??? sorry i can't do englisj well...

#5
Posted 02/10/2018 07:45 AM   
During flash the "rootfs/" subdirectory is [i][b]almost[/b][/i] an exact copy of the resulting file system being installed... The "rootfs/boot/" directory has some files added or overwritten based on the arguments to the flash.sh program (if using JetPack, then JetPack passes arguments to flash.sh indirectly). You can modify your "rootfs/" and customize it prior to flash for everything except "boot/". You will find that if you flash normally, and then merely make the edits or file copies directly to the Jetson's "/boot/" directory, then things should work. You don't even need to flash to add a new kernel or modules. The "/boot/extlinux/extlinux.conf" can be edited directly. For the sake of completeness, if you do want to make such an edit on your host prior to flashing, then what you would need to do for the case of complete control is to place your version of "system.img" in the "Linux_for_Tegra/bootloader/" directory, and then use the "-r" ("reuse") option to flash.sh to not overwrite this new system.img. Keep in mind that system.img can be flashed from either the "sparse" (pseudo-compressed) system.img, or from the raw (uncompressed) system.img.raw...the trick being that it has to be renamed "system.img". Flash.sh does not care, the raw/sparse nature of the file is unimportant to what gets flashed so long as the name is "system.img". system.img.raw can be loopback mounted, and then have your extlinux.conf edits, extra kernels, so on, then put in "bootloader/system.img", and flashed with "-r" option and the boot directory will not be messed with by flash.sh. Example: [code]sudo -s # This is just to remind you to look at how much spare space you have...30GB images are non-trivial. df -H mount -o loop /where/ever/it/is/Linux_for_Tegra/bootloader/system.img.raw /mnt cd /mnt/boot/extlinux # ...edit extlinux.conf, copy files here, so on... cd - umount /mnt cd /where/ever/it/is/Linux_for_Tegra/bootloader cp system.img.raw system.img cd .. exit sudo ./flash.sh [b]-r[/b] jetson-tk1 mmcblk0p1[/code] Beware that flashing a full raw image (versus the sparse image) will take much more time...perhaps hours. [i]It's much easier to simply copy the files directly to the Jetson without flashing[/i] (e.g., "scp")...but for production environments or for backup/restore you'd want an actual image.
During flash the "rootfs/" subdirectory is almost an exact copy of the resulting file system being installed...

The "rootfs/boot/" directory has some files added or overwritten based on the arguments to the flash.sh program (if using JetPack, then JetPack passes arguments to flash.sh indirectly). You can modify your "rootfs/" and customize it prior to flash for everything except "boot/".

You will find that if you flash normally, and then merely make the edits or file copies directly to the Jetson's "/boot/" directory, then things should work. You don't even need to flash to add a new kernel or modules. The "/boot/extlinux/extlinux.conf" can be edited directly.

For the sake of completeness, if you do want to make such an edit on your host prior to flashing, then what you would need to do for the case of complete control is to place your version of "system.img" in the "Linux_for_Tegra/bootloader/" directory, and then use the "-r" ("reuse") option to flash.sh to not overwrite this new system.img. Keep in mind that system.img can be flashed from either the "sparse" (pseudo-compressed) system.img, or from the raw (uncompressed) system.img.raw...the trick being that it has to be renamed "system.img". Flash.sh does not care, the raw/sparse nature of the file is unimportant to what gets flashed so long as the name is "system.img".

system.img.raw can be loopback mounted, and then have your extlinux.conf edits, extra kernels, so on, then put in "bootloader/system.img", and flashed with "-r" option and the boot directory will not be messed with by flash.sh.

Example:
sudo -s
# This is just to remind you to look at how much spare space you have...30GB images are non-trivial.
df -H
mount -o loop /where/ever/it/is/Linux_for_Tegra/bootloader/system.img.raw /mnt
cd /mnt/boot/extlinux
# ...edit extlinux.conf, copy files here, so on...
cd -
umount /mnt
cd /where/ever/it/is/Linux_for_Tegra/bootloader
cp system.img.raw system.img
cd ..
exit
sudo ./flash.sh -r jetson-tk1 mmcblk0p1


Beware that flashing a full raw image (versus the sparse image) will take much more time...perhaps hours. It's much easier to simply copy the files directly to the Jetson without flashing (e.g., "scp")...but for production environments or for backup/restore you'd want an actual image.

#6
Posted 02/10/2018 03:10 PM   
Scroll To Top

Add Reply