Xavier doesn't boot after Secure Boot (PKC + SBK + KEK2) flash (JetPack 5.1.5 / L4T R35.6.1)

kyoungh · April 15, 2025, 8:45pm

Hi, I flashed my AGX Xavier using Ubuntu 20.04 with JetPack 5.1.5 (L4T R35.6.1).

I followed the steps below to generate keys and fuse the device:

sudo su
cd ~/nvidia/nvidia_sdk/JetPack_5.1.5_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/
openssl genrsa -out rsa_priv.pem 3072
openssl rand -hex 16 > sbk.key
openssl rand -hex 16 > kek2.key

Then I tried fusing with the private key, SBK key, and KEK2 key:

sudo ./odmfuse.sh -i 0x19 -k rsa_priv.pem -S sbk.key --KEK2 kek2.key --test jetson-xavier

frm_odmfuse1.log (155.5 KB)
But I got the following error:

*** Calculating HASH from keyfile ... done
PKC HASH: 0xd8923..........f028c
Error: Unsupported SBK keysize 15

I fixed this by adding “0x” the SBK key from:

7ea2aecd2790f51a6b08091ce49c2c8f

to:

0x7ea2aecd2790f51a6b08091ce49c2c8f

After that, the fuse commands worked:

sudo ./odmfuse.sh -i 0x19 -k rsa_priv.pem -S sbk.key --KEK2 kek2.key --test jetson-xavier
sudo ./odmfuse.sh -i 0x19 -k rsa_priv.pem -S sbk.key --KEK2 kek2.key jetson-xavier

frm_odmfuse2.log (94.1 KB)

Then I flashed the board with signed binaries:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash \ 
  -u rsa_priv.pem -v sbk.key jetson-xavier mmcblk0p1

frm_no_flash.log (248.3 KB)

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only \ 
  -u rsa_priv.pem -v sbk.key jetson-xavier mmcblk0p1

frm_flash_only.log (63.7 KB)

However, after flashing is complete, the Xavier doesn’t boot (no UART or HDMI output).
What step might I have missed?
Any help would be appreciated. Thanks!

JerryChang · April 16, 2025, 5:41am

hello kyoungh,

please see-also Topic 117585, it recommends burning all the fuses (including production mode, -p) you need in a single operation.

atrinz · April 16, 2025, 6:36am

