龙芯K平台Linux下MPU6500驱动移植全记录

这次项目，我们“走马观碑组”拿到一块龙芯K系列嵌入式板卡，要把一颗MPU6500惯性传感器从原来的裸机驱动完整迁移到Linux下。刚接到任务时组里几个人都觉得这不算难，I2C设备、寄存器手册、现成驱动，照着改就行了。可真跑起来才发现，平台从MCU换成龙芯SoC之后，总线、中断、设备树、内核框架每个环节都有各自的脾气，调试过程远没想象中顺利。这篇文章就把这次的MPU驱动移植过程完整梳理一遍，包括原理、实操、踩坑和验证思路，给准备在龙芯平台上做外设驱动移植的朋友做个参考。

如果你正打算在龙芯K这类嵌入式平台上适配I2C/SPI传感器，或者想把现有STM32、树莓派的驱动往Linux IIO框架上挪，又或者只是好奇“MPU”这几个字母在不同语境下到底指什么，这篇内容应该都能给你一些实际有用的东西。

1. 项目背景：走马观碑组的这块“龙芯K”板子到底要干什么

1.1 从标题歧义说起：MPU是运动处理单元还是内存保护单元

刚看到项目标题“龙芯k - 走马观碑组MPU驱动移植”的时候，组外同事第一反应基本都是：MPU？内存保护单元？是不是要给龙芯写一个类似Cortex-M上MPU的驱动？

这个误解太常见了。在嵌入式领域，“MPU”这个缩写其实被两个完全不同的东西共用。一个就是单片机里常见的Memory Protection Unit，STM32H750上经常讨论的“MPU怎么设置”就是它，通过配置region来控制一段内存区域的缓存策略、读写权限、可执行权限；另一个是Motion Processing Unit，也就是以InvenSense MPU6050、MPU6500、MPU9250为代表的六轴/九轴惯性传感器。这类传感器广泛应用于无人机、机器人、姿态解算板卡上，通常挂在I2C或SPI总线上，通过读写寄存器输出加速度和角速度数据。

我们这次要移植的，明确是后者：一颗MPU6500六轴惯性传感器。之所以在项目标题里直接写“MPU驱动移植”，是因为传感器手册、原工程、测试脚本里全都用“MPU”指代这颗芯片，大家习惯了。结果就是对外沟通时每次都得先解释一遍，这不是在做内存保护单元，而是在做运动传感器驱动。

为了避免读者混淆，我后面统一用“MPU6500”来称呼芯片，只有在对照内存保护机制那一节才会重新提到Memory Protection Unit。

1.2 硬件架构与项目目标

这块龙芯K板卡的实际主控，是龙芯2K系列SoC，片内集成了多个I2C控制器、GPIO中断控制器、DMA控制器等常用外设。板卡上预留了一个6pin的传感器插座，硬件工程师把MPU6500通过I2C总线接到了SoC的某个I2C控制器上，中断引脚则连到了一个带中断功能的GPIO。

MPU6500的地址由AD0引脚决定。我们板子上AD0接地，所以I2C从机地址是0x68；如果AD0接高电平，地址就是0x69。这一点在初始检测时要特别注意，不少移植失败都是因为拿0x68去探测一个0x69的设备。

项目目标很明确：在龙芯K板卡的Linux环境里，让系统能识别MPU6500，通过IIO子系统提供加速度、陀螺仪数据给上层应用，保持100Hz左右的稳定输出，并且中断方式驱动。不是我吹牛，这个需求在驱动层面其实不算复杂，真正复杂的在于“从无到有”跨平台移植过程中那些细节。

1.3 为什么不直接写用户态程序，非要走内核驱动

有同事提过一嘴：反正linux下也能通过/dev/i2c-N直接访问I2C设备，为什么还要费劲移植一个内核驱动？

用户态读写I2C确实可以，i2cget、i2cset、甚至Python里用smbus库也都能拿到数据。但这样做有几个绕不开的问题：一是稳定性和实时性很难保证，用户态进程被调度走，传感器数据就会出现突刺；二是中断、FIFO、DMA这些能力用不上，MPU6500内置FIFO和硬件中断本来就是为了降低主控负载的，纯用户态轮询不仅费CPU，还丢数据；三是没法接到Linux标准的传感器框架里，上层的iio-sensor-proxy、libiio等工具全都没法直接用。

