个人电脑历史

Question 1

这个问题的答案非常微妙。但根本原因是，虽然 (x86 / x86_64) PC 可能看起来非常多样化，但实际上并非如此。 SBC（通常基于 ARM）更加多样化，甚至 ARM CPU 之间也可能存在巨大差异。

个人电脑历史

PC 缺乏多样性的原因可能有点基于观点，但我大胆猜测这与 Microsoft DOS 和 Microsoft Windows 有关。他们历史上有严格的要求。我相信在早期这是可能的，因为“IBM 兼容 PC“盛行。微软编写的软件就是为了满足这个要求，而不是其他。后来微软占据了主导地位，他们可以随心所欲地要求他们喜欢的东西，硬件供应商也必须遵循。

同样，英特尔拥有如此的主导地位，以至于其他制造商（例如 AMD）为了竞争，必须确保他们的 CPU 与英特尔的兼容。尽管历史上一个有趣的点是我们现在所说的 x86_64 实际上是 AMD 的发明，又名 AMD64。

单板计算机（ARM）

大多数 SBC 都是基于 ARM 的，并且它们背后没有相同的历史。实际上ARM根本不制造CPU，他们只是将设计授权给制造商。这使得许多不同的制造商能够定制这些设计，并且没有足够的商业压力来标准化它们。

ARM SBC 多样性的实际问题

指令集

PC有非常稳定的核心指令集。是的，不同的 Intel / AMD CPU 有一些用于某些高级功能的附加指令集，但在很大程度上，对于运行操作系统来说，这些并不那么重要。它们可能会影响您可以运行的应用程序。

但对于 ARM SBC，指令集方面存在更显着的差异。举个例子，当第一个 Raspberry PI 创建时，他们使用了 ARM CPU 和硬件浮点当时，其他主要 Linux 发行版（例如 Debian）尚未编译为支持此功能。从技术上讲，它们可以工作，但它们会很多没有它会慢一些。

现在重要的是要了解核心 CPU 功能和指令集不仅由内核使用，而且还由您安装的每个软件包使用。如果您想要硬件浮点支持，并且操作系统发行版没有为其编译，那么您必须重新编译系统上的每个软件包。

内核配置

由于 CPU 的其他功能，会出现一些棘手的问题。这意味着许多ARM SBC需要修改Linux内核。现在，为了内核而发布一个全新的发行版似乎有点过分了。但有一件事是真的：

为什么 Raspbian 不能在 OrangePi 上开箱即用

如果您能够克服启动问题（如下），那么您可能仍然会发现它缺少重要的内容内核覆盖。结果可能只是缺少功能，或者可能是内核无法启动。

启动

通常，启动并不是发布全新操作系统的理由。但确实必须小心处理。

在 PC 上，许多硬件初始化要么标准化，要么由 BIOS 处理。 BIOS 存储制造商提供的软件并在操作系统之前运行。然后它负责查找并运行引导加载程序。

ARM SBC 上没有 BIOS。操作系统附带了等效软件。现在从技术上讲，没有什么可以阻止开源操作系统彼此共享此固件（请参阅Raspberry Ri 的 bootcode.bin 的许可证）。但这确实意味着每个操作系统都必须为每个不同的 SBC 提供该固件的副本...而且有许多不同的 SBC。

我相信其他 SBC 通过简单地发布现有操作系统的自己的 ISO 来解决这个问题。 Beagleboard 就是这样做的。

Answer

这个问题的答案非常微妙。但根本原因是，虽然 (x86 / x86_64) PC 可能看起来非常多样化，但实际上并非如此。 SBC（通常基于 ARM）更加多样化，甚至 ARM CPU 之间也可能存在巨大差异。

个人电脑历史

PC 缺乏多样性的原因可能有点基于观点，但我大胆猜测这与 Microsoft DOS 和 Microsoft Windows 有关。他们历史上有严格的要求。我相信在早期这是可能的，因为“IBM 兼容 PC“盛行。微软编写的软件就是为了满足这个要求，而不是其他。后来微软占据了主导地位，他们可以随心所欲地要求他们喜欢的东西，硬件供应商也必须遵循。

同样，英特尔拥有如此的主导地位，以至于其他制造商（例如 AMD）为了竞争，必须确保他们的 CPU 与英特尔的兼容。尽管历史上一个有趣的点是我们现在所说的 x86_64 实际上是 AMD 的发明，又名 AMD64。

单板计算机（ARM）

