企业官网建设流程全解析

很多刚入手Jetson Orin系列开发板的Windows用户，第一反应就是得找一台Ubuntu主机才能刷机、装环境。网上教程也大多默认你有一个Linux环境，搞得大家以为Windows阵营被抛弃了。其实完全不是这么回事，NVIDIA官方提供了SDK Manager的Windows版本，配合WSL2这套组合拳，Windows机器上就能完成Orin系列开发环境的全流程搭建。这篇就把我自己踩过的坑、试出来的可行路径完整分享出来。

1. 整体思路：为什么选WSL2+SDK Manager这条路

先说结论，在Windows上搞Jetson环境，目前最顺的方案就是三件事：装好WSL2作为底层Linux环境、装好Windows版SDK Manager做刷机工具、再在WSL2里补齐开发依赖。各位先别急着问为什么这么绕，我来把逻辑捋清楚。

Jetson设备出厂后的正常使用流程，基本就是刷Linux系统、装CUDA和cuDNN、配置TensorRT、再装自己项目的依赖。这里最大的门槛是，SDK Manager虽然出了Windows版，但它在刷机时要调用一堆Linux原生的fastboot、flash工具，老版本的SDK Manager在Windows上经常各种诡异报错。而WSL2正好提供了一个原生Linux内核的子系统，SDK Manager在Windows里跑的时候，可以很顺畅地通过WSL2调用底层Linux工具链。

选择WSL2还有一层实际考量：Jetson开发避免不了交叉编译，有时候要在本地编译ARM架构的包，原生Windows根本搞不定，虚拟机又太吃资源。WSL2在这时候就能拿来当轻量级编译机，也能直接对接SDK Manager的底层Linux调用。相比双系统动不动就要重启切换，WSL2直接嵌入Windows，共享文件系统，开发体验会舒服很多。

工作流程上，我建议这么拆分：

• Windows端：负责运行SDK Manager图形界面，管理Jetson板卡的刷机流程
• WSL2内：安装Python、CUDA Toolkit for L4T平台（即Jetson上的Ubuntu系统）、PyTorch等全套依赖，兼顾日常开发和交叉编译需求
• Jetson设备：刷好JetPack系统后，配合WSL2进行代码部署和远程调试

这条路走通之后，你等于用一台Windows主力机，完成的是一套跨平台的嵌入式开发工作流，而不是那种妥协方案。

2. WSL2环境的搭建与踩坑记录

2.1 Windows上的WSL2安装三步走

WSL2的核心是让Windows跑一个真正的Linux内核。我用的是Win11系统，Win10的同学也能用同样步骤，但需要先把系统更新到2004以上版本，并开启“适用于Linux的Windows子系统”功能。

第一步，以管理员身份打开PowerShell或CMD，先启用这几个Windows功能：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

完成后重启电脑。这一步是为了让WSL2能用到Windows的虚拟化平台（Hyper-V底层组件），不重启的话后续功能启用不完整。

第二步，把WSL2设置为默认版本：

wsl --set-default-version 2

这一步很重要，WSL1和WSL2的内核机制不一样，WSL2才是真正的轻量虚拟机，如果这里没设置成2，后面SDK Manager调Linux工具时会莫名其妙报错。

第三步，安装一个具体的发行版。建议直接去微软商店搜Ubuntu，装20.04或22.04都行。装完启动一次，设置初始用户名和密码。

装完后，在PowerShell里输入wsl -l -v，可以看到类似这样的输出：

NAME STATE VERSION * Ubuntu Running 2

确认VERSION列是2，就说明WSL2环境已经准备好了。

2.2 WSL2内的初始化配置

Ubuntu装好只是空壳，还需要做点基础配置。我强烈建议先把软件源换成国内镜像源，否则后面装依赖时会让你体会到什么叫度日如年。

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g' /etc/apt/sources.list sudo apt update -y && sudo apt upgrade -y

然后是安装一些基础依赖，Jetson开发常用的工具在这一步就位：

sudo apt install -y build-essential git python3-pip ssh cmake vim curl wget net-tools sudo apt install -y libssl-dev libffi-dev python3-dev

这里有个点要提醒一下，WSL2和Windows的防火墙/网络是完全独立的一套逻辑，所以后续调试Jetson时，我会建议直接用ssh连板子，而不是依赖Windows的共享网络。

2.3 Windows与WSL2的驱动协同

很多人一跑SDK Manager就卡在驱动上，连不上Jetson板子，其实是Windows的USB驱动没弄好。Jetson设备进入刷机模式（Forced Recovery Mode）时，Windows会识别到一个名为“NVIDIA APX”的设备。这个设备默认是没有驱动的，在设备管理器里会显示为未知设备，必须给这个驱动装上之后SDK Manager才能识别到板子。

