AARCH64董事会和感知

最近，我与A13进行了讨论，并意识到人们可能对AArch64板的工作方式有不同的认识：

我从2012年开始从事AArch64的研究。首先是由Armdevelopers开发的快速模型，然后是QEMU。两者都使用直接内核启动方法，而没有任何固件或引导程序。

2013年，我从Canonical / Linaro转移到Red Hat。在那里，我们从Applied Micro获得了服务器。我不记得它在构建软件时是如何启动的。一段时间后，我们有了Mustangs，所有人都在启动UEFI。

然后我回到了野马家。 Fedora，RHEL启动正常。然后CentOS和Debian加入了。所有有趣的grub-efi都喜欢我的x86-64台式机或笔记本电脑。

时间流逝，我让其他服务器可以使用。 HPe M400，ThunderX，ThunderX2，Falkor，D05等。它们每个都运行UEFI。基于Tianocore的还是商业的。

与此同时，SBC世界正与用户展开斗争。每个供应商/ SoC /板子都必须特别对待，因为无法在板子上存储固件（因为SPI闪存非常昂贵）。

一些偏移量迫使使用“过时的” MBR分区，因为没有足够的空间存储GPT信息。 UEFI系统需要GPT而不是MBR。

它还产生了很多错误信息，例如“此文件需要以大写命名（在不区分大小写的文件系统上）”或“需要第一个文件写入分区”。某种“ SBC引导伏都教”。

因此，每个SBC都需要自己的启动媒体-您无法将其与其他SoC一起放在板上，并期望它启动。或者，您花费一些时间来创建某种混合映像，其中写入了一些引导程序。更简单的方法是toprepare每个SBC单独的启动媒体映像。

有时会有带有板载闪存的SBC用于存储固件。有些人使用了它，而其他人则继续使用胶印废话。

去年为我们带来了Arm的一些规格。首先是SBBR，代表服务器基本启动要求。它说固件中应该包含哪些功能（您可以在我以前的有关Armstandards的文章中阅读更多内容）。

由于SBC不是服务器，因此为其创建了一个新规范：EBBR（E表示嵌入式）。它基本上说``尝试遵循服务器的功能''，并且有一些要求被放弃或放松。

两者的目的都是使发行人的生活更轻松。没关系，它是BSD，Linux还是Microsoft Windows-他们必须将EFI引导程序（例如Grub-efi）放入EFI系统分区中，并且系统可以在任何受支持的SBBR / EBBR硬件上引导。

例如，我有一个安装了Debian“ bullseye”的USB Pendrive。它在RockPro64和Espressobin SBC（两者都在板载闪存中存储了EBBR兼容的U-Boot）以及Mustang和HoneyComb（两者都在板载闪存中兼容SBBR的UEFI）上进行引导。

因此，看起来AArch64系统应如何引导取决于您的习惯。 当您从服务器启动时，您将采用SBBR / EBBR方式，并且大多数SBC系统的偏移量和“其他巨型”都显得怪异。 如果您使用的只是SBC，那么进入SBBR / EBBR世界可以是“ zOMG，这简直是行得通的！”。 大多数SBC已经遵循EBBR标准或可以很容易地使其合规。不用担心，您使用的是主线U型靴或自己的叉子（然后考虑上游，因为板子的寿命可能比您预期的更长）。 在配置中启用CONFIG_DISTRO_DEFAULTS选项。 构建U-Boot，将其存储到板上并启动。 然后使用``envdefault -a''命令擦除之前使用的任何环境。 下次重新启动时，您的SBC将遍历``boot_targets''变量并检查一些标准启动文件： 当它得到一些东西时，它将处理并启动。 如果不是，则转到另一个引导目标。

这基本上可以处理Arm系统上使用的每个操作系统，还可以引导通用安装ISO（只要其上的OS支持该设备）。 如果您的SBC有一些板载闪存或eMMC，则可以从中获得奖励积分。 然后可以将固件存储在此处，因此用户甚至不必担心它。