三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Jetson Nano启动故障排查：从Bootloader到SD卡修复全解析

发布时间：2026/8/6 2:13:47 三亩地 编程学习日记
Jetson Nano启动故障排查：从Bootloader到SD卡修复全解析

1. 从“板砖”到“复活”：一次典型的Jetson Nano 4GB启动故障排查实录

如果你也正对着一块插上电源后，风扇转几下就停，或者干脆毫无反应，只有电源指示灯在孤独闪烁的Jetson Nano 4GB开发板发愁，那么恭喜你，你并不孤单。这块由英伟达推出的边缘计算“小钢炮”，以其强大的AI算力和相对亲民的价格，成为了无数开发者、研究者和创客的心头好。然而，与它的高性能相伴的，往往是相对“娇贵”的启动过程。我手头这块4GB版本的Nano，就在一次常规断电重启后，彻底“变砖”了——电源灯亮，风扇不转，HDMI无输出，串口无信息，仿佛一块精致的黑色板砖。经过近一天的排查和尝试，最终让它成功“复活”。这个过程，远不止是按下某个神奇按钮那么简单，它涉及对嵌入式Linux启动流程的深度理解、对硬件供电的苛刻要求，以及对SD卡这个“阿喀琉斯之踵”的重新认识。本文将完整复盘这次故障排查与修复的全过程，不仅给出解决方案，更会深入剖析每一个步骤背后的“为什么”，让你下次遇到类似问题时，能知其然，更知其所以然。

2. 故障现象深度拆解：你的Nano到底“死”在哪个阶段？

Jetson Nano的启动是一个精密的链条反应，任何一个环节出错，都会导致启动失败。因此，精准定位故障点，是解决问题的第一步。我们不能笼统地说“开不了机”，而需要像法医一样，检查“尸体”的各个生命体征。

2.1 电源与指示灯：最初的信号

首先，最直观的观察点是电源和指示灯。Jetson Nano 4GB有两个主要的供电模式：通过桶形插座（DC Jack）供电，或通过GPIO引脚（如J48）的5V引脚供电。无论哪种方式，其核心要求是稳定、足额的5V/4A电流。很多廉价的手机充电器或供电不足的USB线，根本无法满足Nano在启动瞬间，特别是GPU和CPU全速运行时的峰值功耗，这会导致电压被拉低，系统直接复位或宕机。

关键排查点：

  • 电源指示灯（PWR LED）：位于板卡边缘，靠近DC插座。如果这个灯不亮，99%是供电问题。请务必使用标称输出为5V/4A（或更高电流，如5V/5A）的电源适配器，并且电源线要足够粗，以减少压降。
  • 电源模式跳线（J48）：这个跳线帽决定了供电来源。如果使用DC插座供电，跳线帽必须放置在靠外的两个引脚上（标记为“PWR IN”）。如果使用GPIO的5V引脚供电（例如从扩展板取电），则需要将跳线帽放置在靠内的两个引脚上（标记为“5V GPIO”）。跳线帽放错位置，是导致无法启动的最常见人为错误之一。

在我遇到的案例中，电源指示灯正常点亮，这说明供电通路基本是好的，问题出在供电之后的环节。

2.2 启动流程与故障对应表

Jetson Nano的启动流程可以简化为以下几个阶段，每个阶段失败都有对应的现象：

启动阶段负责硬件/固件成功现象失败现象（可能原因）
1. 上电与PMIC电源管理芯片PWR LED亮，风扇可能短促转动一下PWR LED不亮（供电问题、PMIC损坏）
2. BootROM芯片内部ROM无外在表现，内部初始化CPU核心、时钟彻底“砖化”，任何调试手段无效（罕见，通常为硬件损坏）
3. Bootloader (U-Boot)存储在SD卡或eMMC关键阶段！可通过串口控制台看到U-Boot输出信息串口无任何输出（Bootloader损坏、存储介质故障、设备树错误）
4. Linux内核加载U-Boot从存储介质加载串口出现内核解压、设备初始化日志串口卡在“Starting kernel...”或出现内核恐慌（Kernel Panic）（内核镜像损坏、驱动不匹配）
5. 文件系统挂载内核挂载根文件系统串口出现“Welcome to Ubuntu...”等系统启动信息串口卡在等待根文件系统（rootfs损坏、/boot/extlinux/extlinux.conf配置错误）
6. 用户空间启动systemd/init启动服务出现登录提示符，桌面环境启动（HDMI有显示）串口能登录但无图形界面（显示驱动、桌面服务问题）

我的故障现象是：电源灯常亮，风扇在通电瞬间轻微抖动后停止，HDMI无信号，最关键的是，连接串口调试线后，终端里一片空白，没有任何输出。这明确地将故障锁定在了第3阶段：Bootloader (U-Boot) 加载失败。没有U-Boot的打印信息，就像电脑的BIOS都没能启动，后续一切无从谈起。

