1. 为什么裸机启动不是“写个main函数就完事”——RISC-V启动流程的底层契约

很多人第一次接触RISC-V裸机开发时，会下意识地把“启动”理解成：烧录一段汇编初始化栈指针，跳转到C语言的main()，然后开始点灯、串口打印。这种理解在功能层面看似成立，但一旦遇到程序跑飞、中断不响应、内存访问异常，或者换了一颗同系列但不同厂商的芯片就完全无法启动，就会陷入“代码没改，环境变了，怎么就不行了”的困惑。我带过几个刚从ARM Cortex-M转过来的开发者，他们第一反应都是照搬CMSIS启动文件结构，结果在某款RISC-V SoC上卡死在第一条指令——不是代码错了，是根本没理解RISC-V启动流程背后那套硬件-固件-软件三方共同遵守的隐式契约。

这个契约的核心，是RISC-V架构定义的复位向量（Reset Vector）行为与机器模式（Machine Mode）初始状态的强约束。它不像x86有BIOS/UEFI层做大量兜底，也不像ARM Cortex-M默认提供NVIC和SysTick的预配置；RISC-V的裸机世界里，CPU上电后只做最精简的事：清空所有寄存器（除mstatus、mepc等少数几个被明确保留外），将pc强制跳转到一个固定地址（通常是0x00000000或0x10000000，取决于reset_addr配置），然后——就没了。后续所有工作：栈初始化、全局变量清零（.bss段）、.data段拷贝、中断向量表安置、mstatus寄存器使能中断、mtvec设置异常入口——全部由你写的启动代码一肩挑起。没有“默认”，只有“必须”。

这直接导致一个关键事实：RISC-V裸机项目的可移植性，90%取决于启动代码对目标SoC启动要求的精准适配，而非应用逻辑本身。某高校实验室曾用同一份FreeRTOS移植代码，在三款标称“兼容RV32IMAC”的芯片上测试，两款顺利运行，第三款在xTaskCreate调用时崩溃。最终定位到：该芯片的ROM Bootloader在跳转到用户代码前，未正确设置mstatus.MIE位（机器模式中断使能），而另外两款芯片的Bootloader做了此操作。这意味着，你的启动代码必须主动检查并显式置位MIE，否则哪怕中断服务函数写得再完美，硬件也永远不会触发它。这不是bug，是RISC-V生态中“裸机即契约”的典型体现。

提示：RISC-V的mstatus寄存器中，MIE（Machine Interrupt Enable）位控制整个机器模式下的中断全局开关。它与mie（Machine Interrupt Enable register）中的具体中断使能位是两级关系——MIE=0时，无论mie如何设置，所有中断均被屏蔽。这是绝大多数初学者踩坑的第一道坎。

所以，当我们说“【risc-v专栏 07】启动与 bare-metal 流程”时，我们讨论的绝非一个技术步骤清单，而是一套需要你亲手签署、逐字校验、动态维护的硬件交互协议。它决定了你的代码能否被CPU真正“看见”，也决定了后续所有高级功能（如中断、定时器、DMA）能否获得执行资格。接下来，我们将拆解这套协议的四个核心支柱：复位向量的物理落点、机器模式的初始寄存器状态、链接脚本如何映射硬件内存布局、以及中断向量表的两种部署范式。

2. 复位向量不是地址常量，而是SoC设计者的“门禁密码”

在ARM Cortex-M中，复位向量是向量表（Vector Table）的第一个条目，其地址由SCB->VTOR寄存器决定，通常默认为Flash起始地址。而在RISC-V中，“复位向量”这个概念更接近于一个硬件硬编码的跳转目标。根据RISC-V Privileged Architecture Spec，当处理器复位时，pc会被强制设置为reset_addr，而这个reset_addr的值并非由ISA标准统一规定，而是由具体SoC的设计者在芯片流片时固化在硬件中的。这就意味着，同一个RISC-V内核IP（比如SiFive U54），用在A公司SoC和B公司SoC上，其复位地址可能完全不同。

