OpenEmbedded for Tegra
|
I'm using the meta-tegra (commit abe68a0 - the March 13 commit) building an image for an Orin Nano module on a custom board. I created PKC and SBK keys successfully. I copied the entire content of the Linux_for_Tegra directory to the computer I use for flashing and ran the odmfuse.sh script to burn the fuses. The command line I used (changing filenames from actual names) was: The contents of fuses.xml (stripping out the actual key values) is: I deliberately omitted the This seems to have worked. The module reboots into Linux and when I run But if I try to read-back the fuses using the I get an error "Reading board information failed." The output (with filenames and key values stripped) is: In case I may have misunderstood the syntax for the Anyway, I nevertheless proceded to try and flash a known-good system image, using the And... The contents of log-initrd-flash: Any idea what I did wrong? Can I recover or is this module permanently mis-fused? |
Answered by
Shamino0
Mar 24, 2026
Replies: 5 comments 8 replies
|
I also tried signing my image from Yocto. I added a line very similar to the following to my That build succeeded, but when I tried to install it: And ... The NVIDIA module reboots back to Linux and does not boot into the flashpkg image. In log.initrd-flash: |
0 replies
|
To add some useful information: Key creationI created my PKC key files this way, generating an ECDSA P-521 key, as NVIDIA documented here: https://docs.nvidia.com/jetson/archives/r36.5/DeveloperGuide/SD/Security/SecureBoot.html#generate-a-pkc-key-pair
Then generate public key hashes: And generate a public key PEM file (not sure if this is required):
I generated the SBK key by reading 32 bytes from
I then copied that number to sbk.key, formatting it as described here:
Reading existing fusesBefore starting, I read the fuses from my module successfully (this is an Orin Nano 4M module): Burning the fusesI created the fuse-burning file as I wrote in the first comment. Based on documentation found here: https://docs.nvidia.com/jetson/archives/r36.5/DeveloperGuide/SD/Security/SecureBoot.html#jetson-orin-fuse-configuration-file, and using the Orin fuse specification document (v 1.5) from NVIDIA to make sure the correct bits are set in BootSecurityInfo. I then burned the fuses (apparently successfully) this way: Afterward, I was able to log in to Linux and use the QuestionsSo, some questions, that may help resolve this issue:
Does anyone know (not just suspect) the answers to the above? |
0 replies
|
I just ran some tests using my fused (with an RSA-3K PKC) Orin Nano 4G (
So something is broken with the pre-signing setup, at least since we upgraded the branches to R36.5. I'll open an issue for that. On the invocation of the I'd also suggest, as a next step, trying the stock L4T flashing process, as documented by NVIDIA. If that also fails in the same way, then there may well be some kind of issue with using keys other than RSA-3K, and you could open a topic in the NVIDIA developer forum about it. |
6 replies
|
NVIDIA suggested a test (to write just the SPI-flash), which didn't work. I did notice, however, that that script produced an error message at the start:
I think that is referring to this (from R35.1): https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/SD/Security/SecureBoot.html, but it appears that the instructions to install the Secure Boot package no longer exist in current L4T releases. I assume it's part of the base L4T and is no longer a separate overlay. |
|
I'm going to try again with a new module, this time using an RSA-3K key. What instructions/tool did you use to burn your fuses? Did you did what I did (copy the L4T directory from the Yocto build are and use the Did you create the fuse configuration file as described in NVIDIA's R36.5 documentation? |
|
I followed the process documented in the developer guide at the time (which IIRC was 36.4.0 time frame) and used the stock L4T kit downloaded from NVIDIA to do it. (They used to ship the secure boot tooling as a separate overlay package, hence the message you see about installing that, but as you guessed, everything is now included in the base BSP package.) |
|
I just tried using So the problem you experienced seems to have been fixed at some time since then. Or the problem is tied to the SBK, which I'm not using at this time. This is with the current (as of May 1, 2026) meta-tegra head of line: |
|
I couldn't reproduce the problem I was seeing earlier, either. |
|
I installed a new module, this time using an RSA-3K hash and only writing the PKC keys. A quick summary:
Here's the ugly details for anybody who needs them: PrerequisitesI downloaded and unpacked the Create keysThis time, I only created and RSA-3K key: I generated they public key hash using the NVIDIA Read the existing fusesSince the module is new, this is as expected: I noted that this module comes with My previous module must have been older, because it did not have these values fused. Make a fuse-config fileI'm only setting the PKC key. No other keys. And I'm not setting the <genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64" value="0xebcc1285bea9e89c53001920ca1ad2e72b6410ceba0ede5588016c8592b676e2c9a916ed936783924ddebadf56f165394855ef777dd7f680452a1e2aedcc1959"/>
<fuse name="BootSecurityInfo" size="4" value="0x1E1"/>
</genericfuse>Note the Burn the fusesFirst, make a test-burn: On success, the NVIDIA module reboots. The console output prior to the reboot indicates success: If the test failed, the module won't reboot and the console will show errors. The first time I did a test-burn, I didn't have the pre-burned After a successful test, do it again without the Confirm the burned fusesAfter the module reboots back into Linux, the But NVIDIA's This command still fails. The NVIDIA module doesn't show any output at all from its console: Flashing the imageI was able to use But there was some weirdness with But the But the flashing appears to have succeeded anyway. This may be a bug in the OE4T generation of the |
0 replies
Answer selected by
Shamino0
|
I had a similar issue with the odmfuseread.sh script. Using full absolute paths instead of relative paths to the key files when running the command helped me fix it |
2 replies
|
Thank you very much. That worked. I'll go share this on the NVIDIA forum, because I don't think their support people knew this either. |
|
I shared your advice with NVIDIA. They produced a patch for You can download the patch from the discussion thread: https://forums.developer.nvidia.com/t/found-the-solution-to-odmfuseread-sh-failure/379048/6?u=david_charlap I presume that this patch will be integrated into future versions of L4T, but won't be back-ported to v36.5. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I installed a new module, this time using an RSA-3K hash and only writing the PKC keys. A quick summary:
odmfuseread.shscript still can't read anythingdoflash.shworks, but has some weird behavior. After writing all the SPI-flash partitions, the NVIDIA module reboots into Linux, butdoflash.shis trying to do something else, which fails because the module is no longer in recovery mode.initrd-flashworks fineHere's the ugly details for anybody who needs them:
Prerequisites
I downloaded and unpacked the
Jetson_Linux_R36.5.0_aarch64.tbz2archive from NVIDIA and unpacked that, in order to have an unaltered copy (in case Yocto changed anything).Create keys
This time, I only created …