Linux 和处理器之间的兼容性

Posted 2023-02-22

【中文标题】Linux 和处理器之间的兼容性

【英文标题】：Linux and compatibility between processors

【发布时间】：2015-04-20 10:07:30

【问题描述】：

我继承了一个为两个嵌入式系统开发的嵌入式项目：基于 Atmel AT91SAM9g20 的 Glomation GESBC-9G20 和基于 Atmel AT91SAM9g25 的 Acme Systems Aria G25。目前，该项目是使用实现这些处理器的不同板的制造商提供的库存编译器构建的，并且这些板运行不同版本的 Linux 内核：

GESBC-9G20 上的uname -a 提供Linux 2.6.31.5 #10 Thu Nov 5 15:46:30 GMT 2009 armv5tejl GNU/Linux Aria G25 上的uname -a 提供Linux ariag25 3.16.1 #1 Mon Oct 13 11:44:47 BST 2014 armv5tejl GNU/Linux

制造商为每种工具链提供的工具链不兼容，一种使用 EABI 二进制文件，另一种则不兼容。

我做了一些研究，发现这两个微控制器都运行ARM926EJ-S处理器内核，但是根据数据表here和here，G20有32KB的缓存，G25有16KB的缓存。我可以使用相同的工具链为这两个微控制器构建二进制文件吗？缓存大小的差异会影响为这些处理器编译的二进制文件/内核吗？

此外，由于两个系统的应用程序共享大部分源代码，我有兴趣重新编译 linux 内核和应用程序，以便两个板运行相同版本的内核和工具-链。我认为这将使开发更容易，并会减少部署到系统所需的额外工作量。我这样想对吗？

最后，从长远来看，重新编译内核和重新构建工具链所需的额外努力是否值得？我明白每种情况可能会有所不同，但鉴于可用的信息（我目前掌握的信息也一样多），您会选择什么？

总结一下：

两个基于 ARM926EJ-S 的具有不同缓存大小的微控制器是否可以交叉兼容？ 将来为这些微控制器重新构建工具链和内核是否有益并节省开发时间？ 鉴于此信息，您会选择重新构建工具链和内核，还是继续使用现有的单独工具链？

【问题讨论】：

您的主板目前运行的是哪个版本的 Linux 内核？

@RichardPennington 我已经更新了原始问题，在两个板上都包含 uname -a 的输出。

我不确定您的应用程序是什么样的，但一种选择可能是使用单个工具链构建用户空间的东西并保持内核完好无损。如果您静态链接您的用户空间应用程序，它们可能会在两个板上运行。这样您就不必处理升级内核的复杂性，但可以从通用工具链中获得一些好处。

这些不是“微控制器”； Atmel 称它们为 MPU。缓存大小差异与代码无关。我将使用一个工具链（针对 ARM926ej-s 优化）和一个通用代码库来重建所有内容。这两个板可以使用相同的 Linux 内核映像，但使用单独的设备树 blob 启动。

【参考方案1】：

tl;dr - 从合并的 Linux 内核开始并使用 OABI 支持。看看它是如何工作的，然后考虑合并用户空间。

---

您对这个问题的表述方式使其显得很主观。事实上，只要给出一个答案就可以了。让我们考虑一些事实。首先，答案将取决于您的目标和某些组织资格。即，任何人都不可能有完全正确的答案。但是，如果我们检查一下优点和缺点，大多数人应该很清楚。

---

两个基于 ARM926EJ-S 的具有不同缓存大小的微控制器是否可以交叉兼容？

对于编译器的代码生成方面，这些几乎可以肯定是 100% 相同的。即，gcc 应该可以毫无问题地为其中一个生成代码。但是，更改编译器存在更大的问题，

依赖未定义行为的代码可能无法正常工作。 使用编译器扩展的代码需要移植。 编译器中的错误可能在源代码中有解决方法，或者在更新编译器时会导致一些潜在缺陷。 时间差异可能会暴露真正糟糕的车手的比赛条件。

为这些微控制器重新构建工具链和内核是否有益并节省未来的开发时间？

当然，这取决于。 Linux 2.6.31.5 与 Linux 2.6.32.65 不同，它不是一个稳定内核（即，它没有社区补丁）。如果供应商没有提供 git 树，则 不可能 很难分辨出哪些内容已/尚未应用于此树。所以支持这个旧版本的 Linux 可能是一项艰巨的任务。即，安全补丁、子系统更新和一般错误。如果您需要在两个平台上支持自定义驱动程序，那么类似的 Linux API 将是绝对的胜利。如果您只使用供应商 Linux 内核并且没有能力支持/更改它们，那么这可能会导致问题。

3.16 是更现代的 Linux。但是，它也不会获得社区支持。 3.14 或 3.18 目前是长期。最肯定更新到 3.18 并从 3.16 获取供应商驱动程序/设备树是相当简单的任务。所以主要的 Linux 内核问题是，

Vendor A 和 Vendor B 是否都大力支持内核？ 他们提供了多少自定义代码/驱动程序。 您的内部或外部内核能力是什么？ 您自己有自定义驱动程序吗？ 您将来是否会将硬件更新为新的芯片组。 芯片组的预期寿命。 产品是否使用Linux内的iptables、usb等子系统？

根据我的经验，1（对于任何供应商）的答案是从不！。支持这一点的人工作过度，公司不会给他们时间把事情做好。项目 4-6 将指向合并内核。在多个内核上支持东西是痛苦的。不仅用于编写代码，还用于测试。也可以让相同的二进制支持两个平台，这可能会带来其他好处。

至于工具链，您在第一个问题中遇到了用户空间问题。但是，Linux 内核应该可以很好地与各种编译器配合使用。有各种检查来查看编译器是否兼容。此外，现代 Linux 内核同时支持 OABI 和 EABI。所以完全可以让Linux内核合并，同时保持用户空间分离。

鉴于这些信息，您会选择重新构建工具链和内核，还是继续使用现有的单独工具链？

这是现在措辞的意见。供应商支持不太可能与社区一样好。但是，如果您没有使用内核和/或驱动程序的经验并且您认为硬件永远不会改变，那么您可能会坚持使用提供的 Linux 内核。供应商 Linux 中可能存在与 DDR 初始化和其他从未成为主线的硬件怪异相关的隐藏功能。拥有这些内核的源代码会很有帮助。

看来您永远不会制造或修改您的硬件。也就是说，你只使用现成的硬件，从不使用iptable/nftables之类的东西，供应商的支持还过得去，而你（组织）不擅长驱动程序/内核编程，那么它留在原地可能有意义。

否则，即使有一点能力，git 工具和社区支持也可以使内核升级相当容易。如果您的数量足够大，您也可以请求供应商更新代码，或者聘请顾问为您进行移植。毫无疑问，如果您正在编写自定义内核代码，合并后的内核将减少测试、编码并帮助自动化测试和工具。

---

如果合并内核，那么合并用户空间更有意义。即使用户空间可以是相同的代码/编译器，不同的 Linux 内核也会影响运行时行为。最终结果是，合并的代码库更容易支持。问题是，实现目标的努力是否比实现目标的好处更重要？这取决于项目和组织。

【讨论】：

至少，值得花一些时间来研究升级内核。您应该对执行此移植的时间进行一些估计。 2.6.31->3.16（或 3.18）。此外，请进行一些调查，因为可能已经在较新的内核中支持该平台。供应商并不总是让人们意识到这一点。一旦你有了主线，就更容易切换硬件（也许是第三便宜的板）。供应商至少应该有 tarballs 以符合 GPL。针对同一主线版本的递归差异将有助于判断已进行了哪些更改。