eBMC固件烧录：硬件时序、Flash擦写与上电验证全解析-育师

1. 项目概述：这不是刷个BIOS那么简单的事

“eBMC套件固件烧录及上电过程”——光看标题，很多人第一反应是：“哦，服务器带外管理模块升级？”但真干过这活儿的都知道，这六个字背后藏着一整套软硬协同的精密时序系统。它不是把一个bin文件拖进烧录器点一下“开始”就完事了，而是涉及硬件供电路径控制、BootROM跳转逻辑、SPI Flash擦写保护机制、BMC SoC内部状态机切换、以及上电后各子系统（如PHY、RTC、Watchdog、UART）的初始化依赖链。我最早在某高校实验室调试一台国产化服务器平台时，就卡在这个环节整整三天：烧录成功，但上电后串口无任何输出，LED灯也不亮，万用表测到BMC芯片VCC电压在3.3V和0V之间反复跳变——最后发现是电源管理IC的PGOOD信号被某个未启用的GPIO意外拉低，导致整个BMC域供电被强制切断。这件事让我彻底明白：eBMC固件烧录，本质是一次对硬件底层信任链的重建。

这个过程的核心价值，在于它直接决定了整台设备是否具备远程可管理性、安全启动能力、以及故障诊断入口。如果你是硬件工程师，它关系到你设计的板级电路能否通过量产测试；如果你是固件开发人员，它决定了你写的Bootloader能否顺利接管CPU；如果你是运维人员，它影响着你未来能否在机房断网、断电、甚至主板黑屏的情况下，通过IPMI命令重启整台服务器。关键词里没提“安全”，但它天然绑定Secure Boot、Root of Trust、HMAC校验等机制；没提“兼容”，但实际操作中，同一款eBMC芯片，面对不同厂商的SPI Flash（Winbond vs Macronix vs GigaDevice），擦除块大小、写入时序、写保护寄存器地址可能全都不一样。所以这篇内容，不讲概念，不画大饼，只说我在产线、实验室、客户现场踩过的坑，拆解每一步背后的“为什么必须这样”，并给出可直接抄作业的参数配置和验证方法。

2. 整体设计与思路拆解：为什么不能跳过Pre-Boot阶段？

2.1 eBMC与传统BMC的本质区别在哪？

先厘清一个关键前提：eBMC（embedded Baseboard Management Controller）不是简单地把BMC功能集成进主SoC，而是采用一种物理隔离+逻辑协同的架构。它的核心特征是：独立供电域、独立Flash存储、独立复位源、但共享部分PCIe/USB/LAN物理通道。这意味着，当你给服务器上电时，eBMC的供电（通常是+3.3V_AUX）会比主CPU早几十毫秒上电，它必须在主系统还在冷态时，就完成自身固件加载、PHY初始化、网络栈启动，并监听来自主CPU的首次握手请求。这种“先上岗、后协作”的模式，决定了它的烧录流程绝不能套用PC BIOS那种“热更新”逻辑。

我见过太多人误以为eBMC烧录就是找个USB转TTL线连上UART，跑个flashrom -p internal -w firmware.bin就完事。结果呢？烧录工具显示“Success”，但一上电，串口静默，JTAG也连不上。问题出在哪？——他们忽略了eBMC芯片内部存在两级BootROM：第一级是Mask ROM（出厂固化，不可修改），负责最底层的SPI Flash读取和校验；第二级才是我们通常说的“Bootloader”，它从Flash的固定偏移地址（比如0x0000_0000）开始执行。而Mask ROM在启动时，会严格检查该地址处的前4字节是否为合法的Magic Number（例如0x45424D43，即ASCII的"EBMC"），同时校验后续Header区域的CRC32。如果校验失败，Mask ROM会直接进入“Safe Mode”，只开放JTAG调试接口，UART完全关闭——这就是你看到“烧录成功但无输出”的根本原因。

所以整个设计思路的第一条铁律就是：烧录不是覆盖写入，而是可信替换。我们必须确保新固件的Header结构、Magic Number、校验字段、跳转地址全部符合Mask ROM的硬性要求。这就像往银行保险柜里换存单，不是把旧纸撕掉贴张新纸就行，而是要让柜员（Mask ROM）一眼认出这是同一套合规凭证。

2.2 烧录方式选型：JTAG、SPI、UART，哪个才是真命天子？

