FSKP Fuse Burn: USB Write Timeout

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

I’m encountering a USB write timeout while performing an FSKP fuse burn test on my Jetson AGX Orin DevKit.

  • Host OS: Ubuntu 22.04 (tested both Desktop and Server editions)
  • Device: Jetson AGX Orin DevKit
  • L4T version: R36.4 (JetPack 6.x)
  • USB autosuspend: Disabled (verified as per Jetson AGX Orin FAQ)

Command used

sudo ./fskp_fuseburn.py \
  --board-spec orin-agx-board-spec.txt \
  --fusefile /mnt/l4t/JetsonKeys/nvidia_fskp/fuse_config_presecure.xml \
  --keyindex 62 \
  --key-exp /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ak.bin /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ek.bin \
  --fskpcfg /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_conf.txt \
  --chip 0x23 \
  --board /mnt/l4t/Linux_for_Tegra/jetson-agx-orin-devkit.conf \
  --outdir ./out_fuseblob \
  --test

Observed behavior:
Everything runs smoothly until the tool attempts to download the FSKP blob to the target, where it fails with a USB write timeout:

FSKP execution started 2025-10-27 20:33:01.218076
fskp_fuseburn.py script version 0.2
Parsing input arguments
fskp_fuseburn.py script version 0.2
Parsing input arguments
Setting up default paths
Setup host environment
Creating t234 fuse blob
Generating 13 random string pairs
Generating BR-BCT
Saving platform information to plaform_info.txt
Update iv and der string for br_bct_BR.bct
Generating MB1-BCT
Updating mb1-bct with firmware information
Generating MEM-BCT
Using ramcode 0
Get Signed section of bct
Signing BCT
Updating BCT with signature
Generating SHA2 Hash
Updating BCT with SHA2 Hash
Signing mb1_bct_MB1.bct
Update iv and der string for mb1_bct_MB1_aligned_sigheader.bct
Signing bct_MEM.bct
Update iv and der string for bct_MEM_aligned_sigheader.bct
Signing mb1_t234_prod.bin
Update iv and der string for mb1_t234_prod_aligned_sigheader.bin
Signing psc_bl1_t234_prod.bin
Update iv and der string for psc_bl1_t234_prod_aligned_sigheader.bin
Updating mb2-bct with storage information
Concatenating mb2-bct to mb2 binary
fskp_test.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_mb2_t234.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_mb2_t234_aligned_sigheader.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_tegra234-bpmp-3701-0004-3737-0000.dtb
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_tegra234-bpmp-3701-0004-3737-0000_aligned_sigheader.dtb
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_spe.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_spe_aligned_sigheader.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_mce_flash_o10_cr_prod.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_mce_flash_o10_cr_prod_aligned_sigheader.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_pscfw_t234_prod.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_pscfw_t234_prod_aligned_sigheader.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_fskp_test.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_fskp_test_aligned_sigheader.bin
Encrypting /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_fskp_test_aligned_sigheader.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_fskp_test_aligned_sigheader_encrypt.bin
Signing /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_bpmp_t234-TE990M-A1_prod.bin
Update iv and der string for /mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/out_fuseblob/blob_bpmp_t234-TE990M-A1_prod_aligned_sigheader.bin
WARNING!! Testing Fuses option is selected
do you want to continue testing the fuses (Yes/No) yes
Downloading FSKP blob to target
command sudo /mnt/l4t/Linux_for_Tegra/tools/flashtools/flash/tegrarcm_v2 --chip 0x23 --pollbl --download bct_mem bct_MEM_sigheader.bct --download blob blob.bin failed, exit-code=3 error = 
command /mnt/l4t/Linux_for_Tegra/tools/flashtools/flash/tegrarcm_v2 --chip 0x23 --pollbl --download bct_mem bct_MEM_sigheader.bct --download blob blob.bin failed.
BL: version 1.4.0.4-t234-54845784-e89ea9bc last_boot_error: 0
Sending bct_mem
Sending blob
ERROR: might be timeout in USB write.

FSKP execution failed
Traceback (most recent call last):
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/./fskp_fuseburn.py", line 136, in <module>
    main(sys.argv)
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/./fskp_fuseburn.py", line 130, in main
    raise e
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/./fskp_fuseburn.py", line 125, in main
    u.main(commandLineArgs)
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/./fskp_fuseburn.py", line 100, in main
    h.send_fskp_blob_to_target_t234()
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/fskp_helper.py", line 748, in send_fskp_blob_to_target_t234
    self.run_sudo_cmd(cmd)
  File "/mnt/l4t/Linux_for_Tegra/tools/flashtools/fuseburn/fskp_helper.py", line 616, in run_sudo_cmd
    raise OSError("command " + cmd + " failed.\n" + output)
