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.