3. 核心战场：SD卡与Bootloader的排查与修复

既然定位到Bootloader问题，那么矛头就直指存储Bootloader和系统的介质——对于大多数使用开发者套件（Developer Kit）的用户来说，就是那张MicroSD卡。SD卡是嵌入式系统中最脆弱的一环，频繁的读写、异常断电、质量不佳都极易导致其损坏或数据错误。

3.1 创建串口调试环境：获取第一手“黑匣子”数据

在深入处理SD卡前，必须建立串口调试。这是诊断启动问题的“听诊器”。

所需工具：

  • USB转TTL串口模块（如FT232、CH340等，注意必须是3.3V电平！Jetson Nano是3.3V系统，5V模块会烧毁板子！）
  • 杜邦线（母对母）三根

连接方式：

  1. GND：串口模块的GND引脚 -> Jetson Nano J50排针的第6针（GND）。
  2. TX：串口模块的RX引脚 -> Jetson Nano J50排针的第8针（UART1 TX）。
  3. RX：串口模块的TX引脚 -> Jetson Nano J50排针的第10针（UART1 RX）。

注意：这里的TX/RX交叉连接（模块RX接板子TX，模块TX接板子RX）是串口通信的标准接法。J50排针的针脚编号，通常以有缺口的一侧或白色三角标记为第1针，你需要仔细查看板子上的丝印。

软件设置：在电脑上使用串口终端软件（如Windows的Putty、MobaXterm，macOS/Linux的screen或minicom）。设置参数为：波特率115200，数据位8，停止位1，无奇偶校验，无流控制。连接后，给Nano上电，观察终端窗口。如果一切正常，你应该会看到U-Boot的启动日志滚滚而来。而我当时看到的，只有一片寂静的空白，这证实了Bootloader未能执行。

3.2 SD卡“体检”与“手术”：从物理到逻辑的全面排查

当串口无输出时，你需要按以下顺序对SD卡进行排查：

第一步：物理检查与替换测试这是最简单粗暴但最有效的方法。找一张已知良好的、高速的（建议Class 10或A1/A2级别）、容量适中（32GB-128GB）的SD卡，重新刷写官方镜像。NVIDIA官方提供了完整的SD卡镜像（JetPack SDK的一部分），包含预配置的Ubuntu系统。使用BalenaEtcher或Raspberry Pi Imager这类工具进行刷写，确保过程完整无误。

  • 为什么是已知良好的卡？排除SD卡本身硬件故障或兼容性问题。
  • 为什么强调高速卡？Nano的系统，尤其是交换空间（swap）和AI模型加载，对IO速度敏感。低速卡可能导致系统响应极慢甚至启动超时失败。
  • 实操心得：我最初就是卡在这一步。我用了一张闲置的旧SD卡，刷写镜像后启动失败。换用一张新的三星EVO Plus卡后，Nano竟然成功启动了！这直接说明原SD卡已物理损坏或存在坏块。永远不要低估一张高质量SD卡对系统稳定性的影响。

第二步：深入原SD卡——尝试修复与数据抢救如果换卡能启动，说明问题在原SD卡。但卡里的数据可能还有救，或者你想尝试修复它。

  1. 在Linux环境下检查：将故障SD卡通过读卡器插入一台正常的Linux电脑（或虚拟机）。
  2. 使用fsck修复文件系统：首先用lsblk或sudo fdisk -l找到SD卡对应的设备名（如/dev/sdb）。注意：千万别选错设备，否则会格式化你的电脑硬盘！假设SD卡的系统分区是/dev/sdb1，执行：
    sudo fsck -y /dev/sdb1
    -y参数表示自动修复所有错误。这个过程会尝试修复文件系统结构。
  3. 使用dd命令制作完整镜像备份（可选但推荐）：在尝试任何修复前，如果数据重要，先用dd把整张卡备份成一个镜像文件：
    sudo dd if=/dev/sdb of=~/jetson_nano_broken.img bs=4M status=progress
    这样，即使后续操作失误，你还有一份原始“快照”。
  4. 重新分区与格式化（终极手段）：如果fsck无效，可能是分区表损坏。可以使用gparted图形化工具或fdisk/cfdisk命令行工具，删除所有分区，重新创建分区表（通常是MBR或GPT），然后格式化。完成后，再重新刷写官方镜像。

