企业官网建设流程全解析

1. 项目缘起：为什么要在量产前动 eFuse

第一次接触 Jetson 的 eFuse 是在一条小批量试产线上。当时整机已经组装完毕，系统也烧录好了，结果客户那边做安全审计，要求设备必须支持安全启动，防止固件被替换。我们当时的第一反应是“重新烧一版带签名的固件不就行了”，但真正动手才发现，Jetson 的安全启动根信任是焊在芯片里的，不是软件层面能补的。这个“焊在芯片里”的东西，就是 eFuse。

eFuse 全称是 electronic fuse，中文一般叫电子熔丝。它本质上是芯片内部一组一次性可编程的存储单元，每一位出厂时都是未熔断状态，你通过特定的烧录流程把它“烧断”，这一位就永久变成另一个值，而且不可逆。你可以把它理解成芯片出厂时自带的一张白纸，你可以在上面写字，但写上去就擦不掉。Jetson 系列（Nano、TX2、Xavier、Orin 家族）都用 eFuse 来存放安全启动相关的密钥哈希、安全模式标志、FSKP（Fuse Secure Key Programming）相关配置等。

这件事为什么值得单独写一篇实战总结？因为 eFuse 烧录和普通固件烧录完全是两码事。普通固件烧错了，重新刷一遍就行；eFuse 烧错了，这颗芯片基本就废了，或者至少安全启动功能再也用不了。我在实际项目里见过有人把 SecurityMode 位烧反了，导致整批板子无法进入安全启动，最后只能换芯片。所以这篇内容适合两类人看：一类是正在做 Jetson 产品安全启动方案、准备上量产的嵌入式工程师；另一类是已经拿到 Jetson 板子、想搞清楚 eFuse 到底怎么烧、有哪些坑的开发者。下面我会从整体设计思路讲到具体操作，再到踩过的坑，尽量把每一步背后的原因说清楚。

2. 整体方案设计：先想清楚再动手

2.1 安全启动的信任链到底长什么样

在动手烧 eFuse 之前，必须先把 Jetson 的安全启动信任链搞清楚。否则你只是机械地执行命令，出了问题根本不知道是哪一环断了。

Jetson 的安全启动信任链大致是这样的：芯片上电后，BootROM 首先运行，它是一段固化在芯片里的代码，不可修改。BootROM 会去读取 eFuse 里的公钥哈希（Public Key Hash，简称 PKC hash），然后用这个哈希去验证 Bootloader 的公钥是否合法。如果公钥验证通过，再用公钥验证 Bootloader 的签名。Bootloader 验证通过后，后续的加载流程才继续。也就是说，eFuse 里存的不是公钥本身，而是公钥的哈希。这样做的好处是节省 eFuse 空间，同时哈希不可逆，即使 eFuse 内容被读出也无法反推公钥。

这里有一个关键点：PKC hash 是烧录到 eFuse 里的，而对应的私钥必须由你自己保管好。私钥丢了，后续就没法签名新的固件；私钥泄露了，安全启动就形同虚设。我在项目里一般建议客户把私钥放在离线机器上，签名操作也在离线环境完成，不要图省事放在 CI 流水线里。

2.2 为什么选 FSKP 而不是直接烧 PKC

Jetson 的 eFuse 烧录方式有两种常见路径：一种是直接烧 PKC hash 和 SecurityMode 位；另一种是走 FSKP 流程。FSKP 是 Fuse Secure Key Programming 的缩写，它本质上是一种更安全的密钥烧录机制。

直接烧 PKC 的方式比较直接，但问题在于烧录过程中密钥材料会以某种形式出现在烧录工具和日志里，如果产线环境不够干净，存在泄露风险。FSKP 的设计思路是：先用一个临时的对称密钥对要烧录的密钥材料进行加密，然后通过特定的烧录流程把加密后的材料写进 eFuse，芯片内部再解密并熔断。这样即使烧录过程中被截获，攻击者也拿不到真正的密钥材料。

从实操角度看，FSKP 流程比直接烧录多几步，但安全性提升明显。对于量产项目，我一般推荐走 FSKP。当然，如果你的项目对安全要求没那么高，或者只是做功能验证，直接烧 PKC 也能跑通。但既然都动 eFuse 了，多花点时间走 FSKP 是值得的。

2.3 烧录前的准备工作清单