Hi Jerry,
I’m trying to secure a Jetson Xavier AGX using Secure Boot (PKC + SBK), rootfs encryption (with EKS + KEK2), and fuse configuration - using (JetPack 5.1.5 / L4T R35.6.1

Could you please review the steps below to:

Confirm correctness and completeness
Point out any mistakes or potential security issues
Suggest any missing configurations

1. Fuse Command (No Burn Test)

sudo ./odmfuse.sh --noburn -j -i 0x19 -c PKC --disable-jtag -p -k rsa_priv.pem -S ./sbk.key --KEK2 ./kek2.key jetson-xavier

Purpose: Dry-run to simulate fusing PKC, SBK, KEK2, and JTAG disable.
Is this enough to validate that all fuses are set correctly before the actual burn?

2. `odmfuse_pkc.xml` Content

<genericfuse MagicId="0x45535546" version="1.0.0">
  <fuse name="JtagDisable" size="4" value="0x1" />
  <fuse name="SecureBootKey" size="16" value="0x46b4384281a0734f2cd89f005c563cc4" />
  <fuse name="Kek2" size="16" value="0778ce6482d36519bcd47b26f24f941e" />
  <fuse name="PublicKeyHash" size="32" value="0x12794978f75d3644ead2d4e4713718dba3b6b7a20436ef70e19f9ff737dbf431" />
  <fuse name="BootSecurityInfo" size="4" value="0x6" />
  <fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>

Does this XML properly define all required fuses?
Are the values correct and in the right order (esp. BootSecurityInfo, SecurityMode)?
What should be the correct value for BootSecurityInfo? is 0x6 correct?

3. `fusecmd.sh` Script

#!/bin/bash
eval './tegraflash.py \
  --sdram_config tegra194-mb1-bct-memcfg-p2888.cfg,tegra194-memcfg-sw-override.cfg \
  --scr_cold_boot_config tegra194-mb1-bct-scr-cbb-mini.cfg \
  --misc_config tegra194-mb1-bct-misc-flash.cfg \
  --pinmux_config tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.cfg \
  --scr_config tegra194-mb1-bct-scr-cbb-mini.cfg \
  --pmc_config tegra19x-mb1-padvoltage-p2888-0000-a00-p2822-0000-a00.cfg \
  --pmic_config tegra194-mb1-bct-pmic-p2888-0001-a04-E-0-p2822-0000.cfg \
  --br_cmd_config tegra194-mb1-bct-reset-p2888-0000-p2822-0000.cfg \
  --prod_config tegra19x-mb1-prod-p2888-0000-p2822-0000.cfg \
  --device_config tegra19x-mb1-bct-device-sdmmc.cfg \
  --gpioint_config tegra194-mb1-bct-gpioint-p2888-0000-p2822-0000.cfg \
  --misc_cold_boot_config tegra194-mb1-bct-misc-l4t.cfg \
  --dev_params tegra194-br-bct-sdmmc.cfg \
  --uphy_config tegra194-mb1-uphy-lane-p2888-0000-p2822-0000.cfg \
  --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg \
  --minratchet_config tegra194-mb1-bct-ratchet-p2888-0000-p2822-0000.cfg \
  --bins "mb2_bootloader nvtboot_recovery_t194.bin; mts_preboot preboot_c10_prod_cr.bin; \
          mts_mce mce_c10_prod_cr.bin; mts_proper mts_c10_prod_cr.bin; \
          bootloader_dtb tegra194-p2888-0001-p2822-0000.dtb; tlk tos-optee_t194.img; \
          bpmp_fw bpmp-2_t194.bin; bpmp_fw_dtb tegra194-a02-bpmp-p2888-a04.dtb; \
          eks eks_t194.img; kernel boot.img; kernel_dtb tegra194-p2888-0001-p2822-0000.dtb; \
          spe_fw spe_t194.bin" \
  --cfg flash.xml \
  --odmdata 0x9190000 \
  --chip 0x19 \
  --applet mb1_t194_prod.bin \
  --bl nvtboot_recovery_cpu_t194.bin \
  --ramcode 2 \
  --cmd "burnfuses odmfuse_pkc.xml"'

Is this a reliable script to burn the actual fuses from the XML?
Any flags missing for the fuse write or checks to add?*

4. EKS Image Generation

python3 gen_ekb.py -chip t194 -kek2_key kek2.key -fv fv.txt \
  -in_sym_key sym1_t194.key -in_sym_key2 sym2_t194.key -out eks_t194.img

cp eks_t194.img bootloader/eks_t194.img

Does this produce a valid eks_t194.img file using the correct keys?
Can this EKS support full rootfs encryption through OP-TEE?*

5. Flashing (No-Flash + Final Flash)

# Prepare image
sudo ROOTFS_ENC=1   ./flash.sh --no-flash -i ./sym2_t194.key -u rsa_priv.pem -v ./sbk.key jetson-xavier mmcblk0p1

# Final flashing with encrypted rootfs
$ cd bootloader
$ sudo bash ./flashcmd.txt

Is this the correct two-step sequence for full image encryption + secure boot?
Any other flags needed when using OP-TEE and EKS in this flow?*

Final Confirmation Request

Please confirm if the above steps achieve the following goals:

Secure Boot with SBK + PKC
Rootfs encryption using a DEK in EKS
Proper fuse setup with simulation + burning
Valid flashing sequence that boots securely

Would greatly appreciate any guidance or corrections — thank you in advance!

JerryChang · April 16, 2025, 8:47am

hello atrinz,

>> Q1

since you’re working with JP-5 public release version, this command-option, -c <CryptoType> has obsoleted, please use --auth instead.
for example,
$ sudo FAB=400 BOARDID=2888 BOARDSKU=0006 BOARDREV=B.0 ./odmfuse.sh --noburn -i 0x19 --auth NS -p -k <pkc> --KEK2 <kek2> -S <sbk> jetson-xavier-devkit

>> Q2

you may see-also Jetson AGX Xavier Series Fuse Programming Application Note.
please refer to FUSE_BOOT_SECURITY_INFO for examination.

>> Q3
please double check above, you should use correct settings to create fuse commands.

>> Q4
it looks correct,
you may enable disk encryption (ROOTFS_ENC=1) after secureboot.

>> Q5
it looks correct.

atrinz · April 16, 2025, 9:33pm

Hi Jerry,

I tried and successfully fused and flashed the device, but it throws the following error during boot:

No key available with this passphrase

Here are the exact steps I followed:

Fusing the Board

Step 1: Generate fuse commands (no burn yet)

sudo ./odmfuse.sh --noburn --auth NS -j -i 0x19 --disable-jtag -p -k rsa_priv.pem -S ./sbk.key --KEK2 ./kek2.key jetson-xavier

Step 2: Unpack and verify fuses

sudo tar xpf fuseblob.tbz2
cd bootloader
cat odmfuse_pkc.xml  # Verified all fuses were included

Step 3: Burn fuse:

sudo ./fusecmd.sh
cd ..

Step 4: Generating eks_t194.img

python3 gen_ekb.py \
  -chip t194 \
  -kek2_key kek2.key \
  -fv fv.txt \
  -in_sym_key sym1_t194.key \
  -in_sym_key2 sym2_t194.key \
  -out eks_t194.img

Then copied the new EKS image:

cp eks_t194.img bootloader/eks_t194.img

Step 5: Flashing the Device

sudo ROOTFS_ENC=1 ./flash.sh --no-flash -i ./sym2_t194.key -u rsa_priv.pem -v ./sbk.key jetson-xavier mmcblk0p1
cd bootloader
sudo bash ./flashcmd.txt

Issue:

On boot, the system fails to decrypt and gives the error and reboots
View Image

No key available with this passphrase.
failed to unlock the encrypted dev /dev/mmcplk0p2

[ 6.882189] tegradc 15220000.display: Display dc.0000000067df92 registered with id=2
[ 6.908131] tegra-se-nvhost 15830000.se: Adding to iommu group 34
…
[ 13.346552] ERROR: failed to unlock the encrypted dev /dev/mmcblk0p2.
No key available with this passphrase.
…
[ 13.356041] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[ 13.356093] CPU: 6 PID: 1 Comm: bash Not tainted 5.10.216-tegra #1
[ 13.356148] Hardware name: NVIDIA Jetson-AGXJetson, BIOS 6.1-39721438 03/04/2025
…
[ 13.382221] —[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]—

Also, interestingly, on the start up page, it shows test key is used!. why is that?

Jetson UEFI firmware (version 6.1-39721438 built on 2025-03-04T09:36:16)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel…
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map…

Please note:
Flashing without disk encryption works perfectly — the system flashes, boots up, and I can verify with the fuseread tool that the mode, public key hash, and other fuses are correctly set. The device is in production mode, so I believe Secure Boot is functioning properly without encryption. The only issue arises when I try to enable rootfs encryption — the system then fails to boot due to a passphrase-related problem.

I’d really appreciate your help!

Thanks!

v_vuyyuru · April 17, 2025, 12:38am

Hello Jerry,
I have followed all the steps mentioned in Topic 117585. and successfully fused the jetson xavier agx.
But now my host computer is just hanging when I run this command: sudo bash ./flashcmd.txt

 $ sudo bash ./flashcmd.txt
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0100 ] Parsing partition layout
[   0.0118 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0124 ] Boot Rom communication
[   0.0140 ] tegrarcm_v2 --chip 0x19 0 --rcm rcm_1_signed.rcm --rcm rcm_2_signed.rcm
[   0.0141 ] BootRom is not running
[   6.2439 ] tegrarcm_v2 --isapplet

