[参考译文] Linux：升级 AM57x SDK

Nallapaneni

我们经常更改 SDK 的原因有以下几个：

1. 底层开源软件包(U-Boot、内核等)不断变化。 我们发现、通过不断地根据这些变化重新确定我们的变化的基础、并重新测试以快速发现问题、可以更轻松地跟上这些变化。
2. 这些更改修复了错误并添加了我们希望为 SDK 用户提供的功能、因为您希望迁移到 systemd 以更好地控制引导过程。
3. 客户反馈告诉我们、许多用户希望这些频繁更新。

我们的更新计划基本上是1/qtr。 我们大约每年一次将转向最新的 LTS 内核、相应的 U-Boot 版本、Linaro GCC 工具链和 Yocto 分支。 我们的发展在大多数情况下都是上游的、即使在这些主要版本之间也是如此、这样我们的年度过渡就可以管理。

我们知道、这可能比某些用户希望的频率更频繁。 但是、除其他外、我提到的3个好处使我们有必要经常更新。 鉴于此、如果您知道您将来要更新、我建议您考虑跟踪我们的开发、将其作为常规流程的一部分。 您可以选择在某些快照上向您的客户群发布此类快照、并提供此类支持。 但是、当您需要一个新功能时、您将会更接近可能采用该新功能的"音响主机"。 其中大部分可以使用 Git、Jenkins 等标准化工具实现自动化

对于手头的特定任务、没有从 PLSDK 2.x 移植到 PLSDK 4.x 的"简单"路径 SDK 的主要版本表示大约每年发布一次。 您可以看到、这是一个两年的飞跃。 2个 LTS 内核、中间有几个中间内核。 2个主要版本的 U-Boot。 在开放源码领域、这代表了许多、许多变化、有望代表修复的错误(引入的新错误相对较少)和新功能。 我相信大家都可以看到、我列出的文件在这一巨大差距上有变化、这是很难理解的。

话虽如此、我们在公开的基础上进行开发、并展示我们通过变革可以实现的所有变革。 SDK 包含内核和 U-Boot 的 git 树、可用于评估移植工作可能会发生的更改。 它们的架构还试图将板级更改隔离到特定位置。 您实际上可以在内核补丁集中见证这一点、因为您的大多数更改都与用于硬件抽象的器件树文件相关。 您可以在 U-Boot 修补程序中看到类似的主题。 在任何内核或 U-Boot 版本中、您需要对电路板或平台进行的更改可能会与这些文件隔离。

我不会假装这项工作很简单、但最简单的方法是尽可能使用 git、组织提交到干净的补丁、在树中管理这些、这些树可以轻松地重新构建到 TI 提供的树中、 并在发生更改时根据需要移植每个功能。 有些将会非常顺利、有些则需要一些工作来了解基础代码如何更改、并进行一些重新构建以解决该问题。 Linux 和 U-Boot 维护人员以及世界各地的许多开源开发人员每天都使用这些工具来推动庞大的代码库不断向前发展。

很抱歉、我无法提供更简单的路径、但我希望我的解释能为您带来一些好处。

此致、

Ron