所以我从一开始就决定走标准内核驱动移植路线，基于内核IIO框架，把MPU6500作为IIO设备暴露给用户空间，这样后续做姿态解算或者调参都会舒服很多。

2. 移植前准备：芯片手册、内核框架与设备树的基本功

2.1 别急着写代码：先用手读寄存器

很多移植项目翻车，都是因为一开始就急着改代码、编内核，结果硬件链路不通，后面所有调试都在瞎忙。所以插上板卡后的第一件事，是先用I2C工具在用户态确认硬件链路是通的。

龙芯2K的Linux系统起来以后，会在/dev下生成对应的I2C设备节点。先查看一下系统有哪些总线：

bash复制ls /dev/i2c-*
i2cdetect -l

正常情况下能看到i2c-0、i2c-1这样的节点。用i2cdetect扫描总线上的设备：

bash复制i2cdetect -y 2

注意这里-y表示直接操作，不需要交互确认，扫描之前要确认总线号没有搞错，否则可能误操作到别的外设。如果MPU6500确实挂在i2c-2上，且AD0接地，扫描结果里会在0x68位置出现编号。如果什么都没看到，先查供电、查AD0接线、查I2C上拉电阻，不要急着碰驱动。

看到设备之后，先读WHO_AM_I寄存器做身份确认：

bash复制i2cget -y 2 0x68 0x75

MPU6500的WHO_AM_I寄存器地址是0x75，读取值固定为0x70。如果读出来是0x70，说明I2C链路完全没问题，芯片正常工作。如果读到0x00、0xFF或者其他值，就要怀疑芯片是不是进入了睡眠、地址是不是不对、或者I2C时序不稳定。

这一步虽然简单，但能筛掉一大半低级问题。

2.2 内核IIO子系统为什么比裸机驱动移植省心

MPU6500不是冷门芯片，Linux内核里的IIO子系统早就有了专门的驱动，叫inv_mpu6050（目录drivers/iio/imu/inv_mpu6050/），它支持MPU6050、MPU6500、MPU9250等一批InvenSense的IMU芯片。驱动内部已经实现了寄存器初始化、FIFO读取、采样频率设置、中断处理、温度补偿等功能，用户空间只需要通过IIO接口读取数据。

所以在龙芯平台上移植这个驱动，核心工作不是把裸机代码翻译成Linux API，而是让已有的inv_mpu6050驱动能够正确地“认识”这颗挂在龙芯I2C总线上的芯片。说得直白点，就是要把“总线连接关系、中断管脚、电源控制”这些信息告诉内核，让驱动的probe函数能成功执行。

IIO框架还有个好处是应用层接口很稳定。驱动注册成功后，设备会出现在/sys/bus/iio/devices/iio:device0下，里面有一堆in_accel_x_raw、in_anglvel_x_raw这样的属性，应用层直接读这些节点就能拿到传感器数据。如果开了buffer，还可以用iio_readdev工具批量读取连续数据，非常方便。

这也是我强烈建议在龙芯这类Linux平台上做传感器移植时优先选IIO框架的原因：块头不大，生态成熟，调试工具多，后续换芯片也有现成思路。

2.3 设备树节点这么写才不会被内核拒绝

龙芯K平台和大多数ARM平台一样，内核通过设备树描述板级硬件关系。inv_mpu6050驱动在probe时会从设备树里获取“compatible”、“reg”、“interrupt-parent”、“interrupts”这些关键属性，如果节点写得不对，驱动加载时要么找不到设备，要么中断申请失败。

我们这版设备树节点长这样：

dts复制&i2c2 {
    status = "okay";
    clock-frequency = <100000>;

    mpu6500: mpu6500@68 {
        compatible = "invensense,mpu6500";
        reg = <0x68>;
        interrupt-parent = <&gpio0>;
        interrupts = <32 IRQ_TYPE_LEVEL_LOW>;
        vdd-supply = <&vcc_3v3>;
        vddio-supply = <&vcc_3v3>;
        mount-matrix = "0", "1", "0",
                       "-1", "0", "0",
                       "0", "0", "1";
    };
};

简单解释几个关键字段：

• compatible：必须写成“invensense,mpu6500”，驱动匹配表里的字符串就是这样。写错的话，驱动匹配不上，设备树节点形同虚设。
• reg：I2C从机地址，0x68。
• interrupt-parent：当前中断管脚对应的GPIO控制器节点。
• interrupts：第一个数字是GPIO内部的引脚号，第二个是触发类型。这里我们用的低电平触发，因为MPU6500的INT引脚默认是低电平有效。
• mount-matrix：描述传感器安装方向的三行矩阵，用来把芯片坐标映射到设备坐标。如果只有单一朝向，可以用默认矩阵，但系统里做姿态解算的话最好提前标定。