市面上常见的烧录方式有三种：JTAG、SPI直连、UART串口。很多新手会本能选UART，因为线少、工具便宜、操作直观。但实测下来，在eBMC场景下，UART是最不可靠的方案。原因有三：

第一，UART烧录依赖于eBMC当前运行的Bootloader是否开启了串口下载模式。而这个模式往往需要特定的GPIO组合（比如BOOT[1:0] = 0b10）或按键触发。一旦Bootloader本身损坏，或者GPIO被其他电路锁定，UART这条路就彻底堵死。

第二，UART传输速率受限（通常最高115200bps），烧录一个8MB的固件（含完整Linux Kernel + Web Server + IPMI Stack）需要近12分钟。期间只要有一帧数据出错（工业现场电磁干扰太常见），整个烧录就失败，且错误定位极难。

第三，也是最关键的一点：UART烧录通常只更新Flash中的Application区，而跳过Bootloader和Configuration区。这就埋下了巨大隐患——新固件可能和旧Bootloader不兼容，导致启动时跳转地址错误，直接硬复位。

相比之下，JTAG是最底层、最可靠、最可控的方式。它绕过了所有软件层，直接操控芯片内部的调试状态机，可以任意读写CPU寄存器、内存、Flash控制器寄存器。我经手的某款ARM Cortex-A72架构eBMC芯片，其JTAG接口支持SWD（Serial Wire Debug）协议，通过OpenOCD工具，我能精确控制Flash控制器的“Erase Sector”命令，指定擦除0x0000_0000~0x0000_FFFF这一段（64KB Bootloader区），再逐字节写入新Bootloader，最后用verify_image命令做全量比对。整个过程耗时不到90秒，且失败率趋近于零。

那SPI直连呢？它介于两者之间：比UART快（SPI时钟可达25MHz），比JTAG侵入性小（不需要专用调试器）。但它的前提是eBMC芯片必须处于“SPI Slave Mode”，这通常需要硬件设计时预留一个SPI Flash选择引脚（如SSEL），并在上电时由外部MCU拉低。很多商用主板为了节省BOM成本，直接把这个引脚接地或悬空，导致SPI烧录功能被硬件禁用。所以我的经验是：量产阶段首选JTAG（配自动化烧录夹具），研发调试阶段可SPI+UART双备份，但绝不能只依赖UART。

2.3 上电时序：为什么“先按电源键”是个危险动作？

很多人烧录完固件，习惯性地立刻按下服务器前面板的电源键。这是个高风险操作。eBMC的上电过程，本质上是一场多路电源、多个复位信号、多级时钟的精密协奏曲。以某款主流eBMC SoC为例，其上电时序要求如下：

+3.3V_AUX电源必须最先稳定（t < 10ms），这是eBMC的“生命线”，为RTC、Watchdog、基本GPIO供电；
随后+1.8V_CORE在5ms内建立，为CPU内核提供工作电压；
最后+1.2V_IO在3ms内到位，驱动外部SPI Flash和PHY芯片；
所有电源稳定后，POR（Power-On Reset）信号需保持低电平至少100μs，再释放；
POR释放后，eBMC内部RC振荡器启动，约2ms后切换至外部晶振（25MHz）；
晶振稳定后，Mask ROM才开始执行第一行代码。

如果在+3.3V_AUX刚上电、其他电压还没建立时就按下电源键，会导致主CPU域提前上电，其PCIe控制器可能向eBMC发送非法配置请求，而此时eBMC的PCIe PHY尚未初始化，极易引发总线锁死。我遇到过最典型的案例：某次烧录后，客户现场连续三次上电失败，万用表测得eBMC芯片的PCIe_REFCLK引脚电压为0.8V（非标准的0V或1.8V），说明PHY内部LDO已损坏。返厂分析确认，是上电时序紊乱导致参考时钟输入端过压击穿。

因此，正确的上电流程必须是：先确保所有辅助电源（尤其是+3.3V_AUX）已稳定输出，再通过BMC专用的“Soft Power On”命令（如IPMI的Chassis Control命令）触发主系统上电。这个命令会通过LPC或PCIe总线，由eBMC主动向主板电源管理芯片（PCH或Super I/O）发送PS_ON#信号，从而保证主从系统的上电节奏完全受控。这也是为什么所有正规eBMC烧录指南里，都会强调“烧录完成后，务必断电等待10秒，再重新上电”。

3. 核心细节解析与实操要点：从Header结构到电压纹波

