我正在 PicoZed 板（ARM CortexA9 内核）上创建一个可启动的 Linux 系统，但我遇到了一个“限制”，我认为这并不是真正的限制（我觉得这是另一个伪装成局限性）。
我通过在 JTAG 引导模式下启动系统来引导；在板子上电后，我使用 xmd 调试器将 u-boot 放入系统的 RAM 中，然后运行它。
接下来，我将内核 (uImage)、gzip'd initramfs 映像和设备树放入内存中。最后，我告诉 u-boot 使用 bootm 引导系统，并使用三个参数指出所有映像的内存位置。
所有这些都有效，我设法启动了 Linux + 用户空间。但是，我需要增加 initramfs，这就是我遇到问题的地方。
工作图像正好是 16MiB。我尝试将其设置为 24MiB（每次尝试启动时从头开始完全重新生成），但是在内核加载并尝试查找 init 之后，内核报告文件系统故障并失败。不应该有任何重叠，但以防万一我试着移动一些东西，但同样的问题发生了。
在搜索了一些提示后，我在论坛上看到有人说图像需要放置在 16MiB 对齐（我认为这不是真的，但我还是尝试了它，但它没有得到一个工作系统）。另一篇文章声称图像必须与其尺寸对齐（我再次认为这不是真的，但我也尝试过，但没有改变）。还有一篇文章声称如果 initramfs 映像越过 __init 结束边界就会发生这种情况，并且将 initramfs 映像牢固地放置在内部将允许在内核解压缩映像后回收内存，并将其放置在 __init 部分之外工作，但启动后该内存将永远丢失。我对 Linux 知之甚少，无法知道其中任何一个是否真实/准确，而且我不知道“__init”在哪里
我还尝试了原始位置（适用于 16MiB 图像）并创建了 16MiB + 1K 大小的图像，但这也不起作用。（显然，检查它是否没有覆盖任何过度图像）。
这最初让我认为某处潜伏着 16MiB 的 initramfs 大小限制。但是在搜索它时，它让我觉得这没有意义——据我所知，u-boot 中的 bootm 命令应该为系统设置标签列表（包括 initramfs 的位置和大小)，到目前为止，我还没有遇到任何关于与 initramfs 的标记列表相关的 16MiB 限制的说明。
我发现一个页面声称 initramfs 大小实际上限制为系统中物理内存大小的大约一半，而 PicoZed 板有 1G RAM，所以我们距离“应该”的大小相差几个数量级成为一个限制。
澄清一下：16MiB 图像是原始图像的大小；压缩后不到 6MiB。但是，如果我填充它以便它没有被压缩得那么紧，它不会有任何区别 - 问题似乎与压缩图像的大小无关，仅与未压缩图像有关。
主要问题：
- 这个明显的 16MiB initramfs 大小限制来自哪里？
附带问题：
- 是否存在诸如“内核 __init 部分”之类的东西，它在内核具有未压缩/加载的图像后被内核回收？如果是这样，我如何查看/配置它的位置/大小？