update just Kernel from R24.2.1 for R24.1

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hi there,

I grabbed the latest R24.2.1 L4T, and want to use the new kernel directly for R24.1 without updating the whole file system, it works fine if I just update the kennel and modules and boot with old Device tree file. Errors come up when I update the new compiled file “tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” as following, for R24.1, there is no “initrd” file, do have one did the same thing successfully? Thank you.

Retrieving file: /boot.work/Image
20114872 bytes read in 864 ms (22.2 MiB/s)
append: consoleblank=0 console=ttyS0,115200n8 fbcon=map:0 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.autosuspend=-1 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff2bf000 nvdumper_reserved=0xff23f000 core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk0p1 rw rootwait pci=nomsi
Retrieving file: /boot.work/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
424924 bytes read in 437 ms (949.2 KiB/s)
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
   reserving fdt memory region: addr=80000000 size=20000
   Using Device Tree in place at 0000000082000000, end 000000008206abdb
Can't create DT prop nvidia,emc-burst-mc-regs to copy
Can't create DT prop nvidia,revision to copy
Can't create DT node emc-table@204000 to copy
ERROR: board-specific fdt fixup failed: FDT_ERR_NOTFOUND
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###
2

I don’t know what all of the issues would be, but as a checklist you’d need the new “Image” (kernel), the dtb file, the kernel modules directory, the initrd, and possibly the “/lib/firmware” from R24.2.1. Whether or not any change would be required on init (because of suddenly needing initrd) I don’t know.

FYI, drivers, device tree, and firmware all work together, and of course modules are part of the kernel. Whether or not firmware changed I don’t know, but you’d be better off assuming there are changes and using the R24.2.1 versions together as a set.

3

We already tried updating all the related files, kernel, driver, device tree and firmware, and can not get it work?

4

Have you tried copy of the initrd file from R24.2.1 to R24.1, plus adding the INITRD line from R24.2.1’s extlinux.conf to the boot entry of R24.1’s extlinux.conf? The goal being to use the initrd from R24.2.1…note that after a pivot_root is called this goes away and should not interfere with anything from R24.1 once root file system mounts.

5

Hi Linuxdev,

Yes, we also tried this method, as described in the Guide of R24.2.1, the initrd is used to speed up kernel loading when use external file system. Our file system is in the internal mmc. so I do not think this will be any helpful. One interesting thing is if I use the old Device tree file with the new kernel in R24.1, we never have the error when boot up.

6

Pseudo file systems loaded into RAM on a running system do have extreme speed advantages. However, initrd has a special use-case significance unrelated to speed. Initrd is loaded by the boot loader prior to the kernel loading. This means kernel modules and other files in the initrd are available to the kernel before the kernel begins execution regardless of whether the kernel itself can read a file system.

Some kernel features, such as for reading the ext4 file system type or for a hard disk controller are required before mounting the root file system. Having those features integrated into the kernel means the kernel will be able to mount the root file system…but if those features are configured as a module, then boot would fail since the rootfs would require mounting in order to load the drivers mandatory to access of the rootfs…the proverbial “catch 22” or the “chicken and the egg” conundrum. All features required for mounting and accessing the file system which are modular must be in the initrd. Modules are just the most common example, there is also firmware setup at issue.

In the R24.2.1 mounting rootfs is not possible without some of the initrd files (in any case it takes as much time to read those files from eMMC via boot loader as it would via the kernel, and once loaded as initrd the pivot_root actually adds time, so it isn’t there for a speed advantage…plus modules require an extra direct branch assembler action to work, so every module is slightly slower than an integrated feature…but initrd goes away at rootfs mount). Anything breaking in the chain of events to access eMMC (drivers+firmware+device tree), to read partition types (GPT), or to read the file system type (ext4) make the initrd mandatory.

To see what is in that initrd:

cd /tmp
cp /boot/initrd .
gunzip < initrd > initrd.cpio
mkdir tmp
cd tmp
sudo cpio -vid < initrd.cpio

I don’t know that everything there is actually required, but I do see some firmware. If that firmware takes part in the boot process (such as drivers expecting that firmware), then lacking this will imply boot failure via drivers not seeing what is expected. If the firmware is required to read the file system, then the file system won’t be readable without the initrd.

In your specific case, when there is a failure, I’m thinking perhaps the initrd firmware does not match the device tree. Whichever version you load may not match the firmware used because in one case it is the firmware of the initrd, and in the other case it is the firmware on eMMC (it depends if you look before rootfs mount, or after rootfs mount). The fact is that you have two versions of firmware, but most people only think about the one in “/lib/firmware” after rootfs is mounted. The initrd creates a sneaky dual personality! :P

Incidentally, if you add something to the unpacked initrd, reverse packaging goes something like this:

cd /some/location/to/package
sudo -s
find -print | cpio -ov > ../initrd.cpio
cd ..
gzip initrd.cpio
mv initrd.cpio initrd
exit

Check carefully if anything related to a dtb or “/lib/firmware” might be mixing between the old R24.1 and newer R24.2.1 both before and after rootfs mounts (the pivot_root event).