3.1 固件镜像的“身份证”：Header结构深度拆解

eBMC固件不是裸bin文件，它必须携带一个严格定义的Header，这是Mask ROM识别和校验的唯一依据。以某款国产eBMC芯片为例，其Header结构如下（共128字节）：

偏移	长度	字段名	含义	实操要点
0x00	4B	Magic Number	固定值0x45424D43 ("EBMC")	必须大端序，小端写入会导致Mask ROM直接拒载
0x04	4B	Header CRC32	Header区（0x00~0x7F）的CRC32校验值	计算时需将本字段置0后再计算，否则循环校验失败
0x08	4B	Image Length	整个固件镜像（含Header）的总长度	必须是Flash扇区大小的整数倍（如4KB），否则擦除不干净
0x0C	4B	Entry Point	CPU启动后跳转执行的第一条指令地址	必须指向Flash中实际代码起始位置（如0x0001_0000），不能是RAM地址
0x10	16B	Reserved	保留字段，必须全0	任意非0值都可能导致Bootloader解析异常
0x20	32B	Signature	RSA-2048签名数据（用于Secure Boot）	若启用Secure Boot，此字段不能为空，且公钥必须预置在Mask ROM中

这个Header看似简单，但每个字段都暗藏玄机。比如“Image Length”字段，我曾在一个项目中栽过跟头：客户提供的固件镜像长度为0x007A_1234（约7.6MB），但Flash的最小擦除单元是64KB（0x0001_0000）。如果直接烧录，最后0x1234字节会落在一个未擦除的扇区里，导致新旧数据混杂，Mask ROM读取到乱码直接halt。解决方案是：在生成固件时，用padding工具将镜像末尾补零至下一个64KB边界，即最终长度应为0x007A_2000。这个操作必须在签名之前完成，否则Signature字段会因padding而失效。

再比如“Entry Point”，它不是随便填个地址就行。eBMC芯片的内存映射（Memory Map）是固定的：0x0000_0000~0x0000_FFFF为Bootloader区，0x0001_0000~0x000F_FFFF为Application区。如果Entry Point填成0x0000_1000，Mask ROM会从0x0000_1000开始读取指令，但该地址实际存放的是Header的后半部分，CPU执行一堆无效指令后必然异常复位。所以Entry Point必须严格等于Application区的起始地址，且该地址处必须存放一条合法的ARM Thumb指令（如mov r0, #0）。

3.2 SPI Flash擦写：别被“全片擦除”忽悠了

烧录前的擦除操作，是另一个高频出错点。很多烧录工具默认勾选“Erase Full Chip”，听起来很彻底，但对eBMC来说，这往往是灾难的开始。原因在于：eBMC Flash中不仅存固件，还存有硬件配置（Hardware Straps）、MAC地址、温度传感器校准参数等关键NV数据。这些数据通常保存在Flash的最后一个扇区（如0x007F_0000~0x007F_FFFF），如果执行全片擦除，这些数据就永久丢失了，设备可能无法获取正确MAC地址，导致网络无法通信；或者温度读数偏差±20℃，触发误报警。

正确的擦除策略是“精准打击”。以Winbond W25Q80DV（8MB SPI Flash）为例，其扇区划分如下：

扇区0~15：64KB each（0x0000_0000 ~ 0x0000_FFFF）
扇区16~127：4KB each（0x0001_0000 ~ 0x000F_FFFF）
扇区128：64KB（0x007F_0000 ~ 0x007F_FFFF）

其中，扇区0是Bootloader区，扇区16~127是Application区，扇区128是NV Data区。因此，烧录时只需擦除扇区0和扇区16~127，绝对禁止触碰扇区128。在OpenOCD脚本中，这对应以下命令：

# 擦除Bootloader区（扇区0） flash erase_sector w25q80dv 0 0 # 擦除Application区（扇区16~127） flash erase_sector w25q80dv 16 112 # 跳过扇区128！

更进一步，为了防止误操作，我建议在烧录脚本开头加入硬件保护检测。例如，读取Flash的JEDEC ID（0x9F命令），确认是Winbond芯片（ID为0xEF4018）后，再执行擦除；如果是Macronix（ID为0xC22017），则擦除命令参数需调整（Macronix的扇区擦除命令是0x20，而Winbond是0x20或0xD8，取决于扇区大小）。这种“芯片自适应”逻辑，能极大降低跨平台烧录的风险。

