Odmfuse.sh not working, missing command

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi, I’ve been following the guides on the Jetson documentation and reading the nvidia forums to make sure I have everything set up correctly before burning fuses. I have my fuse configuration file, which is set to only burn the fuses for the public key hash, oem_k1, securebootkey, kdk0, and bootsecurityinfo. I’ve triple checked everything and all of the values match what they should be.

The issue comes when I run the odmfuse.sh script. Part of the script is to run tegraflash.sh, with one of the passed arguments being “–cmd burnfuse dummy {fusecfgname}” where fusecfgname is a temporary copy of the passed fuse configuration file to be used as the config file to burn the fuses. The issue I keep getting an error saying

unknown command:burnfuses dummy fuse_lXWpcl.xml

I’ve tried finding anything online to point to where this “burnfuse” command is, but there’s no info. There’s only one thing here: Xavier NX with JetPack4.5.1 Fuse issue that mentions the contents of it, but I’m not sure if that’s supposed to be correct nor if the current version of Jetson supports those same commands. I’m using “Jetson_Linux_R39.2.1_aarch64” and I just wanted to have secure boot and full disk encryption with my custom keys but I can’t do that without getting these fuses burned.

The error shows when I use the --test argument with odmfuse and without. When looking at the contents of odmfuse, it showed it used the command burnfuse when testing, and I was so sure of my fuse config file that I tried without the --test argument but it still failed because “unknowncommand burnfuse”.

Can I please get some kind of help with how I’m suppose to burn the fuses when the command doesn’t exist? I also tried using the fspk method, but I need an fspk key from nvidia to do that, and I’m pretty sure I don’t need to go that route to burn fuses since most guides, even on the Jetson documentary don’t even mention requiring that.

4

Temporary solution found, in case anyone is using Jetson R39 and wants/needs to burn fuses. Jetson R39 is missing the required files to properly burn fuses, so I found forums posts of people who have successfully burned fuses on their Orin Nano Devkit and used the same Jetson version, which in my case turned out to be Jetson R35.0. I’m not sure if I needed to download all of it, but just to match my current L4T installation, I downloaded the BSP driver package, Sample Filesystem, and BSP driver package sources. I was able to successfully test burn with my fuse config file, PKC, and SBK, and it finished without issues, neither did it say “unknowncommand:burnfuses…” I was then able to proceed with burning the fuses to my Orin Nano.

So from what I can gather, the current Jetson 39.x packages are missing the required file(s) for burning fuses by using the odmfuse.sh script. It may work fine by using fspk to burn fuses, but since I figured burning fuses was Jetson version agnostic (especially since this occurs before any Jetson software is loaded), it didn’t matter which version of Jetson to use to burn fuses.

Any mods or Nvidia developers, please take a look at Jetson R39.x, I’ve tried every subversion of R39 and got the same error message, but worked perfectly fine with R35. I could’ve tried R36 later, but since I saw someone have success with R35, I just went with that one since I figured if someone else was successful with R35.0, I should be too.

tl;dr: USE JETSON R35.0 TO BURN FUSES IF R39.x (unless you need to use fspk, which might work for you).

5

I also wanted to include the steps to flash an encrypted file system to the external NVME with Jetson Orin Nano after burning the fuses. I had to look at a few different guides and try to figure out how each stepped worked and what needed to be changed to work with Jetson R39.x

  1. Download and extract BSP, sample file system, and BSP sources
  2. Run the flash_prerequisites and apply_binaries scripts
  3. Go in {BSP_TOP}/source/ and extract the nvidia-jetson-optee tar file
  4. Go into the extracted optee folder, into /samples/hw-agent/host/tool/gen_ekb and put the oem_k1 key file in the same folder (this should be the same key used when you burned the oem_k1 fuse).
  5. Generate the other keys (sym, sym2, auth, and hwkey) following the readme or example script details.
  6. Run the example script.
  7. Copy the generated ekb_(platform).img file to {BSP_TOP}/bootloader, overwriting what was already there, if there is anything.
  8. Copy the generated sym2 key to {BSP_TOP}
  9. In terminal, pointed at {BSP_TOP} run (order matters, order is important:
  1. Optional: $ sudo ./tools/l4t_create_default_user.sh -u {username} -p {password} -n {hostname} --accept-license
  2. $ sudo cp bootloader/eks_t234_sigheader_encrypt.img.signed ./tools/kernel_flash/images/internal/
  3. $ sudo ./l4t_initrd_flash.sh --showlogs --no-flash --network usb0 -u -v -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” jetson-orin-nano-devkit internal
  4. $ sudo ROOTFS_ENC=1 EXT_NUM_SECTORS=XXXXXXXXXX ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u -v --no-flash --external-device nvme0n1p1 -i -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S XYZGiB --external-only --append --network usb0 jetson-orin-nano-devkit external
  5. $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u -v --network usb0 --flash-only jetson-orin-nano-devkit

…where

  • {username}, {password}, and {hostname} are the username, password, and hostname you want associated with the device in case you wanted the initial setup complete for headless mode,
    • If you skip this step, you’ll just have to create the initial user and accept the license on your first boot.
  • is the path to the private key associated with the public key hash from your fuse config xml,
  • is the path to the securebootkey which is also very similar to the securebootkey in your fuse config xml (except it’s the version with 8x 4-length values, not the single 1x 32-length value) (the contents should look like [0x01234567 0x12345678 0x23456789 …]),
  • XXXXXXXXXX is the number of sectors of your storage device. This is calculated by: total size in (gigabytes * (1024^3)) / 512 (512 because you have to divide by the sector size. Modern drives use physical sectors of size 4096 [4K] but can logically map them as 512 for backwards compatibility. Jetson seems to require using 512, so even if you get better performance with the modern 4096, you’ll need to use 512),
    • So for my 1TB drive, the calculation is 1024^4 / 512 = 2147483648.
      • This is the maximum, and likely won’t work. You’ll very likely need to use a lower value. For instance, with a 1TB drive, use 900GB for your calculation → (900*1024^3 / 512)
    • If you have a 500GB drive, you would do 500 *1024^3 / 512 or (500*1024*1024*1024) / 512 = 1048576000
    • If you have a 128GB drive, you would do 128 *1024^3 / 512 = 268435456
  • XYZ is the size you want the encrypted file system to be, this needs to be less than the overall drive size. For a 1TB drive (1024GB), that is equal to about 930GiB, so -S should be at most 930GiB. I use 900GiB.

After flashing, you’ll still likely see “no key with passphrase” when booting, but it will eventually load using your custom keys.