Linux BSP 与驱动开发内核、设备树与板级点亮

• 自研板卡需要点亮 Linux 的公司：板子打回来了，串口不出打印、外设不认，需要有人把系统从 Bootloader 调到业务能跑。

• 设备外设驱动缺失的团队：厂商内核里没有你这颗料的驱动，或者有但跑不稳。

• 路由器与网关类产品的厂商：要在 OpenWRT 上做定制功能与协议集成。

• 接手遗留 Linux 设备的客户：厂商 SDK 版本老旧、没人维护，需要有人接管并继续演进。

BSP（板级支持包）交付不是「内核能启动」就结束：Bootloader 与启动参数、设备树配置、外设驱动、根文件系统与自启动服务，直到上层业务进程稳定运行，整条链路都在范围内。全志 R528 控制板项目就是完整实例——从 Tina-Linux 系统跑到 WebSocket 控制服务，中间的 5 路 UART、GPIO、USB 驱动与开机自启管理全部交付。边界按项目在合同中约定。

全志 R528 控制板跑 Tina-Linux 系统，难点是让多路外设驱动与 Web 服务在 R528 上长期稳定并存。交付内容：5 路 UART 加 GPIO 与 USB 的外设驱动、HTTP 文件（照片）传输通道、WebSocket 实时控制通道、GCODE 文件下发，以及开机自启动的服务管理。外设驱动与上层服务由同一支团队交付——「驱动说数据给了、服务说收不到」这类跨层问题在我们内部就能定位。

树莓派 DSI 显示项目的平台是 Raspberry Pi 5，难点是实现多尺寸屏幕驱动与精确触摸校准。做法：DTS/DTBO 配置 DSI 设备树，ICN6211 桥接芯片做 MIPI DSI 转换，参考 Waveshare 面板驱动做适配，配合 STC8G1K08 的 I2C 调试日志排查问题，最终支持 4.3、5、7、10 英寸多尺寸屏幕。设备树是这类项目的核心战场——同一个接口换一块屏，时序参数、上电顺序、触控配置全要跟着改。

i.MX6 CAN 总线数据采集系统运行在 i.MX6 Quad/Dual 平台的 Linux 上，难点是在 i.MX6 上实现多通道 CAN 总线数据的实时采集与可靠通信。做法：CanMain 模块负责 CAN 数据采集，BMS_CAN 协议解析把原始帧还原为电池管理系统的业务数据，调试阶段用 minicom 与 cutecom 做串口联调。工业总线类项目的重点不在「能收到帧」，而在多通道并发下不丢帧、协议解析与采集节奏互不阻塞。

外设配置有两种做法：把引脚和参数硬编码进驱动，或写进设备树由内核统一解析。树莓派 DSI 项目全程走 DTS/DTBO 路线——换屏、改参数、调时序都动设备树叠加层，不动内核代码。硬编码的做法短期内快，换一版硬件就重编译一次驱动，长期成本反而高。XTELL 的 BSP 交付默认走设备树，配置与代码分离，改板不改码。

显示类驱动的工作量集中在接口时序：树莓派 DSI 项目里，ICN6211 桥接芯片的配置、面板初始化序列与触摸校准占了大部分调试时间。摄像头类驱动（V4L2 框架、模组点亮）属于本页服务范围，需求评估时可以按平台与模组型号直接核对经验。

在 Linux 上做工业总线采集，要同时对付两件事：内核调度带来的时延抖动，以及多通道并发时的数据完整性。i.MX6 CAN 总线数据采集系统的做法是把采集与解析分层——CanMain 模块只负责按时收帧，BMS_CAN 协议解析在其上独立进行，采集节奏不被解析拖慢。这类设计在电池管理、工业控制与车载设备里通用：总线侧要确定，业务侧要可扩展。

板级点亮之后的上层服务同样在交付范围内：R528 控制板的 HTTP 文件传输、WebSocket 实时控制与 GCODE 下发就是驱动之上跑起来的业务；i.MX6 采集系统里的 BMS_CAN 协议解析是跑在 Linux 上的应用层。驱动与服务分两家供应商的传统模式，接口对不齐时双方只能靠邮件猜——同一支团队交付时，这个问题在内部就消化了。

板级开发的排错高度依赖过程记录。树莓派 DSI 项目保留了 STC8G1K08 的 I2C 调试日志，作为触摸通道排查的证据链；R528 项目的外设驱动与自启动服务配置随版本归档。交付文档包含设备树改动、驱动配置、自启动项与已知问题清单——后续无论谁接手，都能复现当时的决策与状态，而不是从串口打印重新开始考古。

无 RTOS 的 MCU 固件（FreeRTOS、裸机）在《固件开发》服务页；电路板设计在《PCB 设计》与《硬件设计》页；本页负责带 Linux 的系统：内核驱动、设备树、BSP 点亮与板上的服务层。一块新产品如果还没定「跑 Linux 还是跑 RTOS」，在需求评估阶段一起定——这个选择影响 BOM 成本、功耗与开发周期，值得在画板之前想清楚。

1. 需求评估：提供板卡平台（或目标平台）、外设清单与业务目标，确认 BSP 范围。

2. 方案与合同：点亮范围、驱动清单、服务层内容与里程碑写清；内核源码与设备树文件是否交付、按开源还是闭源模式，逐项在合同中约定，页面上的任何描述都不构成统一承诺。

3. 开发与联调：bring-up、驱动开发、服务集成与实测验证按版本推进。

4. 交付：范围以合同为准；交期与报价评估后给出，本页不写死数字。

XTELL（深圳市极智未来科技有限公司）2016 年成立于深圳，至今十年，交付过 100 多个项目，客户以欧美 B2B 企业为主。业务覆盖从电路板到云端的每一层：PCB 设计、FPGA、嵌入式固件、Linux BSP、设备界面、手机 App、服务端与物联网平台。