寄存器地址是I2C设备的7位地址，这个对新手来说容易晕。0x68是我们用i2cdetect看到的地址，也是7位地址。Linux I2C子系统中，reg字段填的就是7位地址，不需要再包含读写位。

3. 龙芯K平台上的实际操作：内核配置、编译与首次加载

3.1 打开需要的驱动开关

设备树写完还不行，内核里得把相关驱动模块打开。龙芯2K的官方内核一般基于标准Linux内核，长时间分支维护，IIO框架是有的，但inv_mpu6050驱动可能没编进去，需要手动打开。

进入内核源码目录，执行：

bash复制make menuconfig

在菜单里按下面的路径找到对应选项：

text复制Device Drivers ->
  Industrial I/O support ->
    Inertial measurement units ->
      Invensense MPU6050 devices

建议把下面这几个相关选项全部打开：

• CONFIG_IIO=y：IIO核心框架，编译进内核。
• CONFIG_INV_MPU6050_I2C=m：I2C接口的MPU6050/MPU6500驱动模块。
• CONFIG_INV_MPU6050_IIO=m：IIO接口封装层。
• CONFIG_I2C=y：I2C总线支持。

驱动设置成模块的好处是调试时可以单独加载、卸载，不用每次改驱动都重新烧整个内核。早期调试阶段用模块能省很多时间，等驱动稳定了再考虑编进内核。

配置完了执行make保存.config，然后编译：

bash复制make -j$(nproc)
make modules_install INSTALL_MOD_PATH=/your/rootfs

如果只是交叉编译模块，可以只make模块，速度会快很多。

3.2 编译、安装模块时的坑：符号版本与工具链

龙芯K平台有两种常见的开发方式：一种是在板子上直接装交叉编译工具链，但资源有限；另一种是在服务器上交叉编译，然后把ko文件拷贝到板子加载。我们这次是在x86服务器上交叉编译的，碰到的第一个坑就是工具链和内核符号版本不匹配。

报错长这样：

text复制inv_mpu6050: Unknown symbol i2c_transfer (err -2)

“Unknown symbol”基本可以断定是模块和当前内核版本不匹配。可能原因有两个：一是编译模块用的内核源码config和板子上运行的内核config不一致；二是没有在模块源码目录提前prepare好kernel build目录，导致符号表缺失。

解决方法是保证板子内核跟编译环境是同一套源码。最稳妥的做法，是把板子跑的内核源码放到服务器上，先执行：

bash复制make prepare
make modules_prepare

然后再编译驱动模块。如果板子已经跑起来了，还可以从板子上拷出/proc/kallsyms、/lib/modules内部信息，跟编译环境比对，但这种比对繁琐，不如直接从源头保证一致性。

另外提醒一句：交叉编译时注意设置ARCH和CROSS_COMPILE环境变量。龙芯LoongArch平台一般是：

bash复制export ARCH=loongarch
export CROSS_COMPILE=loongarch64-linux-gnu-

这个如果有人用MIPS工具链编LoongArch内核，会直接编失败，而且错误信息很误导人。

3.3 用iio_info验证一次成功的probe

驱动模块加载成功之后，不要急着看应用层数据，先确认内核有没有正确识别设备。加载命令：

bash复制insmod inv_mpu6050_i2c.ko
insmod inv_mpu6050_iiom.ko

然后看dmesg：

bash复制dmesg | tail -20

正常情况下能看到类似这样的日志：

text复制inv-mpu6050 i2c-2:0x68: whoami 0x70
i2c i2c-2: new device registered: invensense,mpu6500 at 0x68

接着看IIO设备节点：

bash复制ls /sys/bus/iio/devices/

如果只有一个IIO设备，一般是iio:device0。查看它的名称：

bash复制cat /sys/bus/iio/devices/iio:device0/name

输出mpu6500说明设备树匹配成功、驱动probe成功。再读取一个通道的值试试：

bash复制cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw

这个时候用手翻转板卡，读到的数值应该随之变化。如果值完全不动，可能芯片进了睡眠模式，或者采样频率配置异常。

