I experience a problem after flashing the fused Jetson Orin Nano second time after fusing the PKC and SBK keys to Jetson. I use the Jetson Orin Nano DevKit.
I flashed the Jetson many times before with both SDK Manager and flash.sh.
I decided to try the key fusing and everything went smoothly for the first time.
I had a technical need to flash the Jetson from scratch one more time, so I just used the same PKC and SBK with fresh image.
I flashed the Jetpack Linux 6.1 successfully, BUT nothing showed up on the boot stage on my DP display.
Since then, I tried different Jetpacks, with/without disk encytion, SD/NVME storage but still the same issue.
The flash works fine without errors, so I am sure that the SBK and PKC keys are correct.
Additionally, the fan is spinning and the display reacts, when I insert the DP into Jetson, but there is No signal message on the screen.
I used the same hardware (display, cable) previously, and it worked smoothly for a long time with the Jetson.
Also, there are no logs from Serial console, probably because I fused the jtag disabling and production mode bits, so there is no way to debug the issue.
Appreciate any help.
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it appears that you have successfully flashed the Jetson Orin Nano DevKit with the fused PKC and SBK keys for the first time. However, when you attempted to flash the device again from scratch using the same keys, you encountered an issue.
To troubleshoot this problem, let’s break down the key points:
Successful first-time flashing: You were able to flash the Jetson Orin Nano DevKit with the fused PKC and SBK keys, and everything worked smoothly. This suggests that the keys are correct, and the flashing process was successful.
Issue with subsequent flashing: When you attempted to flash the device again from scratch using the same keys, you encountered an issue. This could indicate a problem with the flashing process or the device itself.
No errors during flashing: You mentioned that the flashing process completes without errors, which suggests that the issue is not related to the flashing process itself.
No logs from Serial console: Since you fused the JTAG disabling and production mode bits, you are unable to access the Serial console logs, which makes it difficult to debug the issue.
To compare the two scenarios, let’s examine the differences:
First-time flashing: You used the same PKC and SBK keys, and the flashing process was successful.
Subsequent flashing: You used the same PKC and SBK keys, but the flashing process resulted in an issue.
Given that the keys are the same, and the flashing process completes without errors, it’s possible that the issue is related to the device itself or the way it’s being flashed.
Here are some potential causes:
Device-specific issue: It’s possible that the device has become corrupted or has a hardware issue that’s preventing it from functioning correctly.
Flashing process issue: Although the flashing process completes without errors, it’s possible that there’s an issue with the way the device is being flashed. This could be related to the specific command or options used during the flashing process.
Key-related issue: Although the keys are the same, it’s possible that there’s an issue with the way they’re being used or interpreted during the flashing process.
To resolve this issue, you may want to try the following:
Verify the flashing process: Double-check the flashing process and ensure that you’re using the correct command and options.
Try a different flashing method: If you’re using the flash.sh command, try using the SDK Manager or a different flashing tool to see if the issue persists.
Check the device: Verify that the device is functioning correctly and that there are no hardware issues.
Revert to a previous state: If possible, try reverting the device to a previous state before the issue occurred to see if that resolves the problem.
If none of these suggestions help, you may want to consider seeking further assistance from NVIDIA or a qualified developer who is familiar with the Jetson Orin Nano DevKit and the flashing process.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
let’s have issue narrow down, is it related to disk encryption enabled?
besides.. please also check release tag for L4T version, $ cat /etc/nv_tegra_release
Thanks for advice but unfortunatelly 36.4.4 Tegra leads to the same result with successful and No signal on display port screen. I attached the latest full flash logs: logs.txt (549.8 KB)
Hi @JerryChang
I accidentally misinformation you regarding the Serail console is not working.
It works fine.
Here are the last logs from Serial console during the system booting:
I> RSA PSS signature check: OK
I> KDF derivation: OK
I> KDF derivation: OK
I> GCM decryption: OK
I> eks: Authentication Finalize Done
I> Binary eks loaded successfully at 0xbe020000
I> EKB detected (length: 0x410) @ VA:0xbe020000
I> Task: Add cpubl params integrity check
I> Added cpubl params digest.
I> Task: Prepare TOS params
I> Setting EKB blob info to OPTEE dtb finished.
I> Setting OPTEE arg3: 0xbe040020
I> NVRNG: Health check success
I> NVRNG: Health check success
I> Task: OEM SC7 context save
I> OEM sc7 context saved
I> Task: Disable MSS perf stats
I> Task: Program display sticky bits
I> Task: Storage device deinit
I> Task: SMMU init
I> Task: Program GICv3 registers
I> Task: Audit firewall settings
I> Task: Bootchain failure check
I> Current Boot-Chain Slot: 0
I> BR-BCT Boot-Chain is 0, and status is 1. Set UPDATE_BRBCT bit to 0
I> Task: Burn RESERVED_ODM0 fuse
I> Task: Lock fusing
I> Task: Clear dec source key
I> MB2 finished
\FF\E4NOTICE: BL31: v2.8(release):e12e3fa93
NOTICE: BL31: Built : 08:24:36, Jun 16 2025
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 4.2 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Mon Jun 16 15:35:45 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: fTPM ID is not enabled.
I/TC: ftpm-helper PTA: fTPM DT or EKB is not available. fTPM provisioning is not supported.
I/TC: Primary CPU switching to normal world boot
\FF\E1
Jetson UEFI firmware (version 36.4.4-gcid-41062509 built on 2025-06-16T15:25:51+00:00)
\FF\E4I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TC:?? 00 jetson_user_key_pta_uefi_vars_auth:984 UEFI variable auth key not set !
E/TC:?? 00 stmm_handle_variable_authentication:894 Failed to get signed CMAC ffff0008
ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee_ftpm.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/VarIntCheck.c(932): ((BOOLEAN)(0==1))
I think it is related to some other topics on this forum. But what would you suggest in this particular case? UPD.
Ok, it looks like here is the fix to my problem:
Rebuilding the encrypted EKS with all 0s keys helped me to initialize the OS finally.
Still, there is a question why am I required to do this step, even if I do not want to encrypt the rootfs right now.
this shall back-to what keys you’ve fused onto this module.
generally, it should due to you’ve burn user keys (OEM_K1/K2), it’s necessary to re-generate EKS image.
Hello @JerryChang. Thanks for all information provided. The last question in this topic, just to make things crystal clear:
What fused keys from Fuse Info refers to OEM_K1/K2 ?
fuse read cannot query what the OEM_K1/K2 has burned into the fuses. in fact, that’s only TZ-SE can access to the OEM keys.
please refer to Jetson Orin Fuse Specification for the fuse name, i.e. FUSE_BOOT_SECURITY_INFO_0.
since you’ve BootSecurityInfo: 00000209, which has bit-0, bit-3, bit-9 enabled, it shows it’s a target fused with PKC+SBK+OEM keys.
hence, it’s expected you should re-generate EKS image to include OEM keys for your real use-case.