I was successful with sudo BOARDID=2888 FAB=400 BOARDSKU=0004 BOARDREV=K.0 ./flash.sh --no-flash -u '<key path>/rsa_priv.pem' -v '<key path>/sbk.key' jetson-agx-xavier-devkit mmcblk0p1 cmd. please find the attached flash logs. Any ideas what might be going on?

I’d really appreciate your help.

Thanks!
flash_logs.txt (87.3 KB)

JerryChang · April 17, 2025, 5:10am

hello atrinz,

it’s usually due to an incorrect EKS image has updated.
may I double check you’re using public release sources package with the same L4T release version?
please see-also similar topics for reference, such as.. Topic 310263 and Topic 276275.

JerryChang · April 17, 2025, 5:13am

hello v_vuyyuru,

it looks like a board communication problem,
you may see-also To Determine Whether the Developer Kit Is in Force Recovery Mode, please double check lsusb for connected device.
BTW, if you’re working with virtual machines, you’ll need to resolve the USB port forwarding issue.

v_vuyyuru · April 17, 2025, 4:28pm

Hello Jerry,

I’m using Linux Host with Ubuntu 22 and Jetson is on Tegra v35. I have checked the lsusb for connected device before flashing and foundBus 001 Device 005: ID 0955:7019 NVIDIA Corp. APX.Jetson was not booting and look like it was bricked after sudo ./fusecmd.sh. But I could see Nvidia on the USB bus and dont see any logs coming out on the Jetson Xavier AGX monitor. can I start over the process again by burning fuses and flashing or is there any other way to resolve this?