大多数 SBC 都是基于 ARM 的，并且它们背后没有相同的历史。实际上ARM根本不制造CPU，他们只是将设计授权给制造商。这使得许多不同的制造商能够定制这些设计，并且没有足够的商业压力来标准化它们。

ARM SBC 多样性的实际问题

指令集

PC有非常稳定的核心指令集。是的，不同的 Intel / AMD CPU 有一些用于某些高级功能的附加指令集，但在很大程度上，对于运行操作系统来说，这些并不那么重要。它们可能会影响您可以运行的应用程序。

但对于 ARM SBC，指令集方面存在更显着的差异。举个例子，当第一个 Raspberry PI 创建时，他们使用了 ARM CPU 和硬件浮点当时，其他主要 Linux 发行版（例如 Debian）尚未编译为支持此功能。从技术上讲，它们可以工作，但它们会很多没有它会慢一些。

现在重要的是要了解核心 CPU 功能和指令集不仅由内核使用，而且还由您安装的每个软件包使用。如果您想要硬件浮点支持，并且操作系统发行版没有为其编译，那么您必须重新编译系统上的每个软件包。

内核配置

由于 CPU 的其他功能，会出现一些棘手的问题。这意味着许多ARM SBC需要修改Linux内核。现在，为了内核而发布一个全新的发行版似乎有点过分了。但有一件事是真的：

为什么 Raspbian 不能在 OrangePi 上开箱即用

如果您能够克服启动问题（如下），那么您可能仍然会发现它缺少重要的内容内核覆盖。结果可能只是缺少功能，或者可能是内核无法启动。

启动

通常，启动并不是发布全新操作系统的理由。但确实必须小心处理。

在 PC 上，许多硬件初始化要么标准化，要么由 BIOS 处理。 BIOS 存储制造商提供的软件并在操作系统之前运行。然后它负责查找并运行引导加载程序。

ARM SBC 上没有 BIOS。操作系统附带了等效软件。现在从技术上讲，没有什么可以阻止开源操作系统彼此共享此固件（请参阅Raspberry Ri 的 bootcode.bin 的许可证）。但这确实意味着每个操作系统都必须为每个不同的 SBC 提供该固件的副本...而且有许多不同的 SBC。

我相信其他 SBC 通过简单地发布现有操作系统的自己的 ISO 来解决这个问题。 Beagleboard 就是这样做的。

Question 2

这是一个很好的问题，不幸的是很少有人知道答案，但这些知识仍然非常重要。然而，没有可能的简洁答案，所以请与我坦白。

编辑: 这篇文章总结了一点：“ARM 最终定义了一个平台，将目光投向了服务器机房” - Ars Technica

基础知识：

为了启动操作系统，每台计算机都必须执行以下强制性步骤（请注意缩写词）：

H硬件我初始化S序列（加载非常裸”乙专用集成电路司机“ 为了前端总线去完成）
F首先S塔格乙ootloader（BIOS、UEFI、U-BOOT、“程序”、“引导加载程序”等）
第二阶段引导加载程序（GRUB、LILO、SYSLINUX、BOOTMGR 等）

请注意，BDrivers 主要用于初始化一些主板组件和总线。

一切都不同的地方：

在 AMD64/EM64T (Intel)/x64 平台上，硬件初始化序列是一个非常标准化的程序。这要求计算机制造商（整车厂）将 BDrivers 嵌入到标准化 FSB 中，以便可以启动 CPU。

这意味着 x64 硬件非常多样化，但 FSB 相同，为什么一个 ISO 可以满足所有需求。这就是为什么当 OEM 厂商已经在 2009 年左右放弃软件支持时，您仍然可以从 2021 年（及以后）将 Windows XP 2005 PC/笔记本电脑升级到最新的 Windows 10 或 Linux。

相反，ARM 平台绝对不强制要求这种标准化和不强制 OEM将 BDrivers 嵌入到 FSB 中，甚至也没有嵌入 FSB。这意味着您必须嵌入 BDrivers和将您自己的 FSB 融入您自己的形象中。

由于硬件极其多样化但还有多样化的FSB，没有一个 iso 能够适合所有这些。这解释了为什么您会看到一些奇怪的、无意义的 FSB 序列，例如在 Raspberry 3 上，GPU 启动 CPU（！）。

编辑：请注意，我并不是在谈论要重新编译映像以在 ARM 平台上工作的所有内容（内核、所有系统库、最终用户软件）。

问题，碎片化：

ARM 平台上的这种差异意味着能否获得 BDrivers 仅取决于 OEM 的良好意愿这样你就可以下载它们。

