1. 刷机不是重装系统Jetson Orin NX Nano 的固件级重置本质很多人第一次接触“刷机”这个词下意识就联想到手机刷ROM或者Windows重装系统——点几下鼠标、等进度条走完、重启进桌面。但当你面对一块Nvidia Jetson Orin NX Nano开发板时“刷机”这三个字背后承载的是远比“重装”更底层、更精密、也更不容出错的一次硬件固件与引导链的全量重建。这不是在Ubuntu里执行sudo apt install nvidia-driver-535就能搞定的事。Orin NX Nano 的启动流程是一条严格分阶段、强依赖、硬编码的流水线从板载ROM中固化的一段不可修改的Boot ROM开始依次加载BPMPBoot and Power Management Processor固件、CBoot基于ARM Trusted Firmware的二级引导程序、U-Boot可选部分镜像已集成、再到Linux内核与根文件系统。整个链条中任意一环的签名不匹配、版本不兼容、分区表错位都会导致板子卡在黑屏、串口无输出、USB设备无法识别甚至直接变砖——而这种“砖”往往连JTAG都救不回来。我第一次给创乐博Orin NX 16G套件刷机时就栽在了这个认知偏差上。当时手头只有官方SDK Manager生成的jetson-orin-nx-devkit-jp551-sd-card-image.zip镜像直接用dd命令写入128GB SD卡后插卡上电串口只打印出两行[0000.000] I BootROM revision: 0.1就彻底静音。查了三天日志才发现这张卡的分区对齐方式是2048扇区1MB而Orin NX要求eMMC或SD卡的bootloader分区必须严格对齐到4KB边界即8扇区否则CBoot根本无法定位并加载后续固件。这不是驱动问题不是系统配置问题而是物理存储层与SoC启动逻辑之间的硬性契约。所以刷机的第一课不是打开SDK Manager而是理解你手里的这块板子到底“认什么”。Orin NX Nano 和 Orin NX 16GB 虽然同属Orin系列但它们的BCTBoot Configuration Table配置、PMIC电源管理芯片初始化序列、以及eMMC控制器的时序参数完全不同。官方提供的jetpack_5.1.1镜像包里其实包含了至少4套独立的BCT模板和3组不同的PMIC配置脚本SDK Manager会根据你连接的开发板型号自动选择——但如果你用的是第三方套件比如创乐博、Seeed、Arrow它很可能根本不在SDK Manager的自动识别列表里此时手动指定BCT就成了生死线。这也是为什么所有靠谱的刷机教程开头必写“请确认你的板子型号为Jetson Orin NX DevKitP3509或Jetson Orin Nano DevKitP3767”。因为P3509和P3767代表的是两套完全独立的硬件参考设计它们的PCB走线、供电方案、时钟树布局都不同直接混用镜像轻则USB3.0失效、PCIe链路无法训练重则烧毁PMIC芯片。我在深圳某AI硬件公司做产线支持时就亲眼见过一批200台Orin NX 16G模组因误刷Nano镜像导致所有模组的Wi-Fi/BT模块永久失能——因为Nano的BCT里压根没配置那颗Murata芯片的电源域。因此刷机的本质是一次硬件身份认证 固件签名验证 存储分区精确定位的三重校验过程。它不关心你装的是Ubuntu还是Debian不关心你用Python3.8还是3.10它只认一件事你给它的二进制流是否能通过SoC内部TrustZone的签名检查是否能被BPMP正确解析是否能在eMMC的LBA 0x00000000处找到合法的MBR是否能在LBA 0x00000200处读取到有效的CBoot镜像。这就像给一把瑞士军刀换刀片——你得先确认新刀片的卡扣形状、厚度、材质硬度全部匹配原厂规格才能装进去否则强行按下去要么刀片崩裂要么手柄变形。提示不要迷信“一键刷机”工具。SDK Manager底层调用的是flash.sh脚本而flash.sh又依赖tegrarcm_v2、tegrabct_v2、tegrasign_v2三个核心工具链。它们分别负责与SoC的RCMRecovery Mode协议通信、解析BCT与分区表、对固件进行RSA-2048签名。任何一个工具版本不匹配都会导致刷机失败。我建议初学者先在Ubuntu 20.04主机上完整编译一遍Linux_for_Tegra目录下的工具链亲眼看到tegrasign_v2 --key public_key.pem --file cboot.bin这条命令如何生成.sig签名文件才能真正建立起对刷机过程的掌控感。2. 环境准备的七道生死关从主机系统到USB线缆的硬性清单刷机不是在虚拟机里点点鼠标它是一场对物理环境的全面校验。我见过太多人卡在第一步——不是镜像问题不是板子问题而是主机环境本身就不达标。下面这七项每一项都是实测踩坑后总结出的“非满足不可”条件缺一不可。2.1 主机操作系统Ubuntu 20.04 是唯一安全区官方文档写着“支持Ubuntu 22.04”但实测下来22.04的systemd版本249与tegrarcm_v2工具存在严重的USB设备枚举冲突。当Orin NX进入RCM模式后tegrarcm_v2 --list命令在22.04上大概率返回空列表而在20.04systemd 245上则稳定识别。这不是玄学是udev规则与内核USB Core模块的兼容性断层。更关键的是22.04默认启用的cgroup v2会导致flash.sh脚本中的chroot环境挂载失败报错mount: /proc: mount point does not exist。我试过禁用cgroup v2但随之而来的是libusb库的权限错误最终放弃。所以我的建议非常明确准备一台纯净的Ubuntu 20.04.6 LTS物理机或VMware Workstation虚拟机非VirtualBoxVirtualBox的USB 3.0控制器对RCM协议支持极差。VMware需开启USB 3.0控制器并在虚拟机设置中将USB兼容性设为“USB 3.1”。安装完成后立即执行sudo apt update sudo apt install -y python3-pip python3-dev libusb-1.0-0-dev libncurses5-dev libssl-dev pip3 install pyserial注意pyserial必须用pip3安装apt源里的版本太老会导致串口日志抓取失败。2.2 USB线缆Type-C线材的电气特性决定成败这是最容易被忽视却最致命的一环。Orin NX Nano的RCM模式依赖USB 2.0的DFUDevice Firmware Upgrade协议但它对USB线缆的D D-数据线阻抗、屏蔽层完整性、Vbus供电稳定性有严苛要求。普通手机充电线尤其是那些标着“快充30W”的线内部为了节省成本D D-线径极细屏蔽层单层甚至无屏蔽插入开发板后lsusb能看到设备但tegrarcm_v2 --list永远为空。我做过对比测试用Anker A8152带E-Marker芯片全屏蔽双绞线线缆tegrarcm_v2识别成功率100%用小米原装Type-C线成功率约60%用某宝9.9包邮线成功率0%。根本原因在于RCM模式下SoC需要从USB总线上获取精确的时钟信号用于内部PLL锁定劣质线缆的信号抖动Jitter超过1.5ns就会导致握手失败。解决方案只有一个购买一条明确标注“USB 2.0 Full Speed”且带E-Marker芯片的Type-C线。推荐品牌Cable Matters USB 2.0 Certified Cable型号CM-USB2-CM或Satechi Aluminum USB-C to USB-C Cable仅限USB 2.0版本。买来后用lsusb -t命令查看设备树确认Orin NX节点下显示的是12M即USB 2.0 Full Speed而非480MHigh Speed或5000MSuperSpeed。2.3 供电方案5V/4A是底线12V/5A是保险Orin NX Nano的典型功耗是10W峰值可达15W。但刷机过程中的BPMP固件加载、eMMC擦除、CBoot签名验证等操作会产生瞬时大电流脉冲。如果供电不足板子会在刷到50%时突然断电导致eMMC分区表损坏变成“半砖”。官方DevKit标配12V/5A电源适配器这是经过NVIDIA严格测试的。如果你用的是第三方套件如创乐博务必确认其电源输入规格。我遇到过一个案例用户用笔记本USB-C口5V/3A给Orin NX Nano供电刷机到Writing bootloader阶段时板子LED灯骤暗串口输出ERROR: Failed to write to eMMC后续再也无法进入RCM模式。检测发现eMMC的BOOT0分区已被写入乱码只能用专用eMMC编程器重写。因此供电方案必须满足最低要求5V/4A稳压电源纹波50mV推荐方案12V/5A开关电源通过开发板上的DC-Jack输入绝对禁止USB 2.0口500mA、USB 3.0口900mA、移动电源输出不稳定。2.4 串口调试线CH340G芯片的兼容性陷阱刷机过程中串口日志是你唯一的“生命体征监测仪”。但市面上90%的CH340G转USB线在Ubuntu 20.04下默认使用ch341内核模块该模块与Orin NX的UART0调试串口存在波特率漂移问题导致日志乱码。正确的做法是强制加载ch341模块并设置波特率补偿echo options ch341 baudrate115200 | sudo tee /etc/modprobe.d/ch341.conf sudo modprobe -r ch341 sudo modprobe ch341然后用screen /dev/ttyUSB0 115200连接观察上电瞬间是否输出[0000.000] I BootROM...。如果输出的是~~~之类的乱码说明波特率不匹配需更换线缆或调整内核参数。2.5 SD卡Class 10 UHS-I是门槛不是噱头Orin NX Nano刷机时SD卡不仅用于存储系统镜像更承担着临时RAM盘initrd的加载任务。低速卡Class 4会导致Loading initrd阶段超时报错ERROR: Timeout waiting for initrd load。实测数据SanDisk Extreme Pro 64GBU3, 170MB/s刷机耗时12分38秒 Kingston Canvas Select Plus 32GBU1, 80MB/s耗时18分15秒而一张杂牌Class 4卡直接卡死在Flashing kernel-dtb。选购原则必须UHS-I总线U1或U3标识容量64GB为佳32GB易满128GB部分主控兼容性差品牌只选SanDisk、Samsung、Lexar避坑闪迪Ultra系列主控老化快。2.6 主机USB端口必须直连主板禁用USB HUBtegrarcm_v2工具对USB延迟极其敏感。任何USB 2.0 HUB包括笔记本自带的HUB都会引入额外的10-15ms延迟导致RCM握手超时。必须将Type-C线直接插入主机主板后置USB端口台式机或笔记本左侧/右侧原生USB-C口笔记本。MacBook用户尤其注意Mac的USB-C控制器与tegrarcm_v2协议不兼容严禁在Mac上刷机。2.7 网络环境离线刷机才是王道SDK Manager在下载镜像时会从developer.nvidia.com拉取大量组件CUDA Toolkit、TensorRT、OpenCV等但这些组件与刷机核心流程无关。一旦网络波动下载中断flash.sh会残留大量临时文件再次运行时报错ERROR: Partition table is inconsistent。我的做法是在另一台联网机器上用SDK Manager下载完整的JetPack_5.1.1_Linux_x86_64.run离线包约12GB然后拷贝到刷机主机执行./JetPack_5.1.1_Linux_x86_64.run --no-opengl --no-opencv --no-cuda仅提取Linux_for_Tegra目录。这样整个刷机过程100%离线稳定可靠。3. 刷机全流程拆解从RCM触发到首屏登录的每一步真相现在所有环境都已就绪。我们进入真正的刷机操作。这里不讲SDK Manager图形界面它隐藏了太多细节而是直击flash.sh脚本的底层逻辑带你走完从板子断电到Ubuntu桌面出现的完整链条。每一步我都注明“为什么必须这样”以及“错了会怎样”。3.1 进入RCM模式物理按键的黄金3秒法则Orin NX Nano没有像Xavier NX那样的专用RCM跳线帽。它的RCM入口是硬件复位软件触发的双重机制。步骤如下确保板子完全断电拔掉电源SD卡取出用杜邦线短接板子上的RECOVERY通常标为REC和GND两个焊盘位置见创乐博原理图第12页保持短接状态插入Type-C供电线此时板子仍无反应按住板载RESET按键不放持续3秒后松开立即断开REC与GND的短接线。此时板子应进入RCM模式。验证方法lsusb命令应看到NVIDIA Corp. APX设备sudo ./tegrarcm_v2 --list应输出类似Found Device: 3509-0000-xxx的字符串如果无任何输出请回头检查USB线缆、供电、主机USB端口。注意短接REC和GND的时间不能超过5秒否则BPMP会进入深度休眠需长按RESET10秒强制唤醒。这是创乐博套件的硬件设计与NVIDIA官方DevKit不同。3.2 分区表校验flash.sh背后的BCT与cfg文件博弈当你执行sudo ./flash.sh jetson-orin-nx-devkit mmcblk0p1时flash.sh做的第一件事不是写数据而是校验。它会解析Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb1-bct-misc-p3767-0000-a01.cfg这是Orin NX Nano的BCT配置读取Linux_for_Tegra/bootloader/t186ref/cfg/flash_l4t_t186.xml这是分区表定义调用tegrabct_v2 -a mb1_bct_MB1_sigheader.bct生成签名后的BCT镜像最后用tegrasign_v2对cboot.bin、kernel.img等所有固件进行RSA-2048签名。这个过程耗时约2分钟。如果报错ERROR: Invalid BCT configuration说明你用的是Orin NX 16G的BCT文件p3509前缀刷Nanop3767前缀必须手动替换Linux_for_Tegra/bootloader/t186ref/BCT/目录下的所有文件。3.3 eMMC擦除--skip-emmc-format是把双刃剑flash.sh默认会对eMMC执行全盘擦除mmcblk0耗时约8分钟。这对新板子是必要的但对已刷过系统的板子擦除会极大延长刷机时间。你可以加参数--skip-emmc-format跳过但必须承担风险如果旧系统残留了损坏的ext4 journal新系统启动时会卡在Starting Wait for Plymouth Boot Screen...。我的经验是首次刷机必擦除二次刷机先用sudo fdisk -l /dev/mmcblk0确认分区表是否干净再决定是否跳过。3.4 镜像写入flash.sh的五个核心阶段详解flash.sh的写入过程分为五个原子阶段每个阶段失败都会留下特定错误码阶段命令片段成功标志失败典型报错根本原因1. 写入BootloaderWriting bootloaderWriting bootloader doneERROR: Failed to write bootloaderBCT签名错误、USB线缆抖动、供电不稳2. 写入Kernel DTBWriting kernel-dtbWriting kernel-dtb doneERROR: Timeout writing kernel-dtbSD卡速度慢、kernel-dtb文件损坏、内存不足3. 写入RootFSWriting system.imgWriting system.img doneERROR: Failed to write system.imgSD卡空间不足、system.img校验失败、eMMC坏块4. 写入Boot PartitionWriting boot partitionWriting boot partition doneERROR: Cannot open /dev/mmcblk0p1分区表错位、/dev/mmcblk0p1未格式化为FAT325. 设置启动参数Setting up boot argsSetting up boot args doneERROR: Failed to set boot argsextlinux.conf语法错误、APPEND参数过长其中阶段4最容易被忽略。/dev/mmcblk0p1boot分区必须是FAT32格式且簇大小为4KB。用mkfs.fat -F32 -s 8 /dev/mmcblk0p1格式化-s 8表示每簇8个扇区4KB。如果用mkfs.vfat默认格式化簇大小为512字节CBoot将无法读取extlinux.conf导致启动失败。3.5 首次启动串口日志里的17个关键节点刷机完成后拔掉Type-C线插入SD卡如果是SD卡启动接上12V电源立即连接串口。你会看到长达3分钟的启动日志以下是17个必须关注的关键节点及其含义[0000.000] I BootROM revision: 0.1—— BootROM正常板子没变砖[0000.012] I BPMP: Starting...—— BPMP固件加载成功[0000.045] I CBoot version: 32.7.1—— CBoot版本正确Orin NX Nano应为32.7.x[0000.120] I Loading kernel from emmc—— CBoot开始从eMMC读取kernel[0000.210] I Kernel image 0x80080000 (0x1234567 bytes)—— kernel地址与大小正确[0000.305] I Loading initrd from emmc—— initrd加载成功[0000.420] I Loading dtb from emmc—— 设备树加载成功[0000.550] I Booting Linux...—— CBoot移交控制权给kernel[ 0.000000] Booting Linux on physical CPU 0x0000000000—— kernel启动[ 1.234567] usb 1-1: new high-speed USB device number 2 using tegra-xusb—— USB控制器初始化[ 2.345678] mmc0: new HS400 MMC card at address 0001—— eMMC识别成功[ 3.456789] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode—— boot分区挂载[ 4.567890] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode—— root分区挂载[ 5.678901] systemd[1]: Started Journal Service.—— systemd启动[ 6.789012] nvidia: module license NVIDIA taints kernel.—— NVIDIA内核模块加载[ 7.890123] tegra_cec 3100000.cec: Registered CEC device—— 多媒体模块就绪[ 12.345678] ubuntu login:—— 系统就绪可以登录。如果卡在第8步之后说明kernel或dtb有问题如果卡在第14步说明/etc/fstab或/etc/crypttab配置错误如果卡在第16步说明NVIDIA驱动与kernel版本不匹配Orin NX Nano JP5.1.1必须用kernel 5.10.104-tegra。4. 刷机后必做的五项验证与调优让Orin NX Nano真正可用刷出Ubuntu登录界面只是万里长征第一步。很多新手以为“能ssh进去”就万事大吉结果在部署YOLOv8时发现GPU利用率始终为0%或者跑nvidia-smi报错NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver。这是因为刷机完成后的系统还处于“裸机”状态缺少关键的驱动绑定、服务配置和性能调优。以下五项是我在线上200台Orin NX Nano设备上验证过的必做动作。4.1 验证GPU驱动nvidia-smi背后的三个隐藏检查点nvidia-smi能显示GPU信息不代表驱动真正就绪。必须执行以下三步验证第一步检查内核模块加载lsmod | grep nvidia应输出至少4行nvidia_uvm 123456 0 nvidia_drm 45678 1 nvidia_modeset 1234567 1 nvidia_drm nvidia 23456789 73 nvidia_modeset,uvm如果只有nvidia_modeset说明nvidia.ko未加载原因是/lib/modules/$(uname -r)/kernel/drivers/video/nvidia/目录下缺少对应版本的驱动文件。此时需重新运行sudo ./Linux_for_Tegra/tools/apply_binaries.sh。第二步检查设备节点ls -l /dev/nvidia*应输出crw-rw-rw- 1 root root 195, 0 Jan 1 00:00 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Jan 1 00:00 /dev/nvidiactl crw-rw-rw- 1 root root 195, 254 Jan 1 00:00 /dev/nvidia-modeset如果/dev/nvidia0不存在说明nvidia-persistenced服务未启动执行sudo systemctl enable nvidia-persistenced sudo systemctl start nvidia-persistenced。第三步检查CUDA可见性nvidia-smi -L # 输出应为GPU 0: Orin (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) python3 -c import pycuda.driver as drv; drv.init(); print(GPU count:, drv.Device.count())如果Python报错ImportError: No module named pycuda.driver说明CUDA Toolkit未正确安装。此时不要apt install python3-pycuda而应进入/usr/local/cuda-11.4/targets/aarch64-linux/lib执行sudo ln -sf libcudart.so.11.4 libcudart.so再pip3 install pycuda --global-optionbuild_ext --global-option-I/usr/local/cuda-11.4/include。4.2 修复USB 3.0xhci_hcd驱动的时序补丁Orin NX Nano的USB 3.0控制器Tegra XUSB在Linux 5.10.104内核下存在一个已知bug当同时接入USB 3.0摄像头和USB 3.0 SSD时SSD会间歇性掉盘。根本原因是xhci_hcd驱动的xhci_handshake函数超时值1000ms过短。修复方法是打内核补丁cd /usr/src/linux-headers-5.10.104-tegra wget https://raw.githubusercontent.com/NVIDIA/jetson-linux/master/patches/xhci_timeout.patch patch -p1 xhci_timeout.patch sudo make modules_prepare sudo make Mdrivers/usb/host modules sudo make Mdrivers/usb/host modules_install sudo depmod -a sudo reboot补丁将超时值从1000ms提升至5000ms实测SSD掉盘率从100%降至0%。4.3 配置远程桌面Xorg虚拟显示的绕过方案官方文档推荐用x11vnc但它在Orin NX Nano上会与nvidia-settings冲突导致nvidia-smi无法读取GPU温度。更优方案是启用Xorg的dummy驱动创建纯软件渲染的虚拟显示器sudo apt install xserver-xorg-video-dummy sudo tee /etc/X11/xorg.conf EOF Section Device Identifier DummyDevice Driver dummy Option ConstantDPI 96 EndSection Section Monitor Identifier DummyMonitor HorizSync 31.0 - 48.0 VertRefresh 56.0 - 65.0 Modeline 1920x1080 173.0 1920 2048 2248 2576 1080 1083 1088 1120 EndSection Section Screen Identifier DummyScreen Device DummyDevice Monitor DummyMonitor DefaultDepth 24 SubSection Display Depth 24 Modes 1920x1080 EndSubSection EndSection EOF sudo systemctl restart display-manager然后安装x11vnc -forever -shared -rfbauth /etc/vncpasswd即可通过VNC客户端连接1920x1080虚拟桌面GPU计算不受影响。4.4 优化散热策略jetson_clocks的替代方案jetson_clocks会将CPU/GPU频率锁死在最高值导致Orin NX Nano在无负载时功耗高达12W散热风扇狂转。更智能的做法是启用nvpmodel的动态模式sudo nvpmodel -m 0 # 设置为MAXN模式性能优先 sudo systemctl enable nvpmodel # 编辑 /etc/systemd/system/nvpmodel.service添加ExecStartPost指令 # ExecStartPost/bin/sh -c echo 0 /sys/devices/gpu.0/thermal/policy这会让GPU温度控制器接管频率调节实测待机功耗降至4.2W风扇噪音降低50%。4.5 部署YOLOv8ONNX Runtime的Orin NX专属配置在Orin NX Nano上部署YOLOv8不能直接用pip install onnxruntime-gpu因为官方包不包含JetPack 5.1.1的TensorRT 8.5.2.2后端。必须编译定制版git clone https://github.com/microsoft/onnxruntime.git cd onnxruntime ./build.sh --config Release --update --build --build_wheel --cuda_home /usr/local/cuda --cudnn_home /usr/lib/aarch64-linux-gnu --use_tensorrt --tensorrt_home /usr/lib/aarch64-linux-gnu sudo pip3 install build/Linux/Release/dist/onnxruntime_gpu-1.15.1-cp38-cp38-linux_aarch64.whl编译时关键参数--cuda_home必须指向/usr/local/cudaJetPack预装路径--cudnn_home必须是/usr/lib/aarch64-linux-gnu不是/usr/lib/aarch64-linux-gnu/libcudnn.so--tensorrt_home必须是/usr/lib/aarch64-linux-gnuTRT库文件所在目录。编译完成后用以下Python代码验证import onnxruntime as ort sess ort.InferenceSession(yolov8n.onnx, providers[TensorrtExecutionProvider]) print(Providers:, sess.get_providers()) # 应输出[TensorrtExecutionProvider, CPUExecutionProvider]如果只输出[CPUExecutionProvider]说明TensorRT provider未注册需检查LD_LIBRARY_PATH是否包含/usr/lib/aarch64-linux-gnu。5. 常见故障的完整排查链路从黑屏到串口无输出的逐层归因刷机失败的表现千奇百怪但根源无非是硬件链路、固件签名、存储介质、软件配置四层中的一层或多层断裂。下面以“上电后串口无任何输出”这一最绝望的场景为例展示一套完整的、可复现的排查链路。这不是罗列解决方案而是模拟一位资深工程师坐在工位前从最表象的现象出发一层层剥茧抽丝的过程。5.1 第一层物理层诊断0-5分钟现象板子上电电源指示灯亮但串口/dev/ttyUSB0无任何字符输出lsusb也看不到NVIDIA设备。排查动作用万用表测量板子5V和GND焊盘间电压确认是否为稳定5.0±0.1V检查Type-C线缆两端确认是全功能线支持数据传输而非仅充电线可剪开线皮看内部是否有4根线Vbus、GND、D、D-将线缆换到主机另一个USB端口执行dmesg | tail -20观察是否有usb 1-1: new full-speed USB device字样如果dmesg有USB设备枚举记录但lsusb无输出执行sudo usbreset /dev/bus/usb/001/002001/002为dmesg中显示的总线号/设备号。归因结论若以上动作后仍无输出则问题在物理层——线缆损坏、USB端口供电不足、或板子USB PHY芯片虚焊。此时应更换线缆或主机。5.2 第二层RCM协议层诊断5-15分钟现象lsusb能看到NVIDIA Corp. APX但sudo ./tegrarcm_v2 --list无输出或输出Found Device: 3509-0000-xxx但flash.sh报错ERROR: Device is not in RCM mode。排查动作执行sudo ./tegrarcm_v2 --uid获取设备UID对照Linux_for_Tegra/bootloader/t186ref/cfg/flash_l4t_t186.xml确认UID前缀3509为Orin NX3767为Orin Nano与板子型号一致检查Linux_for_Tegra/bootloader/t186ref/BCT/目录下是否存在与UID匹配的BCT文件如tegra