在真正执行烧录之前，有几件事必须提前准备好，缺一不可：

• 确认芯片型号和对应的 eFuse 布局：Jetson Nano、TX2、Xavier NX、Orin Nano、Orin NX、AGX Orin 的 eFuse 地址和位数不完全一样。比如 Orin 系列的 eFuse 空间比 Nano 大很多，支持的密钥位数也不同。一定要查对应型号的 Technical Reference Manual。
• 生成密钥对：通常使用 RSA 或 ECDSA 密钥。Jetson 安全启动支持 RSA-2048、RSA-3072、ECDSA P-256 等。密钥长度影响安全强度和签名速度，量产项目建议至少 RSA-3072。
• 准备烧录环境：需要一台 Linux 主机（Ubuntu 18.04 或 20.04 比较稳），安装 NVIDIA 的 JetPack 和相应的烧录工具。注意，eFuse 烧录必须在 Linux 下进行，Windows 下没有官方支持。
• 确认板子处于可烧录状态：Jetson 需要进入 Recovery 模式，通常是通过按住 Recovery 键再上电，或者短接特定引脚。不同载板的设计不一样，提前查好。
• 备份原始 eFuse 内容：在烧录之前，先读取并保存当前 eFuse 的值。虽然未烧录的 eFuse 大多是全 0 或全 F，但备份一下总没错，万一后面要对比排查问题。

注意：eFuse 烧录是不可逆的。在按下回车之前，务必确认密钥、哈希、SecurityMode 位都正确。我见过有人把测试密钥烧进了量产板，结果整批板子只能当开发板用。

3. 核心细节解析：eFuse 里到底烧了什么

3.1 PKC Hash 的计算与写入

PKC hash 是 eFuse 里最核心的内容之一。它的计算过程是这样的：你先用 OpenSSL 生成一对 RSA 密钥，然后提取公钥，对公钥做 SHA-256 哈希，得到的 256 位哈希值就是要烧进 eFuse 的内容。

具体命令大概是这样：

# 生成 RSA 3072 私钥 openssl genrsa -out rsa_priv.pem 3072 # 提取公钥 openssl rsa -in rsa_priv.pem -pubout -out rsa_pub.pem # 对公钥做 SHA-256 哈希 openssl dgst -sha256 -binary rsa_pub.pem | openssl enc -base64

得到的 base64 字符串就是 PKC hash。烧录工具会把这个哈希转换成 eFuse 需要的格式，然后写入对应的地址。

这里有一个容易出错的地方：不同 JetPack 版本对公钥格式的要求可能不同。有的版本要求公钥是 DER 格式，有的要求 PEM 格式。我在 JetPack 4.x 上遇到过因为公钥格式不对导致哈希计算错误的情况，后来统一用 DER 格式才稳定。建议在计算哈希之前，先确认你用的 JetPack 版本对应的文档要求。

3.2 SecurityMode 位的含义与设置

SecurityMode 位是 eFuse 里的一个标志位，它决定芯片是否进入安全启动模式。这个位一旦烧录，芯片就会强制验证 Bootloader 的签名，验证不通过就不启动。

SecurityMode 位通常不是单独存在的，它和另外几个位配合使用，比如 ODM Production Mode 位、Debug Mode 位等。ODM Production Mode 位烧录后，芯片会进入量产模式，一些调试接口会被关闭。Debug Mode 位则控制是否允许 JTAG 调试。

在实际操作中，我一般建议分两步走：先烧 PKC hash，验证安全启动能正常工作；确认无误后，再烧 SecurityMode 位和 ODM Production Mode 位。这样万一 PKC hash 有问题，还有机会补救。如果一次性全烧了，出问题就只能换芯片。

3.3 FSKP 流程中的密钥加密

FSKP 流程的核心是用一个临时密钥（通常叫 FSKP key）对要烧录的密钥材料进行加密。这个临时密钥本身也需要通过安全渠道传递，不能明文放在产线脚本里。

具体操作上，NVIDIA 提供了一套工具链来支持 FSKP。大致流程是：先在离线环境生成 FSKP 加密后的密钥包，然后把密钥包传到产线机器上，产线机器通过烧录工具把密钥包写入 eFuse。芯片内部会用预先烧录的 FSKP 解密密钥来解密密钥包，然后熔断相应的 eFuse 位。

