NVIDIA Jetson Nano（Parker）启动失败故障排查与解决方案

dctc_青龙

说到Jetson Nano的启动问题，十个里头有九个半都是电源闹的。这玩意儿用的是Maxwell架构GPU，峰值功耗能飙到10-15W，官方套件配的那个5V/4A电源说实话有点勉强。实测下来，一旦电源输出掉到4.8V以下，SoC的电压保护直接拉闸，红色电源LED闪两下就灭了。

怎么判断是不是电源的锅？两步走。第一，拿万用表量一下DC接口的实际输出，偏差别超过±5%。第二，换个靠谱的电源，电流至少3.5A起，或者直接上支持PD协议的65W充电器配一根20AWG以上的USB-C线。有些人买的第三方电源标注的电流是够了，但纹波系数超标，一样会触发保护。预算够的话还是建议直接入官方那个5V/4A适配器，省心。

从硬件层面讲，板子上电源管理IC是MAX77620，核心电压轨的调节和监控都靠它。当输入电压掉到4.75V以下，UVLO（欠压保护）直接切断VDD_CPU_GPU供电，系统瞬间掉电。这个阈值是写死的，软件层面没法绕过。

还有个常见场景很多人没注意到：有些人用充电宝供电（标称5V/3A），启动阶段看着没问题，但GPU一加载CUDA驱动电流就往上窜，电压直接塌陷然后反复重启。用示波器抓的话，典型波形就是5V供电在GPU负载切换瞬间跌到3.8V左右，持续个50-100ms又恢复。

另外供电方式不同也有讲究。DC Jack直供和USB-C接口走PD协商握手再供电，走的电路路径不一样。部分USB-C线缆超过55cm以后压降就开始明显了，配上低内阻的PD诱骗器在高负载下稳不住。电源线长度最好控制在1.2米以内，线径不低于18AWG等效规格。

---

说完电源，再来看存储这边。Parker版本的Jetson Nano支持两种启动介质：板载eMMC（部分型号）和microSD卡槽。启动失败的案例里，大概35%是存储介质本身或者文件系统损坏导致的。

eMMC版本出问题了，先用NVIDIA SDK Manager重新烧录系统镜像。如果设备已经进了maskROM模式（表现就是上电后USB端口能识别成0945:11d1的NVIDIA设备），那就强制进恢复模式：按住REC/FORCE RECOVERY按钮别松手，保持按下状态再按一下RESET按钮，等2秒后松开REC按钮，接下来就可以从主机执行镜像烧录了。

SD卡版本的话，品质很重要。最低要求是Class 10或UHS-I以上，实测Samsung EVO Plus 64GB和SanDisk Ultra兼容性还不错。低价卡片用一阵子容易出随机读取错误。用dd命令跑个完整性测试：

```bash
dd if=/dev/zero of=/dev/sdX bs=1M count=1024 oflag=direct
```

写入速度低于20MB/s或者直接报I/O error的，说明卡有物理坏块，别犹豫了直接换。

深入到技术细节，Parker平台的启动流程对存储介质要求相当严格。eMMC版本上电后，BootROM从0x0地址读取Bootloader blob，里面包含MB1和MB2两部分。MB1负责基础时钟初始化和BCT校验，MB2则干更复杂的引导活儿。一旦eMMC的0x0扇区有坏块或者数据损坏，BootROM压根没法正确加载引导程序，系统表现就是完全没输出——串口没日志，LED也不亮。这种情况在eMMC物理老化或者经历过异常掉电后很常见，常规分区修复没用，得全片擦除再重新烧录。

SD卡启动的逻辑不太一样。Jetson Nano的SD卡槽走SDMMC控制器，MB1阶段通过特定引脚电平检测决定从哪里加载第二阶段bootloader。SD卡高速读写时要是产生位翻转，BCT校验就会失败，日志里会看到`BCT filename mismatch`或者`Failed to read BCT`。还有一个容易被忽视的点：某些SD卡在低温环境（10℃以下）读写延迟会明显增加，这是闪存本身的温度系数特性导致的。季节性故障可以试试先把卡预热再用。

---

设备通电了但屏幕一片黑，这时候串口调试是最直接的手段。Jetson Nano有专门的40-pin GPIO串口（1500000 baud, 8N1），接个FTDI USB转串口模块，连接TX/RX/GND三针，就能捕获完整的启动日志。

不同启动阶段卡住的日志特征：

- BootRom阶段：出`tegrarcm`相关字样后没动静了，说明USB传输或芯片通信有问题
- MB1阶段：日志停在`MB1 done`没后续了，可能是BCT配置和硬件对不上
- Linux引导阶段：卡在`waiting for root device`是存储识别失败；卡在`starting kernel`得查设备树兼容性

用`ls /dev/mmcblk*`确认存储设备节点有没有生成，没有的话基本就是硬件层面问题了。

