AARCH64董事会和感知

2021-02-25 04:20:54

最近,我与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,则可以从中获得奖励积分。 然后可以将固件存储在此处,因此用户甚至不必担心它。