不幸的是，十年来我们已经看到了 ARM 主流设备（例如 Android/Apple 设备）的工作原理：只有 OEM 可以升级您的操作系统版本，因为他们是唯一拥有 BDrivers 的厂商。

如果没有这些 BDrivers，没有人可以轻松制作自定义 ROM 或映像。因此，为什么 Android 设备上的定制 ROM 需要如此长的时间，而且由于强制逆向工程而很难制作，而且几乎没有人知道如何为苹果设备制作定制的 iOS 或 Android 映像。

UEFI、U-Boot 等甚至无法在 ARM 上拯救你：

很容易假设您所需要的只是在 ARM 平台上拥有一些标准化的 FSB，这样一切就可以像在 x64 平台上一样工作：

哪个已经事实证明是100%错误的...由 Microsoft 亲手打造 Surface（RT，2012）和 Surface 2（2013），此类设备上确实有一些 UEFI。另请注意，这些平板电脑像任何 ARM 设备一样有自己独立的映像，并且自微软多年前放弃支持以来正式停留在 Windows 8.1 上，没有任何官方升级到 Windows 10。

即使 8 年后，出于与任何 ARM 设备相同的原因，几乎不可能为这些 Surface 提供自定义/社区开发的 Windows 10 映像：这是由于微软不想发布上述BDrivers。

迄今为止（2021 年），近十年来，所有其他 Microsoft Surface 产品都在 x64 平台上发布，即 22 个 x64 设备对应 4 个 ARM 设备，这说明了很多...

最近发布的一个例外是 Surface Pro X（2019 年 10 月），arm64尽管拥有 UEFI，但即使在 1.5 年后，它仍然无法启动标准 ISO：Surface Pro X 上的 Linux 问题 - Github

这意味着绝对拥有 UEFI不保证您可以在 ARM 平台上启动标准映像。

和ARM上的UEFI一样，U-Boot的情况也是一样的：没有 BDrivers，没有图像。甚至还希望有一个标准化的 FSB。
在几乎所有 Android 设备上，情况更糟，因为通常所说的“引导加载程序”（FSB）被 OEM 锁定。 iOS 设备甚至不会给你任何通过官方方式解锁的机会，更不用说非官方的方式了。

ARM 和 Google 对这种情况的看法：

甚至 ARM 也承认 ARM 平台会造成严重的碎片混乱。他们尝试用以下方法修复服务器上的情况SBSA2014年以来：服务器基础系统架构 - 维基百科

但遗憾的是，自从SBSA平台诞生以来，除了少数服务器之外，我们还没有看到太多关于此类SBSA平台的新闻，这表明SBSA在防止碎片方面是失败的。

更糟糕的是，不太可能在主流平台（手机、平板电脑、PC 等）上看到类似 SBSA 的解决方案，因为计划报废的利润太高，而且这种情况已经持续太久了，因此 OEM 厂商是否希望恢复这种解决方案几乎没有，尤其是在 Android/iOS 设备上。

Google 试图解决 ARM 平台带来的碎片问题Project Treble，Project Mainline因为他们无法强迫 OEM 拥有标准化的 FSB 序列。目标是提供独立于 OEM ROM 的 Android 系统更新，这些 ROM 由于计划废弃而停留在特定版本上。然而，这并没有改变任何事情，而且对于定制 ROM 开发人员来说也更加困难。

事实上，谷歌当然可以迫使原始设备制造商在通过 Android 认证设备计划时拥有标准化的 FSB 序列。

但请记住，AOSP 是开源的，如果 Google 强制执行任何规定，OEM 可能会选择走自己的路。这种情况已经发生在华为、荣耀手机等搭载“HarmonyOS”的手机上：“Android 外流：更多手机制造商可能会转向华为的 HarmonyOS” - Techradar。

总而言之，这两次尝试都没有在规避 ARM 平台碎片方面取得重大进展

事实上，ARM 在设计上确实是支离破碎的。

带来更多碎片化的一件大事是 ARM 在其“架构”中使用“滚动发布”开发风格的坏习惯：

这通常会导致残酷且偷偷的功能删除，并且没有解决方法：

那里的工作正在进行中

虽然 x64 保持了从最早的 64 位 CPU（AMD 的 Athlon 64）到最新 CPU 的兼容性，但 ARM 可能不会像他们在 32 位上所做的那样：

即使在 32 位 ARM 上也存在armel差异。armhf
哪个经常
公司现在甚至可以通过 ARM 的 CXC 程序对指令集进行调整。