我参与过一个跨平台固件迁移项目，目标是将某款国产RISC-V MCU的Bootloader移植到另一款FPGA软核平台上。原MCU的复位地址是0x20000000（片上SRAM起始），而FPGA软核的复位地址被配置为0x00001000（Boot ROM末尾）。如果直接烧录原二进制，CPU上电后会从0x20000000取指令，但该地址在FPGA上是未映射的无效空间，结果就是总线错误（Bus Error），mcause寄存器报告异常码7（Store/AMO access fault），程序彻底静默。解决方法不是改代码，而是修改FPGA的顶层配置，将reset_addr重新绑定到0x20000000，并确保该地址空间在FPGA中确实挂载了有效的RAM块。

这个案例揭示了一个残酷现实：RISC-V裸机开发的第一步，永远不是写代码，而是读SoC的手册，找到那个被加粗标红的“Reset Vector Address”章节。它通常藏在“Memory Map”或“System Control”部分，表述可能五花八门：“Initial PC Value”、“Hard Reset Entry Point”、“Boot Address after Power-on Reset”。你需要做的，是把这个十六进制地址，精确无误地注入到你的构建流程中。常见注入方式有三种：

1. 链接脚本（Linker Script）指定入口点（ENTRY）：这是最主流、最可控的方式。在link.ld中，ENTRY(_start)声明入口符号，而_start标签所在的代码段，必须被链接器放置在reset_addr处。这要求你在.text段定义时，使用> REGION_NAME AT (reset_addr)语法强制定位。例如：

   MEMORY { RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } SECTIONS { . = 0x20000000; /* 强制.text段起始地址为复位向量 */ .text : { *(.text.entry) /* 放置_start所在段 */ *(.text) } > RAM }

   这里0x20000000就是你从手册里查到的reset_addr。链接器会确保生成的二进制文件，其第一个字节就对应_start的机器码。

2. 汇编启动文件中硬编码跳转：某些极简场景（如纯汇编Demo），会在_start开头写一条j reset_handler，而reset_handler的地址则通过.org伪指令硬编码。例如：

   .section .text .org 0x20000000 _start: # 初始化代码

   这种方式简单粗暴，但可维护性差，一旦reset_addr变更，必须手动修改.org值。

3. 工具链参数传递：GCC的-Ttext-section-lma=0x20000000或-Wl,-Ttext=0x20000000可以覆盖链接脚本中的默认.text地址。但这种方式容易与链接脚本冲突，调试困难，不推荐在正式项目中使用。

注意：reset_addr不仅决定代码从哪里开始执行，还决定了CPU首次取指的物理地址空间属性。如果该地址映射的是只读Flash，那么你试图在_start中执行sw（store word）指令修改自身代码，必然触发存储访问异常。因此，reset_addr通常指向可执行且可写（XW）的内存区域，如SRAM或带MMU/MPU配置后的RAM镜像区。

3. 机器模式（M-Mode）的初始状态：一张必须亲手填写的“空白答卷”

当CPU从reset_addr开始执行第一条指令时，它已处于RISC-V特权架构定义的最高权限级别——机器模式（Machine Mode, M-Mode）。这是RISC-V裸机世界的“上帝视角”，没有任何操作系统或hypervisor为你遮风挡雨。此时，所有与系统控制相关的CSR（Control and Status Register）都处于一个明确定义但极度“干净”的初始状态。理解这些CSR的复位值，是你编写可靠启动代码的基石。它们不是可选项，而是你必须主动“填写”的答卷。

最关键的三个CSR及其复位行为如下：

我曾在一个基于GD32VF103（RISC-V内核）的项目中，因疏忽未在_start末尾设置mtvec，导致串口中断服务函数注册后，UART接收数据时CPU跳转到0x0执行，而该地址存放的是0x00000000（unimp指令），从而触发非法指令异常，mcause=2。调试时发现mtvec寄存器值仍为0，才恍然大悟。

因此，一个健壮的_start汇编片段，其核心骨架必须包含对这三个CSR的显式初始化：

.section .text.entry .global _start _start: # 1. 初始化栈指针（SP） la sp, stack_top # 2. 清零.bss段（由链接脚本定义的_start_bss和_end_bss） la a0, _start_bss la a1, _end_bss bgeu a0, a1, bss_clear_done bss_clear_loop: li a2, 0 sw a2, 0(a0) addi a0, a0, 4 bltu a0, a1, bss_clear_loop bss_clear_done: # 3. 拷贝.data段（从flash到ram） # ... (此处省略具体拷贝逻辑) # 4. 设置mtvec为中断向量表起始地址 la t0, exception_vector_table csrw mtvec, t0 # 5. 设置mepc为main函数入口 la t0, main csrw mepc, t0 # 6. 配置mstatus：使能M-Mode中断(MIE)，设置MPP为M-Mode(11) li t0, 0x80000000 # MIE bit li t1, 0x00000018 # MPP=11 (M-Mode) in bits 12:11 or t0, t0, t1 csrw mstatus, t0 # 7. 跳转到main jalr zero, t0, 0

