文章归档

嵌入式 Linux 产品的核心竞争力往往不在于内核本身，而在于其承载的用户空间组件：文件系统布局、包选型、init 策略和安全加固。Buildroot 作为轻量级构建系统，能从源码交叉编译出最小化的根文件系统镜像，但实际项目中很少停留在 make qemu_arm_vexpress_defconfig 的默认状态。本文讨论如何在 Buildroot 框架内，将一个 minimal 根文件系统逐步演进为满足量产要求的生产级镜像。

联网设备必须有清晰的设备身份。设备 ID、SN、MAC、证书和私钥如果管理混乱，会影响 MQTT 连接、云端认证、售后追踪和安全性。身份信息要从生产阶段就设计好。

嵌入式 Linux 不等于只能写 C。驱动和底层库仍以 C 为主，但业务服务、网络通信、配置管理、升级程序可以根据资源和团队能力选择 C++、Go 或 Rust。语言选型要看约束，不要只看偏好。

嵌入式项目很容易变成一堆 SDK 压缩包、临时补丁、手工改动和不可复现镜像。项目目录和协作方式如果不规范，团队越多人，问题越难追。

嵌入式设备的存储介质差异很大。NOR、NAND、eMMC、SD 卡的特性不同，适合的文件系统和升级方式也不同。选错存储方案，后面会在断电、坏块、寿命和性能上不断补坑。

嵌入式 Linux 上的 C 服务代码，不只是能编译运行就可以。它要长期运行，要处理异常输入，要能记录日志，要能重载配置，要能在资源紧张和网络异常时保持可控。

应用访问外设时，经常会用到 /dev/ttyS1、/dev/i2c-1、/dev/spidev0.0 这类设备节点。设备节点怎么来的、权限怎么设置、热插拔怎么处理，是 rootfs 设计的一部分。

内核配置决定了系统支持哪些驱动、文件系统、网络协议和调试能力。嵌入式 Linux 里，内核不是越全越好，也不是越小越好，而是要和硬件、rootfs、调试需求匹配。

U-Boot 是很多嵌入式 Linux 系统的启动核心。它决定从哪里加载 kernel、dtb、rootfs，也决定 OTA A/B 分区如何切换。理解 U-Boot 环境变量和启动脚本，是排查启动问题和做升级回滚的基础。

嵌入式项目也需要自动化测试。只靠人工烧录、人工点功能，很快会被版本迭代拖垮。自动化不一定一开始就复杂，可以先从构建检查、冒烟测试和硬件在环测试做起。