企业官网建设流程全解析

第一次拿到Jetson Orin Nano开发套件时，我几乎是本能地打开Windows电脑准备安装双系统。因为所有人都告诉我NVIDIA SDK Manager只能在Linux上运行，而Windows上那个老版本早就被官方文档冷落了。折腾一周之后，我却发现真正可行的路径，其实就藏在每个Windows用户已经装好的WSL2里。这篇文章是我把NVIDIA SDK Manager完整跑通在WSL2上、并成功刷写Jetson Orin开发环境的全过程记录，包括那些文档里根本不会写的依赖坑、USB直通细节和网络限制。如果你也是Windows主力机加一块Jetson开发板的组合，这篇文章应该能帮你跳过至少一个周末的弯路。

1. 为什么我说WSL2是Windows下刷Jetson的正解

1.1 SDK Manager在Windows上的历史性尴尬

NVIDIA SDK Manager严格来说是Ubuntu下的原生工具，最早甚至没有Windows版本。后来虽然官方出过一个Windows版，但体验比较折磨——它本质上跑在一个受控的虚拟化环境里，USB设备识别靠虚拟驱动转发，网络连接经常莫名断开，而且新版SDK Manager的deb包只面向Linux分发，Windows用户只能回头找旧版本。这不是你的操作问题，而是工具本身就为Linux设计。

很多人在这一步就放弃了，转头去装双系统或者找一台闲置Linux机器。但双系统切来切去很麻烦，尤其你只是偶尔刷个板子、平时还是Windows办公，何必为一个刷机工具改变整个工作流。

1.2 WSL2提供的三重能力恰好命中需求

WSL2能做到这件事，靠的是三个能力的叠加，少一个都会卡壳。

第一是原生Linux内核。WSL2不是模拟器，它跑的是真正的Linux内核，deb包可以直接装，systemd可以启用，udev规则可以生效，这些恰恰是SDK Manager的硬性前提。第二是GPU透传。Windows侧的NVIDIA驱动在WSL2里通过GPU-PV机制让Linux侧也能看到CUDA设备，SDK Manager在配置宿主组件时不会因为检测不到GPU而报错。第三是USB设备共享。利用usbipd-win这个开源工具，Windows上的USB设备可以被"附加"到WSL2内部，Jetson设备在恢复模式下枚举出来的APX设备，WSL2可以直接访问。

这三个能力拼在一起，就形成了一个完整的闭环：Linux环境有了，GPU加速有了，USB设备通路也有了。SDK Manager在WSL2里运行的条件全部满足。

1.3 什么时候该放弃WSL2方案

当然WSL2不是万能的。如果你要同时烧录多台设备、跑JetPack镜像的Docker批量构建、或者需要开发板通过网络引导方式在刷机过程中保持网络通信，这些场景建议老老实实用原生Linux或者专门的CI服务器。WSL2的NAT网络模式对某些网络引导流程不友好，硬要用会浪费不少时间。

但如果你只是个人开发、学习，手里一块Orin板子，想赶紧烧个系统跑起来，WSL2完全够用。这也是我推荐它的原因：用最小的改动解决最实际的问题。

2. 预装环境：把"地基"打牢的四件事

2.1 用命令而不是向导安装WSL2和Ubuntu 22.04

很多人习惯用Microsoft Store装Ubuntu，但那样版本不好控制。推荐直接在管理员权限的PowerShell里执行：

wsl --install -d Ubuntu-22.04

注意我特意指定了Ubuntu 22.04。为什么不用最新版？因为SDK Manager的官方支持矩阵偏向Ubuntu 20.04和22.04，24.04虽然也能跑，但很容易遇到Qt库版本不一致之类的隐性问题。没有必要拿稳定流程去试新版本。

装完系统会提示重启，重启后进入Ubuntu终端，先做一次彻底更新：

sudo apt update sudo apt upgrade -y

2.2 开启systemd并验证GPU透传

SDK Manager运行时会调用systemctl管理服务，所以WSL2里的systemd必须开启。修改/etc/wsl.conf：

[boot] systemd=true

然后在Windows PowerShell里执行wsl --shutdown，再重新进入WSL2，让配置生效。接着验证GPU透传：

