尧图网站建设 
简介Mellanox Adapters Programmers Reference ManualPRM第4部分面向从事RDMA与高速网络开发的驱动工程师、固件开发者及底层协议研究人员用于查阅Mellanox网卡编程接口与寄存器级实现细节。资源为单个PDF文件压缩包约6.14MB内容聚焦扩展原子操作、WQE格式与RDMA写原子性等核心机制涵盖1字节与2字节原子操作的掩码规则、比较与交换、SWAP及取加操作的地址对齐方式并说明写操作与原子操作之间的原子性约束条件如接收QP需启用atomic-writes、写大小不得超过max_atomic_size配置等。已有44人学习适合需要深入理解硬件语义、排查原子操作异常或进行底层性能调优的开发者作为案头参考。1. Mellanox Adapters PRM 第 4 版一份让驱动工程师少走弯路的寄存器地图如果你正在给 ConnectX 系列网卡写驱动、做固件调试或者用 mlxlink 排查光模块链路问题迟早会撞上 PRM 这份文档。Mellanox Adapters Programmers Reference Manual 第 4 版本质上是 Mellanox现属 NVIDIA给 ConnectX 系列网卡公开的寄存器级编程手册——它把网卡的初始化流程、命令接口、队列布局、寄存器语义全部摊开写清楚。没有它你面对的就是一块黑匣子固件在跑什么、doorbell 该往哪写、CQ 的相位位怎么翻全靠猜。这份 PRM 解决的就是从硬件寄存器到驱动行为的映射问题适合驱动开发、固件验证、性能调优和底层排障的从业者。它不教你写业务代码但决定了你的代码能不能让硬件真正动起来。2. PRM 第 4 版到底覆盖了什么从 HCA 初始化到命令接口的完整链路2.1 先搞清楚 PRM 的文档结构和版本边界PRM 不是一本从头读到尾的书它更像一份分层索引。第 4 版主要围绕 ConnectX 系列含 ConnectX-4/5/6 等代际的 HCAHost Channel Adapter架构展开核心章节通常包括HCA 初始化与复位流程、Command Interface命令接口、Work Queue 与 Completion Queue 的内存布局、门铃寄存器Doorbell语义、以及各类硬件资源的管理规则。版本号这件事必须说清楚PRM 的版本和固件版本、驱动版本是三条独立的线。你手上的网卡固件可能是 16.x驱动是 MLNX_OFED 5.x而 PRM 是第 4 版——它们之间不是一一对应关系。常见做法是先确认你的芯片代号比如 ConnectX-5 是 MT27800 家族再去 PRM 里找对应章节。翻错代际的 PRM 是血泪经验里最常见的一种翻车寄存器偏移看着差不多语义已经变了。提示PRM 里每个寄存器描述都会标注适用的芯片型号和固件版本范围动手前先对一遍别默认第 4 版就是最新。2.2 HCA 初始化驱动加载时硬件到底经历了什么驱动加载的第一步不是直接发命令而是让 HCA 进入一个可编程状态。PRM 里描述的初始化链路大致是复位 → 等待固件就绪 → 读取 HCA 能力Capabilities→ 配置必要的全局寄存器 → 建立命令通道。这里最关键的是命令通道的建立。Mellanox 网卡用一套基于 doorbell 和共享内存的命令接口驱动把命令写进命令队列敲 doorbell固件处理后把结果写回。PRM 会明确告诉你命令队列的基地址寄存器、生产者索引Producer Index怎么递增、以及固件就绪标志位在哪个寄存器。下面是一段示意性的初始化检查逻辑用 Python 伪代码表达寄存器读取流程实际驱动里是 C但逻辑一致# 示意读取 HCA 固件就绪状态与能力位 # 实际寄存器地址以 PRM 对应芯片章节为准此处为逻辑演示 HCA_FW_READY_OFFSET 0x0 # 占位真实偏移查 PRM HCA_CAP_OFFSET 0x4 # 占位 def wait_fw_ready(bar0): 轮询固件就绪位超时则报错 timeout 1000 while timeout 0: val read_reg(bar0, HCA_FW_READY_OFFSET) if val 0x1: # bit0 表示固件就绪 return True timeout - 1 sleep_ms(1) raise RuntimeError(固件未就绪检查复位流程或固件版本) def read_capabilities(bar0): 读取能力寄存器决定后续支持哪些特性 cap read_reg(bar0, HCA_CAP_OFFSET) # 按 PRM 定义的位域解析比如是否支持某些队列类型 return parse_cap_bits(cap)逻辑说明先轮询就绪位而不是盲目发命令是因为固件加载有延迟抢跑会拿到全 0 或垃圾值。参数说明timeout的取值要看你的硬件启动时间冷启动通常比热复位慢HCA_FW_READY_OFFSET这类偏移必须从 PRM 对应芯片章节抄不能跨代际套用。2.3 命令接口驱动和固件之间的协议栈命令接口是 PRM 里最厚的一块。它定义了命令的输入/输出邮箱Mailbox格式、命令操作码Opcode、以及同步/异步两种执行模式。同步命令发出去后驱动阻塞等结果异步命令则通过事件队列EQ通知完成。一个典型的命令交互长这样驱动在邮箱里填好输入参数 → 写命令寄存器触发 → 固件执行 → 结果写回输出邮箱 → 驱动读状态位判断成功失败。PRM 会给出每个 Opcode 的邮箱布局哪个偏移放什么字段、字段多少位、保留位必须写 0 还是写 1都有明确规定。我一般会建议先把QUERY_DEV_CAP查询设备能力和QUERY_ADAPTER查询适配器信息这两个命令跑通它们是后续所有操作的基础。跑通这两个说明你的命令通道、邮箱读写、doorbell 触发都是对的。注意保留位Reserved的处理是高频翻车点。PRM 说必须写 0你就写 0说忽略你也最好写 0别留随机值否则固件行为可能不符合预期。3. 用 mlxlink 和寄存器视角做链路诊断把 PRM 知识落到排障现场3.1 mlxlink 的 -m 和 -c 参数在诊断什么mlxlink 是 Mellanox 网卡运维里出场率极高的工具专门看光模块和线缆状态。它的-m参数读的是模块信息Module Info-c读的是线缆/链路状态Cable/Link。这两个参数背后其实就是驱动通过命令接口去问固件要数据而固件的数据来源又和 PRM 里描述的寄存器、模块 EEPROM 读取流程相关。# 查看指定网卡的光模块信息 mlxlink -d mlx5_0 -m # 查看链路和线缆诊断状态 mlxlink -d mlx5_0 -c # 带端口号指定多端口网卡 mlxlink -d mlx5_0 -p 1 -m逻辑说明-d指定设备名如 mlx5_0-m输出模块的厂商、型号、温度、电压、光功率等-c输出链路速率、FEC 状态、误码计数等。参数说明多端口卡必须用-p指定端口否则可能读到错误端口的数据。当你看到模块温度异常或光功率超范围问题往往在物理层不在驱动。3.2 从 PRM 视角理解 mlxlink 读到的数据从哪来mlxlink 显示的温度、电压、光功率来自光模块内部的 EEPROM 和诊断监控接口DDM。驱动读取这些数据的路径是发命令给固件 → 固件通过 I2C 访问模块 → 数据回传。PRM 里会描述固件如何管理这些低速接口以及相关状态寄存器在哪。理解这一层的好处是当 mlxlink 报模块读取失败时你能判断是 I2C 链路问题、模块本身问题还是固件/驱动没把命令通道建好。如果命令通道都没通mlxlink 大概率直接报设备不可用而不是模块数据异常。3.3 一个真实的排查顺序链路起不来先看哪三层链路起不来我一般按三层排查物理层模块、线缆、光功率→ 固件/配置层速率、FEC、端口模式→ 驱动层命令通道、队列。# 第一层物理层看模块和链路状态 mlxlink -d mlx5_0 -m mlxlink -d mlx5_0 -c # 第二层固件和配置看端口速率和 FEC mlxconfig -d mlx5_0 query | grep -i -E LINK_TYPE|FEC # 第三层驱动层看设备是否正常枚举 lspci | grep -i mellanox ibv_devinfo -d mlx5_0逻辑说明先确认物理层有没有信号再看配置是否匹配对端最后确认驱动把设备管起来了。参数说明mlxconfig的query是只读改配置要用set并重启才生效ibv_devinfo看的是 RDMA 设备状态端口 state 不是 ACTIVE 就要往回查。提示mlxlink 的-c里如果有 FEC 相关计数在涨别急着换模块先确认两端 FEC 模式是否一致这是玄学问题的高发区。4. 避坑与排查PRM 落地时最容易翻车的五个地方4.1 现象命令发出去没反应状态位一直是 pending原因doorbell 写错了地址或写错了值。PRM 里 doorbell 通常要求写生产者索引的低位且不同队列类型的 doorbell 偏移不同。另一个常见原因是命令队列的内存没有按 PRM 要求对齐。解决对照 PRM 确认 doorbell 寄存器偏移和写入格式检查队列内存的对齐要求常见是 4KB 或按队列条目大小对齐。用读回寄存器的方式验证你写的值确实生效了。4.2 现象CQ 轮询拿不到完成事件或者拿到重复事件原因Completion Queue 的相位位Phase Bit翻转逻辑搞错了。PRM 里 CQ 条目有一个 ownership/phase 位驱动靠它判断这个条目是新的还是旧的。翻转时机错了就会漏事件或重复处理。解决严格按 PRM 描述的相位翻转规则实现通常是在消费者索引回绕时翻转。调试时打印每次轮询的相位位和索引对照 PRM 的时序图核对。4.3 现象换了一块不同代际的网卡同样的寄存器偏移读出垃圾值原因跨代际套用寄存器偏移。ConnectX-4 和 ConnectX-5 的部分寄存器布局有差异PRM 第 4 版虽然覆盖多代但每代都有独立章节。解决按芯片代号查对应章节别用我记得上次是 0x…这种经验主义。把芯片代号和 PRM 章节的对应关系记在代码注释里。4.4 现象mlxlink 能读到模块但链路始终不 up原因速率或 FEC 配置不匹配或者端口模式如以太网 vs InfiniBand设错了。这类问题不在物理层mlxlink 的模块信息会显示正常。解决用mlxconfig query确认端口配置和对端对齐速率、FEC、协议模式。改完配置需要冷重启断电重启不是 reboot才生效这一点很多人踩过。4.5 现象驱动加载时报资源不足或队列创建失败原因队列数量或深度超过了固件允许的上限或者没有先查询设备能力就盲目申请。解决先发QUERY_DEV_CAP拿到实际支持的最大队列数和深度再按这个上限往下配。PRM 里会说明哪些资源是固件预分配的哪些是动态申请的。5. 进阶用 PRM 做寄存器级验证和性能调优的一个具体手法当你把基本流程跑通后PRM 真正的价值在于做寄存器级验证和性能调优。我常用的一个手法是针对某个关键路径比如发送队列的 doorbell 触发用读回寄存器的方式做闭环验证确认驱动写的值和硬件实际收到的值一致。具体做法是在驱动里加一个调试钩子每次写 doorbell 后通过调试接口读回对应的生产者索引寄存器比对两者。如果读回值和你写的不一致说明要么写错了地址要么硬件没接受这次写。这个手法在排查命令偶发丢失这类玄学问题时特别有效。# 用 mft 工具做寄存器读写验证需安装 MFT # 读回某个寄存器确认驱动写入是否生效 mstregdump -d /dev/mst/mt4119_pciconf0 --reg_name 寄存器名 # 或者用 mcra 读、mcwa 写具体寄存器名查 PRM mcra -d /dev/mst/mt4119_pciconf0 寄存器地址逻辑说明mstregdump能 dump 一批寄存器适合做快照对比mcra/mcwa是单寄存器读写适合精确验证。参数说明设备路径/dev/mst/...里的芯片代号要和你的卡对上寄存器地址必须从 PRM 对应章节取。另一个进阶方向是性能调优PRM 里会描述中断合并Interrupt Moderation、队列深度、以及 doorbell 批处理相关的寄存器。调整这些参数能影响吞吐和延迟的平衡。我的习惯是先用默认配置跑基线再针对瓶颈路径调一两个参数每次只改一个改完立刻测别一次改一堆——否则出了问题你根本不知道是哪个参数导致的。调优时还要注意PRM 里有些寄存器是写一次生效直到下次复位有些是每次操作都要重写搞混了会出现改了没效果或效果时有时无的情况。这类细节 PRM 都写了但很容易被跳过。最后说个我自己的教训刚接触 PRM 时总想一口气把整本读完再动手结果读了三章就迷失在寄存器海洋里。后来改成带着一个具体问题去查对应章节效率高得多。PRM 是工具书不是教材用它的时候目标越具体收获越大。希望帮到你。本文还有配套的精品资源点击获取 Mellanox Adapters PRM 第4版：ConnectX网卡驱动开发与寄存器编程实战指南
简介Mellanox Adapters Programmers Reference ManualPRM第4部分面向从事RDMA与高速网络开发的驱动工程师、固件开发者及底层协议研究人员用于查阅Mellanox网卡编程接口与寄存器级实现细节。资源为单个PDF文件压缩包约6.14MB内容聚焦扩展原子操作、WQE格式与RDMA写原子性等核心机制涵盖1字节与2字节原子操作的掩码规则、比较与交换、SWAP及取加操作的地址对齐方式并说明写操作与原子操作之间的原子性约束条件如接收QP需启用atomic-writes、写大小不得超过max_atomic_size配置等。已有44人学习适合需要深入理解硬件语义、排查原子操作异常或进行底层性能调优的开发者作为案头参考。1. Mellanox Adapters PRM 第 4 版一份让驱动工程师少走弯路的寄存器地图如果你正在给 ConnectX 系列网卡写驱动、做固件调试或者用 mlxlink 排查光模块链路问题迟早会撞上 PRM 这份文档。Mellanox Adapters Programmers Reference Manual 第 4 版本质上是 Mellanox现属 NVIDIA给 ConnectX 系列网卡公开的寄存器级编程手册——它把网卡的初始化流程、命令接口、队列布局、寄存器语义全部摊开写清楚。没有它你面对的就是一块黑匣子固件在跑什么、doorbell 该往哪写、CQ 的相位位怎么翻全靠猜。这份 PRM 解决的就是从硬件寄存器到驱动行为的映射问题适合驱动开发、固件验证、性能调优和底层排障的从业者。它不教你写业务代码但决定了你的代码能不能让硬件真正动起来。2. PRM 第 4 版到底覆盖了什么从 HCA 初始化到命令接口的完整链路2.1 先搞清楚 PRM 的文档结构和版本边界PRM 不是一本从头读到尾的书它更像一份分层索引。第 4 版主要围绕 ConnectX 系列含 ConnectX-4/5/6 等代际的 HCAHost Channel Adapter架构展开核心章节通常包括HCA 初始化与复位流程、Command Interface命令接口、Work Queue 与 Completion Queue 的内存布局、门铃寄存器Doorbell语义、以及各类硬件资源的管理规则。版本号这件事必须说清楚PRM 的版本和固件版本、驱动版本是三条独立的线。你手上的网卡固件可能是 16.x驱动是 MLNX_OFED 5.x而 PRM 是第 4 版——它们之间不是一一对应关系。常见做法是先确认你的芯片代号比如 ConnectX-5 是 MT27800 家族再去 PRM 里找对应章节。翻错代际的 PRM 是血泪经验里最常见的一种翻车寄存器偏移看着差不多语义已经变了。提示PRM 里每个寄存器描述都会标注适用的芯片型号和固件版本范围动手前先对一遍别默认第 4 版就是最新。2.2 HCA 初始化驱动加载时硬件到底经历了什么驱动加载的第一步不是直接发命令而是让 HCA 进入一个可编程状态。PRM 里描述的初始化链路大致是复位 → 等待固件就绪 → 读取 HCA 能力Capabilities→ 配置必要的全局寄存器 → 建立命令通道。这里最关键的是命令通道的建立。Mellanox 网卡用一套基于 doorbell 和共享内存的命令接口驱动把命令写进命令队列敲 doorbell固件处理后把结果写回。PRM 会明确告诉你命令队列的基地址寄存器、生产者索引Producer Index怎么递增、以及固件就绪标志位在哪个寄存器。下面是一段示意性的初始化检查逻辑用 Python 伪代码表达寄存器读取流程实际驱动里是 C但逻辑一致# 示意读取 HCA 固件就绪状态与能力位 # 实际寄存器地址以 PRM 对应芯片章节为准此处为逻辑演示 HCA_FW_READY_OFFSET 0x0 # 占位真实偏移查 PRM HCA_CAP_OFFSET 0x4 # 占位 def wait_fw_ready(bar0): 轮询固件就绪位超时则报错 timeout 1000 while timeout 0: val read_reg(bar0, HCA_FW_READY_OFFSET) if val 0x1: # bit0 表示固件就绪 return True timeout - 1 sleep_ms(1) raise RuntimeError(固件未就绪检查复位流程或固件版本) def read_capabilities(bar0): 读取能力寄存器决定后续支持哪些特性 cap read_reg(bar0, HCA_CAP_OFFSET) # 按 PRM 定义的位域解析比如是否支持某些队列类型 return parse_cap_bits(cap)逻辑说明先轮询就绪位而不是盲目发命令是因为固件加载有延迟抢跑会拿到全 0 或垃圾值。参数说明timeout的取值要看你的硬件启动时间冷启动通常比热复位慢HCA_FW_READY_OFFSET这类偏移必须从 PRM 对应芯片章节抄不能跨代际套用。2.3 命令接口驱动和固件之间的协议栈命令接口是 PRM 里最厚的一块。它定义了命令的输入/输出邮箱Mailbox格式、命令操作码Opcode、以及同步/异步两种执行模式。同步命令发出去后驱动阻塞等结果异步命令则通过事件队列EQ通知完成。一个典型的命令交互长这样驱动在邮箱里填好输入参数 → 写命令寄存器触发 → 固件执行 → 结果写回输出邮箱 → 驱动读状态位判断成功失败。PRM 会给出每个 Opcode 的邮箱布局哪个偏移放什么字段、字段多少位、保留位必须写 0 还是写 1都有明确规定。我一般会建议先把QUERY_DEV_CAP查询设备能力和QUERY_ADAPTER查询适配器信息这两个命令跑通它们是后续所有操作的基础。跑通这两个说明你的命令通道、邮箱读写、doorbell 触发都是对的。注意保留位Reserved的处理是高频翻车点。PRM 说必须写 0你就写 0说忽略你也最好写 0别留随机值否则固件行为可能不符合预期。3. 用 mlxlink 和寄存器视角做链路诊断把 PRM 知识落到排障现场3.1 mlxlink 的 -m 和 -c 参数在诊断什么mlxlink 是 Mellanox 网卡运维里出场率极高的工具专门看光模块和线缆状态。它的-m参数读的是模块信息Module Info-c读的是线缆/链路状态Cable/Link。这两个参数背后其实就是驱动通过命令接口去问固件要数据而固件的数据来源又和 PRM 里描述的寄存器、模块 EEPROM 读取流程相关。# 查看指定网卡的光模块信息 mlxlink -d mlx5_0 -m # 查看链路和线缆诊断状态 mlxlink -d mlx5_0 -c # 带端口号指定多端口网卡 mlxlink -d mlx5_0 -p 1 -m逻辑说明-d指定设备名如 mlx5_0-m输出模块的厂商、型号、温度、电压、光功率等-c输出链路速率、FEC 状态、误码计数等。参数说明多端口卡必须用-p指定端口否则可能读到错误端口的数据。当你看到模块温度异常或光功率超范围问题往往在物理层不在驱动。3.2 从 PRM 视角理解 mlxlink 读到的数据从哪来mlxlink 显示的温度、电压、光功率来自光模块内部的 EEPROM 和诊断监控接口DDM。驱动读取这些数据的路径是发命令给固件 → 固件通过 I2C 访问模块 → 数据回传。PRM 里会描述固件如何管理这些低速接口以及相关状态寄存器在哪。理解这一层的好处是当 mlxlink 报模块读取失败时你能判断是 I2C 链路问题、模块本身问题还是固件/驱动没把命令通道建好。如果命令通道都没通mlxlink 大概率直接报设备不可用而不是模块数据异常。3.3 一个真实的排查顺序链路起不来先看哪三层链路起不来我一般按三层排查物理层模块、线缆、光功率→ 固件/配置层速率、FEC、端口模式→ 驱动层命令通道、队列。# 第一层物理层看模块和链路状态 mlxlink -d mlx5_0 -m mlxlink -d mlx5_0 -c # 第二层固件和配置看端口速率和 FEC mlxconfig -d mlx5_0 query | grep -i -E LINK_TYPE|FEC # 第三层驱动层看设备是否正常枚举 lspci | grep -i mellanox ibv_devinfo -d mlx5_0逻辑说明先确认物理层有没有信号再看配置是否匹配对端最后确认驱动把设备管起来了。参数说明mlxconfig的query是只读改配置要用set并重启才生效ibv_devinfo看的是 RDMA 设备状态端口 state 不是 ACTIVE 就要往回查。提示mlxlink 的-c里如果有 FEC 相关计数在涨别急着换模块先确认两端 FEC 模式是否一致这是玄学问题的高发区。4. 避坑与排查PRM 落地时最容易翻车的五个地方4.1 现象命令发出去没反应状态位一直是 pending原因doorbell 写错了地址或写错了值。PRM 里 doorbell 通常要求写生产者索引的低位且不同队列类型的 doorbell 偏移不同。另一个常见原因是命令队列的内存没有按 PRM 要求对齐。解决对照 PRM 确认 doorbell 寄存器偏移和写入格式检查队列内存的对齐要求常见是 4KB 或按队列条目大小对齐。用读回寄存器的方式验证你写的值确实生效了。4.2 现象CQ 轮询拿不到完成事件或者拿到重复事件原因Completion Queue 的相位位Phase Bit翻转逻辑搞错了。PRM 里 CQ 条目有一个 ownership/phase 位驱动靠它判断这个条目是新的还是旧的。翻转时机错了就会漏事件或重复处理。解决严格按 PRM 描述的相位翻转规则实现通常是在消费者索引回绕时翻转。调试时打印每次轮询的相位位和索引对照 PRM 的时序图核对。4.3 现象换了一块不同代际的网卡同样的寄存器偏移读出垃圾值原因跨代际套用寄存器偏移。ConnectX-4 和 ConnectX-5 的部分寄存器布局有差异PRM 第 4 版虽然覆盖多代但每代都有独立章节。解决按芯片代号查对应章节别用我记得上次是 0x…这种经验主义。把芯片代号和 PRM 章节的对应关系记在代码注释里。4.4 现象mlxlink 能读到模块但链路始终不 up原因速率或 FEC 配置不匹配或者端口模式如以太网 vs InfiniBand设错了。这类问题不在物理层mlxlink 的模块信息会显示正常。解决用mlxconfig query确认端口配置和对端对齐速率、FEC、协议模式。改完配置需要冷重启断电重启不是 reboot才生效这一点很多人踩过。4.5 现象驱动加载时报资源不足或队列创建失败原因队列数量或深度超过了固件允许的上限或者没有先查询设备能力就盲目申请。解决先发QUERY_DEV_CAP拿到实际支持的最大队列数和深度再按这个上限往下配。PRM 里会说明哪些资源是固件预分配的哪些是动态申请的。5. 进阶用 PRM 做寄存器级验证和性能调优的一个具体手法当你把基本流程跑通后PRM 真正的价值在于做寄存器级验证和性能调优。我常用的一个手法是针对某个关键路径比如发送队列的 doorbell 触发用读回寄存器的方式做闭环验证确认驱动写的值和硬件实际收到的值一致。具体做法是在驱动里加一个调试钩子每次写 doorbell 后通过调试接口读回对应的生产者索引寄存器比对两者。如果读回值和你写的不一致说明要么写错了地址要么硬件没接受这次写。这个手法在排查命令偶发丢失这类玄学问题时特别有效。# 用 mft 工具做寄存器读写验证需安装 MFT # 读回某个寄存器确认驱动写入是否生效 mstregdump -d /dev/mst/mt4119_pciconf0 --reg_name 寄存器名 # 或者用 mcra 读、mcwa 写具体寄存器名查 PRM mcra -d /dev/mst/mt4119_pciconf0 寄存器地址逻辑说明mstregdump能 dump 一批寄存器适合做快照对比mcra/mcwa是单寄存器读写适合精确验证。参数说明设备路径/dev/mst/...里的芯片代号要和你的卡对上寄存器地址必须从 PRM 对应章节取。另一个进阶方向是性能调优PRM 里会描述中断合并Interrupt Moderation、队列深度、以及 doorbell 批处理相关的寄存器。调整这些参数能影响吞吐和延迟的平衡。我的习惯是先用默认配置跑基线再针对瓶颈路径调一两个参数每次只改一个改完立刻测别一次改一堆——否则出了问题你根本不知道是哪个参数导致的。调优时还要注意PRM 里有些寄存器是写一次生效直到下次复位有些是每次操作都要重写搞混了会出现改了没效果或效果时有时无的情况。这类细节 PRM 都写了但很容易被跳过。最后说个我自己的教训刚接触 PRM 时总想一口气把整本读完再动手结果读了三章就迷失在寄存器海洋里。后来改成带着一个具体问题去查对应章节效率高得多。PRM 是工具书不是教材用它的时候目标越具体收获越大。希望帮到你。本文还有配套的精品资源点击获取