I was suspecting the fused PublicKeyHash generated from the rsa_priv.pem. I can confirm the other 2 keys(KEK2, SBK) in the odmfuse_pkc.xml are matched with my original keys.

sudo bash ./flashcmd.txt
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0106 ] Parsing partition layout
[   0.0121 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0130 ] Boot Rom communication
[   0.0144 ] tegrarcm_v2 --chip 0x19 0 --rcm rcm_1_signed.rcm --rcm rcm_2_signed.rcm
[   0.0147 ] BootRom is not running
[   6.1290 ] tegrarcm_v2 --isapplet

As it shows BootRom is not running. does it mean it looking for the match between the fused keys and flashed keys.
Ques1 : Do we need to generate public key hash in separate, from the rsa_priv.pem file using ./tegrakeyhash --pkc rsa_priv-3k.pem --chip 0x19? or it will generate automatically when we run the sudo BOARDID=2888 FAB=400 BOARDSKU=0004 BOARDREV=K.0 ./odmfuse.sh --noburn -j -i 0x19 -c PKC -p -k rsa_priv.pem -S ./sbk.key --KEK2 ./kek2.key jetson-xavier.

The point is I could generate the Publickeyhash using the ./tegrakeyhash. but it seems, the generated publickeyhash is different from the odmfuse_pkc.xml generated by the /.odmfuse.sh.

Thanks

v_vuyyuru · April 17, 2025, 11:47pm

Hello Jerry,

Update: You are right. The problem is with communication. Now, I could able to flash the firmware to jetson and it boots up with out any error.

Question : I want to check the fused keys on Jetson board . So I run this command.
sudo ./odmfuseread.sh -i 0x19 -k '<key path>/rsa_priv.pem' -S' <key path>/sbk.key' jetson-xavier.

output:

PublicKeyHash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (It was matched with my odmfuse_pkc.xml file. intentionally hide the key)
SecureBootKey: ffffffffffffffffffffffffffffffff
Kek0: ffffffffffffffffffffffffffffffff
Kek1: ffffffffffffffffffffffffffffffff
Kek2: ffffffffffffffffffffffffffffffff
Kek256: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
BootSecurityInfo: 00000006
JtagDisable: 00000000
SecurityMode: 00000001
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
ReservedOdm8: 00000000
ReservedOdm9: 00000000
ReservedOdm10: 00000000
ReservedOdm11: 00000000

If you see the Kek2, Securebootkey they were marked as fffffffffffffffffffffff.
what could be the reason for that? can I fuse them again into hardware with sudo ./fusecmd.sh ?

this is the odmfuse_pkc.xml file

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="SecureBootKey" size="16" value="actual sbk " />
<fuse name="Kek2" size="16" value="actual kek2" />
<fuse name="PublicKeyHash" size="32" value="actual public hash key" />
<fuse name="BootSecurityInfo" size="4" value="0x6" />
<fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>

I’d really appreciate your help.
Thanks
Vamsi.

JerryChang · April 18, 2025, 1:41am

hello v_vuyyuru,

that is expected for security concern. if these fuses can be read out after burning, that will be a huge security vulnerability.
as long as SecurityMode is burned, you will get 0xffff… when reading these fuses. It doesn’t matter if they are burned or not.