这段代码的每一行，都是对硬件复位状态的一次主动“覆盖”。它不是在“配置”系统，而是在“重建”一个符合你预期的运行环境。其中，mtvec的设置尤为关键，它引出了下一个核心主题：中断向量表的部署策略。

4. 中断向量表：静态驻留 vs 动态重定向——两种生存哲学

RISC-V的mtvec寄存器决定了当任何中断或异常发生时，CPU将跳转到哪个地址去执行处理代码。这个地址所指向的数据结构，就是中断向量表（Interrupt Vector Table）。与ARM Cortex-M的固定8字节/条目、必须位于RAM起始的向量表不同，RISC-V的向量表格式更灵活，但也带来了更大的设计自由度与责任。目前业界主流采用两种部署范式，它们代表了两种截然不同的工程哲学。

4.1 静态驻留向量表（Static Vector Table）

这是最直观、最接近传统MCU思维的方案。你预先在代码中定义一个数组，每个元素是一个jalr（Jump and Link Register）指令，直接跳转到对应的中断服务函数（ISR）。这个数组的起始地址，就是mtvec的值。

.section .text.vectors .global exception_vector_table exception_vector_table: # 0: Machine Trap Vector (for all exceptions/interrupts) # 使用"direct"模式，每个向量占4字节，直接是跳转指令 jalr zero, handler_mtrap, 0 # 所有异常共用一个入口 # 1: Reserved jalr zero, handler_mtrap, 0 # 2: Reserved jalr zero, handler_mtrap, 0 # ... 依此类推，填满所有可能的向量索引

优势：实现简单，启动快，代码体积小。对于资源极度受限、中断源极少的场景（如仅需一个定时器中断的传感器节点），这是最优解。

劣势：极度缺乏扩展性。RISC-V的mtvec支持两种模式：direct（单入口）和vectored（多入口）。direct模式下，所有中断都跳转到同一个入口，你必须在入口函数中读取mcause和mtval寄存器，再手动switch-case分发到具体ISR，这引入了额外的分支开销。而vectored模式要求向量表中每个条目必须是一个完整的、可执行的跳转指令，且向量索引必须与mcause的低几位严格对应。这意味着，如果你新增一个外设中断，就必须修改向量表数组，并确保其大小和对齐满足mtvec的要求（通常要求4字节对齐）。在大型项目中，这极易出错。

4.2 动态重定向向量表（Dynamic Redirect Vector Table）

这是一种更现代、更工程化的方案，其核心思想是：向量表本身只存放一个通用的“跳板”（trampoline），真正的ISR地址由软件在运行时动态写入一个独立的、可读写的向量地址数组中。mtvec指向这个跳板，而跳板代码则根据mcause的值，从那个动态数组中读取真实的函数地址并跳转。

# 跳板代码（固定位置，由mtvec指向） .section .text.trampoline .global trampoline_entry trampoline_entry: # 保存必要的寄存器（a0-a7, s0-s11等） # 读取mcause寄存器，获取异常/中断类型 csrr a0, mcause # 提取低2位（用于索引），或更高位（用于区分中断/异常） andi a0, a0, 0x3 # 计算动态向量数组中对应条目的地址 la a1, dynamic_vector_table slli a2, a0, 2 # a0 * 4 (每个地址4字节) add a1, a1, a2 # 从动态数组中加载真实ISR地址 lw a2, 0(a1) # 跳转到真实ISR jr a2 # 动态向量数组（位于RAM中，可读写） .section .data.vector_table .global dynamic_vector_table dynamic_vector_table: .word handler_mtrap .word handler_timer .word handler_uart_rx .word handler_gpio

