Jetson Orin Nano - Exception in EL3

Hi All,

I’ve been wrestling with this issue for a long time and just cant crack it.

We’re attempting to get the most secure secure boot chain that we can working and I believe so far we’ve got the process for generating keys and burning them correct. I’ve had a few boards and have burned the fuses with the following fuse config file (obviously removed the keys).
jetson-fuses.txt (358 Bytes)

We’re using jetpack-nixos to make our own OS and flashing it to an nvme disk, but we’ve found that the system boots just fine with the “SecurityMode” fuse is left unburned, however once burned we can no longer get the machine to boot NixOS, and only ever get the following error every time. We found this by using 2 boards, and burning more and more fuses, working the way down the list of fuses in the attached config file and testing after every step until the board no longer booted properly.
jetson-boot-error.txt (40.4 KB)

What are we doing wrong here? I thought that last fuse setting only locked things down to prevent further modification of fuses. Am I missing something here?

We are also using a 3rd party carrier board.

Any help would be appreciated. Hopefully theres a line in the log files that tells exactly whats going wrong here.

hello roryb,

it’s mentioned by developer guide, Secure Boot.
after the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.

we’ve tested and it’s confirmed we can burn fuses and boot up success on Orin-NX-8GB + r35.4.1
you may see-also Topic 263458 for reference.

Do you know if this fuse setting changes or enables any other behaviour except blocking additional fuse write requests?

On our boards, the instant this is enabled, our board stops being able to boot. Burning all the other fuses beforehand and stopping before burning the SecurityMode fuse does not cause any issues. But the moment we burn the SecurityMode fuse it fails to boot.

hello roryb,

you cannot change fuse values once a fuse bit is set to 1.
for example, a fuse value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), but not to 4 (0x4) because bit 0 is already programmed to 1.

moreover,
the recommended way is to burn all fuses together instead of burning fuses step-by-step.

Yes, burning them all together is what we have been doing. However when we burn all of them together (including the SecurityMode fuse) we are unable to boot. When we take another board, and burn all the same fuses together and just dont burn the SecurityMode fuse, we can still boot the system. If I then burn the SecurityMode fuse on the second board, to bring it in line with the first, the second board is unable to boot. Just like the first.

The act of burning that fuse is somehow changing behaviour somewhere.

hello roryb,

could you please share all your steps in details, and also the fuse configuration file (i.e. *.xml file that contains fuse data) for reference.

Hi JerryChang,

An example fuse configuration file was always included in the original post, however I have removed the key values to protect them. I will attach another here with correct, but unused keys to demonstrate that our key generation technique is correct. We have scripted the generation process to generate keys and produce the final fuse.xml file.
jetson-fuses-2.txt (2.7 KB)

Our flash process for a non-working system is as follows:

  1. Generate keys and fuse configuration files
  2. Download L4T, ATF and OPTEE source, checking out the relevant versions
  3. Using our keys generated in step 1, generate an EKS image with the correct OEM_K2 fuse value, FV and sym_key values. Eventually producing eks_t234.img
  4. Recompile OPTEE to contain our new FV and disable use of test keys, eventually producing tos-optee_t234.img
  5. Replace files in Linux_for_Tegra/bootloader path with the ones generated in step 3 & 4
  6. Place the board into recovery mode and connect to host computer
  7. Use the provided odmfuse.sh script to burn the fuses in one step ./odmfuse.sh -X <XML_FILE_PATH> -i 0x23 jetson-orin-nano-devkit-nvme
  8. Power cycle the board just to be sure, and enter recovery mode again
  9. Run ./flash.sh -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit-nvme internal to push the updated tos-optee and eks images.
  10. Insert pre-flashed NVMe disk and boot

Result: Board does boot to uefi, but when it attempts to boot our OS we get the same error as in original posts log file every time.

Our flash process for a working system is as follows:

  1. Generate keys and fuse configuration files
  2. Remove line containing <fuse name="SecurityMode" size="4" value="0x1"/> from fuse configuration file.
  3. Download L4T, ATF and OPTEE source, checking out the relevant versions
  4. Using our keys generated in step 1, generate an EKS image with the correct OEM_K2 fuse value, FV and sym_key values. Eventually producing eks_t234.img
  5. Recompile OPTEE to contain our new FV and disable use of test keys, eventually producing tos-optee_t234.img
  6. Replace files in Linux_for_Tegra/bootloader path with the ones generated in step 3 & 4
  7. Place the board into recovery mode and connect to host computer
  8. Use the provided odmfuse.sh script to burn the fuses in one step ./odmfuse.sh -X <XML_FILE_PATH> -i 0x23 jetson-orin-nano-devkit-nvme
  9. Power cycle the board just to be sure, and enter recovery mode again
  10. Run ./flash.sh -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit-nvme internal to push the updated tos-optee and eks images.
  11. Insert pre-flashed NVMe disk and boot

Result: Board does boot to uefi, and boots our OS successfully.

@JerryChang has there been any movement on this, or are we out of ideas?