需要记住和考虑的几件事：

ARMv1 到 ARMv7、A32 和 AArch32 都是 32 位 ARM，这意味着我们可以合理地预期 64 位 ARM 上的损坏水平相同。
在 x64 上，很少有功能会突然消失，这意味着 2021 年的 CPU 仍然保留整个 32 位甚至 16 位兼容性（！）。如果发生（罕见的）功能删除（例如 3DNow！），通常会有一种解决方法来规避这种情况。
ARM 甚至无法拥有 10 年的向后兼容性和稳定性，更不用说从 x64 算起的 25 年了。
我们仍然拥有完美运行的 2005 x64 CPU，它们对于当今的网页浏览来说仍然足够强大。

这种向后兼容性确实可以防止碎片。

聚苯乙烯: 我的帖子确实很重。如果有人能让它更好地理解，我愿意接受建议。

Answer

这是一个很好的问题，不幸的是很少有人知道答案，但这些知识仍然非常重要。然而，没有可能的简洁答案，所以请与我坦白。

编辑: 这篇文章总结了一点：“ARM 最终定义了一个平台，将目光投向了服务器机房” - Ars Technica

基础知识：

为了启动操作系统，每台计算机都必须执行以下强制性步骤（请注意缩写词）：

H硬件我初始化S序列（加载非常裸”乙专用集成电路司机“ 为了前端总线去完成）
F首先S塔格乙ootloader（BIOS、UEFI、U-BOOT、“程序”、“引导加载程序”等）
第二阶段引导加载程序（GRUB、LILO、SYSLINUX、BOOTMGR 等）

请注意，BDrivers 主要用于初始化一些主板组件和总线。

一切都不同的地方：

在 AMD64/EM64T (Intel)/x64 平台上，硬件初始化序列是一个非常标准化的程序。这要求计算机制造商（整车厂）将 BDrivers 嵌入到标准化 FSB 中，以便可以启动 CPU。

这意味着 x64 硬件非常多样化，但 FSB 相同，为什么一个 ISO 可以满足所有需求。这就是为什么当 OEM 厂商已经在 2009 年左右放弃软件支持时，您仍然可以从 2021 年（及以后）将 Windows XP 2005 PC/笔记本电脑升级到最新的 Windows 10 或 Linux。

相反，ARM 平台绝对不强制要求这种标准化和不强制 OEM将 BDrivers 嵌入到 FSB 中，甚至也没有嵌入 FSB。这意味着您必须嵌入 BDrivers和将您自己的 FSB 融入您自己的形象中。

由于硬件极其多样化但还有多样化的FSB，没有一个 iso 能够适合所有这些。这解释了为什么您会看到一些奇怪的、无意义的 FSB 序列，例如在 Raspberry 3 上，GPU 启动 CPU（！）。

编辑：请注意，我并不是在谈论要重新编译映像以在 ARM 平台上工作的所有内容（内核、所有系统库、最终用户软件）。

问题，碎片化：

ARM 平台上的这种差异意味着能否获得 BDrivers 仅取决于 OEM 的良好意愿这样你就可以下载它们。

不幸的是，十年来我们已经看到了 ARM 主流设备（例如 Android/Apple 设备）的工作原理：只有 OEM 可以升级您的操作系统版本，因为他们是唯一拥有 BDrivers 的厂商。

如果没有这些 BDrivers，没有人可以轻松制作自定义 ROM 或映像。因此，为什么 Android 设备上的定制 ROM 需要如此长的时间，而且由于强制逆向工程而很难制作，而且几乎没有人知道如何为苹果设备制作定制的 iOS 或 Android 映像。

UEFI、U-Boot 等甚至无法在 ARM 上拯救你：

很容易假设您所需要的只是在 ARM 平台上拥有一些标准化的 FSB，这样一切就可以像在 x64 平台上一样工作：

哪个已经事实证明是100%错误的...由 Microsoft 亲手打造 Surface（RT，2012）和 Surface 2（2013），此类设备上确实有一些 UEFI。另请注意，这些平板电脑像任何 ARM 设备一样有自己独立的映像，并且自微软多年前放弃支持以来正式停留在 Windows 8.1 上，没有任何官方升级到 Windows 10。

即使 8 年后，出于与任何 ARM 设备相同的原因，几乎不可能为这些 Surface 提供自定义/社区开发的 Windows 10 映像：这是由于微软不想发布上述BDrivers。