这一步跑通了，整个移植的核心链路就算打通了。接下来才能进入“调优”阶段。

4. 实测中绕不开的那些坑：从数据异常到驱动挂死

4.1 I2C时钟速率影响到数据稳定性的复现与解决

第一版设备树里，我犯了个想当然的错误：I2C时钟频率随手写了400000，也就是400kHz。MPU6500规格书上确实支持最高400kHz的I2C速率，但那是理想走线条件下。龙芯K板卡的I2C走线很长，中间还有连接器，负载电容偏大，400kHz下频繁出现读回0xFF、i2c timeout、数据跳变的问题。

具体现象是：dmesg里时不时出现“i2c-2: sendbytes: NAK bailout”，传感器数据偶尔一整段都是0xFFFFFFFF。用示波器抓波形，发现数据位的下降沿已经明显畸变，比数据手册要求的上升时间慢了一个量级。

解决办法很简单，把设备树里的clock-frequency改成100000，重新编译设备树，重启系统。问题直接消失，数据完全稳定。

这个坑给我的教训是：设备树里的I2C速率上限不能只看传感器手册，还要看你板子的实际布局。项目初期为了稳定性优先用100k没毛病，后面如果确实需要高频率再调快，并且要做电气验证。

4.2 中断申请失败与固件升级带来的GPIO重映射

还有一次问题更隐蔽。驱动能probe，能出数据，但dmesg里提示中断申请失败，驱动自动回退到轮询模式。传感器数据依然能读，但这个就不是我们设计的中断驱动了。

排查过程是这样的：我先看设备树里的interrupts字段，pin号、触发类型都对着电路图检查过，没问题。然后用gpiod命令和debugfs反复确认：

bash复制cat /sys/kernel/debug/gpio

结果发现，设备树里面写的那颗GPIO，在系统启动阶段就已经被某个BIOS固件里的默认配置占用了，管脚复用状态不是设备树期望的GPIO模式。

这里有个龙芯平台特有的背景：龙芯K板卡更新固件后，固件对SoC内部管脚复用的默认配置可能会变化。我们这块板子之前为了修复网口问题刷过一次新固件，正好把某个I2C中断引脚复用到了其他功能上。同时因为固件变更，GPIO中断控制器内部的中断映射编号也跟着变。

直到看了最新固件release notes里“管脚配置变更”那条才明白过来。于是对照新固件手册，把设备树里的interrupt-parent换成了正确的gpio控制器，interrupts编号也重新修正，中断就正常了。

这件事提醒我：在龙芯平台做设备树适配，不能默认固件不会动管脚复用。查硬件问题之前，先确认固件版本，再看芯片手册里的管脚复用寄存器，最后再怀疑驱动代码。顺序反了会浪费大量时间。

4.3 SPI模式下的DMA与Cache一致性（顺带说LoongArch）

我们项目最终用的是I2C，但调驱动的时候顺手看了看inv_mpu6050驱动对SPI模式的支持，毕竟MPU6500本身也支持SPI接口。而且同期另一个组在龙芯板卡上用SPI接了一颗高速ADC，遇到了DMA缓冲区数据错乱的问题，最后定位到Cache一致性上。

LoongArch和ARM一样，CPU侧的Cache结构对驱动开发者有直接影响。如果外设通过DMA往内存写数据，而这段内存被CPU cache缓存了，CPU读到的可能是缓存里的旧数据，而不是DMA刚写的新数据。这就是经典的Cache一致性问题。

内核驱动里解决这个问题的标准做法是使用DMA API：

• 分配一致性DMA缓冲区用dma_alloc_coherent；
• 流式DMA传输之前用dma_map_single，传输完成后用dma_unmap_single；
• 确保buffer地址按cacheline大小对齐。

如果自己写的驱动直接拿kmalloc出来的buffer传给DMA，在龙芯平台上很可能出现数据时好时坏的现象。虽然这和我们MPU6500的I2C传输无关，但做外设驱动移植时，只要涉及到DMA，都必须过这一关。这里提一句算是给后续SPI DMA方案做个铺垫。

4.4 字节序、数据排版与“看着不对”的IMU数据

第一次通过IIO节点连续读数据时，发现加速度值明显不对，x轴正常变化，y轴始终在一个大数值附近抖动，z轴几乎不变。起初怀疑寄存器配置有误，后来用iio_readdev连续读才发现问题在于数据输出没有按预期更新。

