MPU6050驱动移植龙芯K平台：I2C设备树与IIO框架踩坑全记录-平芜编程栈

“走马观碑组”这个名字，是组长在一次季度总结会上起的，意思是我们看问题要又快又准，像古代那些扫一眼碑文就能背下来的神人。结果这次接到的任务——把MPU6050六轴传感器驱动从老平台移植到龙芯K平台的Linux内核里——恰恰把大家按在地上磨了整整三周。如果你也有过“驱动能编译，但硬件不认账”的经历，这篇复盘应该对你有用。

实际工作不复杂，但很碎：要先搞清楚龙芯K平台的I2C控制器在设备树里怎么描述，再看内核里现有的inv_mpu6050驱动能不能直接匹配，最后解决中断、时钟、采样率和掉电唤醒一堆问题。后面我把完整链路和踩坑过程都写出来，包括设备树怎么写、内核选项怎么开，以及遇到i2cdetect扫不到设备时到底应该先查哪儿。

1. 从“复制粘贴”到“跑通验收”——这次MPU驱动移植到底难在哪

1.1 任务背景：为什么要把MPU6050驱动挪到龙芯K上

我们组一直做一款小型运动监测模块，原来主控用的是ARM Cortex-A7，姿态数据和云台控制都靠MPU6050。后来产品做平台切换，核心板换成龙芯K系列，要求传感器和外设尽量不动。理论上MPU6050走I2C，任何CPU只要有时序都能读，但真实情况远非如此：内核里没有现成设备树节点、I2C控制器寄存器配置不一样、中断号和旧平台对不上，原来的驱动代码里还掺了不少平台相关的头文件。

这次移植的目标很明确：让MPU6050在龙芯K平台上稳定输出三轴加速度和三轴角速度。不是说能读出数据就算完，而是要经得起产品级的长时间运行。所以项目刚开始我就跟组里打了个预防针——这不是一个“今天改改，明天就跑通”的活，而是要把从设备树到I2C核心再到IIO子系统整条链路都走一遍。

1.2 移植前的技术摸底：三件事必须提前做

开始动手前，我带着组员做了三件事，这三件事后来被证明帮我们省了至少两天debug时间。

第一，查清楚龙芯K平台有几个I2C控制器，各自在设备树里叫什么名字，物理引脚有没有被复用成GPIO。龙芯的SoC引脚复用很强，一个引脚既可能是I2C的SCL，也可能是普通GPIO，BSP默认配置不一定是你要的样子。第二，确认BSP内核版本。我们手上是Linux 5.10，里面已经有IIO框架下的inv_mpu6050驱动，理论上可以少写很多代码。第三，用示波器和万用表把MPU6050的I2C引脚、中断脚都量一遍，确认没有接反、没有虚焊。

技术摸底的意义在于，把“移植驱动”拆成“改设备树+调内核配置+验证中断路径”三个独立小任务。每个小任务都可以单独验证，任何一个失败都能精确定位，而不是等到最后烧完系统才发现一堆问题叠在一起。

1.3 我们定义的验收标准：别让“驱动能编译”糊弄过去

驱动移植最容易出现的一种情况是：模块编译进了内核，日志里也打印了probe成功，大家就以为搞定了。但实际一读数据，不是全0就是乱跳。所以我在本项目里定了一个四层验收标准，防止“假成功”。

上电后i2cdetect能扫到0x68设备地址，且地址稳定。
驱动probe成功，/sys/bus/iio/devices/iio:device0节点出现，能读到加速度和角速度数据。
连续跑24小时，不能出现FIFO溢出和中断丢失。
同样一套设备和设备树，换到相同型号的另外两块板子上，仍能正常工作。

这个标准看着简单，但第四条就替我们挡下了不少坑。因为有些板子的接线或者焊接问题，会导致代码在A板上能跑，B板上就挂，如果只拿一块板子验收，很容易漏掉硬件一致性问题。