优势：极致的灵活性与可维护性。添加新中断只需在dynamic_vector_table数组中增加一行.word，无需触碰汇编跳板代码。你可以轻松实现中断优先级管理、运行时中断使能/禁用、甚至热插拔设备的中断注册。这对于需要支持多种外设、未来可能升级固件的工业控制器或网关设备，是唯一可行的方案。

劣势：启动代码稍复杂，需要在main()之前完成dynamic_vector_table的初始化（通常是memset清零，再逐个memcpy赋值），且每次中断都会多一次内存读取和间接跳转，带来微小的性能开销（通常在10-20个周期内，对大多数应用可忽略）。

提示：选择哪种范式，不应由个人喜好决定，而应由你的SoC硬件特性和项目需求决定。如果SoC手册明确说明其mtvec仅支持direct模式，或你的RAM空间紧张到连一个32字节的向量数组都放不下，那就必须用静态方案。反之，如果项目需要长期演进、支持OTA升级，动态方案是值得投入的基础设施。

5. 链接脚本：裸机世界的“宪法”，定义一切内存的归属

如果说启动代码是裸机世界的“政府首脑”，那么链接脚本（Linker Script）就是它的“宪法”。它以一种近乎冷酷的精确性，规定了.text（代码）、.rodata（只读数据）、.data（已初始化数据）、.bss（未初始化数据）等所有段（Section）在最终二进制文件中的布局，以及它们在目标硬件内存空间中的绝对地址（Load Memory Address, LMA）和运行时地址（Virtual Memory Address, VMA）。在RISC-V裸机开发中，一个错误的链接脚本，足以让最完美的C代码变成一堆无法执行的乱码。

其核心矛盾在于：代码通常存储在非易失性的Flash中，但CPU执行时，需要将.data段从Flash拷贝到RAM中，同时将.bss段在RAM中清零。链接脚本必须清晰地告诉链接器：.data段的LMA（在Flash中的位置）和VMA（在RAM中的位置）是不同的，而.bss段只有VMA（因为它在Flash中不占空间，只在RAM中存在）。

一个典型的、为RISC-V SoC定制的链接脚本link.ld结构如下：

/* 定义内存区域 */ MEMORY { /* Flash区域，用于存放代码和常量 */ FLASH (rx) : ORIGIN = 0x00010000, LENGTH = 512K /* RAM区域，用于运行时数据和堆栈 */ RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } /* 定义入口点 */ ENTRY(_start) SECTIONS { /* .text段：代码，必须放在reset_addr处 */ . = 0x00010000; /* 与FLASH ORIGIN一致，也是常见的reset_addr */ .text : { *(.text.entry) /* _start必须放在这里 */ *(.text) *(.rodata) . = ALIGN(4); _etext = .; /* 标记.text结束地址 */ } > FLASH /* .data段：已初始化数据，LMA在FLASH，VMA在RAM */ .data : { _sdata = .; /* data段在RAM中的起始地址 */ *(.data) . = ALIGN(4); _edata = .; /* data段在RAM中的结束地址 */ } > RAM AT > FLASH /* AT > FLASH 表示LMA在FLASH */ /* .bss段：未初始化数据，只在RAM中存在 */ .bss : { _sbss = .; *(.bss) *(COMMON) . = ALIGN(4); _ebss = .; } > RAM /* 栈空间：通常放在RAM末尾 */ .stack (NOLOAD) : { . = ALIGN(16); _stack_start = .; . = . + 4K; /* 分配4KB栈空间 */ _stack_end = .; } > RAM /* 全局符号，供C代码引用 */ PROVIDE(_start_bss = _sbss); PROVIDE(_end_bss = _ebss); PROVIDE(stack_top = _stack_end); }

这个脚本的关键点解析：

• MEMORY块定义了硬件的物理内存布局。ORIGIN和LENGTH必须与SoC手册中的“Memory Map”章节完全一致。FLASH的ORIGIN通常就是reset_addr。
• .text段的起始地址0x00010000，必须与reset_addr相同，否则CPU无法找到入口。
• .data段的> RAM AT > FLASH是精髓。它告诉链接器：.data的内容在最终二进制文件中（LMA）紧随.text之后，存放在Flash里；但当程序运行时（VMA），它应该被加载到RAM的0x20000000起始处。启动代码中的.data拷贝逻辑，就是依据_sdata（RAM起始）、_edata（RAM结束）、以及.data在Flash中的实际位置（可通过objdump -h查看）来完成的。
• .bss段的PROVIDE语句，将链接器生成的符号_sbss和_ebss暴露给C代码，使得启动代码可以用memset(_sbss, 0, _ebss - _sbss)来清零整个.bss段。
• PROVIDE(stack_top = _stack_end)为汇编启动代码提供了栈顶指针，la sp, stack_top即可完成栈初始化。

