Linux和处理器之间的兼容性

Posted 2021-05-01

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

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

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

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

除此之外，由于两个系统的应用程序共享其大部分源代码，我有兴趣重新编译Linux内核和应用程序，以便两个板运行相同版本的内核和工具链。我认为这将使开发更容易，并将减少部署到系统所需的额外工作量。我是否正确地思考这个？

最后，重新编译内核和重新构建工具链所需的额外工作是否值得长期努力？我很欣赏每种情况可能会有所不同，但鉴于可获得的信息（目前我也有这么多）你会选择什么？

总结一下：

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

答案

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

---

你表达这个问题的方式使它看起来很主观。事实上，只是给出一个答案。让我们考虑一些事实。首先，答案取决于您的目标和某些组织资格。即，任何人都没有完全正确的答案。但是，如果我们检查一下利弊，那么大多数情况都应该是明确的。

---

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

对于编译器的代码生成方面，这几乎肯定是100％相同。即，一个gcc应该没有麻烦为其中一个生成代码。但是，更改编译器存在更大的问题，

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

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

当然，这取决于。与Linux 2.6.32.65不同，Linux 2.6.31.5不是一个稳定的内核（即它没有社区补丁）。如果供应商没有提供git树，那就是 不可能 很难说出这棵树有什么/没有应用。因此，支持这个旧版本的Linux可能是一项艰巨的任务。即，安全补丁，子系统更新和一般错误。如果您需要在两个平台上支持自定义驱动程序，那么类似的Linux API将是一个明确的胜利。如果您只使用供应商Linux内核并且没有能力支持/更改它们，那么这可能会使问题更加严重。

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

1. 供应商A和供应商B是否都大力支持内核？
2. 他们提供了多少自定义代码/驱动程序。
3. 您的内部或外部内核能力是什么？
4. 你有自定义驱动程序吗？
5. 您将来是否会将硬件更新到新的芯片组。
6. 芯片组的预期寿命。
7. 该产品是否在Linux中使用iptables，usb等子系统？

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

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

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

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

看来你永远不会制作或修改你的硬件。即，你只使用现成的硬件，从不使用像iptable / nftables等的东西，供应商的支持是可以通过的，你（组织）不能胜任驱动程序/内核编程，那么保持投入可能是有意义的。

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

---

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