DP读书：不知道干什么就和我一起读书吧——以《鲲鹏处理器 架构与编程》中鲲鹏软件的构成为例 为啥写博客：

Posted on by hackdl

DP读书：不知道干什么就和我一起读书吧

  • 为啥写博客：
    • 好处一：记录自己的学习过程
    • 优点二：让自己在各大社群里不那么尴尬
    • 推荐三：坚持下去，找到一个能支持自己的伙伴
    • 模版：鲲鹏软件构成
      • 硬件特定软件
        • 1. Boot Loader
        • 2. SBSA 与 SBBR
        • 3. UEFI
        • 4. ACPI


虽然清楚知识需要靠时间沉淀，但在看到自己做不出来的题别人会做，自己写不出的代码别人会写时还是会感到焦虑怎么办？

你是否也因为自身跟周围人的差距而产生过迷茫，这份迷茫如今是被你克服了还是仍旧让你感到困扰？来分享一下吧！

我就读了几天书，就这样了。感觉和周围人还挺不同的，所以就把这样的经历分享出来。

为啥写博客：

（质量：用自己2000+的内容和新鲜感做出来）

好处一：记录自己的学习过程

总是有人在我身边浑浑噩噩，如果这样看自己也就这么差不多了

于是

我开始出去打比赛：

		化工设计
		电赛选拔
		程序设计
		高数竞赛
		设计择优
		......

做的方向很多，也没有啥系统的计划

直到我开始打——鲲鹏开源应用设计大赛

在像往常一样的学习过程中，我发现单独对官方文档硬啃，与其他比赛不太一样，这个竞赛更多的是鲲鹏社区的视频资料为主…

习惯啃文档，学习新东西整活的我，于是做了一个大胆的决定——直接上手（我是纯小白啊…）

于是边做边研究第一个名词：openEuler

买了本书就开始啃：《鲲鹏处理器 架构与编程》

就有了我更了一周的DP读书系列：鲲鹏处理器 架构与编程

优点二：让自己在各大社群里不那么尴尬

提示：自己使用openEuler时，在官网机缘巧合加了openEuler小助手的微信，从此就潜水在openEuler的官方论坛群里，看着大佬们的对话，脑袋里一片空白，于是下定决心，要看懂他们说啥。

自己开始一点一点的读书、啃书、做笔记、敲记事本、学着写Blog、学着用AIGC帮自己画图、学着跟帖、学着画好看的图

推荐三：坚持下去，找到一个能支持自己的伙伴

小王子的作者，安托万·圣埃克苏佩里，同时拥有三位很好的异性朋友，经常深夜打电话，或者寄信给她们，想让她们帮自己看文章，最终成为一代人的童年

我就有一个不错的老友——MIN，总是能给我以精神上的激励。每每我快吐血，肝不动一点的时候，总能在相互交流话语里找到激励。

还有我妈，也总是支持我写一些东西，无论我去哪里，只要我开始动笔，或者开是思考，总是能被悄悄的感动到，我能有一个贼好的创作环境也要很感谢你。

对了，我爸，也老是把我送到很多地方，让我长些见识，创作灵感的涌现也不可或缺有他的帮助，我才今天如此。

下面是，我的一篇最近的原创：希望能作为模版提供给您参考

模版：鲲鹏软件构成

鲲鹏处理器的软件生态是一个不断发展的软件生态，服务器本身也具有复杂度多样性，经过很长时间的发展服务器硬件有不同的操作系统方案，这些操作系统往往还实现了软件的分层组合，很难简单描述其软件架构。

本节从一个比较高的层次，主要从GNU/Linux软件生态角度出发，介绍鲲鹏软件的构成。

以下为鲲鹏 GNU/Linux 的软件架构高层视图：


上图中，底部为鲲鹏服务器硬件，以 鲲鹏处理器为核心的通用服务器设备。
在包含ARM核心的硬件系统上运行的软件不可避免的会包含特定系统的代码，此类代码通常以固件形式与其他系统软件分开，本节将此特性的代码称为—-硬件特定软件。

在服务器领域，服务器的硬件与硬件特定软件对服务器“开箱即用”的影响最大，所以这两部分都要满足ARM服务器相关的合规性要求（详见：ARMv8-A 体系结构、鲲鹏软件生态与云服务）

硬件特定软件

硬件特定软件是指ARM服务器中特定系统的、常以固件形式提供的软件，主要包括所谓的Boot Loader 和设备特定固件。

