【意见征集】imx-forge 长期规划与社区需求收集；[Request for Comments] Long-term Roadmap and Community Feedback for imx-forge

[Charliechen114514]

IMX-Forge 接下来要补齐什么：从驱动教程到 IMX6ULL 加油站

Author: Charliechen114514

English summary is available below. Slide down for reading!

---

imx-forge 的发展其实稍微超出了我的预期。最开始的最开始，我本来是想把它当作一个普通而又简单的，自己创建着玩的 imx 笔记 + 方便工具抽象的项目。但是没想到一下子成为笔者从事计算机并以嵌入式作为爱好以来最活跃的项目！

为了给各位关注本项目发展的朋友一个交代，这里特别开一个 Issue / Discussion，欢迎大家前来讨论 imx-forge 接下来的前进方向和需求规划。

先声明一下：这篇不是“一次性全部做完”的承诺书，更像是一个需求池和路线草案。哪些先做、哪些后做、哪些其实没必要做，都欢迎大家直接拍砖。我们现在要做的，是先把方向放到桌面上。

这个项目是什么，又不是什么

imx-forge，正如“加油站”的定位而言，不计划交付一份拿来直接烧录的 binary。工具链大家都存在差异，每个人开发的发行版不一样，使用的工具链也存在微小的差异。C/C++ 的 ABI 不兼容性也不是一天两天造成的了。直接给可烧录的 binary 简直不现实；就算跑起来了，您如何二次开发呢？

CI 里出现的 artifact，更多是构建验证产物，证明这套体系能构建出来；它不是我们打算长期维护并承诺“拿去量产烧录”的通用交付物。嵌入式 Linux 的真正价值，还是在于能不能重新构建、重新调试、重新扩展。

笔者希望做的事情很简单：

1. 对于已经有经验的朋友，我们尝试跑通一套基于现代工具链、现代 U-Boot、现代 Linux 和现代 Rootfs 裁剪方案的嵌入式 Linux 项目。笔者在自己的教程反复强调了，一个最完整的项目永远被上面这些范畴涵盖。我们希望减少大家以 i.MX6ULL 为例子的各大嵌入式 Linux 开发板的重新探索流程。保证看到一次，之后的其他开发板都能类比推移，至少让难度小一点！笔者相信，它的真正可复用的价值，在于一套能被别人重新构建、重新调试、重新扩展的工程体系。

2. 对于初入嵌入式 Linux 的朋友，尽管现在各个开发板的教程趋于稳定和成熟，代价就是使用的工具链老旧，难以体验到新特性。笔者永远不会忘记自己当初为了入门，想尽办法安装 Ubuntu 16.04，4.9.2 版本的 gcc，以及那段没有追上现在更新的、现代的 VSCode 和好用 clangd 的日子。正是受够了写驱动的时候，我不得不使用 C89，看着全是飘红的未定义符号（尽管使用 clangd 可以有效缓解，但是你知道的，配套的东西找起来就很痛苦）。笔者希望这个仓库的发展，可以让后续入门这块开发板，进而入门掌握嵌入式 Linux，裁剪自己的发行版跑自己的应用的朋友，能以更为友好的学习曲线达到这个目的，而不是学到一半望而生畏，甚至放弃这个有趣的领域。

这就是这个项目开发的根——它不是厂商 SDK 的替代品，也不是一个正式发行版项目，而是一个具备入门教程、解决方案、现代嵌入式 Linux 工程样板和点子收集的仓库；一个尝试拒绝将自己框死在厂商提供的 SDK 中，鼓励大家尝试更现代工具链和基础组件的点子与手段参考的加油站。

这里的“加油站”不是终点，而是一个补给点。你可以在这里补工具链、补构建经验、补调试思路、补项目参考，然后继续改自己的板子、自己的 Rootfs、自己的应用。

---

项目定位

笔者说完价值，下面来实际的。

IMX-Forge 应当交付这些内容：