我曾在一个项目中，因链接脚本中RAM的ORIGIN写错了1个字节（0x20000000误写为0x20000001），导致.data段被错误地映射到一个未对齐的地址。虽然代码能编译通过，但运行时memcpy拷贝.data时，由于RISC-V的lw/sw指令要求地址4字节对齐，触发了load address misaligned异常（mcause=4），调试数小时才发现根源在链接脚本。这再次印证：在裸机世界，链接脚本不是辅助文件，而是与C代码同等重要的核心源码。

6. 实战排错：从“程序不运行”到“定位到第7行汇编”的完整链路

理论终须落地。下面我将以一个真实发生的、极具代表性的启动失败案例，完整复现从现象到根因的排查链路。这个过程，比任何教程都更能体现RISC-V裸机开发的“契约精神”。

现象：某开发者使用一款新型RISC-V评估板，烧录了标准的“LED闪烁”裸机程序。板子上电后，LED没有任何反应。使用JTAG调试器连接，发现CPU始终停在0x00000000地址，执行的是一条unimp（非法指令）。

第一步：确认复位向量是否正确

• 查阅评估板手册，确认SoC的reset_addr为0x20000000（片上SRAM）。
• 使用objdump -d firmware.elf反汇编，检查_start符号是否真的在0x20000000。结果发现，_start在0x00010000（Flash起始），而0x20000000处是一片0x00000000。
• 结论：链接脚本错误，.text段未被强制定位到reset_addr。修正link.ld，加入. = 0x20000000;，重新编译烧录。

第二步：复位后仍卡在0x00000000

• 重新连接JTAG，复位后单步执行，发现CPU确实从0x20000000开始执行，_start的第一条指令la sp, stack_top成功执行。
• 但执行到jalr zero, t0, 0（跳转到main）后，下一条指令地址又变成了0x00000000。
• 关键线索：jalr指令的跳转目标，是由mepc寄存器决定的。mepc的值，就是jalr指令执行后，mret将要返回的地址。
• 使用调试器读取mepc，发现其值为0x00000000。
• 结论：启动代码中遗漏了csrw mepc, t0指令，导致jalr跳转后，mepc未被更新，mret自然返回到0x0。

第三步：修复mepc后，程序进入main，但LED仍不亮

• 在main函数开头添加while(1) { __asm__ volatile("nop"); }，确认CPU已到达此处。
• 使用调试器单步，发现程序在main中调用led_init()后，立即崩溃。
• 查看mcause寄存器，值为7（Store/AMO access fault）。
• 单步到led_init()内部，发现崩溃点在*(volatile uint32_t*)GPIO_BASE = 0x1;这一行。
• 检查GPIO_BASE宏定义，其值为0x40010000。
• 关键动作：使用调试器的内存视图，尝试读取0x40010000地址。结果返回0xFFFFFFFF，表明该地址未被SoC的APB总线控制器映射，是一片“黑洞”。
• 回顾SoC手册的“Memory Map”章节，发现GPIO外设的实际基地址是0x40020000，而非常见的0x40010000。手册中有一个不起眼的脚注：“GPIO A/B/C base addresses are configurable via SYSCFG register at boot time. Default is 0x40020000.”
• 结论：外设地址配置错误。GPIO_BASE宏必须改为0x40020000。

第四步：修正地址后，LED闪烁，但串口无输出

• 添加uart_init()和printf("Hello\n")，串口无任何信号。
• 使用逻辑分析仪抓取UART TX引脚，发现无波形。
• 检查uart_init()，发现其配置了波特率寄存器，但未使能UART模块的时钟。
• 查阅SoC的“Clock Tree”章节，发现UART时钟由一个名为CLKEN_UART的寄存器位控制，该寄存器位于0x40000010。
• 在uart_init()开头添加*(volatile uint32_t*)0x40000010 |= (1 << 5);（假设bit5是UART时钟使能位）。
• 结论：外设时钟未开启，是裸机开发中最隐蔽也最常见的问题之一。

