Jetson AGX Orin BOM修改后无法正常烧写fuse

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Jetson AGX Orin Series 更换BOM后PCN210100（DRAM、eMMC），无法进行fue烧写。现在使用旧的环境和新的环境（patch）都无法对FAB=501的模组烧写fuse，请问fuse这一块是否有改动过，如何解决这个问题。附件是烧录fuse过程中串口打印。
新物料环境烧写fuse串口日志.log (51.9 KB)

3

hello 1712127445,

may I double check what’s the modification you’ve done?
is this module fused before? are you able to boot-up for checking its fuse variables?

5

非常感谢你的回复。首先烧写fuse的系统环境和软件环境没有变动（尝试过新物料的patch），只是agx orin(32GB)的新物料变成FAB=501，以前是FAB=500。该模组的fuse没有烧写过，使用nv_fuse_read.sh命令查看public_key_hash字段都是0

6

我们是使用jetpack5.1.2，通过patch的方式解决了烧写FAB=501新物料的问题。现在使用jetpack5.1.2的这套环境烧写fuse失败。

7

hello 1712127445,

is it a new module?
please refer to Jetson Orin Nano HW FAQ,
re-cap as below..

BOOT_SECURITY_INFO was burned (by manufacturing) to 0x1E0 as default value.

8

是新的模组，这个模组是PCN210100。

image
image1160×160 23.9 KB
。“BOOT_SECURITY_INFO was burned (by manufacturing) to 0x1E0 as default value.”这个啥意思了，在FAQ里面也没看懂啊

9

你好，我今天做了如下的测试，有一些疑问需要咨询。FAB=501的BootSecurityInfo字段默认是有值的（是0x1E0），而FAB=500的BootSecurityInfo字段值都为0。我们烧写fuse的程序是一起烧写PublicKeyHash和BootSecurityInfo到模组中的。
现在我将BootSecurityInfo字段从fuse_config.xml文件中去掉，使用./odmfuse.sh 可以烧写fuse成功，烧写完成后系统可以正常启动（开启了安全启动）。
但是有个问题：我烧写的PublicKeyHash值不是安全镜像打包时使用的PublicKeyHash，但是设备也正常启动进入系统了，请问这种情况正常吗？我的操作正常吗？
例如：镜像使用flash.sh打包时，使用的PublicKeyHash是0x11，在没有烧写fuse的情况下，我将安全镜像烧写到模组中。接着使用PublicKeyHash是0x22完成fuse的烧写。按照安全启动原理此时设备不能正常启动，但是现在启动正常。

image
image1030×382 22.6 KB

10

it meant a new module will have BOOT_SECURITY_INFO=0x1E0 by default.

11

感谢你的回复。我现在遇到问题是fuse只burn PublicKeyHash，不burnBootSecurityInfo成功后，接着烧写含安全启动（uefi 、dtb、kenel都含有sig签名）和不含安全的镜像都可以正常启动，没有达到安全启动的目的。
请问这是什么原因导致的，我只burn PublicKeyHash是否正确。

12

hello 1712127445,

I’m not understand your question, it’s PKC for sign, SBK for encryption.

13

FAB=501的模组在烧写fuse实现安全启动时是否只烧写PublicKeyHash字段？

14

I encountered the same problem using jetpack5.1.2, burning public_key_mash and boot_desecurity_info=0x1e9, but an unsigned image can still boot. What is the reason for this?

image
image1947×706 35.3 KB

15

hello 1712127445,

may I know the steps in detail for reference?
please see-also Topic 330423 to verify secure boot.

16

May I ask which fields must be burned in order for fuse to work, and whether it is necessary to burn the Security Mode field? Currently, we have only burned PublicKeyHash and SecureBootKey. The bit3 of SecureBootKey indicates that the secure boot encryption scheme (SBK) is enabled, but it does not work when set to 1.

17

（1）openssl genrsa -out pkc_rsa3k.pem 3072
（2）tegrasign_v3.py --pubkeyhash pubkey_rsa3k.pubkey pubkey_rsa3k.hash --key pkc_rsa3k.pem

image
image1444×246 33.7 KB

（3）fuse_config.xml

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="0x5a56bcb4b6f3927ce601a5462797b9362bca12a74adf02515fd29cf71eb297d2649666d37fe81d9dee24bd02a2a6b63755c7969e"/>
    <fuse name="BootSecurityInfo" size="4" value="0x1E9"/>
</genericfuse>

（4）sudo ./odmfuse.sh -X fuse_config.xml -i 0x23 -k pkc_rsa3k.pem jetson-agx-orin-devkit
（5）nv_fuse_read.sh

image
image1950×702 38.5 KB

（6）Images without secure signatures can still boot
image

18

hello 1712127445,

I see..
you’re referring to /boot/extlinux/extlinux.conf
it’s the kernel image from rootfilesystem.

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image

since you’ve only bootloader secureboot enabled.
you may see-also.. $ ls -la /dev/disk/by-partlabel/
there’re kernel partitions that’s need to signed.
lrwxrwxrwx 1 root root 15 May 23 01:07 A_kernel -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 May 23 01:07 B_kernel -> ../../mmcblk0p5

besides,
you may test without PKC key for image flashing.
there’s Boot Rom communication in the early stage to report the errors and abort the process.

19

image
image1254×616 46.8 KB

what?

My main problem now is that fuse has been burned, but non secure images can still be downloaded and started, which is incorrect.

image
image1684×277 43.5 KB

20

please check my comments above, you’re loading the kernel image from rootfilesystem.

21

I understand what you’re saying. The dtb/kernel in the root file system and the dtb/kernel in flash are both unsigned, and starting from either of these two methods is normal. If fuse is successfully burned, neither of these methods should be able to start.

image
image1317×549 35.2 KB

22

Has there been any modification (hardware and software) to the safe boot of the AGX ORIN (32GB) FAB=501 module? Apart from the default factory default value of 0x1E0 for the BootSecurInfo field, what other module operations differ from FAB=500. We are in a hurry to mass produce, this issue is urgent and directly affects production.
This is a module with FAB=500, and the value of BootSecurInfo is 0x201. On the FAB=501 module, where is the function of bit9?

image
image2197×684 161 KB