大多数基于 ARM 的消费设备都冻结在 LTS 内核版本中，之后就不再更新（Android、Chrome 操作系统、物联网设备等）。然而，如果您有任何 x86 设备，通常只需升级内核即可，一切都很好！
我假设两个设备的内核模块/驱动程序都在上游。
难道他们不应该像任何其他计算机一样升级假设设备树保持不变吗？
答案1
[更新]phuctv注释：
ARM 中有 SBSA/SBBR，具有这些功能的机器具有与 x86 上完全相同的正确 UEFI，并且可以启动任何符合 UEFI 的 ISO 映像或驱动器。不再有设备树的东西，并且为 SBSA 构建的 ISO 可以在任何具有 UEFI 的 ARM 板上启动...甚至还支持 Raspberry Pi 4 的 SBBR
考虑到这一点，这将主要影响 ARM 服务器，这是有道理的，这才是真正的钱所在，正如 phuctv 指出的那样，Raspberry pi 4 支持这一点。但我怀疑没有多少其他 SOC 类型的板可以做到这一点。然而，总的来说，到目前为止，这并没有显着改变以下答案，因为问题更与一般小型 ARM SOC 类型设备相关，而不是 ARM 服务器。
https://en.wikipedia.org/wiki/Server_Base_System_Architecture
从历史上看，基于 ARM 的产品通常是针对特定应用和功率配置进行定制的。基于 ARM 的硬件平台之间的差异一直是一个障碍，需要针对每个产品调整操作系统。
SBSA 旨在通过指定一组最小的标准化功能来加强 ARM 生态系统，以便为此标准平台构建的操作系统能够正确运行，而无需对符合该规范的所有硬件产品进行修改。
这使得以下内容适用于没有 SBSA 的系统，这仍然是大多数 ARM 设备，它们是 SOC，而不是服务器。
预先更正的答案：
启动 ARM/MIPS 类型设备与启动 x86 类型设备有很大不同。复杂得多。此外，大多数 SOC 类型的设备在售后为生产商带来的利润为零，但维护专有驱动程序等是一项成本，因此没有经济原因。三星、苹果等高端产品往往更新时间更长，因为涉及更多资金。迁移到较新的内核可能需要极其昂贵的驱动程序等编程时间，并且通常没有任何好处，因此，它无法完成。 –
我认为你关于上游的假设也是不正确的。如果我没记错的话，BSD 难以添加对 ARM 设备的支持的原因之一是 Linux 内核中的专有组件。 ARM 真是一团糟，特别是小型设备 SOC 类型的 ARM。坚持使用像 Raspberry pi 这样受支持的硬件，或者随着时间的推移而受到支持的其他类似的板，你会没事的。 ARM设备树也非常复杂，与x86类型的启动逻辑有很大不同，基本上每个都是它自己的东西。请记住，不存在“他们”，存在着试图赚取利润、避免成本的经济利益。
这是全球社区的大型项目是不错选择的原因之一，有人正在处理正在进行的内核/启动问题，并且有一个很大的用户群，例如 Raspberry Pi 2、3、3b、4、Zero 等，因此有一个社区处理添加对每一代硬件的支持，但在其他 SOC 上，操作系统/内核可能是由供应商制造的，这很可能是您可以在其上运行的唯一内核，除非有人可以对某些核心内容进行反向工程获得支持，但这只有在非常受欢迎的情况下才会发生，因为要做到这一点需要做很多工作。
我已经对这些东西有了足够的了解来使用它，但我不知道具体细节或复杂性，所以我不想错误地陈述它。例如，我相信 Raspberry pi 在 Linux 中受到支持，因为它们从供应商那里获得了一些专有固件，因为 Linux 是第一个支持 ARM SOC 板（如 Raspberry pi）的。这使得 FreeBSD 或 OpenBSD 甚至很难启动这些东西，更不用说运行良好了。当我们测试这个时，我们甚至无法让 NetBSD 在树莓派 4 上启动。而那是一个应该“适用于任何东西”的操作系统。其他 BSD 上的性能很糟糕，几乎可以肯定是由于 Linux 内核中缺少那些关键的专有位。我认为我们大约 8 个月前进行了这项测试，所以它可能已经改变，但那是 1 月/2 月的情况，而且这些设备在市场上已经有很多很多年了。
本文https://yuhei1-horibe.medium.com/building-and-booting-complete-customized-os-on-raspberry-pi-f743899c79d深入了解在 ARM SOC（本例中为 pi）上启动 Linux 所涉及的细节。
在构建之前，必须针对特定的目标硬件进行配置。就我而言，我专门为“Raspberry pi 3B”配置了它。您可以通过这样做找到树莓派的默认配置；
您必须替换硬件的默认配置。另外，您可以使用交互式“menuconfig”自定义“默认启动命令”、“超时”等，但这不是强制性的。
基本上，它的作用是从 SD 卡读取“内核映像”、“设备树 blob”和（如果需要）“initrd”，并将其放入 DRAM 中。另外，重要的是“kernel bootarg”。自定义这一点很重要，因为我们从外部存储挂载根文件系统 (root=/dev/sda1)。
...
配置内核，并像 u-boot 一样构建它。对于内核，配置文件位于“arch/arm64/configs”文件夹中。
这次，只有 3 个配置文件。如果是Raspberry pi 3，则选择bcmrpi3_defconfig。
请注意其中的关键区别，一个单一内核（例如 AntiX、Debian）可以在几乎任何 x86/x86_64 板上启动，但您必须为每个 SOC 板制作一个内核，而不仅仅是一个品牌，而是一个特定版本，比如 Raspberry Pi B3、4 等。因此，您正在为该特定设备构建内核，以及引导加载程序，我认为这大致正确，这与我对这些东西的理解相对应。
我再次不想弄错，但我相信主要区别是 x86 硬件启动上的 Linux 内核，然后开始发现硬件，以及通过 grub 或 lilo 从 BIOS/uefi 获取基本启动场景管他呢。
SOC ARM 必须事先获知硬件是什么、设备树等，然后将其用作与 SOC 配合使用的映射。
我欢迎对此进行更正，但这大致就是我在从稍微不同但非常面向内核的方向处理这些内容时发现的情况。
所以这两者之间根本没有可比性。我个人认为，当他们制定 ARM/SOC 规范时，这是一个非常严重的设计错误，因为它造成了这种 70 年代/80 年代/90 年代风格的无组织混乱，这些混乱在很大程度上已针对 x86 主板和系统进行了清理，但是特意随 SOC/ARM 设备重新引入的。非常复杂。
然而，像 ARM 服务器这样的东西并不像这样，例如，它会向内核启动提供标准 PCI 总线，但我不知道它们是否也需要某种类型的设备树或自定义启动设置。我确实知道一个我认识的人打算切换到 ARM 服务器，但据我所知，他从未这样做过，因为重建他的所有软件包和工具链太难了，所以上次我检查时，他仍在 x86_64 上。
请注意，我不打算将此作为答案发布，因为我没有核心专业知识来完全理解 SOC ARM 设备、MIPS、PowerPC 或 RISC-V 上的设备树和启动设置，等等，所有这些在很多方面都是相似的。
一种可能的理解方式是 SOC 是他们所谓的“IP”的集合，这些IP通常是专有知识产权，也就是说，可以做某些事情的设计，例如马里图形、网络、蓝牙等。他们使用这些在设计SOC芯片时，这就是为什么它被称为片上系统，它的芯片本身有很多组件，这有助于降低成本，加快设计过程。
以 Linux 上的蓝牙为例，该设备基本上总是位于两个位置之一：USB 总线（标准）或 PCI 总线（不太常见），并且所有蓝牙设备都通过蓝牙 USB 为 USB 运行Linux 中的驱动程序。另一方面，Raspberry pi 的版本 3 和 4 具有非常自定义的类型，据我所知，仅由 Raspberry pi 使用，甚至尝试从中获取数据也非常困难，位置是很难确定，我认为该驱动程序是专有的（不是积极的，但我认为是这样，手头没有人可以检查这一点）。
更复杂的是，一些 SOC 还具有 PCI 总线，一些东西以及 SOC 和 IP 都通过它运行。
我对参与各种支持 SOC ARM 的 Linux 项目的回忆是，它基本上是一个接一个板的案例。顺便说一句，这也是为什么升级手机如此困难，这些手机通常拥有完全专有的非开放硬件和驱动程序，这就是为什么大多数手机上的 Linux 项目往往只有一小部分支持的手机列表，通常只是来自 Google 的 Pixel，例如。