• 可复现的 Docker/主机开发环境。
• 可复现的源码组织：Git Submodule + patches + build scripts。
• 默认 BSP 构建链路：U-Boot、Linux NXP BSP、BusyBox Rootfs。
• mainline 兼顾链路：通过 CI 构建验证，并在教程中说明差异。
• alpha-board 的 Tier-1 支持。
• 可学习、可修改、可部署的驱动和用户态应用样例。
• 从最小系统到 Qt/项目应用的完整教程链路。

IMX-Forge 不应承诺这些内容：

• 长期提供可直接量产烧录的通用 binary。原因我在上面提到
• 对所有 i.MX6ULL 板卡提供同等级支持。这不现实，不可能对所有的开发板都提供等同的 CI 验证，我的钱包和精力就受不了。当然，如果某块板子受众足够大、有人愿意长期维护，那它可以进入更高支持等级。
• 每个 mainline 能力都和 BSP 实机表现完全一致。这更不可能，内核自己都在迭代。

---

我们还差什么

如果赞同上面的说法，那么我们可能还差这些东西。

为了避免这个列表看起来像“全都马上开干”，我先粗略分一下优先级：

• 第一优先级：板子上手、构建体系主线、Rootfs/应用部署、系统调试。
• 第二优先级：开发工作流、工具快捷索引、常见错误模式。
• 第三优先级：参考资源索引、小项目迭代、版本号细化。

这个优先级也欢迎大家讨论。笔者现在的判断是：先把系统工程闭环讲清楚，再去补更多花活。

1. 板子上手与硬件现实

5月16日到5月17日，笔者在忙碌的时候就在统计和审查文档，当时就发现，现在项目已有大量构建和内核内容，但“第一次拿到板子”这一段还需要更清楚。

我们可能需要补充：

• alpha-board 硬件速查：电源、启动拨码、串口、SD/eMMC、网口、LCD、触摸接口。
• 第一次上电检查：串口接线、波特率、U-Boot 进不去时怎么判断问题。
• 启动介质选择：SD、eMMC、NFS 分别适合什么阶段。
• 安全烧录教程：如何识别目标盘，如何避免写错磁盘。（感谢@Leon19960120，这位朋友提醒我 “您好像没有烧录的部分哦”，让我一下子反应过来，还真是，一直都是tftp调试的状态）
• 其他的部分（等待各位热心朋友的补充！）

2. 构建体系主线

项目已经有 release-all.sh、Docker、CI 和补丁工具，但还需要一条面向读者的主线教程。但是我注意到，这个仓库仍然，还有很多内容没有讲清楚，笔者稍微回顾了很多朋友的私信：

• 从空仓库到完整构建：clone、submodule、Docker、本地构建的完整路径。
• out/ 目录说明：哪些是中间产物，哪些是调试产物，哪些只是 CI artifact。
• BSP 默认构建链路：为什么默认 BSP，release-all.sh 实际构建了哪些东西。
• mainline 验证链路：为什么要兼顾 mainline，它在 CI 和教程中的角色是什么。
• patch 工作流实战：如何修改第三方源码、生成 patch、验证 patch。

如果漏了您的，随时在Issue中反馈！

3. Rootfs 与用户空间

内核启动完成后，会切换到用户空间并执行 Rootfs 中的 init 进程。这里是内核态与用户态的交接点，也是整个系统启动链路中最容易出现断点的一环。我们似乎还缺少好多内容：

• BusyBox Rootfs 扩展：init、mdev、fstab、网络配置、启动脚本。
• rootfs overlay 使用方式：如何把配置、应用、脚本合入 Rootfs。
• 内核模块部署：.ko 放在哪里，开机加载怎么做，如何排查加载失败。
• 固件和第三方库部署：WiFi firmware、Qt 库、字体、tslib 等这些用户态要如何放进系统。
• NFS 开发流和更加专门的调试说明：本地改应用，板端直接运行，减少反复烧卡。

4. 应用开发与部署

当前驱动和系统内容较多，但从用户态应用到板端运行之间还需要更连续。

