Flashing and SecureBoot test before burning ODM Production Mode FUSE

I need to restore all partitions from non-SecureBoot enabled device (no fuse burnt) to SecureBoot enabled device (fuse burnt). I am using Orin Nano devkit with Jetpack 6.0.

[ Orin Nano (No FUSE burnt) ] ==> [ Orin Nano (SecureBoot with FUSE enabled) ]
  • I guess it is possible to do it with backup restore tool if I use PKC file and SBK file with -u and -v option. But could you please confirm this before I actually consume another device FUSE?
    # Backup
    sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit
    
    # Restore
    sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r \
        -u pkc.key -v sbk.key jetson-orin-nano-devkit
    
  • Suppose I have mfi tar ball from the non-SecureBoot enabled device, I guess it is not possible to flash the mfi image to the SecureBoot enabled device. However, will it turn possible if I don’t burn ODM Production Mode FUSE but only PKC/SBK/OEM_K1 FUSE?
    # Will this work if ODM Production Mode FUSE is not burnt?
    cd mfi_jetson-orin-nano-devkit
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only
    
  • Related to the above question, is it possible to test SecureBoot without burning ODM Production Mode FUSE? Actually I have verified with burning ODM Production Mode FUSE that I can enable SecureBoot with FUSE as follows. But I’d like to know whether the same can be tested without ODM Production Mode FUSE or not before consuming another device FUSE.
# Generate keys and EKS
python3 gen_ekb.py \
        -chip t234 \
        -oem_k1_key oem_k1.key \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -in_auth_key auth_t234.key \
        -out eks_t234.img

# oem_k1.key contains the same value as OEM_K1 FUSE
# sym_t234.key, sym2_t234.key, and auth_t234.key includes randomly generated Hex strings
# Copy to eks_t234.img to Linux_for_Tegra/bootloader
# Copy sym_t234.key and sym2_t234.key to Linux_for_Tegts

sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --network usb0 -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
        -u pkc.key -v sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key \
        --erase-all --no-flash jetson-orin-nano-devkit internal

sudo cp bootloader/eks_t234_sigheader_encrypt.img.signed ./tools/kernel_flash/images/internal/

sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --erase-all --no-flash --external-device nvme0n1p1 \
        -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml \
        -u pkc.key -v sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key \
        --external-only --append jetson-orin-nano-devkit external

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only

hello akudo,

actually, you may using backup/restore script after secure boot has enabled.
for instance,
$ sudo ./tools/backup_restore/l4t_backup_restore.sh -u <PKC> -v <SBK> -b <Jetson-platform>

however,
there’s security concern to backup/restore an encrypted disk, (i.e. ROOTFS_ENC).
please refer to Topic 291335 to create encrypted images with a generic key,
so that you may create a massflash (i.e. mfi_*.tar.gz) package to flash multiple devices simultaneously.

Hello JerryChang,

Yes, I will use the generic key solution in the end for mass production.
I have verified it works as well.
For R&D phase, I sometimes create an image without --massflash option because it can save time from creating mfi.

What about my question when FUSE is burnt without ODM Production Mode flag?

I have mfi tar ball from the non-SecureBoot enabled device, I guess it is not possible to flash the mfi image to the SecureBoot enabled device. However, will it turn possible if I don’t burn ODM Production Mode FUSE but only PKC/SBK/OEM_K1 FUSE?

is it possible to test SecureBoot without burning ODM Production Mode FUSE?

Thank you.

I have schedule constraints and so I will try the ODM Production Mode test myself.
Thank you for all the information, anyway.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.