atrinz · April 21, 2025, 7:55pm

Hi Jerry,
Thanks for your reply! Yes my public release sources package and L4T release version are the same.

I successfully flashed my AGX Xavier using Secure Boot and encryption. Here are the steps I followed:

1. Fuse simulation (`--noburn`)

sudo ./odmfuse.sh --noburn --auth NS -j -i 0x19 --disable-jtag -p -k rsa_priv.pem -S ./sbk.key --KEK2 ./kek2.key jetson-xavier
sudo tar xpf fuseblob.tbz2
cd bootloader
cat odmfuse_pkc.xml  # Confirmed required fuses are included

2. Burn fuses

sudo ./fusecmd.sh
cd ../

3. Prepare PK, KEK, DB keys and signed payloads

Followed instructions here to generate RSA keypairs and certificates and sign payloads:
🔗 Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation

4. Generate encrypted key blob (EKB)

sudo python3 gen_ekb.py -chip t194 -kek2_key kek2.key -fv fv_ekb.txt -in_sym_key sym1_t194.key -in_sym_key2 sym2_t194.key -out eks_t194.img
sudo cp eks_t194.img bootloader/

5. Flash the device (Secure Boot + RootFS encryption + UEFI secure boot)

sudo ROOTFS_ENC=1 ./flash.sh --generic-passphrase --no-flash -i sym2_t194.key -u rsa_priv.pem -v sbk.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym1_t194.key jetson-xavier mmcblk0p1

cd bootloader
sudo bash ./flashcmd.txt

Current status:

The system boots successfully
However, I still see this message on boot:

WARNING: Test Key is used

I’ve used freshly generated keys for SBK, KEK2, RSA private key, and UEFI signing.
So why do I still get the test key warning?

Additional Question:

Based on this lsblk output, can you confirm that encryption is working properly?
Also, is it possible to encrypt /boot as well? Or is /boot required to stay unencrypted?

$ sudo lsblk -f
NAME           FSTYPE      LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINT
loop0          vfat        L4T-README 1234-ABCD
mmcblk0
├─mmcblk0p1    ext4                   973a8704-c965-49ff-ad6e-c3b0a640eb10    218M    34% /boot
├─mmcblk0p2    crypto_LUKS            fd8ab285-5583-434b-bde4-f542724b432c
│ └─crypt_root ext4                   fafea971-ee12-4446-9207-e894ffae6d4c   19.9G    21% /
├─mmcblk0p3
├─mmcblk0p4
├─mmcblk0p5
├─mmcblk0p6
├─mmcblk0p7
├─mmcblk0p8
├─mmcblk0p9
├─mmcblk0p10
├─mmcblk0p11
├─mmcblk0p12
├─mmcblk0p13
├─mmcblk0p14
├─mmcblk0p15
├─mmcblk0p16
├─mmcblk0p17
├─mmcblk0p18
├─mmcblk0p19
├─mmcblk0p20
├─mmcblk0p21
├─mmcblk0p22
├─mmcblk0p23
├─mmcblk0p24
├─mmcblk0p25
├─mmcblk0p26
├─mmcblk0p27
├─mmcblk0p28
├─mmcblk0p29
├─mmcblk0p30
├─mmcblk0p31
├─mmcblk0p32
├─mmcblk0p33
├─mmcblk0p34
├─mmcblk0p35
├─mmcblk0p36
├─mmcblk0p37
├─mmcblk0p38
├─mmcblk0p39
├─mmcblk0p40
├─mmcblk0p41   vfat                   9F89-4C7F
├─mmcblk0p42
├─mmcblk0p43
├─mmcblk0p44
└─mmcblk0p45   crypto_LUKS            0b044971-8af7-46ad-abfd-431dca7f687d
  └─crypt_UDA  ext4                   4f7fa5d1-35a9-491d-9a45-93900d046683  199.4M     0% /mnt/crypt_UDA
zram0                                                                                     [SWAP]
zram1                                                                                     [SWAP]
zram2                                                                                     [SWAP]
zram3                                                                                     [SWAP]
nvme0n1
└─nvme0n1p1    crypto_LUKS            a4dd3f3b-f493-48cc-b4a7-e27f64dbe464