• C/CMake 交叉编译应用教程。很多朋友可能需要快速的CMake入门
• Qt 最小应用到板端运行教程。
• Qt 触摸屏、字体、环境变量、输入设备配置教程。
• 应用部署规范：放进 rootfs overlay、NFS、/usr/bin 或 /opt/imx-forge 的选择。
• 板端调试：gdbserver、strace、日志、core dump 的基础流程。

5. 系统调试手册

调试！笔者认为，这个部分最重要了。LLM现在的确很强大，但是一些corner case，它只能靠猜测，甚至完全无能为力，我们希望提供这些场景的调试手段，一些部分笔者可能遇到了但是没有记录。我们可能需要这些内容：

• U-Boot 常见问题：串口无输出、网口不可用、环境变量错误。
• Kernel panic 常见问题：DTB 错误、rootfs 挂载失败、init 不存在。
• NFS/TFTP 排查：主机 IP、板端 IP、防火墙、WSL2 mirrored 网络。
• 模块加载失败：内核版本不匹配、符号缺失、设备树未匹配。
• 串口日志阅读路线：看到一段日志后，下一步应该查什么。

6. 开发工作流与工具链

即使文档和示例齐全，开发体验也会决定学习效率。嵌入式开发的特殊性（交叉编译、远程调试、资源受限）需要专门的工具链配置。

我们可能需要补充一下：

• VSCode 远程开发配置：

  • WSL2 / Docker 环境的 Remote-SSH 配置
  • clangd 配置（交叉编译头文件路径）
  • 远程文件编辑与本地 Git 的协同工作流
  • tasks.json 中常用的构建/烧录命令模板

• 交叉调试工作流：

  • gdbserver 在板端的部署与使用
  • VSCode / GDB 的跨平台调试配置
  • 多线程调试、断点、变量查看的注意事项
  • 调试共享库（.so）的特别配置

• 性能分析与诊断工具：

  • top、htop、ps 的基础使用
  • strace 追踪系统调用定位问题
  • perf 基础使用（如果硬件支持）
  • 内存泄漏检测基础（valgrind 替代方案）

• 日志与监控：

  • dmesg、/var/log/、串口日志的收集方法
  • systemd journal（如果使用 systemd）
  • 自定义日志系统的设计考虑

7. 工具快捷索引

嵌入式开发会用到大量命令行工具，新手往往不知道有哪些工具可用、该怎么用。

• 镜像操作：

  • dd - 烧录 SD 卡/eMMC，如何正确指定 bs 和 of
  • uuu - NXP 官方烧录工具，使用场景和基本命令
  • mkfs.* - 文件系统创建（vfat/ext4/squashfs）

• 串口与通信：

  • minicom - 串口终端，配置保存、发送文件
  • screen - 轻量级串口连接
  • picocom - 替代方案
  • cu - 传统 Unix 串口工具

• 文件系统操作：

  • cpio - initramfs 打包解包
  • squashfs - 只读压缩文件系统
  • losetup - 挂载镜像文件到 loop 设备
  • mount --bind - chroot 环境准备

• 网络与传输：

  • tftp - U-Boot 网络启动
  • nfs - 根文件系统网络挂载
  • scp / rsync - 文件传输到板端
  • netcat / nc - 快速网络调试

• 调试与分析：

  • strace - 系统调用追踪
  • ltrace - 库调用追踪
  • objdump - 反汇编、符号表查看
  • nm - 符号表提取
  • readelf - ELF 文件信息
  • file - 快速识别文件类型

8. 常见错误模式

在嵌入式 Linux 开发中会反复遇到某些相似的错误。提前识别这些模式可以大幅降低学习阻力。

• 环境类：

  • 在 Windows 路径下执行 shell 脚本（换行符问题）
  • Docker 权限问题（需要 sudo 或用户组配置）
  • WSL2 文件系统性能问题（尽量在 WSL2 内操作）

• 构建类：

  • 忘记 git submodule update 导致源码不完整
  • 交叉编译使用了错误的 toolchain（宿主机 gcc 而非 arm-linux-gnueabihf-gcc）
  • 配置时路径包含空格或特殊字符