3.3 供电质量：纹波超标是烧录失败的隐形杀手

最后，也是最容易被忽视的一点：供电质量。eBMC芯片对电源纹波极其敏感，尤其是+3.3V_AUX电源。根据某款eBMC芯片的Datasheet，其允许的最大峰峰值纹波为50mV。但在实际产线环境中，开关电源的纹波常常达到100~200mV，尤其是在多台设备并行烧录时，地线回路引入的共模噪声会叠加。

纹波超标带来的直接后果是：Mask ROM在读取Flash时发生位错误。比如，本该读到0x45（'E'），却因电压跌落读成0x05，Magic Number校验失败，启动中断。这种问题极具迷惑性——你用逻辑分析仪抓SPI总线，看到的波形完美无缺；用示波器测电源，看起来也“挺稳”，但放大时间轴就会发现，在每次SPI Clock边沿处，电源线上都有一个微小的毛刺（<100ns宽，但幅度>80mV）。这个毛刺恰好发生在Flash数据采样窗口内，导致采样错误。

解决方法有两个层面：

硬件层：在eBMC芯片的VCC引脚就近（<5mm）放置一个10uF钽电容+100nF陶瓷电容的并联组合。钽电容滤低频，陶瓷电容滤高频，形成完整的去耦网络。
测试层：烧录前，必须用示波器的AC耦合模式，带宽限制为20MHz，探头接地弹簧直接焊在芯片VCC引脚焊盘上，测量纹波。合格标准是：RMS值 < 15mV，峰峰值 < 45mV。我见过最极端的案例：某产线烧录良率只有60%，排查三天才发现，是烧录工装的电源线与伺服电机电缆捆扎在一起，电机启停时产生的EMI直接耦合进了eBMC供电线。

4. 实操过程与核心环节实现：从JTAG连接到首条日志输出

4.1 JTAG硬件连接与OpenOCD环境搭建

第一步，搞定硬件连接。eBMC芯片的JTAG接口通常遵循IEEE 1149.1标准，引脚定义如下：

TCK（Test Clock）：时钟信号，频率建议设为1MHz（太高易受干扰，太低效率低）
TMS（Test Mode Select）：模式选择，决定TAP控制器状态机走向
TDI（Test Data In）：数据输入
TDO（Test Data Out）：数据输出
TRST#（Test Reset，可选）：异步复位JTAG链

注意：TCK和TMS必须加上拉电阻（通常4.7kΩ）到+3.3V_AUX，否则在eBMC未上电时，这些信号呈高阻态，JTAG调试器无法识别目标芯片。很多廉价JTAG适配器（如FT2232H方案）的原理图里没画上拉，导致连接后openocd -f interface/jlink.cfg -f target/xxx.cfg命令一直报“JTAG scan chain interrogation failed”。

软件环境方面，我推荐使用OpenOCD 0.12.0版本（较新版本对国产eBMC支持更好）。配置文件target/ebmc.cfg关键内容如下：

# 设置JTAG速度 adapter speed 1000 # 定义TAP控制器 jtag newtap ebmc cpu -irlen 4 -ircapture 0x1 -irmask 0xf # 配置目标芯片 set _CHIPNAME ebmc target create $_CHIPNAME cortex_a -chain-position $_CHIPNAME.cpu # 加载Flash驱动（以W25Q80DV为例） flash bank w25q80dv w25q80dv 0 0 0 0 $_CHIPNAME

验证连接是否成功，执行：

openocd -f interface/jlink.cfg -f target/ebmc.cfg -c "init; reset halt; dump_image ram_dump.bin 0x00000000 0x1000; exit"

如果看到Info : Listening on port 6666 for tcl connections和Info : Listening on port 4444 for telnet connections，说明JTAG链已通。此时，你可以用telnet连接4444端口，输入mdw 0x00000000 4，读取Flash起始4字节，确认是否为0x45424D43。

4.2 分步烧录：擦除、写入、校验三部曲

烧录不是一蹴而就，必须严格遵循“擦除→写入→校验”三步。我写了一个自动化脚本burn_ebmc.sh，核心逻辑如下：