OSError: command /mnt/l4t/Linux_for_Tegra/tools/flashtools/flash/tegrarcm_v2 --chip 0x23 --pollbl --download bct_mem bct_MEM_sigheader.bct --download blob blob.bin failed.
BL: version 1.4.0.4-t234-54845784-e89ea9bc last_boot_error: 0
Sending bct_mem
Sending blob
ERROR: might be timeout in USB write.

What I’ve tried

  • Disabled USB autosuspend system-wide via udev and /sys/bus/usb/devices/*/power/control (confirmed all on)

  • Swapped multiple USB-C cables (both data-rated and NVIDIA-supplied)

  • Tested on multiple host machines (Intel x86_64)

  • Tried both USB 3.0 and USB 2.0 ports

  • Verified tegrarcm_v2 works for standard flashing operations (no issue)

Despite these, the timeout occurs consistently at the same stage.

Questions

  • Has anyone encountered this specific USB timeout during fskp_fuseburn.py?

  • Could this be related to the device’s recovery mode stability or host USB controller timing?

  • Are there recommended tegrarcm_v2 parameters or known issues with the FSKP test mode on R36.4?

Any insight or workaround would be appreciated — I’m trying to validate the fuse burn process before finalizing secure boot provisioning.

Thanks in advance!

5

hello yakovyna,

is this target fused before?

please note that, the fuse value for boot_security_info was burned (by manufacturing) to 0x1E0. you may see-also Jetson Orin Series Modules Fuse Update Field Services Bulletin,
please try to execute nv_fuse_read.sh for reading fuse variables if you’re able to boot into linux.
or.. you may putting device enter forced-recovery mode for reading fuse via flash script.
for instance, $ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

following above, please examine the fuse.xml file for your key contents.
if you fuse burn with a board shown default boot_security_info=0x1E0.
you must bitwise logically OR the desired value with 0x1E0 in your fuse programming flow.

6

Hello Jerry,

Thank you for your earlier insight — you were correct that my board came from the factory with BootSecurityInfo = 0x1E0 already burned.

Below is the current fuse readout:

==== Fuse Info (/mnt/l4t/Linux_for_Tegra/bootloader/fuse_t234.bin) ====
PublicKeyHash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000001e0
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmInfo: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
Sku: 000000d0
Uid: 0081010b0000007c61015e7004000000
OptEmcDisable: 00000000

I’ve updated my fuse_config_presecure.xml as follows:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <!-- PKC: public key hash generated from your OEM public key -->
    <fuse name="PublicKeyHash" size="64" value="<PKC>"/>

    <!-- SBK: 128-bit AES key for boot image encryption -->
    <fuse name="SecureBootKey" size="32" value="<SBK>"/>

    <!-- BootSecurityInfo: must preserve pre-burned bits (0x1E0 factory value) by applying bitwise OR with desired flags.
         Example: new_value = 0x1E0 | desired_bits.
         This ensures reserved bits [8:4] remain intact and avoids PSC validation or USB timeout errors during FSKP fuse burn. -->
    <fuse name="BootSecurityInfo" size="4" value="0x1E9"/>

    <!-- SecurityMode = 0x0 keeps Secure Boot unenforced for testing -->
    <fuse name="SecurityMode" size="4" value="0x0"/>
</genericfuse>

However, I’m still encountering the same USB write timeout error during the --test phase.
Do you have any suggestions on what else could cause this?

7

hello yakovyna,

let’s narrow down this by running with odmfuse script directly.
please see-also Burn Fuses with the Fuse Configuration file.
here’s an example, $ sudo ./odmfuse.sh --test -X <fuse_config> -i <chip_id> <target_config>

8

Hi Jerry,

The odmfuse.sh run completed successfully (at least from what I can tell) using the same fuse_config_presecure.xml I shared earlier.

I also wanted to clarify my understanding of the BootSecurityInfo field:
0x1E9 = 0x1E0 (reserved bits [8:4]) + 0x8 (SBK enable, bit [3]) + 0x1 (PKC = RSA-3072, bits [2:0]).

Could you please confirm if this interpretation is correct, or if there’s anything I’m missing?

I’ve attached logs from two consecutive odmfuse.sh runs for your review:

odmfuse_log2.txt (93.6 KB)

odmfuse_log1.txt (93.8 KB)

Thanks.

9

hello yakovyna,

that looks correct.
however, did you modify fuse_config_presecure.xml to enable SecurityMode for testing?
please refer to below, this is what I see from the fusing logs, it seems it’ll burn this fuse with a value of 0x1, all additional fuse write requests will be blocked.

node: name=SecurityMode size=4
type 0x1d size 4 
  value=0x1
10

Hi Jerry,

Yes, I did modify the file to enable SecurityMode for testing.

However, I’m still unsure why the fskp_fuseburn.py script fails on my setup — is it known to have issues, or could there be something specific in my environment?

Ultimately, what would you recommend as the proper approach to burn Secure Boot on the device?
The documentation mentions that the odmfuse method is deprecated, so I’d prefer to use the FSKP flow if possible.
Could you please help me understand what might be causing the failure in fskp_fuseburn.py?

I’d really appreciate your guidance on this.

11

hello yakovyna,

is it due to L4T version mismatch?
anyways, please contact your NVIDIA representative since it’s related to FSKP tool package.

14

hello yakovyna,

could you please share the complete logs (both host and target side) for reference?
BTW, please also check Preparing the Encrypted and Signed Blob, we’ll need to confirm those board info.

15

Hi Jerry,

Thank you for your reply. The issue was caused by the file I passed as the --board-spec parameter. After correcting the values, I was able to complete the test stage successfully.

However, I’m now facing a different problem — while the test fuse burn completes without errors, the production fuse burn doesn’t seem to persist.

I’ve attached the full host-side fuse burning logs for reference:

fuse_burn.log (42.0 KB)

After the fuse burn completed, I powered off the board, re-entered Recovery Mode, and ran the following command (expecting it to fail since PKC and SBK weren’t provided):
sudo ./flash.sh --read-info jetson-agx-orin-devkit mmcblk0p1

The resulting fuse readout still shows empty values — here’s the relevant section:

==== Fuse Info (/mnt/l4t/Linux_for_Tegra/bootloader/fuse_t234.bin) ====

PublicKeyHash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

BootSecurityInfo: 000001e0

ArmJtagDisable: 00000000

SecurityMode: 00000000

SwReserved: 00000000

DebugAuthentication: 00000000

OdmInfo: 00000000

OdmId: 0000000000000000

OdmLock: 00000000

ReservedOdm0: 00000000

ReservedOdm1: 00000000

ReservedOdm2: 00000000

ReservedOdm3: 00000000

ReservedOdm4: 00000000

ReservedOdm5: 00000000

ReservedOdm6: 00000000

ReservedOdm7: 00000000

Sku: 000000d0

Uid: c001fe0b0000005c44015e7004000000

OptEmcDisable: 00000000



==== EEPROM content (/mnt/l4t/Linux_for_Tegra/bootloader/cvm.bin) ====

00000000: 02 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000010: 00 00 00 0a 36 39 39 2d 31 33 37 30 31 2d 30 30  ....699-13701-00

00000020: 30 35 2d 35 30 31 20 47 2e 30 00 00 00 00 00 00  05-501 G.0......

00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000040: 00 00 00 00 1e 29 b1 66 6d 3c 31 34 32 33 32 32  .....).fm<142322

00000050: 35 30 32 37 32 35 32 00 00 00 00 00 00 00 00 00  5027252.........

00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000090: 00 00 00 00 00 00 4e 56 43 42 00 00 4d 31 00 00  ......NVCB..M1..

000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 1e 29 b1 66  .............).f

000000b0: 6d 3c 0a 00 00 00 00 00 00 00 00 00 00 00 00 00  m<..............

000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d1  ................

At the moment, I can’t provide the target-side UART logs as I don’t have the appropriate adapter available, but I can capture and share them once I do.

Could you please help me determine why the fuses appear unprogrammed even though the burn process completes successfully?

16

hello yakovyna,

did you have fuse xml to set SecurityMode = 0x0?
for instance,

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="SecurityMode" size="4" value="0x0"/>
</genericfuse>

if yes… please try removing it from the xml file.

17

Hey Jerry,

I have tried with the commented “SecurityMode” section, as you suggested:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <!-- PKC: public key hash generated from your OEM public key -->
    <fuse name="PublicKeyHash" size="64" value="VALUE"/>

    <!-- SBK: 128-bit AES key for boot image encryption -->
    <fuse name="SecureBootKey" size="32" value="VALUE"/>

    <fuse name="OemK1" size="32" value="VALUE"/>
    <fuse name="OemK2" size="32" value="VALUE"/>

    <!-- BootSecurityInfo: must preserve pre-burned bits (0x1E0 factory value) by applying bitwise OR with desired flags.
         Example: new_value = 0x1E0 | desired_bits.
         This ensures reserved bits [8:4] remain intact and avoids PSC validation or USB timeout errors during FSKP fuse burn. -->
    <!-- 0x1E0 (factory) | 0x8 (SBK enable, bit 3) | 0x1 (PKC 3k RSA, bits [2:0]) | 0x200 (ODM Key Valid, bit 9) = 0x3E9 -->
    <fuse name="BootSecurityInfo" size="4" value="0x3E9"/>

    <!-- SecurityMode = 0x0 keeps Secure Boot unenforced for testing -->
    <!-- <fuse name="SecurityMode" size="4" value="0x0"/> -->
</genericfuse>

The process completed successfully without errors, but the result was the same — no fuses were actually programmed (verified with ./flash.sh --read-info).

Do you have any ideas why this would happen?

18

hello yakovyna,

we may need the logs both from host side and target side for confirmation.

19

Hi Jerry,

Could you please help me figure out which cable I should use to connect to the serial port for debugging (if I’ve identified it correctly)?

I tried using a USB-to-TTL cable but wasn’t able to get any logs from the device, following the official guide.

Thanks in advance!

20

hello yakovyna,

you should connect your host with the USB micro-B port for debugging.
there’s node /dev/ttyACM0 for communication, you may setup a terminal to execute picocom or minicom for gathering the logs.
for instance, $ sudo picocom -b 115200 /dev/ttyACM0

21

I’ve performed three tests:

  1. Fuse burning using the --test option

  2. Generating a blob with -b and --out_dir

  3. Actually burning the generated blob using the -b parameter

Additionally, I ran sudo ./flash.sh --read-info jetson-agx-orin-devkit mmcblk0p1 to retrieve the fuse information.

Please find attached the host and target device logs for all operations.
Hope this helps in identifying the issue.

fuse-test-host.txt (3.6 KB)

fuse-test-target.txt (104.1 KB)

fuse-burn-with-output-host.txt (39.5 KB)

fuse-burn-final-host.txt (2.1 KB)

fuse-burn-final-target.txt (44.9 KB)

get-info-result.txt (2.2 KB)

22

hello yakovyna,

you should also assign --keyindex for actually fuse burning.
for example,
this is command-line with --test options.
$ sudo ./fskp_fuseburn.py --board-spec orinnano-board-spec.txt -f fuseblob.xml -i 62 --test --key-exp fskp_ak.bin fskp_ek.bin --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B <top>/jetson-orin-nano-devkit.conf
in order to burn the fuse, you should replace the --test argument with the -b options.

23

Here are the exact commands I ran during the test phase:

sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec-fixed.txt \
    --fusefile /mnt/l4t/JetsonKeys/nvidia_fskp/fuse_config_presecure.xml \
    --keyindex 62 \
    --key-exp /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ak.bin /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ek.bin \
    --fskpcfg /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_conf.txt \
    --chip 0x23 \
    --board /mnt/l4t/Linux_for_Tegra/jetson-agx-orin-devkit.conf \
    --outdir ./out_fuseblob \
    --test

sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec-fixed.txt \
    --fusefile /mnt/l4t/JetsonKeys/nvidia_fskp/fuse_config_presecure.xml \
    --keyindex 62 \
    --key-exp /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ak.bin /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_ek.bin \
    --fskpcfg /mnt/l4t/JetsonKeys/nvidia_fskp/FSKP/fskp_conf.txt \
    --chip 0x23 \
    --board /mnt/l4t/Linux_for_Tegra/jetson-agx-orin-devkit.conf \
    --outdir ./out_fuseblob \
    --burnfuse --verbose

sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec-fixed.txt \
    -P ./out_fuseblob \
    -c 0x23 \
    --board /mnt/l4t/Linux_for_Tegra/jetson-agx-orin-devkit.conf \
    --burnfuse

When I try adding --keyindex to the last command, the script immediately throws:

Parsing input arguments
--keyindex/-i is not a supported option with --prebuilt/-P

So at this point I don’t see what I’m missing – I’m following the documented steps, and the tool itself rejects --keyindex when using a prebuilt blob.

24

The out_fuseblob has the Keyindex already embedded , so it’s not needed for the last command

1 Like
25

Hi,

Thanks for the clarification. I understand that the prebuilt blob already contains the key index.
Given that, do you have any idea where the issue might actually be coming from or what I should check next?