nvidia-smi

如果能看到类似下面这样的输出，说明GPU透传正常：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 545.23.06 Driver Version: 545.23.06 CUDA Version: 12.3 | +-----------------------------------------------------------------------------+

这一步不能跳过。因为后面SDK Manager启动时如果检测不到CUDA环境，界面可能长时间卡住，让人误以为程序坏了，其实是环境没准备好。

2.3 给WSL2预留足够的磁盘空间

JetPack 6.x的完整镜像压缩包就已经4到6GB，解压后占用轻松超过15GB，再加上SDK Manager的下载缓存、日志，整个流程下来二三十GB是常见情况。如果你的C盘空间紧张，建议先把WSL2的虚拟磁盘迁移到其他分区：

wsl --manage Ubuntu-22.04 --move D:\WSL\Ubuntu22.04

这一步在刷机前做，比事后扩容舒服得多。迁移完重新进入WSL2确认一下df -h，根分区有30GB以上可用空间再继续。

2.4 安装usbipd-win，准备"USB直通"工具链

从GitHub Releases下载usbipd-win的msi安装包，安装完成后，WSL2内置了配套的客户端，不需要在Linux侧额外装东西。在PowerShell里执行：

usbipd list

如果命令能正常列出USB设备列表，说明工具链就绪。这一步提前做好，后面Jetson进入恢复模式之后就可以直接开始附加设备，不用手忙脚乱临时补装。

3. 在WSL2里安装SDK Manager：依赖坑与无头模式

3.1 下载deb包并处理依赖

SDK Manager的deb包需要在NVIDIA开发者官网下载，建议注册一个账号，后面刷机登录也需要用。下载得到类似sdkmanager_2.3.0-11831_amd64.deb的文件，在WSL2里执行：

sudo dpkg -i sdkmanager_2.3.0-11831_amd64.deb sudo apt -f install -y

dpkg报依赖错误是正常的，第二条命令会自动修复。如果apt自动修复失败，大概率是Qt库的问题。在Ubuntu 22.04上我最常用的做法是提前把这几个包装上：

sudo apt install -y libqt5core5a libqt5gui5 libqt5widgets5 libqt5dbus5 libqt5network5 libusb-1.0-0 libgtk-3-0

装完再重新dpkg -i，基本一次过。

3.2 两个容易忽略的运行前置条件

第一个是GUI窗口。WSL2自带WSLg，可以显示Linux图形程序，但某些精简版Windows或者较老的Win10不带WSLg，SDK Manager图形界面打不开时，很多人的第一反应是重装程序，其实先确认WSLg是否正常更高效。第二个是systemd状态。SDK Manager在后台会调用systemctl管理服务，没有systemd会提示"System booted in WSL"之类的警告，虽说不至于立刻崩掉，但后续刷写阶段可能出现服务启动异常。

另外建议以sudo权限运行SDK Manager。因为它需要写系统分区、访问USB设备，普通用户权限跑起来会遇到各种Permission denied的报错，排查起来非常浪费时间。

3.3 无头模式：一条能自动化的路线

如果不想用图形界面，SDK Manager还提供了命令行模式。进入命令行模式的命令是：

sudo sdkmanager --cli

进入后会有一个交互式菜单，可以列出可用组件、下载镜像、烧录设备。这个模式最大的价值是自动化——把整个刷机流程固化成一套固定命令，以后每次刷机执行同一套指令就行。我的建议是，第一次刷机用图形界面，把整个流程的每个阶段看清楚，心里有个底；之后再做批量刷机或者重复部署，就用命令行模式提速。

3.4 SDK Manager首次启动可能遇到的白屏与卡死

如果图形界面打开后白屏，或者长时间停在加载界面，常见原因有两个。第一个是~/.nvsdkmgr目录权限不对，导致程序无法写入配置：

sudo chmod -R 755 ~/.nvsdkmgr sudo sdkmanager

第二个是窗口其实已经打开，但焦点没有切过去。尤其在WSLg环境下，某些窗口不会自动抢焦点，按一下Alt+Tab切换试试。这两个问题我都实际遇到过，都不是程序坏了，别急着卸载。

