Li Lee1. 项目背景与整体设计思路
1.1 为什么是“走马观碑组”
先说这个“走马观碑组”是个什么来头。很多人第一次看到这个名字会愣一下，以为是什么文学社团或者碑帖研究小组。实际上，这是我们内部对一类驱动移植任务的戏称——项目要求里写着“MPU驱动移植”，但真正拿到手里的硬件资料、参考代码、芯片手册都极其有限，只能靠着零散的线索“走马观碑”式地判断问题、猜测寄存器、验证行为。走马观碑这个典故讲的是古人骑马路过石碑，扫一眼就能把碑文背下来，我们做这类移植工作，很多时候也得练出这种一眼抓关键的能力：芯片手册翻几页就能锁定MPU相关的寄存器，参考驱动里扫一遍就能找到和硬件版本不匹配的适配点。
这次任务的目标平台是龙芯，具体来说是把一套原本跑在其他架构上的MPU驱动，移植到龙芯处理器环境里。MPU在这里不是内存保护单元（Memory Protection Unit），而是惯性测量单元（Inertial Measurement Unit），也就是陀螺仪加加速度计的组合传感器。这类器件在工业控制、机器人、飞行器姿态解算里非常常见，很多项目直接叫它“姿态传感器”或者“IMU”。把驱动从一个平台搬到另一个平台，听上去不算太难，无非是改改寄存器地址、调调中断号，但实际做起来，坑比想象中多得多。
我最初接到这个任务时，手上的材料只有三样：一份原平台的MPU驱动源码，一份目标板卡的硬件原理图，以及一块能跑的龙芯开发板。没有供应商提供的官方BSP，没有现成的设备树补丁，也没有专门的技术支持微信群——一切都要靠自己啃。
1.2 这类驱动移植到底在移什么
在动手之前，先要把“驱动移植”这件事拆清楚。很多人一听到“移植”就以为是把代码从一个文件夹复制到另一个文件夹，改个交叉编译器就能编过，这其实是最粗浅的理解。真正的驱动移植，核心在于三层适配：
第一层是硬件接口适配。MPU芯片通常挂在I2C或者SPI总线上，原平台的驱动代码里可能硬编码了总线号、片选引脚、中断GPIO、复位引脚等信息，这些到了龙芯平台上几乎全都要重新映射。龙芯处理器的GPIO控制器、中断控制器和原平台的寄存器布局完全不同，原驱动里通过gpio_request、request_irq之类的API拿到的资源，到了新平台未必有对应实现。
第二层是内核API适配。原驱动如果是针对老版本内核写的，里面的i2c_register_driver、input_allocate_device、iio_triggered_buffer_setup这些接口，在龙芯内核上可能已经改了签名或者被新接口替代。更麻烦的是，龙芯社区维护的内核往往是一个长期稳定版本，里面可能没有原驱动依赖的某些子系统，比如特定的IIO框架版本、特定的regmap配置选项。
第三层是时序和性能适配。MPU这类传感器对I2C通信时序、中断响应延迟、数据buffer大小都有要求。龙芯平台的I2C控制器时钟频率、中断响应路径、DMA能力都和原平台不同，如果只是把寄存器配置搬过来，可能出现数据丢帧、读取超时、中断风暴等问题。这一层才是真正考验移植者对硬件理解深度的部分。
所以，“走马观碑组”的真正含义不是说马虎大意，而是要学会在有限的资料里快速定位关键差异，然后精准出手。下面我把这次移植的完整过程拆开讲，包括设计思路、寄存器配置、代码改造、踩坑记录，希望给正在做类似龙芯或其他国产平台驱动移植的朋友一些参考。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 平台特性分析与驱动架构选型
2.1 龙芯平台的驱动开发环境概览
这次使用的目标平台是龙芯3A5000或者龙芯2K1000这类的板子，具体型号不方便透露太多，但大体上属于LoongArch架构，内核版本基础是Linux 5.10左右。龙芯平台和x86/ARM最大的区别在于指令集和体系结构，但对外设驱动开发者来说，真正要动手改的往往不是汇编层，而是总线层和中断层。
龙芯的内核维护在gitee的Loongson分支上，社区活跃度这些年提升很快，但和主流内核的间距还是存在。很多第三方外设驱动，尤其是那些直接抄厂商SDK的代码，往往默认你在ARM或者x86上编译，里面的内存屏障、缓存一致性、字节序处理可能全部需要重新审视。
MPU驱动挂在I2C总线上，所以第一步是确认龙芯平台的I2C控制器驱动是否已经正常启用。我这边板子的I2C控制器在设备树里定义为ls2k-i2c或者ls7a-i2c，不同型号略有差异，但基本上内核里都有现成的驱动。如果要移植的驱动是绕开内核I2C子系统、直接操作寄存器实现的（比如某些RTOS移植过来的带跑马灯风格代码），那在Linux下就必须先重写为标准的I2C client驱动结构，否则寸步难行。
2.2 原驱动架构分析：从“能用”到“能搬”
我们拿到手的原MPU驱动，是一个典型的IIO子系统驱动，支持MPU6050、MPU6500、MPU9250等多款器件。文件结构大概包含：
- 核心驱动文件：
inv_mpu_core.c，负责芯片ID检测、采样率配置、传感器使能、FIFO操作等。 - I2C接口层：
inv_mpu_i2c.c，封装了i2c_transfer、regmap_read/write等底层读写函数。 - IIO触发与缓冲：
inv_mpu_trigger.c，实现硬件中断触发、数据采集和上报。 - 平台数据配置：
inv_mpu_platform.c，保存了中断GPIO编号、I2C地址、电源管理设置等。
原代码的工程组织比较规范，但里面有一个非常关键的历史包袱：很多寄存器操作都通过regmap完成，而regmap的初始化参数里写死了regmap_config结构体，包括读写标志位、缓存类型、最大寄存器地址等。这些参数本身和硬件是绑定的，问题不大；但原代码里的read/write回调函数直接调用了i2c_master_send和i2c_master_recv，这两个函数在老内核里能用，到了新内核上如果I2C控制器的超时策略变了，就会出现偶发传递错误。
所以我的整体思路是：保留原驱动中的核心算法层和寄存器定义（这部分是芯片厂商反复验证过的，不需要动），重写底层的I2C访问层和中断映射层，让它适配龙芯平台的标准设备模型。这样做的好处是，后续如果要升级芯片型号或者调整硬件设计，核心代码不需要大改，只动平台适配层就够了。
2.3 设备树与资源映射：驱动移植的第一道坎
在Linux设备模型下，外设驱动不关心具体的寄存器物理地址和中断号是多少，它只认设备树节点里的资源描述。所以移植工作的第一步，就是为MPU设备在龙芯板卡的设备树里添加或者修改一个节点。
原平台的设备树节点可能是这样的：
dts复制&i2c2 {
status = "okay";
clock-frequency = <400000>;
mpu6050@68 {
compatible = "invensense,mpu6050";
reg = <0x68>;
interrupt-parent = <&gpio1>;
interrupts = <7 IRQ_TYPE_EDGE_RISING>;
mount-matrix = "0", "1", "0",
"-1", "0", "0",