我需要为Cortex-M MCU构建一个完整的Linux开发框架，特别是STM32 F7 Cortex-M7。首先我得解释一些背景信息，所以请容忍我。
我已经下载并构建了一个gcc工具链，其中croostool-ng 1.24指定了一个带有thumb-only指令的armv7 e-m架构，linux 4.20作为操作系统，我希望输出是FLAT可执行文件（我假设它意味着bFLT）。
然后我继续使用configs/stm32_defconf编译linux内核（版本4.20），然后是静态编译的busybox rootfs，所有这些都使用了我的新工具链。
内核启动正常，但抛出一个错误，内核painc显示以下消息：
启动init：/sbin/init存在但无法执行（错误-8）
和
request_module：无法处理modprobe binfmt-464 c，kmod忙碌有50个线程
有趣的是最后一条信息。我的busybox excutable原来是一个.ELF！Cortex-M没有MMU，所以在.ELF支持的无MMU架构上构建Linux内核是不可能的，这就是为什么找不到（464 c）“LF”二进制加载器的原因，根本没有。
最后，我的问题是：

**如何构建bFLT可执行文件以在无MMU的Linux架构上运行？**我的工具链有elf 2flt，但在crosstool-ng中我已经指定了一个无MMU的架构和FLAT二进制文件，我期待直接的bFLT输出，而不是一个“无用的”可执行文件。这可能吗？

或者更好：是否有一个文档化的标准过程来构建一个完整的，基于Cortex-M的Linux系统？

后续行动：

我放弃了构建FLAT二进制文件，并尝试了FDPIC可执行文件。又是一条死胡同。AFAIK：

1. Linux一直支持ELF FDPIC，但ARM的ABI是相当新的。
   1.看起来，在这个时代，GCC还没有一个标准的方法来启用FDPIC。在某些体系结构上，您可以使用-mfdpic。不知道为什么，手臂上没有。我甚至不知道ARM FDPIC是否被主线GCC支持。信息是极其稀缺的，如果不存在。
2. crosstool-ng 1.24似乎在构建ARM ELF FDPIC支持时被破坏了。生成的gcc没有-mfdpic，并且-fPIC生成ARM可执行文件，而不是ARM FDPIC。
   任何见解将非常赞赏。