这个长达四步的排查过程，每一步都直指RISC-V裸机启动流程的一个核心环节：复位向量、mepc、外设地址映射、外设时钟。它不是一个孤立的bug，而是一张由硬件手册、链接脚本、汇编启动代码、C语言驱动共同编织的网。任何一个节点的疏忽，都会导致整张网的失效。这也正是RISC-V裸机开发的魅力与挑战所在——你不是在调用API，而是在与硅基世界进行一场字字珠玑的对话。

7. 经验沉淀：那些手册不会写，但会让你少走半年弯路的实战技巧

经过数十个RISC-V裸机项目的淬炼，我总结出几条血泪经验。它们不构成教科书式的理论，却是你真正动手时，能立刻派上用场的“暗知识”。

技巧一：永远先用“最小可行启动”验证硬件不要一上来就写一个功能完备的main()。创建一个最简_start，只做三件事：1) 初始化SP；2)csrw mepc, main；3)csrw mstatus, 0x80000000（只开MIE）；4)jalr zero, main, 0。然后main()里只写一个无限循环while(1) asm volatile("wfi");。烧录后，用JTAG连接，确认CPU能稳定停在这个wfi指令上。这一步验证了：复位向量、栈、mepc、mstatus全部正确。只有通过了这一步，你才能放心地往里面添加.data拷贝、.bss清零、外设初始化等逻辑。我见过太多人，在main()里加了10行代码后发现不运行，却花了三天时间在main()里打日志，而问题其实出在_start的mepc没设对。

技巧二：.data拷贝逻辑，务必用memcpy而非手写循环初学者常喜欢在汇编里写一个bss_clear_loop那样的循环来拷贝.data。这在小项目中可行，但一旦.data段变大（比如加入了字体库、音频采样表），手写循环的效率会急剧下降，且容易出错。正确的做法是：在C代码中，用memcpy函数完成拷贝。但这需要你确保memcpy本身是可重入的，且不依赖.data或.bss。解决方案是：将memcpy的实现放在.text段（只读代码），并在链接脚本中，用KEEP(*(.text.memcpy))将其保留在.text段的开头，确保它在任何.data初始化之前就能被调用。这样，你的启动流程就变成了：汇编_start-> C语言copy_data()（内含memcpy） ->clear_bss()->main()。代码更清晰，调试更容易。

技巧三：为mtvec设置一个“兜底陷阱”在mtvec指向的向量表中，除了你明确处理的中断（如handler_timer,handler_uart_rx），一定要为所有其他向量（尤其是0号向量，即“未定义异常”）设置一个handler_trap。这个函数的唯一任务，就是点亮一个LED、或通过SWD/JTAG输出一个固定的错误码，然后进入死循环。这样，当发生未预料的异常（如访问非法地址、执行未实现指令）时，你至少能知道“程序挂在这里了”，而不是无声无息地死掉。我曾用这个技巧，在一个内存泄漏导致堆栈溢出的项目中，快速定位到是malloc返回了NULL，而后续代码未做检查，直接解引用，触发了load access fault。

技巧四：善用mcause和mtval，它们是你的“黑匣子”RISC-V的mcause寄存器记录了异常/中断的类型（高1位是中断标志，低log2(n)位是具体编号），mtval则在某些异常（如页错误、非法地址访问）时，提供更详细的错误信息（如出错的虚拟地址）。在你的handler_trap中，务必读取并打印这两个寄存器的值。mcause=2是非法指令，mcause=5是环境调用（ECALL），mcause=7是存储访问错误。结合mtval，你能瞬间判断是sw指令写到了只读Flash，还是lw指令读了未映射的外设地址。这比在main()里加一百个printf都有效。

技巧五：版本化你的“启动模板”为每一个你接触过的RISC-V SoC，建立一个独立的、经过充分验证的启动模板仓库。模板中应包含：1) 精确匹配该SoC手册的link.ld；2) 包含_start、mtvec、mepc、mstatus初始化的startup.S；3) 一个能点亮LED并打印“Hello from RISC-V”的main.c；4) 一份README，详细记录该SoC的reset_addr、RAM/Flash地址、关键外设基地址、时钟使能寄存器地址。当你开始一个