如果你在设备管理器里看到很多带感叹号的NVIDIA相关设备，建议装两个东西：第一个是NVIDIA USB Driver for Jetson，在NVIDIA官网开发者区就能下载；第二个是WinUSB驱动，这个集成在SDK Manager的安装包里，一般会自动装上。实在找不到的话，可以安装一个叫Zadig的小工具，用它能强制给APX设备装上WinUSB驱动。我当时就是靠这招解决了设备识别问题，Zadig操作很简单，在列表里选中APX设备，然后点击“Install Driver”就行。

3. NVIDIA SDK Manager的安装与关键配置

3.1 下载安装与首次启动

SDK Manager下载地址在NVIDIA官网的开发者专区，Windows版本选好后直接下载安装包。安装过程很傻瓜，一路下一步就行。装完后第一次启动，会让你登录NVIDIA开发者账号，这个得注册一下，没有账号是进不去的。

然后有两个模式：SDK Manager for Jetson和SDK Manager for DRIVE/CLARA。我们这里选Jetson。

紧接着会让你选目标平台，这里能看到Jetson AGX Orin、Orin NX、Orin Nano等型号。选择你手头的那款，再选JetPack版本。目前Orin系列比较稳定的是JetPack 5.x和6.x，建议装JetPack 6系列。

3.2 最重要的一步：手动指定WSL2作为命令执行环境

SDK Manager安装目录下有个关键配置，需要手动设置一下，否则它在Windows下找Linux工具链时会找错地方。

第一次进入SDK Manager之后，它界面有个“Setup”或“Preferences”入口，里面找“Language”或者“Runtime Environment”相关的选项。如果你是新版SDK Manager，它会识别你装了WSL2，但你要自己确认一下它认的是哪个发行版，默认有时会选错。

我曾经遇到过一次，SDK Manager默认调用了WSL里另一个发行版的路径，刷机的时候报一堆奇奇怪怪的错误，比如“Failed to flash Jetson device”。这种问题排查起来极费时间。所以建议界面上如果显示WSL发行版信息，务必确认是你用来做开发的那个Ubuntu。

如果没有界面入口，也可以直接修改SDK Manager的配置文件，在C:\Users\你的用户名\.nvsdkmgr\settings.json里找到相关的路径字段，设置正确的WSL发行版即可。

3.3 SDK Manager全流程示例

配置完成后，完整刷机过程大致如下：

第一步，连接硬件：Jetson板子通过Type-C线连接Windows电脑（注意一定要直接连主板上的USB口，不要经过扩展坞），然后用跳线帽短接板子上的Force Recovery排针。短接后给板子上电，板子不会正常启动，而是进入刷机模式。

第二步，在SDK Manager主界面点击“Continue”，它会开始检测设备。正常情况下，它会显示设备已连接，并列出待安装的Jetson平台软件包。

第三步，勾选你需要的组件。如果硬盘紧张，可以先只选基础的Jetson OS和CUDA工具；等系统刷好了，再通过后续的软件安装补上其他组件。

第四步，点击“Install”，输入你前面在Ubuntu里设置的用户名密码，然后就是等待。大概整个刷机过程20到30分钟内，具体取决于你的网络和机器配置。期间千万别去动USB线，也别碰板子电源键。

这里有个细节：SDK Manager安装包下载的东西非常多，动辄10GB以上，容易中途失败。建议在“Download and install”选项里，先选择仅下载，全部下载完成后再安装。这样即使中途断网，也不用从头再来。

4. WSL2中配置开发依赖与交叉编译实践

4.1 从零开始搭建Python与CUDA环境

系统刷完，SDK Manager安装了一部分CUDA到Jetson里，但WSL2这边还得自己装一份。

这里不要直接下载桌面版的CUDA Toolkit，要用NVIDIA给的Jetson专用Toolchain。建议直接用SDK Manager时候生成的包，它会在WSL里装好对应版本的CUDA、TensorRT、cuDNN等组件。如果没有装，看看SDK Manager在“Install”阶段是不是漏掉了“SDK Components”这个分类下的勾选。

装完之后，你会发现在WSL2里多了/usr/local/cuda目录，这个就是Jetson的交叉编译工具链所在。为了让它随时可用，在~/.bashrc里加一段：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

然后刷新一下配置：

source ~/.bashrc nvcc -V

如果看到CUDA版本号输出，说明交叉编译所需的CUDA环境已经就位。注意，不要试图在WSL2里跑CUDA程序，WSL2里没有NVIDIA GPU直通给CUDA用的这套机制——除非后面你配了WSL2的GPU加速，但那个属于桌面级显卡的事，和Jetson开发不是一回事。这里WSL2主要承担的角色是编译器和依赖环境。

4.2 交叉编译一个OpenCV示例

既然要交叉编译，我给你演示一个最常见的场景：在WSL2里用aarch64交叉编译工具链编译一个OpenCV项目，然后拷贝到Jetson上直接跑。

第一步，确认WSL2里有aarch64版本的编译工具链：

sudo apt install -y gcc-aarch64-linux-gnu g++-aarch64-linux-gnu aarch64-linux-gnu-g++ --version

第二步，写一个最简单的主程序，比如从相机读取帧并保存成图片。这里核心是C++的CMakeLists文件，需要设置ARM相关的编译选项：