这里的关键是 FSKP 解密密钥本身怎么烧进去。通常的做法是先用一个默认的 FSKP 密钥（NVIDIA 提供的或者你自己生成的）烧录一次，然后再用这个密钥来加密后续的密钥材料。这个过程有点像“先用一把钥匙锁住另一把钥匙”，逻辑上要理清楚，否则容易把自己绕进去。

3.4 烧录工具与命令解析

Jetson eFuse 烧录主要用 NVIDIA 提供的fuseburn工具，它是 JetPack 的一部分。不同版本的命令参数略有差异，但核心逻辑差不多。

一个典型的烧录命令大概长这样：

sudo ./fuseburn --chip 0x23 --key rsa_pub.pem --secmode 1 --odm 1

其中--chip指定芯片型号，--key指定公钥文件，--secmode和--odm分别指定 SecurityMode 和 ODM Production Mode 位。

实际使用时，我建议先用--dry-run或者类似的只读模式跑一遍，确认工具能正确识别芯片和 eFuse 布局。确认无误后再去掉 dry-run 参数真正烧录。

提示：烧录过程中不要断电，不要拔线。eFuse 烧录需要稳定的电源，电压波动可能导致烧录失败甚至芯片损坏。

4. 实操过程：从零到安全启动跑通

4.1 环境搭建与工具安装

我用的环境是 Ubuntu 20.04 LTS，JetPack 5.1。安装步骤大致如下：

1. 从 NVIDIA 官网下载 JetPack SDK Manager，安装到主机上。
2. 通过 SDK Manager 安装 Jetson 相关的烧录工具和驱动。
3. 确认fuseburn工具已经安装，通常在/opt/nvidia/或 JetPack 安装目录下。
4. 安装 OpenSSL 和其他依赖库。

这里有一个坑：SDK Manager 默认会下载完整的 JetPack 包，体积很大。如果只需要烧录工具，可以在 SDK Manager 里只勾选“Flash”相关的组件，不勾选 CUDA、cuDNN 等大包。这样能省不少时间和磁盘空间。

4.2 生成密钥并计算哈希

按照前面说的方法生成 RSA 密钥对，然后计算 PKC hash。我一般会把密钥和哈希值放在一个专门的目录里，命名清晰，比如：

keys/ rsa_priv.pem rsa_pub.pem pkc_hash.txt

计算完哈希后，把哈希值保存到pkc_hash.txt，后面烧录时直接引用这个文件。

4.3 进入 Recovery 模式并连接

Jetson 进入 Recovery 模式的方法因载板而异。以 Orin Nano 开发套件为例，通常是按住 Recovery 键，然后按一下 Reset 键，再松开 Recovery 键。连接主机后，用lsusb命令应该能看到 NVIDIA 的设备。

确认连接成功后，用fuseburn的查询命令读取当前 eFuse 状态：

sudo ./fuseburn --chip 0x23 --read

这个命令会输出当前 eFuse 的各个位状态，包括 PKC hash 是否已烧录、SecurityMode 位是否已设置等。第一次操作时，这些值应该都是未烧录状态。

4.4 执行烧录并验证

确认一切就绪后，执行烧录命令。烧录过程通常很快，几秒钟到几十秒不等。烧录完成后，再次用--read命令读取 eFuse 状态，确认 PKC hash 和 SecurityMode 位已经正确写入。

然后重新上电，观察启动过程。如果安全启动配置正确，芯片会正常启动；如果配置有误，可能会卡在 BootROM 阶段，串口没有任何输出。这时候不要慌，先检查 eFuse 读取的值是否和预期一致，再检查公钥格式和哈希计算是否正确。

4.5 签名固件并烧录

eFuse 烧录完成后，后续的固件必须用对应的私钥签名才能启动。签名过程通常由 JetPack 的脚本自动完成，你只需要在编译固件时指定私钥路径即可。

签名后的固件烧录和普通固件烧录流程一样，但烧录工具会额外验证签名。如果签名不匹配，烧录会失败。

5. 常见问题与排查技巧实录

5.1 烧录失败：工具报错“Chip not found”

这是最常见的问题，通常是因为板子没有正确进入 Recovery 模式。排查步骤：

