全志Fex文件：从配置到驱动的硬件资源管理实践
1. 全志Fex文件入门：硬件配置的"万能钥匙"
第一次接触全志平台开发时，我被各种硬件配置搞得晕头转向。直到一位老工程师扔给我一份.fex文件，说："这是咱们的硬件圣经"。打开这个看似普通的文本文件，里面密密麻麻的配置项让我瞬间明白了它的价值——原来全志芯片的所有硬件资源管理，都从这里开始。
Fex文件（全称是Flexible Configuration File）是全志平台特有的硬件资源配置文件。它采用类似INI的键值对格式，用纯文本方式定义GPIO、电源管理、外设参数等硬件特性。比如下面这个触摸屏电源控制的典型配置：
[ctp_para] ctp_power_ldo = "axp22_aldo3" ctp_power_io = port:PL04<1><default><default><1>这种配置方式比传统DTS（设备树）更直观，就像在填表格一样简单。我在调试触摸屏时，只需要修改ctp_power_ldo对应的电源域，就能快速切换供电方案，完全不需要重新编译内核。
与主流Linux设备树相比，Fex文件有三个明显特点：
- 即时生效：修改后刷入设备即可生效，适合快速迭代
- 硬件无关：同一套配置可适配不同型号的全志芯片
- 人机友好：不需要掌握复杂的语法结构，新手也能快速上手
2. Fex文件深度解析：从文本到驱动的神奇旅程
2.1 配置语法精要
Fex文件采用分段式结构，每个硬件模块有独立的配置段。以触摸屏电源管理为例：
[ctp_para] ctp_used = 1 ctp_name = "gt9xx" ctp_twi_id = 0 ctp_power_ldo = "axp22_aldo3"这里每个参数都有明确含义：
ctp_used=1表示启用触摸屏ctp_name指定驱动兼容性（对应驱动中的compatible）ctp_twi_id选择I2C总线编号ctp_power_ldo定义供电LDO节点
我在调试时发现一个坑：当ctp_power_ldo配置为axp22_aldo3时，实际对应的驱动代码会通过字符串匹配在sw-device.c中找到对应的电源操作函数。如果拼写错误，比如写成axp_aldo3，系统就找不到对应的电源控制节点。
2.2 与驱动交互的完整链路
当系统启动时，Fex配置的完整加载流程是这样的：
- uboot阶段：解析fex文件生成二进制格式的sys_config.fex
- 内核初始化：通过
sunxi_device_init()注册平台设备 - 驱动匹配：
sw-device.c中的platform_driver通过compatible匹配 - 资源分配：
ctp_power_ldo等参数被存入统一设备管理数组
这个过程中最精妙的是第3步。驱动代码里会这样定义：
static const struct of_device_id ctp_of_match[] = { { .compatible = "allwinner,ctp_para" }, {} };当内核检测到ctp_para段的ctp_used=1时，就会触发probe函数，完成硬件初始化。这种设计让硬件配置和驱动代码完美解耦，我在更换不同型号触摸屏时，只需要改fex文件，完全不用碰驱动代码。
3. 实战：触摸屏电源管理调优
3.1 电源配置的黄金法则
在全志平台上调试触摸屏电源，我总结出三个关键点：
LDO选择：不同开发板使用的PMIC可能不同，比如：
- AXP系列：
axp22_aldo3 - SY8106A：
sy8106a_ldo3 - 需要查阅具体的电源芯片手册
- AXP系列：
GPIO控制：当需要使能信号时，配置格式为：
ctp_power_io = port:PL04<1><default><default><1>这表示使用PL04引脚，初始电平为高（最后的
<1>）时序控制：有些触摸屏需要严格的上下电时序，可以在fex中添加：
ctp_power_vol = 2800000 ctp_power_on_delay = 100
3.2 常见问题排查指南
去年调试一款工业平板时，我遇到触摸屏时好时坏的问题。通过逻辑分析仪抓取波形，发现是电源不稳导致的。最终通过修改fex配置解决：
[ctp_para] ctp_power_ldo = "axp22_dldo2" ; 改用驱动能力更强的DCDC ctp_power_vol = 3300000 ; 适当提高电压 power_on_delay = 200 ; 增加上电延时这个问题让我深刻理解到，硬件配置不是简单的参数填写，需要考虑：
- 电源芯片的驱动能力
- 线路阻抗导致的压降
- 外设的上电时序要求
4. Fex vs DTS：设计哲学对比
4.1 技术实现差异
在给客户做技术培训时，经常被问到为什么全志要用fex而不是标准设备树。通过对比两者的实现方式，就能理解各自的优势：
| 特性 | Fex文件 | 设备树(DTS) |
|---|---|---|
| 配置格式 | INI风格文本 | 结构化DT语言 |
| 修改生效 | 刷入新fex即可 | 需要重新编译内核 |
| 硬件适配 | 同一文件适配多款芯片 | 需要不同dts文件 |
| 调试便利性 | 直接编辑文本 | 需要dtc编译工具链 |
| 社区支持 | 全志生态专用 | Linux主流标准 |
4.2 适用场景选择
根据我的项目经验，这两种方案各有最佳使用场景：
选择Fex当：
- 需要快速迭代硬件配置
- 同一套系统要适配多个硬件版本
- 团队缺乏设备树开发经验
选择DTS当：
- 需要上游内核支持
- 使用非全志主控的方案
- 项目对启动速度有极致要求
有个有趣的案例：我们有个客户的产品既要用全志又要用瑞芯微方案。为了统一开发流程，我在全志平台上实现了一个fex到dts的转换器，这样应用层就能用同一套配置方法管理不同硬件。