cmake_minimum_required(VERSION 3.10) project(FrameCapture) set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++) set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) find_package(OpenCV REQUIRED) add_executable(frame_capture main.cpp) target_link_libraries(frame_capture ${OpenCV_LIBS})

这个CMakeLists里最关键的是后面三个CMAKE_FIND_ROOT_PATH_MODE设置，它表示查找库和头文件时只去aarch64的根目录找，避免误用到x86的库。不设这个，交叉编译时经常会遇到架构不匹配的报错。

然后编译：

mkdir build && cd build cmake .. make

编译出来的可执行文件，file命令看一下：

file frame_capture

如果输出里显示“ELF 64-bit LSB executable, ARM aarch64”，说明编译成功。把这个文件拷到Jetson板子，配合板子上的OpenCV运行库，就能正常跑了。

4.3 通过SSH无缝远程部署

WSL2里也能直接SSH到Jetson，因为两个都是Linux环境，密钥认证配置起来干净利落。先确保Jetson上开了SSH服务：

sudo systemctl enable ssh sudo systemctl start ssh

然后WSL2里生成密钥，拷贝到Jetson：

ssh-keygen -t rsa -b 4096 ssh-copy-id 用户名@Jetson的IP

后续在WSL2里就能免密登录Jetson：

ssh 用户名@Jetson的IP

我再补充一个实用技巧：如果你想直接从Windows端Code编辑器连Jetson，其实最好是在Windows里通过VS Code的Remote-SSH插件直连，因为WSL2的网络在NAT模式下，Windows访问WSL2里的服务偶尔会有端口转发的问题，而Windows直连局域网内的Jetson反而最顺。

5. 常见报错与排查技巧

5.1 刷机时报“Failed to flash Jetson device”

这是SDK Manager使用中最常见、也最让人崩溃的报错。我的排查优先级是：

• 检查USB连接模式：确认Jetson确实进入了刷机模式。怎么看？正常运行Jetson，接上电源，用lsusb（WSL2里）或Windows设备管理器。如果有NVIDIA APX设备，说明进入了刷机模式。这点特别坑，我一开始没短接Force Recovery就点了Continue，SDK Manager等半天也没反应。
• 换一条USB线：不是所有USB Type-C线都支持数据传输。有些线只能充电，数据根本不通。卡在刷机阶段，优先怀疑线材。
• 检查SDK Manager的WSL2配置：如果你改了WSL发行版或重装过，SDK Manager里的WSL路径可能已经失效。重开一次设置页，让它重新识别。

5.2 WSL2无法访问Jetson

这个其实不是连接问题，是网络隔离问题。WSL2是NAT网络模式，它的IP和Windows物理机的IP不一样。Jetson和Windows处于同一个局域网，但WSL2不一定能直接访问这个局域网。我用过的一个比较简单的方法：

在WSL2里查看当前IP和默认网关：

ip addr

然后用端口转发的方式让WSL2去访问Jetson。不过更稳的做法是，在WSL2里用netsh工具做端口转发（需要管理员权限），或者干脆在WSL2里直接用Windows的IP访问Jetson，Windows作为宿主机是能访问外部局域网的。

ping Windows主机在局域网里的IP

如果这个能通，说明WSL2通过宿主机来访问Jetson，那SSH时直接用Windows机器的IP去连Jetson就行。

5.3 刷机到一半卡住

JetPack刷到一半卡住的情况，极大可能就是SDK Manager在下载依赖或安装系统镜像时超时。这时候建议杀进程，然后重新打开SDK Manager，它会多一个“Continue from previous installation”的选项，直接续跑。

如果连续跑都失败，那我建议重刷，但这次先选择“Download and install”里的“Only download”模式，把镜像都拉下来，确认下载完整后再选择“Already downloaded data”执行安装。

还有一次，我重试好多次都卡死，最后发现是Windows的Windows Defender实时扫描把SDK Manager的临时文件干掉了。遇到这种程度的问题，就到“病毒和威胁防护”里把SDK Manager的安装目录和WSL2的文件系统暂时排除掉。

6. 实操配置速查表

为了方便你照抄，我把关键配置汇总成一个表：

7. 踩了这么多坑之后的几点体会

后来我也试过用纯虚拟机（比如VMware跑Ubuntu）来做整套流程，发现两个问题：一是GUI版的SDK Manager在虚拟机里偶尔USB重定向有问题，对板子的识别不够稳定；二是虚拟机太占资源，开着Ubuntu虚拟机干一天的活，16GB内存都不太够用。相比下来，WSL2这套组合拳是目前Windows下开发Jetson性价比最高的方案，它不占用一整台虚拟机，日常用起来又完全是Linux体验。

我个人的建议是，如果你手头只有Windows电脑，不用犹豫，直接按这套流程走。如果你有条件，也可以先用一台专门的Ubuntu机器刷好系统，后续开发再回到Windows上用WSL2。两种方式我都实测过，后面这种方式最省心，但前者完全可行，还不至于让你为了刷个板子专门去折腾一台Linux主机。