• 确认 USB 线连接的是正确的接口（有些载板有多个 USB 口，只有一个是 Recovery 口）。
• 确认 Recovery 键的操作顺序正确。
• 用lsusb确认主机能识别到 NVIDIA 设备。
• 如果还是不行，尝试换一根 USB 线或换一个主机 USB 口。

5.2 烧录后无法启动：串口无输出

如果烧录后串口没有任何输出，可能是 SecurityMode 位烧录了但 PKC hash 不正确，导致 BootROM 验证失败。这时候需要：

• 用fuseburn --read读取 eFuse，确认 PKC hash 的值和预期一致。
• 检查公钥格式是否正确（PEM vs DER）。
• 检查哈希计算时是否用了正确的哈希算法（SHA-256）。

如果确认 PKC hash 烧错了，这颗芯片基本就废了。所以再次强调：烧录前一定要反复确认。

5.3 签名固件烧录失败：签名验证不通过

这通常是因为签名用的私钥和 eFuse 里的 PKC hash 不匹配。排查方法：

• 确认签名用的私钥和生成 PKC hash 时用的公钥是同一对。
• 确认签名算法和 eFuse 配置一致（RSA vs ECDSA）。
• 检查签名脚本的参数是否正确。

5.4 常见问题速查表

5.5 独家避坑技巧

• 先烧测试板：量产前一定要用一两块测试板走完整流程，确认无误后再上量产。
• 密钥离线保管：私钥不要放在产线机器上，签名操作在离线环境完成。
• 记录烧录日志：每次烧录都保存日志，包括 eFuse 读取值、烧录命令、时间戳等，方便追溯。
• 不要跳过 dry-run：烧录工具的 dry-run 模式能帮你发现很多配置问题，不要嫌麻烦。
• 电源要稳：eFuse 烧录对电源敏感，建议用带稳压的电源适配器，不要用劣质 USB 线供电。

6. 量产环境下的 eFuse 烧录管理

6.1 产线烧录流程设计

量产环境下，eFuse 烧录不能像实验室里那样手动操作。需要设计一套可重复、可追溯的流程。我一般建议把烧录流程分成几个阶段：

• 阶段一：芯片预检。读取 eFuse 状态，确认芯片是未烧录状态，记录芯片序列号。
• 阶段二：烧录 PKC hash。用产线工具自动烧录，烧录后立即读取验证。
• 阶段三：烧录 SecurityMode 和 ODM 位。验证 PKC hash 无误后，再烧录这些位。
• 阶段四：签名固件烧录。用签名后的固件烧录系统，验证启动正常。
• 阶段五：记录归档。把烧录日志、芯片序列号、密钥版本等信息归档。

每个阶段都要有明确的通过/失败判定标准，失败品要隔离处理，不能混入良品。

6.2 密钥版本管理与轮换

量产项目通常会涉及密钥轮换。比如第一批产品用密钥 A，第二批用密钥 B。这时候 eFuse 里的 PKC hash 就不一样了，产线工具需要支持多密钥版本。

管理上，我建议给每个密钥版本分配一个唯一的版本号，烧录时记录版本号，后续固件签名时也带上版本号。这样即使将来需要排查问题，也能快速定位到对应的密钥。

6.3 烧录设备的维护与校准

产线烧录设备需要定期维护。USB 线缆会老化，电源会漂移，这些都可能影响烧录成功率。建议每周做一次烧录设备自检，用已知良好的测试板验证烧录流程。

另外，烧录工具的版本也要管理。不同版本的fuseburn可能对 eFuse 布局的理解不同，升级工具版本前一定要在测试板上验证。

7. 个人经验总结与后续扩展

我在多个 Jetson 项目上做过 eFuse 烧录，踩过的坑不少。最大的体会是：这件事急不得。每一步都要确认，每一个参数都要核对。我见过太多因为赶进度而跳过验证步骤，最后整批板子报废的案例。

另一个体会是，文档要自己写一遍。NVIDIA 的官方文档很全，但有些细节只有自己动手才会发现。比如不同载板的 Recovery 模式操作不一样，不同 JetPack 版本的工具参数有差异，这些在文档里往往一笔带过，但实际操作中很容易卡住。

后续如果要做更深入的安全方案，可以考虑结合 Secure Boot 和 Trusted Execution Environment（TEE），在 eFuse 基础上增加运行时安全保护。不过那是另一个话题了，先把 eFuse 这一关过好，后面的路才走得稳。