• 烧录类：

  • 写错磁盘（没有确认 lsblk 结果）
  • 烧录后没有 sync 导致数据未落盘
  • eMMC 烧录时目标设备仍在挂载状态

• 启动类：

  • 串口波特率错误（115200 vs 9600）
  • U-Boot 环境变量错误导致启动失败
  • DTB 与内核版本不匹配

• 开发类：

  • 修改了驱动但忘记 rmmod 旧模块就 insmod 新模块
  • 应用编译成功但板端运行找不到库（LD_LIBRARY_PATH）
  • Qt 应用显示乱码（缺少字体或插件）

9. 参考资源索引

IMX-Forge 不应重复造轮，而应成为知识的"入口"和"索引"。指向权威资源可以帮用户深入理解。

建议补充参考资源索引：

• NXP 官方资源：

  • i.MX 6ULL Reference Manual（芯片手册）
  • i.MX 6ULL Applications Processor Reference Manual
  • Linux BSP 用户指南（对应版本）
  • U-Boot 和 Linux 的 NXP BSP 分支（GitHub）

• 内核与驱动：

  • Linux Kernel Documentation（官方）
  • Linux Device Drivers（LDD3）- 部分内容过时但基础概念仍有价值
  • Greg Kroah-Hartman 的驱动开发文章
  • Mainline Linux 的 IMX6ULL 设备树示例

• 工具与框架：

  • Buildroot / Yocto 官方文档（如果用户想进一步了解 Rootfs 构建）
  • Qt 官方文档，以及项目内后续整理的 Qt 教程入口
  • ARM 官方 GCC 工具链文档

• 社区与论坛：

  • NXP 官方论坛（i.MX 区）
  • Stack Overflow 嵌入式标签
  • Linux 内核邮件列表（高级用户）

10. 进入小项目迭代

会写驱动了，会处理三件套了，不做点什么，不管是出于求职，还是爱好，没有可以直接展示给别人的东西，多少也令人感到缺少点什么。

这里需要承认一下：原先规划里的 PROJ-001 / PROJ-002 有点太大了。一上来就传感器、Qt、SQLite、MQTT、Web 看板，或者 V4L2、OpenCV、ZBar、上传服务全塞进去，听着很爽，真做起来很容易变成“每个都像产品，但每个都没闭环”。

所以后续项目更适合按 MVP 推进：

• PROJ-001 环境监测站先做一个真实 I2C 传感器 + Qt 本地实时显示。
• PROJ-002 图像分析仪先做采一张图 + Qt 显示。
• 后面的多传感器、SQLite、MQTT、Web 看板、OpenCV 多算法、上传服务，都作为后续阶段。

项目推进原则

• 先做一个主项目闭环，再扩展更多项目。
• 每个项目先定义 MVP，不以最终大闭环作为第一阶段成败标准。
• BSP 是默认运行轨；mainline 必须兼顾并通过 CI 构建验证。
• 每个项目都应有教程、构建脚本、部署说明和故障排查入口。

具体做什么，原先的设计可能只会作为参考了，具体做哪些，各位可以提供一些想法和建议。

---

11. 版本号策略

这部分仍然出于草案。笔者个人倾向：正式发布版本从 v0.1.0 开始。

原因是：当前仓库没有真实 release/tag 作为版本锚点，已有 v0.5 更像历史路线图编号，不应继续混用为正式发布版本。具体的发行规则，笔者的计划是一边干，一边确定粒度。

当然，这个也欢迎讨论。如果大家觉得历史编号应该延续，也可以在这里提意见。但无论如何，我们需要把“历史里程碑编号”和“正式 release 版本号”分开。

Docker 标签建议：

标签	含义
preview	main 分支手动发布的预览镜像
latest	最新稳定 release 对应镜像
vX.Y.Z	对应 git tag 的版本镜像

package.json 中的 0.0.1 仅代表文档站点包版本，不代表 IMX-Forge 项目 release。

我们需要您的帮助