查了MPU6500数据手册，发现一个很容易踩的坑：芯片上电后默认处于sleep模式，不调用寄存器把sleep位清掉，传感器数据根本不更新，读出来的全是无效值。inv_mpu6050驱动在正常流程里会初始化电源管理寄存器，但前提是匹配成功并且驱动的chip_info里指定了MPU6500的处理方式。

另外，MPU6500数据寄存器输出是补码格式，16位有符号数，加速度和角速度的原始值需要在应用层再乘以量程系数。如果应用层把原始值当无符号数处理，就会看到负值的怪异表现。LoongArch和ARM一样是小端处理器，寄存器高低字节按小端拼接，跟传感器输出一致，所以不需要额外做字节序交换。但要是在老款龙芯MIPS平台上做同样的事情，就得留意核心的字节序配置，不能理所当然。

5. H750的MPU设置和龙芯MMU：两种内存保护机制的对照

5.1 为什么很多人在问H750的MPU怎么设

写这一节是因为我们这个项目沟通过程中，总有人把“MPU驱动移植”理解成“内存保护单元驱动移植”，搜索记录里也经常出现“h750 mpu怎么设置”。这里就顺便把这个概念彻底说清楚。

STM32H750这类Cortex-M7单片机里有个MPU外设，属于ARM内核的一部分，用来给开发者提供“内存区域属性”的细粒度控制。比如H750内置Flash只有128KB，但可以通过外部QSPI挂载更大的Flash，这时候就需要配置MPU，把外部Flash区域设置成“不可缓存”或者“Device”属性，否则内核从外部Flash取指时可能因为预取、缓存策略不对而触发HardFault。

H750上设置MPU的常见做法就是初始化一个或多个region，指定起始地址、大小、访问权限、缓存属性：

c复制MPU_Region_InitTypeDef MPU_InitStruct = {0};
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x90000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_8MB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL_0;
MPU_InitStruct.IsCacheable = MPU_REGION_NO_CACHE;
MPU_InitStruct.IsBufferable = MPU_REGION_NO_BUFFER;
MPU_InitStruct.IsShareable = MPU_REGION_NO_SHARE;
HAL_MPU_ConfigRegion(&MPU_InitStruct);

这段代码的目的，是告诉内核“这段外部Flash区域不要做cache”，避免CPU访问外部Flash时读到乱序或旧数据。这个逻辑和龙芯Linux下访问外部设备寄存器时要ioremap、要noncached，本质上是一回事，只是MCU里靠MPU寄存器手工配，Linux SoC里靠MMU页表自动配。

5.2 龙芯Linux驱动开发中保护内存安全靠什么

龙芯K这类处理器跑的是完整Linux，内核使用MMU来做进程间内存隔离。用户空间的程序各有各的虚拟地址空间，内核态有内核态页表，普通应用既不能随便读写物理内存，也不能直接执行IO地址上的代码。

所以写Linux驱动时，我们不需要像裸机MCU那样手工配置MPU region，而是依赖内核提供的一系列内存访问接口来完成保护。例如：

• 访问物理寄存器空间，必须用ioremap把物理地址映射到内核虚拟地址，再用readl/writel读写；
• 用户空间传过来的缓冲区，必须用copy_from_user/copy_to_user，不能直接内核态访问用户地址；
• 想给某段物理内存设置“不可执行”属性，用set_memory_nx；
• DMA缓冲区要按DMA API管理，保证Cache一致性。

很多从单片机转过来的开发者会踩同一个坑：拿到一个寄存器物理地址就直接用指针解引用访问，结果oops报错。原因就是没有经过ioremap，内核页表里这段地址可能根本没有映射。这不是龙芯特有的问题，所有MMU Linux平台都一样，但在LoongArch的异常信息里，oops地址解读方式和ARM略有不同，容易被误导。

5.3 一个可以直接套用的内存属性注意清单

这里给大家整理了一张表，把裸机MCU和Linux SoC两种环境下处理内存/Cache问题的思路对应起来：

这张表不是理论堆砌，是我在同时做过H750裸机项目、又做了龙芯Linux驱动之后总结出来的一个“翻译对照表”。遇到问题先确认你在哪个环境，然后去找对应环境的标准接口，别把H750上写MPU寄存器的手感直接搬到Linux里来，那样不仅没用，还会把事情搞复杂。

6. 没有开发板怎么办：龙芯模拟环境里的驱动自测