#!/bin/bash # Step 1: 擦除指定扇区 echo "=== Erasing Bootloader and Application sectors ===" openocd -f interface/jlink.cfg -f target/ebmc.cfg -c " init; reset halt; flash erase_sector w25q80dv 0 0; flash erase_sector w25q80dv 16 112; exit; " # Step 2: 写入固件（注意：--offset指定从Flash起始地址写入） echo "=== Writing firmware to Flash ===" openocd -f interface/jlink.cfg -f target/ebmc.cfg -c " init; reset halt; flash write_image erase ebmc_firmware.bin 0x00000000; exit; " # Step 3: 全量校验（关键！） echo "=== Verifying firmware integrity ===" openocd -f interface/jlink.cfg -f target/ebmc.cfg -c " init; reset halt; verify_image ebmc_firmware.bin 0x00000000; exit; "

这里有个极易忽略的细节：flash write_image命令中的erase参数，它表示“写入前自动擦除”，但这个“自动擦除”是按页（Page，通常256B）进行的，而不是按扇区（Sector）。如果固件镜像跨越了扇区边界，而该扇区其他部分还有重要数据（如NV区紧邻Application区），erase参数可能导致误擦除。因此，我坚持手动擦除+手动写入的分离式操作，虽然脚本长一点，但可控性100%。

校验环节更是重中之重。verify_image命令会逐字节比对Flash中读出的数据和原始bin文件，一旦发现差异，立即报错。我曾在一个项目中，因Flash芯片批次差异，某颗芯片的写入时序需额外增加50ns延时，否则最后几个扇区写入失败。verify_image在第3次烧录时捕获到了这个差异，避免了不良品流入产线。

4.3 上电验证：从串口日志到IPMI连通

烧录完成后，断电等待10秒，然后接上串口线（波特率115200，8N1），再上电。理想情况下，你应该在1秒内看到如下启动日志：

[0.000000] EBMC Bootloader v2.1.0 [0.000123] SPI Flash: W25Q80DV (8MB), JEDEC ID: 0xEF4018 [0.000456] Loading Application from 0x00010000... [0.001234] Application CRC32: 0xABCDEF12 OK [0.002345] Jumping to Application...

如果卡在第一行，说明Bootloader本身损坏，需重烧Bootloader区；如果卡在第二行，说明SPI Flash通信失败，检查SCLK/CS/DO/DI线路焊接；如果卡在第三行，说明Application区Header校验失败，用dump_image导出Flash数据，用xxd对比原始bin文件，定位具体哪一字节出错。

当看到Jumping to Application...后，日志会切换为Linux内核启动信息：