第三步：验证Bootloader配置有时，SD卡本身是好的，但Bootloader的配置文件出了问题。成功刷写镜像后，在Linux电脑上挂载SD卡的第一个分区（通常是FAT32格式的/boot分区）。 检查/boot/extlinux/extlinux.conf文件。这个文件告诉U-Boot从哪里加载内核。一个典型的错误是root=参数指定的设备名不对。对于SD卡启动，它通常应该是root=/dev/mmcblk0p1。确保这个路径与你的实际分区一致。

# 示例 extlinux.conf 关键行 LABEL primary MENU LABEL Jetson Nano LINUX /boot/Image FDT /boot/tegra210-p3448-0000-p3449-0000-a02.dtb INITRD /boot/initrd APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0

重点看root=/dev/mmcblk0p1。如果这里错误地指向了/dev/sda1（假设是SATA设备），自然无法启动。

4. 进阶排查：当换卡与修复都无效时

如果你更换了多张SD卡、重新刷写了官方镜像，串口依然没有任何输出，那么问题可能更深层。这时，我们需要怀疑硬件或更底层的软件。

4.1 eMMC版本与强制恢复模式（Force Recovery）

Jetson Nano 4GB开发者套件默认使用SD卡，但也有一些模块或定制载板集成了eMMC存储。如果你的是eMMC版本，或者之前刷写过eMMC，可能需要进入强制恢复模式。

  1. 操作步骤：
    • 断开Nano电源。
    • 用跳线帽或镊子短接位于板卡上的REC（恢复）引脚和GND引脚。对于Nano开发者套件，这通常是J50排针旁边的两个小孔，标记为“REC”和“GND”。
    • 保持短接状态，给Nano上电。
    • 大约2秒后，松开短接。
    • 此时，Nano应进入恢复模式。在连接了USB线到电脑的情况下，你可以在电脑上用lsusb命令看到NVIDIA Corp.的设备。
  2. 使用SDK Manager刷机：在主机电脑上运行NVIDIA SDK Manager，选择“目标硬件”为Jetson Nano，并勾选“手动操作”下的“进入恢复模式”选项。按照提示，可以重新向eMMC或SD卡刷写完整的系统镜像。这是一个“核武器”级别的修复，能覆盖Bootloader在内的所有软件层。

4.2 硬件层面的终极怀疑

如果上述所有软件方法都失败，尤其是连串口在开机瞬间都没有任何乱码输出（这很重要，即使Bootloader损坏，上电瞬间CPU跑飞也可能产生乱码），那么就需要考虑硬件问题。

  1. 电源完整性：再次确认电源。尝试使用台式机电源的5V输出（通过转接线），或者使用大功率的USB PD诱骗器，排除电源适配器动态响应不足的可能。
  2. 观察元件：仔细检查板卡上是否有肉眼可见的损坏，如电容鼓包、芯片烧焦的痕迹、异味等。
  3. 环境因素：静电放电（ESD）可能损伤敏感元件。确保在干燥环境下操作时，自己和工作台有良好的接地。

5. 我的解决路径与最终复盘

回顾我的整个解决过程，它是一条典型的、由浅入深的排查路径：

  1. 现象确认：电源灯亮，风扇不转，HDMI无输出 -> 初步判断非单纯供电问题。
  2. 关键诊断：连接串口，发现无任何输出 -> 锁定故障在Bootloader加载阶段。
  3. 第一轮修复：怀疑SD卡软件错误，在Linux下用fsck尝试修复原卡 -> 无效。
  4. 第二轮修复：怀疑SD卡物理损坏或Bootloader损坏，更换一张全新的、高质量的SD卡，并重新刷写NVIDIA官方镜像->问题解决！Nano成功启动。
  5. 根本原因分析：原SD卡是一张使用多年的旧卡，长期在Nano上高负载运行（训练模型、频繁读写交换分区），最终出现了无法通过软件修复的坏块或控制器故障，导致Bootloader数据读取失败。

这个案例最深刻的教训是：在嵌入式开发中，存储介质的质量与可靠性是系统稳定的基石，其重要性不亚于CPU和内存。对于像Jetson Nano这样依赖外部存储启动的设备，一张高品质的SD卡应被视为标准配件，而不是可以随便将就的部分。

此外，串口调试工具是嵌入式开发的“眼睛”，没有它，排查启动故障就像在黑暗中摸索。投资一个可靠的3.3V USB转TTL模块，并学会使用它，是每个嵌入式开发者的必备技能。

最后，保持系统镜像的备份是一个好习惯。当你花费大量时间配置好一个完美的开发环境后，不妨用dd命令将整张SD卡备份成一个.img文件。下次再遇到启动失败，只需几分钟就能还原到一个已知的工作状态，而不是从头开始配置。毕竟，我们的时间是宝贵的，应该更多地花在创造性的开发工作上，而不是与硬件故障反复纠缠。

编程学习 学习日记 实战经验
← 返回列表