6.1 QEMU能把模拟做到什么程度

项目中期有一块龙芯K板子被派去支持别的项目了，我们手上只剩一个不能上电的旧板。那几天完全没硬件可调，但又不想让进度卡死，于是想到了龙芯模拟环境。

网上常说的龙芯模拟环境，一般指QEMU模拟LoongArch平台。qemu-system-loongarch64可以启动LoongArch Linux内核，跑一个完整的系统，甚至能执行大部分常见命令。不过，QEMU对外设的模拟并不完整，特别是龙芯2K板载的I2C控制器、GPIO中断控制器，模拟器里基本上不会按真实时序实现。

所以在QEMU里直接跑MPU6500驱动，希望它能模拟出传感器数据，目前是做不到的。QEMU更大的价值在于验证“驱动代码能否正确编译”、“模块加载会不会缺符号”、“LoongArch内核的启动流程是否正确”、“设备树语法错误能不能提前暴露”这些偏基础的问题。

我当时的做法是：在QEMU里启动一个龙芯LoongArch内核，手动insmod编译好的inv_mpu6050模块，观察模块加载有没有未定义符号、依赖缺失之类的错误。这一步能提前发现不少工具链和内核config的问题，省不少时间。

6.2 利用i2c-stub与regmap在宿主机上跑通驱动核心逻辑

如果想让驱动的核心读写逻辑在没有真实芯片的情况下先跑起来，可以在普通x86 Linux机器上借助内核的i2c-stub模块来模拟一条虚拟I2C总线。

i2c-stub是内核自带的一个测试模块，它允许你预先声明一批虚拟I2C从设备地址，然后所有对这个总线的读写都会被拦截，并保存到内存里。虽然它没有MPU6500的行为逻辑，但我们可以先给某个地址写入WHO_AM_I寄存器应有的值，再加载inv_mpu6050驱动，看驱动能否成功识别设备。

具体做法是：

bash复制modprobe i2c-stub chip_addr=0x68
i2cset -y 9 0x68 0x75 0x70

这里i2c-stub虚拟总线的编号通常从9开始。先把reg 0x75写成0x70，模拟WHO_AM_I返回值，然后加载inv_mpu6050_i2c.ko，驱动就可能成功probe。当然，其他寄存器的行为还要继续补，但这个思路足以验证设备树匹配、I2C regmap读写路径、IIO设备注册逻辑这些核心代码。

用这套方法，我们在等新板卡的几天里先把驱动和用户态读取脚本调通了，等真机一到，直接进入硬件时序调试阶段，省了一轮又一轮的编译往返。

6.3 模拟环境验证和真机验证的边界

必须强调一点：模拟环境再方便，也不能替代真机验证。i2c-stub模拟的只是寄存器读写行为，它没有真实I2C时序，没有上拉电阻，没有中断信号，没有电气噪声，也不能复现我们在4.1节遇到的那种时钟速率问题。

模拟环境能帮你确认的事情：

• 驱动代码能否正常编译；
• 设备树解析是否通过；
• 模块加载和IIO设备注册流程是否正常；
• 寄存器读写函数能不能执行到预期分支。

但模拟环境不能帮你确认的事情：

• I2C实际时序和信号质量；
• 中断触发和响应延迟；
• 电源纹波对传感器量测的影响；
• 不同温度下的数据漂移。

所以我的建议是：前期用模拟环境做“代码级自测”，把驱动链路的大部分问题提前消化掉，但一旦拿到真机，必须立刻把注意力放回真实硬件上。合板时优先验证硬件通路，再回头优化驱动参数，这样才不容易被模拟环境的“顺利假象”带偏。

说起来“走马观碑”这个名字，原本是说一个人骑着马经过石碑，扫一眼就能看清碑文并记住内容。我们组做驱动调试，特别讲究这种“一眼定位”的能力：看到报错现象，能快速判断问题在硬件、设备树、内核还是应用层，并且知道下一步该看哪里。这种本事的养成没有捷径，就是多啃手册、多调真实硬件、多记录踩坑过程。这次MPU6500驱动移植虽然中间绕了几个弯，但最终所有难点都落在了可解释、可复现的原因上，整个过程反而成了组里新同事学习龙芯平台外设驱动的最佳案例。如果你们也在龙芯K这样的平台上做类似移植，希望这份记录能帮你们少踩几个坑，尤其是I2C速率和固件管脚复用那两处，真的值得多留个心眼。