Any insight would be appreciated. Thanks!

JerryChang · April 22, 2025, 2:47am

hello atrinz,

please see-also Topic 279304.

ya, it looks you’ve disk encryption (i.e. it’s partition APP_ENC ) enabled.

please refer to developer guide, [UEFI Secureboot].

it could load signed L4TLauncher, kernel, kernel-dtb, initrd, and extlinux.conf with UEFI SecureBoot enabled.

L4TLauncher cannot detect whether UEFI payload encryption is enabled. However, if the EKB contains the UEFI payload encryption key and UEFI secure boot is enabled, L4TLauncher will assume that UEFI payload encryption is enabled and will attempt to decrypt the UEFI payloads.

atrinz · April 22, 2025, 9:06pm

Hi Jerry,
Thank you for your response. I just want to confirm if my understanding is correct:

The root filesystem (/) and user data area (/mnt/crypt_UDA) are encrypted using LUKS.
The /boot partition cannot be encrypted with LUKS since it’s needed early in the boot process. However, its contents are protected by UEFI Secure Boot (through signature verification), and certain payloads within it are encrypted using a key stored in the EKB (UEFI Payload Encryption).

Also, regarding the warning message—could you please guide me on how to update the UEFI? I tried following the instructions on the edk2-nvidia wiki but didn’t have much luck. I’m still new to this and a bit confused about how to build UEFI with the patch mentioned in Topic 279304.
Thanks again for your help!

JerryChang · April 23, 2025, 3:18am

hello atrinz,

it’s because Bootloader cannot read encrypted files, disk encryption requires to divide system partitions into.. unencrypted APP partition, and an encrypted APP_ENC partition.
please see-also Layout of an Encrypted Disk section for details.

you may refer to Home · NVIDIA/edk2-nvidia Wiki · GitHub for the steps to build/flash UEFI binary.

Topic		Replies	Views
Xavier NX (eMMC) and TX2 NX Secureboot Fusing renders devices unbootable Jetson Xavier NX security	15	2155	February 25, 2022
Failure to unlock 'crypt_root' with fused module when ROOTFS_ENC=1 Jetson Xavier NX boot , kernel , security	18	1314	January 31, 2024
Postmortem: Jetson Xavier AGX will not get past Boot ROM after burning PKC+SBK+KEK256 Jetson AGX Xavier security	9	1880	April 20, 2022
Enabling Secure Boot on Jetson Xavier NX Without EEPROM Access Jetson Xavier NX security , flash , platform-jetson	16	166	October 18, 2024
The device can't start up after flashing one disk encryption image Jetson Xavier NX security	40	2698	March 2, 2022
Secure Boot on Jetson Xavier AGX Jetson AGX Xavier security , nvbugs	44	5235	October 18, 2021
Jetson Xavier NX burn Tegra fuses made the device unbootable Jetson Xavier NX security , nvbugs	24	2808	October 18, 2021
Jetson Xavier NX - Avermedia EN715 - Secureboot Jetson Xavier NX security	31	1109	April 29, 2024
UEFI Reports "Test Key Detected" even when there are no test keys on the system Jetson AGX Xavier boot , kernel , security	11	1189	March 12, 2024
Xavier NX (eMMC) Secureboot Fusing renders devices unbootable Jetson Xavier NX boot , security	27	1342	May 10, 2023

Xavier doesn't boot after Secure Boot (PKC + SBK + KEK2) flash (JetPack 5.1.5 / L4T R35.6.1)

1. Fuse Command (No Burn Test)

2. odmfuse_pkc.xml Content

3. fusecmd.sh Script

4. EKS Image Generation

5. Flashing (No-Flash + Final Flash)

Final Confirmation Request

Fusing the Board

1. Fuse simulation (--noburn)

2. Burn fuses

3. Prepare PK, KEK, DB keys and signed payloads

4. Generate encrypted key blob (EKB)

5. Flash the device (Secure Boot + RootFS encryption + UEFI secure boot)

Current status:

Additional Question:

Related topics

2. `odmfuse_pkc.xml` Content

3. `fusecmd.sh` Script

1. Fuse simulation (`--noburn`)