我继承了一个为两个嵌入式系统开发的嵌入式项目：基于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
咏叹调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且具有不同缓存大小的两个微控制器是否可以交叉兼容？
为这些微控制器重新构建工具链和内核是否会有所益处并节省未来的开发时间？
有了这些信息，您将选择重新构建工具链和内核，还是继续使用现在可用的单独工具链？
最佳答案
tl; dr-从合并的Linux内核开始并使用OABI支持。查看其工作原理，然后考虑合并用户空间。
您对这个问题的表述方式使其显得主观。实际上，仅给出答案即可。让我们考虑一些事实。首先，答案将取决于您的目标和特定的组织资格。即，任何人都不可能有完全正确的答案。但是，如果我们检查一下利弊，那么大多数情况应该是清楚的。
基于ARM926EJ-S且具有不同缓存大小的两个微控制器是否可以交叉兼容？
对于编译器的代码生成方面，几乎可以肯定它们是100％相同的。即，一个gcc应该不会为一个或另一个生成代码。但是，更改编译器存在更大的问题，
依赖未定义行为的代码可能无法正常工作。
使用编译器扩展的代码将需要移植。
编译器中的错误可能在源代码中具有解决方法，或者在更新编译器时导致某些潜在的缺陷。
时间上的差异可能会在真正糟糕的车手中暴露出比赛条件。
为这些微控制器重新构建工具链和内核是否会有所益处并节省未来的开发时间？
当然，这取决于。与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内核问题是
供应商A和供应商B是否都大力支持内核？
他们提供多少自定义代码/驱动程序。
您的内部或外部内核能力是什么？
您是否有自定义驱动程序？
您将来会否将硬件更新到新的芯片组。
芯片组的预期寿命。
该产品是否在Linux中使用iptables，usb等子系统？
以我的经验，对任何供应商来说1的答案永远不会！支持此工作的人员劳累过度，公司不会给他们时间做正确的事情。第4-6项将指向合并内核。在多个内核上支持事物是很痛苦的。不仅用于编写代码，还用于测试。在两个平台上都具有相同的二进制支持也是可能的，这可能带来其他好处。
至于工具链，您需要解决的第一个问题是用户空间。但是，Linux内核应该可以与各种编译器一起很好地工作。有各种检查来检查编译器是否兼容。另外，现代Linux内核同时支持OABI和EABI。因此，完全有可能使Linux内核合并，同时保持用户空间分离。
有了这些信息，您将选择重新构建工具链和内核，还是继续使用现在可用的单独工具链？
这是现在发表的意见。供应商的支持很难像社区一样好。但是，如果您没有内核和/或驱动程序的经验，并且您设想硬件永远不变，那么您可能会坚持使用所提供的Linux内核。供应商Linux中可能存在与DDR初始化和其他从未成为主流的硬件怪胎有关的隐藏功能。拥有这些内核的源代码很有帮助。
看来您永远不会制造或修改硬件。即，您只使用现成的硬件，而从不使用iptable / nftables之类的东西，供应商的支持是可以通过的，并且您（组织）没有能力进行驱动程序/内核编程，那么留在原地是有道理的。
否则，即使没有一点能力，git工具和社区支持也可以使内核升级变得相当容易。如果您的交易量足够大，您也可以请求供应商更新代码，或者雇用顾问为您进行移植。当然，如果您要编写自定义内核代码，则合并的内核将减少测试，编码并提供自动化测试和工具帮助。
如果合并内核，则合并用户空间更有意义。即使用户空间可以是相同的代码/编译器，但不同的Linux内核也会影响运行时行为。最终的结果是，合并的代码库更易于支持。问题是，努力实现目标重在实现目标的好处吗？这取决于项目和组织。
关于linux - Linux和处理器之间的兼容性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29744896/