[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.10.123 (builder@buildhost) ... [ 0.000000] CPU: ARMv8 Processor [410fd034] revision 4

此时，拔掉串口线，用网线将eBMC的管理网口（通常标为“BMC”或“MGMT”）接入局域网，执行：

ipmitool -I lanplus -H 192.168.1.100 -U ADMIN -P ADMIN chassis status

如果返回System Power : on，恭喜，eBMC已完全激活。此时，你已经拥有了这台服务器的“数字心脏”，后续的所有远程管理、固件升级、日志收集，都将基于此展开。

5. 常见问题与排查技巧实录：那些年我们追过的“黑屏”

5.1 问题速查表：症状、原因、解决方案

症状	可能原因	解决方案	我的实操心得
JTAG连接失败，OpenOCD报“JTAG scan chain interrogation failed”	1. TCK/TMS未上拉 2. JTAG线过长（>15cm）导致信号反射 3. eBMC芯片未上电（+3.3V_AUX=0V）	1. 用万用表测TCK/TMS对地电压，应为3.3V 2. 换用屏蔽双绞线，长度<10cm 3. 测eBMC芯片VCC引脚电压	我曾花两天排查这个问题，最后发现是JTAG适配器的TMS引脚虚焊，用热风枪重吹一遍就OK。记住：硬件问题永远排在第一位。
烧录成功，但上电后串口无任何输出	1. Mask ROM校验失败（Magic Number/CRC错误） 2. 供电纹波超标 3. 复位信号异常（POR未满足100μs低电平）	1. 用`dump_image`读取Flash前128字节，检查Magic和CRC 2. 示波器实测VCC纹波 3. 用逻辑分析仪抓POR信号	这是最常见的“假成功”现象。务必养成烧录后立即校验的习惯，不要等到上电才发现。
串口有输出，但卡在“Loading Application...”	1. Application区Header中Entry Point地址错误 2. Flash物理损坏（某扇区无法写入） 3. Secure Boot启用，但Signature无效	1. 检查Entry Point是否指向有效代码区 2. 对Application区执行`verify_image`，定位失败扇区 3. 临时禁用Secure Boot（需硬件跳线）	某次客户投诉，我们发现是Flash芯片在运输中受静电损伤，表面完好，但0x0002_0000扇区写入后读出全0xFF。更换Flash后解决。
IPMI命令超时，无法连接	1. eBMC网络配置未生效（DHCP未获取IP） 2. 管理网口PHY未初始化（时钟/复位异常） 3. 防火墙或ACL策略拦截	1. 串口登录后执行`ifconfig`查看IP 2. 查看内核日志`dmesg	grep phy`<br>3. 用`tcpdump -i eth0 icmp`抓包确认网络层连通性

5.2 独家避坑技巧：来自产线的血泪总结

技巧一：建立“黄金镜像”备份库
每次成功烧录并验证通过的固件，必须立即用dump_image导出一份完整Flash镜像，命名为ebmc_golden_v2.1.0_20240520.bin。这个镜像就是你的“后悔药”。当某台设备在现场出现无法解释的异常时，不用纠结原因，直接用JTAG把它刷回黄金镜像，90%的问题都能瞬间解决。我所在团队的产线，就有一个专门的NAS服务器，存放着过去三年所有版本的黄金镜像，按日期+版本号+芯片型号分类，查找起来非常方便。

技巧二：自制“电压纹波测试夹具”
买一个带AC耦合和20MHz带宽限制的示波器探头很贵，但我们可以用低成本方案替代：找一块FR4 PCB，蚀刻出T型分支，主路接eBMC VCC，分支一路接10uF钽电容到地，另一路接100nF陶瓷电容到地，最后在两个电容的接地端引出一根短线，焊上BNC接头。这样，你就能用普通示波器（哪怕只有100MHz带宽）准确测量纹波。这个夹具成本不到5元，但帮我们规避了数十次批量性烧录失败。

技巧三：善用“Bootloader Rescue Mode”
几乎所有eBMC芯片都内置一个Rescue Mode，当正常启动失败时，它会自动进入一个极简的命令行界面，只支持几个基础命令（如read_flash,write_flash,reset）。触发方式通常是：上电时按住某个特定GPIO（如GPIO_12）为低电平。这个模式不依赖Application固件，是真正的最后一道防线。我建议在每块主板的设计文档里，明确标注Rescue Mode的触发GPIO和操作步骤，并在产线工装上加装一个物理按键。去年某次大规模固件升级事故，就是靠这个Rescue Mode，在2小时内恢复了全部200台设备。

技巧四：记录每一次烧录的“指纹”
在烧录脚本末尾，自动执行：

echo "$(date): Burned $(sha256sum ebmc_firmware.bin | cut -d' ' -f1) to $(hostname)" >> /var/log/ebmc_burn.log

这样，每台设备的烧录时间、固件哈希、烧录机器名都被记录下来。当某台设备在未来出现安全漏洞时，你可以快速定位它使用的是哪个版本的固件，是否已打补丁，大大缩短应急响应时间。

6. 最后分享一个小技巧：如何用万用表快速判断烧录是否成功？

不用示波器，不用逻辑分析仪，就用你工具箱里最普通的DT830B万用表，也能做一个快速判断。方法如下：

将万用表调至二极管档（或蜂鸣档）；
黑表笔接地（eBMC芯片GND引脚），红表笔轻触eBMC芯片的SPI Flash的CS#引脚（通常为第1脚）；
正常烧录成功的eBMC，在上电后几毫秒内，CS#会由高电平（3.3V）被拉低（0V），然后周期性地在高低电平间切换（SPI通信时）；
用二极管档测量时，如果CS#被持续拉低，万用表会显示一个很小的电压（<0.3V），并可能发出蜂鸣声；如果CS#一直是高电平，显示“OL”（开路）；
如果上电后，CS#始终为高电平（显示“OL”），说明eBMC根本没有启动SPI通信，大概率是Bootloader未运行，需要重烧。

这个技巧的原理是：二极管档输出约0.4~0.7V的测试电压，当CS#被eBMC内部下拉晶体管拉低时，万用表检测到低阻通路，显示低电压；当CS#为高阻态（未启动）时，万用表测不到电流，显示“OL”。整个过程耗时不到5秒，是产线巡检的利器。我试过上百次，准确率超过95%。记住，这不是替代专业仪器的方法，而是给你一个“秒级反馈”，让你在第一时间知道，是不是该拿起JTAG线了。