上面列出的内容并不是“马上全部完成”的承诺，而是 IMX-Forge 接下来可能补齐的方向草案。为了让项目真正解决使用者的问题，我们真的很希望更多来自实际使用者、学习者和开发者的反馈。这样整个项目才能健康的发展，尝试帮助更多朋友自由的，更加方便的入门嵌入式Linux

如果您愿意参与讨论，欢迎重点从下面几个角度给出意见：

1. 优先级建议
   您认为 IMX-Forge 接下来最应该先补哪一块？
   是板子上手、构建体系、Rootfs、应用部署、系统调试，还是驱动教程？

2. 上手断点反馈
   如果您已经尝试使用本项目，在哪一步最容易卡住？
   例如环境配置、submodule、Docker、U-Boot、Kernel、Rootfs、NFS/TFTP、烧录、串口调试等。

3. 内容取舍建议
   哪些内容您觉得很有必要补？
   哪些内容您觉得可以暂缓，甚至没有必要由 IMX-Forge 维护？

4. 开发板与场景补充
   除 alpha-board 之外，是否还有其他 i.MX6ULL 开发板值得纳入支持或文档说明？
   您是否有真实项目、学习路径、调试经验可以补充？

5. 教程与示例需求
   您更希望看到哪类教程或示例？
   例如最小 Rootfs、Qt 应用部署、驱动开发、gdbserver 调试、NFS 开发流、小型综合项目等。

6. 贡献意向
   如果您愿意参与贡献，可以直接在本 Discussion 中留言。
   无论是补文档、补脚本、补开发板经验、整理常见错误、提交 PR，还是单纯指出问题，都是非常有价值的帮助。

后续我们会基于本 Discussion 中的反馈，整理一个长期 Tracking Issue，用于拆分任务、标记优先级和跟踪进度。

English Summary

IMX-Forge is not intended to be a vendor SDK replacement or a ready-to-flash binary distribution.

Instead, it aims to become a practical "refueling station" for i.MX6ULL embedded Linux development: a place where developers can find reproducible build workflows, modern toolchain practices, BSP / mainline Linux experiments, Rootfs examples, driver tutorials, application deployment notes, debugging references, and project ideas.

This Discussion is a roadmap and requirement collection thread. It is not a promise that everything listed here will be finished immediately.

We would like to collect feedback on the following topics:

1. What should be prioritized first?

For example:

• board bring-up
• build workflow
• Rootfs and init process
• application deployment
• driver tutorials
• system debugging
• Qt examples
• small end-to-end projects

2. Where do users currently get stuck?

For example:

• environment setup
• submodules
• Docker
• U-Boot
• Kernel
• Rootfs
• NFS / TFTP
• flashing
• serial console debugging
• application deployment

3. Which topics are truly necessary?

Which parts should IMX-Forge maintain?

Which parts can be postponed, simplified, or left to external documentation?

4. Are there other boards or workflows worth documenting?

Besides alpha-board, are there other i.MX6ULL boards, development workflows, or real-world use cases that should be covered?

5. What tutorials or examples would be most useful?

For example:

• minimal Rootfs
• Qt application deployment
• Linux driver development
• gdbserver debugging
• NFS-based development workflow
• common troubleshooting guides
• small practical projects

6. Would you like to contribute?

Contributions are welcome in many forms:

• documentation
• scripts
• board notes
• debugging records
• examples
• pull requests
• issue reports
• roadmap suggestions

A separate tracking issue will be created to break this roadmap into actionable tasks and link related PRs.

[Charliechen114514]

仓库在imx-forge，欢迎您的到来！！！

[Leon19960120]

首先感谢大佬的付出！
感觉可以写一下驱动要怎么编译，比如我换个内核（boot.img）WiFi就驱动不起来了。

[Charliechen114514]

收到，这个后续专门开栏目好好说明的会！

[QAQ-cmd]

给你加油

[Charliechen114514]

嗯嗯，会加油的QAQ，刚刚就在摸鱼休息的时候构思下一步的更新