2. 先把地基打对：龙芯K平台的I2C与设备树配置

2.1 通信链路：从CPU寄存器到传感器寄存器的一整条路

MPU6050是一个六轴IMU，内部包含三轴加速度计和三轴陀螺仪，通过I2C从机接口和外部通信，从机地址默认是0x68（AD0接地）或0x69（AD0接高）。龙芯K平台片内集成多个I2C控制器，对我们来说，CPU侧的“主设备”就是一系列寄存器加中断控制器。

驱动移植的本质，是让Linux I2C核心能找到这条总线，让inv_mpu6050驱动能找到挂在总线上的从设备，然后通过标准的I2C读写接口去操作传感器寄存器。说起来像流水线，但每个环节都有各自的“脾气”：I2C控制器要有时钟、引脚要复用对、设备树要描述对、驱动要和设备树匹配上。任何一环脱节，数据就到不了用户态。

2.2 设备树节点：一个字节都不能错

在龙芯K的BSP里，I2C控制器已经由芯片厂商描述好了，通常像这样：

&i2c2 { status = "okay"; clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&i2c2_pins>; };

而MPU6050需要在这个父节点下增加子节点：

&i2c2 { #address-cells = <1>; #size-cells = <0>; mpu6050@68 { compatible = "invensense,mpu6050"; reg = <0x68>; interrupt-parent = <&gpio>; interrupts = <19 2>; }; };

很多新手在这里直接复制示例，但有三个细节我必须强调：

reg地址必须是7位I2C地址，写成0xD0之类的是错的。I2C协议里8位地址的最后一位是读写位，设备树里填的是高7位。
interrupts里的第二个数字是触发类型，2表示下降沿触发，8表示低电平触发。这个必须跟硬件实际接法一致，不同触发方式对中断丢失的影响非常大，后面踩坑章节还会细说。
compatible字符串必须跟驱动里的of_match_table完全一致，多一个空格、少一个字母都不行。字符匹配失败，驱动不会进入probe，而且内核不会报错，只会安静地忽略。

我们项目里MPU6050的中断脚接在GPIO 19，硬件设计是低电平有效，所以设备树最终写的是interrupts = <19 8>。这个“8”是很多教程里不太会讲清楚的坑，很多人照抄<19 2>也能跑，但一旦中断丢起来，你就知道差别了。

2.3 内核配置：该开的选项一个都不能少

我比较倾向于把驱动编成模块，调试期迭代快，改一行代码重新编译模块比整个内核重编省太多时间。内核配置需要确保下面这几个选项是开着的：

CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y（方便用i2cdetect/i2cget调试）
CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
CONFIG_INV_MPU6050_I2C=m

这里特别提醒：CONFIG_IIO_BUFFER经常被遗漏。没有它，即使probe成功你也不会看到可用的buffered数据接口，iio_info看不到采样数据，上层应用就更测不出来了。而且这个选项默认可能不是开启的，必须手动进menuconfig确认。

2.4 框架选型：为什么坚持用IIO而不是老式input子系统

老式Linux驱动里也有用input子系统上报事件的写法，上报事件类型是EV_ABS，配合input_abs_setup把六轴数据丢给用户态。这种方式不是不行，但MPU6050本质是传感器，IIO（Industrial I/O）框架才是正道：缓冲、触发、采样频率、温度补偿、掉电唤醒都是“一等公民”，上层应用也能通过统一的/sys/bus/iio/接口访问。

另一个重要原因是内核主线代码的可持续性。5.10内核里inv_mpu6050驱动已经比较成熟，我们决定不用厂商提供的旧补丁，直接用主线代码。虽然主线驱动在个别龙芯平台上可能会有I2C时序兼容性问题，但至少保证后续内核升级时我们能跟上社区节奏。项目遇到问题也能拿主线代码去和BSP对比，更容易定位是哪一层动了手脚。

3. 逐行走通移植过程：从内核源码到模块加载

3.1 准备交叉编译环境与内核源码

我们手上有的是龙芯官方BSP源码包，里面自带交叉编译器。以2K1000样片为例，目标平台是MIPS64小端，交叉编译前缀是mips64el-linux-gnuabi64-。设置环境变量的方式如下：

export ARCH=mips export CROSS_COMPILE=mips64el-linux-gnuabi64-

然后先生成默认配置，再打开我们需要的内核选项：

make loongson2k_defconfig make menuconfig

在menuconfig里逐项找到：

Device Drivers -> I2C support
Device Drivers -> Industrial I/O support -> Inertial Measurement Units -> Invensense MPU6050 devices

把MPU6050相关项勾选为M（模块），I2C保持打开，/dev/i2c-*字符设备也建议打开。

3.2 修改设备树并编译DTS

龙芯BSP的dts文件通常在arch/mips/boot/dts/loongson/目录下。我们需要改的是板级dts文件，比如loongson2k1000.dtsi和对应的开发板dts。在i2c2节点里加上MPU6050子节点后，执行：

make dtbs

编译完成后，在arch/mips/boot/dts/下会生成对应的dtb文件。烧写时需要连同内核镜像一起更新。这里有一个无数人踩过的坑：只更新内核Image，不更新dtb，设备树改了等于没改，因为引导程序加载的是旧dtb，内核根本不认识你新加的节点。

检查dtb是否生效，可以反编译看一下：

dtc -I dtb -O dts arch/mips/boot/dts/loongson/loongson2k1000.dtb | grep -A5 mpu6050

如果能看到mpu6050@68节点，说明dtb已经带上了。

3.3 编译驱动模块

执行make modules后，会在drivers/iio/imu/inv_mpu6050/下生成两个关键文件：inv-mpu6050.ko和inv-mpu6050-i2c.ko。

inv-mpu6050.ko是核心驱动，负责IIO设备注册、寄存器初始化、数据读取逻辑。
inv-mpu6050-i2c.ko是I2C传输适配层，负责把核心驱动的读写请求转成I2C控制器的实际时序。

这两个模块有依赖关系，加载时必须先加载核心模块，或者用modprobe让系统自动处理依赖。如果只用insmod且顺序反了，会报“Unknown symbol”错误，因为核心驱动里引用了I2C适配层的导出符号。

模块拷贝到板子上之后，先执行depmod -a，然后用：

modprobe inv-mpu6050-i2c

3.4 加载后确认probe流程

加载成功后马上看内核日志：

dmesg | tail -30

正常会看到类似“iio device registered”或者驱动的name提示。这时候去/sys/bus/i2c/devices/下看，应该会出现2-0068这样的目录（前面是总线号，后面是设备地址）。再进/sys/bus/iio/devices/，看到iio:device0就说明设备枚举成功了。

如果只看到I2C核心创建了设备，但驱动没有probe，先别急着怀疑驱动代码，去核对compatible字符串和reg值。我把这个过程做成了一张自检表：

步骤	操作	验证命令
内核源码	`make loongson2k_defconfig`	`grep CONFIG_INV_MPU6050 .config`
设备树	增加`mpu6050@68`子节点	`dtc -I dtb -O dts ...
编译模块	`make modules`	`ls drivers/iio/imu/inv_mpu6050/*.ko`
加载驱动	`modprobe inv-mpu6050-i2c`	`dmesg \| grep -i imu`
设备节点	确认IIO设备注册	`ls /sys/bus/iio/devices/`

4. 翻车合集：传感器找不到、读出全是0xFF、probe就是不进

4.1 第一批板子I2C扫描不到设备的排查链路

这是最让人崩溃的一个问题：板子通电后执行i2cdetect -y 1，列表里完全没有0x68，全是“--”。当时组里第一反应是驱动没编对，但后来发现驱动根本没机会参与，因为I2C设备压根没出现在总线上。

排查链路要一步一步来。第一步，先确认I2C总线号。龙芯2K1000有多个I2C控制器，设备树里的i2c2在Linux里可能被注册成i2c-1或i2c-2，不同BSP版本编号策略还不一样。用i2cdetect -l列出所有总线，再找到对应设备树节点的那条。我们板子上i2c2对应的是i2c-1，但很多教程默认用i2c-2，白白扫了半天。

第二步，检查硬件连接。用示波器量MPU6050的SCL和SDA，如果SCL有波形但SDA一直被拉低，十有八九是SDA上拉电阻没焊或者焊错了位置。如果两根线都没有波形，检查引脚复用，也许它被BSP默认配成了GPIO。

第三步，确认从机地址。AD0脚接地是0x68，接VCC是0x69。我们有一块板子的AD0丝印标反，实际是0x69，所以一直扫0x68当然没有。还有一块板子是AD0悬空，地址在上下电瞬间不稳定，有时扫到0x68，有时扫不到。

在我们这个案例里，第一批三块板子中一块是AD0引脚问题，其余两块是总线号没对上。最终通过逐个对照原理图和i2cdetect输出确认，跟驱动代码半毛钱关系都没有。

4.2 读到全0xFF或全0x00：硬件电气问题还是软件初始化顺序

i2cdetect能扫到地址，心里踏实一点，但用i2cget -y 1 0x68 0x75读取WHO_AM_I寄存器时，返回0xFF。这说明I2C从机没有正确响应。

全0xFF通常意味着从机没拉低ACK，可能是如下几个原因：

SDA/SCL上拉电阻缺失或阻值太大，信号上升沿太慢。
MPU6050的VDDIO参考电压和主控电平不匹配。我们遇到过一个真实案例：VDDIO接的是5V，而龙芯I2C控制器是3.3V电平，两边信号识别混乱。
I2C时钟频率过高。如果BSP默认配了400kHz，但板子线缆比较长，可以先降回100kHz试一次。

全0x00的情况通常是SCL一直为低，或者是传感器处于sleep状态且读写时序异常。确认初始化顺序很重要：上电后先写PWR_MGMT_1（地址0x6B）把SLEEP位置0，然后延时50ms，再读WHO_AM_I。如果一上电就直接读，MPU6050还在复位过程中，自然读不出正确值。

4.3 compatible对不上导致probe函数不执行

这个问题最迷惑。设备树节点加了，i2cdetect也能看到设备，modprobe也成功了，但dmesg里就是没有probe日志。更诡异的是，/sys/bus/i2c/devices/下已经出现了2-0068目录，说明I2C核心把设备枚举出来了，但驱动没有绑定上。

排查方法很简单：

cat /sys/bus/i2c/devices/2-0068/name

看看设备名称是不是符合预期。如果设备目录名和驱动匹配表里的compatible不一致，绑定就会失败。我们曾经把设备树的compatible写成"invensense,mpu6050"，但某个分支的驱动里of_device_id数组只写了"invensense,mpu6050-byte-swap"这类变体，导致一直绑定不上。

还有一种可能是模块依赖没加载完整。inv-mpu6050.ko没先加载，inv-mpu6050-i2c.ko虽然加载了，但核心驱动不存在，probe会被deferred。dmesg里会看到“probe deferred”字样，有时候会被日志刷掉看漏。用这个命令专门查：

dmesg | grep -i defer

4.4 FIFO溢出导致数据卡死，中断和轮询的取舍

probe成功，iio_info也能看到设备，但连续读取一段时间后，某一个轴的角速度数据始终不变，像被冻住一样。

实际上这是FIFO溢出问题。inv_mpu6050驱动默认用FIFO做数据缓冲，FIFO满之后如果没有及时读取清空，新数据写不进去，旧数据一直顶在头上，用户态读到的自然永远是旧值。dmesg里会周期性出现“FIFO overflow”错误。

我们把中断触发方式从下降沿改成低电平触发后，这个问题得到明显缓解。原因是：边沿触发如果正好在CPU屏蔽中断期间到来，这个边沿就永远丢了，驱动永远不知道有新数据，FIFO自然越积越满。而低电平触发不同，只要电平一直保持低，等CPU打开中断后依然能识别到pending事件，不会漏掉。

如果板子用的是轮询模式，要额外确认CONFIG_IIO_TRIGGERED_BUFFER已经打开，否则buffer提交不上，数据也是死的。

5. 驱动活了，距离产品化还差这几步

5.1 先用命令行验证六轴数据合理性

probe成功后，不要急着写应用程序，先用命令行快速验证数据。静止状态下依次读取：

cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw cat /sys/bus/iio/devices/iio:device0/in_accel_y_raw cat /sys/bus/iio/devices/iio:device0/in_accel_z_raw

如果量程是±2g，静止时Z轴读数应该接近16384（1g对应的LSB），X/Y轴接近0。陀螺仪三个轴应该接近0，偏差在几十LSB以内正常。如果Z轴读数明显不对，先查PWR_MGMT_1寄存器，确认SLEEP位是0，然后确认量程寄存器配置是否和预期一致。

用iio_info可以一次性看到所有通道和采样频率，比一个个cat方便得多。这一步数据对了，再往上写应用才是水到渠成的事。

5.2 采样率、FIFO阈值与CPU占用率的平衡

MPU6050的加速度计和陀螺仪最高支持4kHz采样，但I2C带宽有限，中断频率太高CPU会一直在处理中断。我们最终把加速度计和陀螺仪输出速率都配置在100Hz，FIFO采样率也是100Hz，实测CPU占用率不到3%。

在设备树里可以这样配置，但不同内核版本支持的属性名有差异：

mpu6050@68 { compatible = "invensense,mpu6050"; reg = <0x68>; interrupt-parent = <&gpio>; interrupts = <19 8>; inven,accel_freq = <100>; inven,gyro_freq = <100>; };

修改属性前一定要去drivers/iio/imu/inv_mpu6050/inv_mpu6050_core.c里查一下驱动对设备树属性的解析代码，因为有些版本用的是invensense,accel_freq，多一个字母不影响编译，但会被驱动静默忽略。

5.3 低功耗设计：把MPU6050睡眠和唤醒做好

如果产品是电池供电，MPU6050默认上电后处于sleep状态，我们唤醒后如果长时间不采集，应该再次写PWR_MGMT_1寄存器进入sleep状态，需要时再唤醒采集。内核里inv_mpu6050驱动提供了runtime PM支持，在设备树节点里加一条wakeup-source;即可，同时确保内核打开CONFIG_PM=y。

我们实测启用runtime PM后，待机电流从约800μA降到90μA。如果板子上还有别的功耗大户，这个数字仅供参考，但趋势是对的。做产品的人都知道，传感器本身的功耗往往不是大头，但白给的功耗省一点是一点。

5.4 项目收尾：把踩坑沉淀成组内公共文档

项目结束时，我把这次踩坑整理成四页文档，核心格式是“问题现象—排查步骤—根因—永久修正”。设备树修正后的版本固化到了BSP基线里，而不是只存在某个人的工作目录。i2cdetect扫描命令和dmesg过滤命令也写成可执行脚本，放到组内共享。后续再有人做同类型传感器迁移，直接跑一遍自检脚本就能筛掉大部分硬件问题。

这次移植给我最大的感受是，所谓“驱动移植”，真正难的不是驱动本身，而是对硬件平台的掌握。龙芯K平台和ARM平台在I2C时序、中断控制器行为、BSP内核配置上都有微妙差异，任何一点差异都可能让传感器数据变得不可用。但把这些差异摸清楚以后，替换传感器型号、扩展到其他IMU也就是换个compatible字符串的事。