串口调试得理解每个阶段的职责边界。BootRom是芯片里固化的最小引导程序，通过USB或SDMMC接口从外部读数据。这个阶段卡住最常见的原因是USB线质量——Jetson Nano的USB数据线超过0.5米信号衰减就挺明显，传大块数据容易CRC重试最后超时。实际维修中，用带屏蔽的USB 2.0线可以将BootRom阶段下载成功率从78%拉到96%以上。

MB1阶段日志一般带`[TEGRA]`前缀，看到`MC ERROR`或`FG ERROR`说明内存初始化出问题了。Jetson Nano用的是LPDDR4，电压需求1.1V，电源管理IC某个供电轨出岔子的话内存就进不了自刷新，系统会在MB1阶段hang住。还有个容易被忽略的因素是散热——SoC温度超过105℃时保护机制会主动降频，严重时内存访问超时。这个温度阈值写在MB1固件里，是硬件层面的保护，跟用户态的温度监控不是一回事。

---

固件和系统镜像的兼容性也得注意。Parker版本用的是L4T 32.x系列内核，社区维护的部分第三方镜像存在兼容问题。建议老老实实用NVIDIA官方SD卡镜像（JetPack 4.x分支），别贪方便用第三方预装系统。

烧录完成后首次启动，系统会自动跑OEM配置，大概3-5分钟，这段时间千万别断电。因为异常断电把系统搞坏了的话，这样恢复：

```bash
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
```

SD卡版本更简单，格式化后直接用Etcher或者dd命令写官方镜像就行。

固件兼容性有个重要细节：Parker芯片的bootloader对L4T版本要求严格匹配。用错了给Jetson Xavier准备的镜像，或者用了Jetson Nano 2GB版本（代号`jetson-nano-2gb`）的镜像，启动早期就会报`Platform not supported`错误然后停住。不同硬件平台的BCT配置参数完全不同，内存容量、闪存布局、CPU核心数这些都是关键信息。BCT加载错了，后续MB1/MB2流程会因为参数不匹配在内存初始化阶段失败，典型症状就是串口输出`CBoot`日志后立刻重启，什么错误提示都没有。

烧录失败的时候，网络连接状态也值得关注。用SDK Manager通过USB线刷机，建议主机和目标设备在同一个局域网里，主机端的VPN最好关掉。实测发现某些VPN的TUN驱动会干扰USB枚举，设备在Recovery模式下识别不出来，错误表现为`No NVIDIA USB device found`。这时候可以试试断开VPN重新枚举：

```bash
sudo /etc/init.d/apparmor stop && sudo ./nv-l4t-usb-device-mode.sh start
```

---

除了电源、存储、固件这几个大头，还有一些相对隐蔽的启动失败原因。

**GPIO引脚冲突**算一个。Jetson Nano的40-pin GPIO里，第29脚（Pin13，SDO）是系统烧录模式选择引脚。如果这个引脚在启动时被外设强制拉低，设备会进Force Recovery模式而不是正常启动。用户接了扩展板或者传感器模块，但模块的GPIO默认电平配置和Jetson Nano不兼容，就容易出这个问题。排查方法是断开所有外接设备，只留电源和串口线，看能不能正常启动。

**散热问题**也容易被忽视。SoC上方有散热片和风扇，但风扇转速是软件根据温度调节的。散热片和SoC之间的导热硅脂干涸了，或者散热片安装歪了接触不好，SoC温度在启动后会迅速飙升，触发DVS降频保护。极端情况下系统可能在进桌面环境之前就因为过热保护自动关机了。判断依据是：设备能完成BootRom和Linux引导，但在加载图形界面时突然掉电重启，重启前风扇转速明显变大。

**HDMI显示器兼容性**也是高频问题。某些低端HDMI显示器用的EDID信息不符合标准，导致内核枚举显示输出时超时失败。Jetson Nano的显示输出配置写在设备树里，EDID信息和预设分辨率列表对不上的话，系统会反复尝试输出直到超时。表现就是串口日志正常通过引导阶段，但显示器一直无信号。强制指定显示输出模式可以解决：

```bash
export DISPLAY=:0
xrandr
```

或者在`/boot/extlinux/extlinux.conf`里加内核参数`video=HDMI-1:1920x1080@60`。

---

Jetson Nano启动失败的原因，说来说去主要就三块：电源供电能力不行、存储介质坏了或者文件系统出岔子、固件配置和硬件对不上。按电源测量→存储验证→串口日志分析这个顺序查下来，绝大部分启动故障都能覆盖到。

如果以上都排查完了还是不行，那可能就得考虑SoC本身或者PCB硬件层面有损伤了，这种情况下建议联系NVIDIA官方支持或者授权经销商走RMA流程。

大家有没有遇到过什么奇葩的启动问题？评论区聊聊，看看有没有什么本文没覆盖到的坑。