【发布时间】：2019-12-09 19:07:04
【问题描述】：
我需要为 Cortex-M MCU，特别是 STM32F7 Cortex-M7 构建一个完整的 linux 开发框架。首先我要解释一些背景信息，所以请多多包涵。
我已经下载并构建了一个带有 croostool-ng 1.24 的 gcc 工具链，指定了一个 armv7e-m 架构，只有拇指指令和 linux 4.20 作为操作系统，我希望输出是 FLAT 可执行文件（我认为这意味着bFLT)。
然后我继续使用configs/stm32_defconf 编译 linux 内核（4.20 版），然后是静态编译的busybox rootfs，全部使用我的新工具链。
内核启动得很好，但给我一个错误和内核疼痛，并显示以下消息：
正在启动 init：/sbin/init 存在但无法执行（错误 -8）
和
request_module: modprobe binfmt-464c 无法处理，kmod 忙于 50 个线程
有趣的部分是最后一条消息。我的busybox可执行文件竟然是.ELF！ Cortex-M 没有 MMU，因此在支持 .ELF 的无 MMU 架构上构建 linux 内核是不可能的，这就是为什么找不到 (464c)"LF" 二进制加载器的原因，没有。
最后，我的问题是：
如何构建 bFLT 可执行文件以在无 MMU 的 Linux 架构上运行？ 我的工具链有 elf2flt，但在 crosstool-ng 中我已经指定了无 MMU 架构和 FLAT 二进制文件，并且 我期待直接的 bFLT 输出，而不是“无用”的可执行文件。这可能吗？
或者更好：是否有文档化的标准程序来构建基于 Cortex-M 的完整、可运行的 Linux 系统？
跟进：
我放弃了构建 FLAT 二进制文件并尝试了 FDPIC 可执行文件。又一个死胡同。阿法克：
- Linux 长期以来一直支持 ELF FDPIC，但适用于 ARM 的 ABI 是相当新的。
- 似乎仍然在这个时代，GCC 还没有启用 FDPIC 的标准方法。在某些架构上，您可以使用 -mfdpic。没有手臂，不知道为什么。我什至不知道主线 GCC 是否完全支持 ARM FDPIC。如果不存在，信息将极其稀缺。
- 似乎 crosstool-ng 1.24 在构建 ARM ELF FDPIC 支持时出现问题。生成的 gcc 没有 -mfdpic，-fPIC 生成 ARM 可执行文件，而不是 ARM FDPIC。
任何见解将不胜感激。
【问题讨论】：
-
“标准程序”是使用 yocto - 特别是为您的 SoC、SoM 或至少您的特定控制器设计的 yocto 配方。
-
我无法回答您的问题，但我一直被告知 STM32 MCU 没有足够的 RAM 来运行 Linux。你考虑过这个问题吗？
-
@markus-nm 我会研究一下 yocto，谢谢！
-
@GuillaumePetitjean 这不正确。 Cortex-M3/4/7 的中/高引脚版本通常具有外部存储控制器，然后您可以添加 SDRAM。 16 Mb 应该足以运行 Linux。我的系统有 16 Mb，它启动得很好，直到它执行一些我无法正确构建的东西。
-
即使您不想使用 yocto 检查它的作用也会引导您找到答案。使用 .elf 作为 intermediate 格式是很正常的，即使对于无法在运行时加载一个然后必须将其转换为其他内容的目标，例如链接到 elf 的较小的 Cortex-M 部分然后使用 objcopy 将其写为闪存中内容的平面二进制图像，如果我记得 bFLT 的过程是相似的。我不确定您所做的事情是否具有经济意义，尤其是因为 MMU 有便宜的零件。
标签： linux gcc embedded cortex-m toolchain