I encountered weird issue when TX2 NX on DevKit carrier board refusing to boot into encrypted NVME when WiFi module removed (M2 key E module). JetPack 4.6.6 and JetPack 4.6.1
Initially I created EKB key: echo "00000000000000000000000000000000" > ekb.key
created user and password sudo ./tools/l4t_create_default_user.sh -u nvidia -p nvidia -a --accept-license
Updated flash_l4t_nvme_rootfs_enc.xml for proper size of APP_ENC partition.
Flashed with this command sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -S 100GiB -c ./tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml --external-only jetson-xavier-nx-devkit-tx2-nx nvme0n1p1
And as long wifi module installed it works properly fine, but if wifi module removed or it was flashed without it (also tested on Auvidea JN30D, same story). It just crashing with this error from Debug UART console
(source NVIDIA Jetson Linux Developer Guide : Security | NVIDIA Docs ) In my understanding TX2 NX with JP 4.6.6 cannot use “Generic LUKS key“ (according to this Kernel panic when trying to boot from encrypted NVME - #15 by JerryChang), and I need to use ECID option. I see it says “per-device unique info from fuse“. Does it mean that I need to burn something to some fuses to make it work without M.2 wifi module? And I don’t remember if I mentioned this before but this issue happens only when I try to boot from encrypted NVME. When bootting from encrypted EMMC it works fine with/without M.2 wifi module.
Build device tree blobs and copied all of them to the Linux_for_Tegra/kernel/dtb folder.
I tried both options with two clean setups, but outcome was the same:
To build only dtbs:
# Navigate to kernel source cd Linux_for_Tegra/source/public/kernel/kernel-4.9/ # Configure for Tegra (this creates the .config file) make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- tegra_defconfig # Now build device trees make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
Setup GCC from Jetson Linux R32.7.6 package and build dtbs together with kernel with the single script nv_src_build.sh
I tried different order for the EKS, DTB partition and full NVME flashing steps but the outcome was the same. EMMC was already flashed with ECRYPTION enabled.
your step-9 looks incorrect. please refer to developer guide, Disk Encryption Implementation in Jetson Linux. please also check the commands to generate EKS image, Tool for EKB Generation. that <sym2_key_file> is the LUKS key for disk encryption support. it’s the -i options in flash commands to assign key for EKB. so, you should also assign the same disk encryption key to the flash command-line, for instance, $ sudo ROOTFS_ENC=1 ./flash.sh -i ./ekb.key <board> <rootdev>
Build device tree blobs and copied all of them to the Linux_for_Tegra/kernel/dtb folder.
I tried both options with two clean setups:
To build only dtbs:
# Navigate to kernel source cd Linux_for_Tegra/source/public/kernel/kernel-4.9/ # Configure for Tegra (this creates the .config file) make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- tegra_defconfig # Now build device trees make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
Setup GCC from Jetson Linux R32.7.6 package and build dtbs together with kernel with the single scipt nv_src_build.sh
Update flash_l4t_nvme_rootfs_enc.xml for bigger SSD. (
I also tried to generate eks.img with gen_ekb.py, placed it to Linux_for_Tegra/bootloader folder and tried to reflash EKS partition with command sudo ./flash.sh -r -k eks jetson-xavier-nx-devkit-tx2-nx mmcblk0p1. But this is also didn’t help. But I noticed that eks.img generated by gen_ekb.py was different from eks.img generated by flash.sh after flashing EMMC. In both cases I was using the same zero filled key. sym2.key was “00000000000000000000000000000000“.
I already tried patriot 256gb nvme ssd and samsung 128gb with original Xavier nx carrier board and chinese copy of the carrier board from waveshark (jetson-io-base-b) with the same outcome. Only difference that when I am flashing 256gb disk with config for 128gb it take some extra step to fill disk with zeroes, which takes extra 2-3 hours.
I also tried to flash nvme with encryption with wifi module plugged in and without.
If wifi module plugged in during flashing, and stays there during booting - it boots. If wifi module unplugged after flashing- it shows error during boot process and restarts.
If wifi module unplugged before flashing - it show the same error during booting. Plugging wifi module back in doesn’t solve the issue in this case, and issues remains even if wifi module plugged back after the flashing.
Well, too bad. Probably I will consider different options then. But just in case, if you have any hints where and what I can investigate regarding this problem, please let me know.
I made some more testings and seems like this issue doesn’t happend with XavierNX on the same carrier board with the same JP4.6.6.
