OpenEmbedded for Tegra
dunfell-l4t-r32.5.0-bootloop-secureboot #1028
Answered
by
madisongh
llewellyn-evo
asked this question in
Q&A
-
|
Hi, I am currently facing issues with secure boot and my board is stuck in a boot loop. The following is the error I create and fused the device by using scripts that you can find here https://github.com/llewellyn-evo/jetson-nx-secure-boot I have to mention if I use the ubuntu image from Nvidia the board does boot successfully. Regards |
Beta Was this translation helpful? Give feedback.
Answered by
madisongh
Sep 3, 2022
Replies: 4 comments 11 replies
-
|
Did the EKB you generated with your fused keys (via the |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
Do I have to generate the ekb? I haven't done this. Can you let me know how to do this? |
Beta Was this translation helpful? Give feedback.
-
|
It's described in the L4T documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I have generated the eks.img and added it to boot files. but I still have the same issue. I am attaching the entire log for the bootloop. I have to mention i am running A/B Partition and integrated swupdate. Thanks ! |
Beta Was this translation helpful? Give feedback.
-
|
This looks like the problem: The signature check looks OK, but the kernel image isn't getting parsed. IIRC, with the NVIDIA key management in place, cboot is expecting the kernel to be encrypted using the same "user key" as was used to create the EKB. See here for more info. The file with that key is added via |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry guys, I didn't have time to reply here |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hello, we have a similar problem on our xavier-nx-emmc board, signature is verified correctly but then the kernel is not parsed (invalid header magic). We enabled secure boot and production mode but we did not burn a kek2 key on the fuses, so if I understood correctly it should not be necessary to generate a eks.img using the python script. What am I missing? Maybe since kek2 is not burnt also the "user_key" must be all zeros? (currently it is not) |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I just fired up my fused Xavier NX eMMC board for comparison, using dunfell latest (L4T R32.7.2) as the base, and everything came up fine. Signature check on the kernel was OK, I get the So maybe there's something going wrong during your build or flashing that's causing the kernel |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
OK, if you are encrypting the kernel, you should not be seeing the 'keyslot 14 is zero' message in cboot, and instead you should see a message about it attempting to decrypt the kernel image before moving on to the boot.img magic check. And when flashing, you should be using that |
Beta Was this translation helpful? Give feedback.
-
|
So I finally got my jetson nx to boot. This issue seems fixed for me. Can be closed :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @llewellyn-evo for the updates. |
Beta Was this translation helpful? Give feedback.
-
|
I've updated the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks A lot :) |
Beta Was this translation helpful? Give feedback.
Answer selected by
ichergui
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just fired up my fused Xavier NX eMMC board for comparison, using dunfell latest (L4T R32.7.2) as the base, and everything came up fine. Signature check on the kernel was OK, I get the
keyslot 14 is zerowarning because I don't encrypt the kernel, either, and theboot.imgheader magic was OK, too.So maybe there's something going wrong during your build or flashing that's causing the kernel
boot.img(which should begin withANDROID!- that's the "magic" cboot is looking for) to either not get flashed or get corrupted somehow?