迄今为止（2021 年），近十年来，所有其他 Microsoft Surface 产品都在 x64 平台上发布，即 22 个 x64 设备对应 4 个 ARM 设备，这说明了很多...

最近发布的一个例外是 Surface Pro X（2019 年 10 月），arm64尽管拥有 UEFI，但即使在 1.5 年后，它仍然无法启动标准 ISO：Surface Pro X 上的 Linux 问题 - Github

这意味着绝对拥有 UEFI不保证您可以在 ARM 平台上启动标准映像。

和ARM上的UEFI一样，U-Boot的情况也是一样的：没有 BDrivers，没有图像。甚至还希望有一个标准化的 FSB。
在几乎所有 Android 设备上，情况更糟，因为通常所说的“引导加载程序”（FSB）被 OEM 锁定。 iOS 设备甚至不会给你任何通过官方方式解锁的机会，更不用说非官方的方式了。

ARM 和 Google 对这种情况的看法：

甚至 ARM 也承认 ARM 平台会造成严重的碎片混乱。他们尝试用以下方法修复服务器上的情况SBSA2014年以来：服务器基础系统架构 - 维基百科

但遗憾的是，自从SBSA平台诞生以来，除了少数服务器之外，我们还没有看到太多关于此类SBSA平台的新闻，这表明SBSA在防止碎片方面是失败的。

更糟糕的是，不太可能在主流平台（手机、平板电脑、PC 等）上看到类似 SBSA 的解决方案，因为计划报废的利润太高，而且这种情况已经持续太久了，因此 OEM 厂商是否希望恢复这种解决方案几乎没有，尤其是在 Android/iOS 设备上。

Google 试图解决 ARM 平台带来的碎片问题Project Treble，Project Mainline因为他们无法强迫 OEM 拥有标准化的 FSB 序列。目标是提供独立于 OEM ROM 的 Android 系统更新，这些 ROM 由于计划废弃而停留在特定版本上。然而，这并没有改变任何事情，而且对于定制 ROM 开发人员来说也更加困难。

事实上，谷歌当然可以迫使原始设备制造商在通过 Android 认证设备计划时拥有标准化的 FSB 序列。

但请记住，AOSP 是开源的，如果 Google 强制执行任何规定，OEM 可能会选择走自己的路。这种情况已经发生在华为、荣耀手机等搭载“HarmonyOS”的手机上：“Android 外流：更多手机制造商可能会转向华为的 HarmonyOS” - Techradar。

总而言之，这两次尝试都没有在规避 ARM 平台碎片方面取得重大进展

事实上，ARM 在设计上确实是支离破碎的。

带来更多碎片化的一件大事是 ARM 在其“架构”中使用“滚动发布”开发风格的坏习惯：

这通常会导致残酷且偷偷的功能删除，并且没有解决方法：

那里的工作正在进行中

虽然 x64 保持了从最早的 64 位 CPU（AMD 的 Athlon 64）到最新 CPU 的兼容性，但 ARM 可能不会像他们在 32 位上所做的那样：

即使在 32 位 ARM 上也存在armel差异。armhf
哪个经常
公司现在甚至可以通过 ARM 的 CXC 程序对指令集进行调整。

需要记住和考虑的几件事：

ARMv1 到 ARMv7、A32 和 AArch32 都是 32 位 ARM，这意味着我们可以合理地预期 64 位 ARM 上的损坏水平相同。
在 x64 上，很少有功能会突然消失，这意味着 2021 年的 CPU 仍然保留整个 32 位甚至 16 位兼容性（！）。如果发生（罕见的）功能删除（例如 3DNow！），通常会有一种解决方法来规避这种情况。
ARM 甚至无法拥有 10 年的向后兼容性和稳定性，更不用说从 x64 算起的 25 年了。
我们仍然拥有完美运行的 2005 x64 CPU，它们对于当今的网页浏览来说仍然足够强大。

这种向后兼容性确实可以防止碎片。

聚苯乙烯: 我的帖子确实很重。如果有人能让它更好地理解，我愿意接受建议。

个人电脑历史

答案1

个人电脑历史

单板计算机（ARM）

ARM SBC 多样性的实际问题

指令集

内核配置

启动

答案2

基础知识：

一切都不同的地方：

问题，碎片化：

UEFI、U-Boot 等甚至无法在 ARM 上拯救你：

ARM 和 Google 对这种情况的看法：

事实上，ARM 在设计上确实是支离破碎的。

那里的工作正在进行中

相关内容