本节将先介绍Boot Loader，然后介绍 ARM 服务器中的固件要求规范 SBSA 和 SBBR，以及其中 涉及到的一些重要元素， 如 UEFI、ACPI 与 ATF( ARM 可信固件)。

1. Boot Loader

Boot Loader 即启动加载程序，是 Bootstrap Loader 一词的缩写版，通常是系统上电或重置运行后的第一个软件，因此它是专门针对特定处理器和主板的。

粗略的看启动流程包括三个主要阶段：

  1. 系统上电，硬件加载Boot Loader；
  2. Boot Loader 加载操作系统，例如Linux内核；
  3. 操作系统加载应用程序和用户数据，完成启动过程。

#mermaid-svg-XFu0QJNg81dxsI5B {font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .error-icon{fill:#552222;}#mermaid-svg-XFu0QJNg81dxsI5B .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-XFu0QJNg81dxsI5B .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-XFu0QJNg81dxsI5B .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-XFu0QJNg81dxsI5B .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-XFu0QJNg81dxsI5B .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-XFu0QJNg81dxsI5B .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-XFu0QJNg81dxsI5B .marker{fill:#333333;stroke:#333333;}#mermaid-svg-XFu0QJNg81dxsI5B .marker.cross{stroke:#333333;}#mermaid-svg-XFu0QJNg81dxsI5B svg{font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-XFu0QJNg81dxsI5B .label{font-family:”trebuchet ms”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .cluster-label text{fill:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .cluster-label span{color:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .label text,#mermaid-svg-XFu0QJNg81dxsI5B span{fill:#333;color:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .node rect,#mermaid-svg-XFu0QJNg81dxsI5B .node circle,#mermaid-svg-XFu0QJNg81dxsI5B .node ellipse,#mermaid-svg-XFu0QJNg81dxsI5B .node polygon,#mermaid-svg-XFu0QJNg81dxsI5B .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-XFu0QJNg81dxsI5B .node .label{text-align:center;}#mermaid-svg-XFu0QJNg81dxsI5B .node.clickable{cursor:pointer;}#mermaid-svg-XFu0QJNg81dxsI5B .arrowheadPath{fill:#333333;}#mermaid-svg-XFu0QJNg81dxsI5B .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-XFu0QJNg81dxsI5B .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-XFu0QJNg81dxsI5B .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-XFu0QJNg81dxsI5B .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-XFu0QJNg81dxsI5B .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-XFu0QJNg81dxsI5B .cluster text{fill:#333;}#mermaid-svg-XFu0QJNg81dxsI5B .cluster span{color:#333;}#mermaid-svg-XFu0QJNg81dxsI5B div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:”trebuchet ms”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-XFu0QJNg81dxsI5B :root{–mermaid-font-family:”trebuchet ms”,verdana,arial,sans-serif;}

系统上电 加载
加载
加载
硬件
BootLoader
操作系统
应用程序和用户数据

其中，Boot Loader的主要作用就是充当硬件与操作系统之间的媒介，用于加载操作系统。为完成这一目的，Boot Loader往往要寻找并释放操作系统，建立操作系统运行的基本环境（例如初始化内存、发现硬件设备参数回传操作系统等）。一些复杂的 Boot Loader还会有很多额外的功能，如支持多阶段启动、多种启动方式（如Flash内存、磁盘、网络、U盘、光盘等）、启动多种操作系统、更新固件、提供运行时服务、支持底层调试等。

在服务器领域，支持 安全启动也是一个很重要的特性。

2. SBSA 与 SBBR

不同操作系统对系统加载过程中的要求是不一样的。在ARM的传统强项——嵌入式设备与移动终端——领域的Soc产品，往往是 定制化、差异化、价格敏感的，用户很少跟换硬件模块操作系统。在这些情况下，定制软件的成本远远小于移除硬件功能带来的成本节省。所以此类情况下使用方案多是高度定制化的，如“启动固件+Boot Loader（u-boot、fastboot）+操作系统（Linux）+应用软件”

但在 服务器和PC领域，软件通常由第三方开发，用户只要考虑“开箱即用”和“模块可更换”。定制硬件的成本远超过软件成本。所以，使用的方案一般为标准化的接口兼容的。

SBSA（Server Base Boot Requirements）和SBBR（Server Base Boot Requirements）是ARM在服务器应用领域对服务器基本启动需求提出的规范。

SBBA的规范是基于ARM 64 位处理器架构的硬件体系结构的规范，详细描述了服务器操作系统软件，如：操作系统、Hypervisor（虚拟机管理器）和固件所依赖的特性和系统架构关键层面，包括 CPU、PCIe、定时器、IOMMU、UART（Universal Asynchronous Recevier / Transmitter，通用异步收发传输器）、看门狗和中断等，目标是有足够标准的
系统架构，来使一个恰当的系统镜像能在所有符合规范的系统硬件上运行。