4. USB直通：把你的Jetson Orin"送"进WSL2

4.1 让开发板进入恢复模式

不同开发套件进入恢复模式的方式有差异，这里以最常见的两款为例。

Jetson AGX Orin Developer Kit有实体按键，操作顺序是：按住Recovery键不放，按住Reset键2秒，松开Reset，保持Recovery按2秒后松开。这时候板子不会正常启动，而是等待USB主机下发镜像。

Jetson Orin Nano Developer Kit没有实体Recovery键，需要短接底板上的Force Recovery排针，然后再给板子上电。具体引脚位置看底板丝印，通常是两个相邻的排针，用跳线帽短接即可。

进入恢复模式后，用USB-C线连接开发套件的USB-C数据口和电脑。Windows设备管理器里会出现一个NVIDIA APX设备，这就是刷机通道。

4.2 使用usbipd把设备附加到WSL2

在Windows管理员PowerShell里执行：

usbipd list

找到NVIDIA APX设备对应的busid，比如3-4，然后依次执行：

usbipd bind --busid 3-4 usbipd attach --wsl --busid 3-4

回到WSL2终端：

lsusb

如果能看到类似输出，说明直通成功：

Bus 002 Device 003: ID 0955:7323 NVIDIA Corp. APX

注意，attach成功之后，Windows设备管理器里这个设备会消失，这是正常现象。整个刷机过程中这个USB连接会一直占用，不要关闭PowerShell窗口，也不要让电脑进入睡眠。

4.3 设备识别不到的四步排查

从实测经验来看，识别不到基本逃不出四个原因。

第一步，确认设备真的在恢复模式。Windows设备管理器里出现APX设备就是铁证，没有的话检查跳线和按键操作。第二步，确认attach之后没有报错。usbipd attach如果提示设备被占用，先执行usbipd detach --busid 3-4再重新attach。第三步，确认WSL2侧有权限访问USB设备，直接sudo lsusb，能看到就说明权限没问题。第四步，如果lsusb反复看不到，手动添加一条udev规则：

echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="0955", MODE="0666"' | sudo tee /etc/udev/rules.d/60-nvidia-usb.rules sudo udevadm control --reload-rules

然后重新插拔USB线，再走一遍attach流程。

4.4 刷机时间很长，如何保证不掉线

一块Orin完整刷写时间通常在5到15分钟，取决于镜像大小和USB速度。这期间USB直通链路非常脆弱，Windows侧睡眠、WSL2重启、电源计划切换都可能打断刷写。我的做法是先把Windows电源计划里的睡眠时间设为"从不"，刷机期间不操作其他USB设备。如果中途发现usbipd attach失败，先detach再重新attach，比直接物理拔线可靠得多——直接拔线容易让Windows判定设备异常，重新插上后状态也经常不对。

5. 刷写JetPack：关键参数选择与手动模式防坑

5.1 明确你的硬件型号与JetPack版本

SDK Manager界面里的Jetson Orin Series下拉列表，要精确选择你的模组型号和开发套件型号。选错型号后面大概率卡在"找不到设备"，因为不同模组的引导镜像和分区表都不一样。

JetPack版本方面，6.x系列是Orin平台的主线版本。新项目建议选择6.0或者6.1稳定版，不要一上来就追最新预发布版本，预发布版本只对部分模组开放，下拉列表里选不到的版本别硬选。

5.2 Host Machine和Target Components的正确勾选策略

这一步是新手最容易迷惑的地方。SDK Manager会列出两个大的组件类别：

我的做法是：第一轮刷机Target全选，确保功能完整；Host只保留Driver和CUDA Toolkit，方便之后在WSL2里跑一些宿主侧的编译验证。不用怕"全选"会把WSL2塞满，下载的组件有几十GB但通过后续裁剪可以清理。

5.3 务必选择Manual Setup模式

这是整个流程里最关键的决策点。SDK Manager提供两种连接方式，Auto Setup和Manual Setup。

Auto Setup模式下，SDK Manager会尝试通过USB虚拟网卡识别并连接Jetson目标板，自动配置网络、SSH等。听起来省事，但在WSL2默认NAT网络下，这个机制经常失败，因为WSL2的网络架构跟原生Linux不一样，虚拟网卡转发的链路在刷写阶段非常容易断。

Manual Setup模式的逻辑是：SDK Manager只负责把镜像写进设备，不负责后续网络通信。烧完之后你自己决定怎么连开发板，是用HDMI接显示器，还是插网线走路由器，还是用USB-C网卡直连。这正好绕开了WSL2的网络限制，大幅提高成功率。

在Manual Setup模式下，流程是：SDK Manager先下载镜像并解包，然后进入Flash阶段，终端会打印U-Boot的烧写日志，看到"success"之类的字样就说明镜像写入完成，开发板会自动重启。

5.4 日志视角：判断当前到底在哪一步

刷机过程中如果卡住，先看日志再操作。SDK Manager的日志一般在~/.nvsdkmgr/sdkm.log，刷写阶段的详细输出在终端子窗口里。

如果长时间卡在"Reading partitions"或者"Writing partition"，不要慌，先看usbipd list确认USB状态。如果设备一直是Attached且枚举正常，多数情况是镜像写入慢，不是死机。如果日志里出现Error while flashing，把完整的错误文本复制下来，按错误关键词去查，比笼统搜"刷机失败"有用得多。

6. 刷写完成后的验证与开发环境落地

6.1 两种方式确认系统活着

刷写完成后，开发板会重启，此时USB直连链路会断开，WSL2里的APX设备消失是正常的，说明设备已经脱离了刷写模式。

最简单的验证方式是接HDMI显示器和键鼠，直接看启动画面。更接近日常开发的方式是串口连接：用USB转串口模块接开发板的Debug UART，波特率115200，能看到完整的Linux启动日志，需要账户密码登录。

还有一种隐藏技巧：Orin Developer Kit自带的USB-C口可以充当网络接口（RNDIS），刷完系统后把USB-C线插上，Windows侧通常会获取到192.168.55.100的地址，Jetson的默认IP是192.168.55.1，直接SSH连接：

ssh ubuntu@192.168.55.1

默认密码一般是ubuntu，首次登录会提示修改，按提示操作即可。注意，如果WSL2里连不上192.168.55.1，因为WSL2的NAT网络跟Windows网络不完全互通，用Windows的PowerShell或者Windows Terminal连接，不要绕到WSL2里去连。

6.2 验证JetPack环境是否完整

登录开发板，先确认系统版本和JetPack环境：

cat /etc/nv_tegra_release nvcc --version

如果能看到L4T版本号和CUDA版本号，说明核心环境已经就位。再跑一个CUDA sample做实测：

cp -r /usr/local/cuda/samples ~/ cd ~/samples/1_Utilities/deviceQuery make ./deviceQuery

如果deviceQuery能正确识别到Orin的GPU信息，说明GPU计算管线没问题，之后装PyTorch、Jetson Inference、DeepStream这些框架都是水到渠成的事。

6.3 把WSL2变成日常管理端

刷机完成并不意味着WSL2的使命结束。把WSL2当作开发板的日常管理终端，你会发现这比在Windows和Linux之间反复切换顺手得多。

在WSL2里装好sshpass、rsync，可以写Shell脚本批量部署代码到开发板：

sshpass -p '你的密码' rsync -avz --progress ./project ubuntu@192.168.55.1:/home/ubuntu/

如果后续需要定制JetPack系统镜像，比如预置自己的rootfs、应用软件包，也可以在WSL2里先用JetPack的镜像定制工具提前做好，再通过SDK Manager烧写。这样WSL2这个环境就从一个"刷机工具"变成了"持续部署工作台"，价值比单次刷机大得多。

最后分享一个我自己的习惯。每次刷完一台Orin，我都会在WSL2里跑一条简单的命令，把设备的MAC地址、JetPack版本、烧录时间、自定义分区大小记录到笔记文件里。不要嫌麻烦，之后如果遇到系统无法启动、需要重新刷机或者对比两台设备差异，这些记录能省下大量排查时间。另外多说一句，usbipd attach过的设备在Windows设备管理器里会消失，刷完机如果发现Jetson在Windows下不见了，先在PowerShell执行usbipd detach --all，再重新插拔，这比盲目重装驱动可靠得多。