SBSA标准主要定义了以下方面的要求：

1.服务器在加电自检（POST）阶段应该检查的基本硬件组件，例如处理器、内存、硬盘驱动器、键盘和鼠标等。
2.服务器引导过程中需要加载的最小软件集合，包括固件（如BIOS或UEFI固件）、引导加载器（如GRUB或UEFI引导加载器）以及内核等。
3.服务器在引导过程中应该遵循的基本时序和顺序。
4.对于采用多引导架构的系统，SBSA还规定了引导过程中如何处理多个操作系统的引导选项。

SBBR规范是对系统启动固件的规范，定义了符合SBSA标准的ARM AArch64 架构的服务器上的操作系统或者Hypervisor（虚拟机管理器）要实现开箱即用能力的基本固件需求，包括所需启动和运行时的服务和安全要求，并遵循UEFI（Unified Extensible Firmware Interface，统一可拓展固件接口）和ACPI （高级适配电源管理接口规范）

SBSA/SBBR是针对ARM服务器能够启动OS或监视器等固件上提出的最小需求集，同时遵循了UEFI、ACPI、PSCI、SMBIO等工业标准。其中，SBSA和SBBR虽然名字相似，但它们实际上关注的方面有所不同。SBSA主要关注系统启动和运行的最小需求，包括启动加载程序、运行时服务、固件抽象等，而SBBR则关注引导程序的最小需求，例如UEFI的BootServices、RuntimeServices、Protocol等基础服务及协议接口。

在实现层面，SBSA和SBBR规范主要通过LuvOS这个定制化Linux系统来实现。LuvOS是基于Linux内核的，通过将FWTS（Firmware Test Suite）和SBSA-ACS（ARM Server Base Architecture – Automotive and Server Consortium Starter Kit） 在Linux下的工具与标准Linux内核共同编译获得。

3. UEFI

UEFI最早由Intel推出，是16位 x86“传统”PC BIOS的后继产品，目前由UEFI论坛维护。

UEFI（Unified Extensible Firmware Interface） 是一种在计算机固件中使用的图形化标准接口，它被设计用来替代传统的BIOS。UEFI被定义为一个可扩展的固件接口规范，它提供了一组标准的API，使得操作系统可以在预启动环境下与固件进行交互。

UEFI规范的开源参考实现是edk2 或 EDK Ⅱ,源码位于https://github.com/tianocore/tianocore.github.io/tree/master/edk2
上游开发小组为TianoCore社区

UEFI是以图形化界面展示的，相比传统的BIOS，它更易于使用和定制。此外，UEFI还提供了一些先进的功能，例如网络配置、硬件诊断和安全启动等。

UEFI是由一些行业领先的公司共同制定的，包括AMD、Intel、Microsoft等。随着计算机硬件的发展，UEFI也在不断演进，以满足新的需求。

UEFI 规范中包含一个启动管理器 BOOT Manager ,他会根据NVRAM（Non-Volatile Random Access Memory，非易失性随机访问存储器）中的参数决定如何加载可执行文件（可能是Boot Loader 或者其他镜像文件），EFI（可拓展固件接口）可执行文件格式必须符合 PE（Protable Executable，可移植可执行） 格式，PE是一种广泛应用在Windows平台上的二进制可执行文件格式。
根据SBBR规范，用于 AArch64架构的UEFI 加载镜像文件必须为64位的PE/COFF格式，并且必须包含A64格式的代码。

4. ACPI

ACPI（Advanced Configuration and Power Interface）是一种开放式电源管理接口规范，它被设计用来提供一种通用的、标准化的电源管理方式。ACPI定义了在操作系统控制之下对电源管理进行完全控制的一种接口规范。

ACPI主要包含以下几部分：

  1. 用于描述计算机系统中电源状态和设备状态的表 （Tables） ；
  2. 用于操作系统与固件之间进行通信的接口 （Interfaces） ；
  3. 用于描述电源、散热管理及系统配置的规范；
  4. 用于提供运行时电源管理的事件 （Events） 。

ACPI是一种比较复杂的规范，它提供了丰富的电源管理功能。在计算机领域，许多新的电源管理特性都是基于ACPI实现的。

我的介绍就到这里啦，感谢观看！

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用

服务器托管

咨询：董先生

电话13051898268 QQ/微信93663045！

上一篇:
下一篇: