Kunpeng ecological software and hardware composition
Kunpeng Software Composition
The software ecology of the Kunpeng processor is a constantly developing software ecology. The server itself also has a variety of complexity. After a long period of development, server hardware has different operating system solutions. These operating systems often implement a layered combination of software. , it is difficult to simply describe its software architecture .
This section introduces the composition of Kunpeng software from a relatively high level, mainly from the perspective of GNU/Linux software ecology .
The following is a high-level view of the software architecture of Kunpeng GNU/Linux:
In the picture above, the bottom is the Kunpeng server hardware, which is a general-purpose server device with the Kunpeng processor as the core .
Software running on a hardware system that includes an ARM core will inevitably contain system-specific code. Such code is usually separated from other system software in the form of firmware . This section refers to the code of this feature---- hardware-specific software .
In the server field, the hardware and hardware-specific software of the server have the greatest impact on the " out-of-the-box " server, so these two parts must meet the compliance requirements related to ARM servers (see: ARMv8-A architecture , Kunpeng software Ecology and cloud services )
hardware specific software
Hardware-specific software refers to software that is specific to a system in an ARM server and is often provided in the form of firmware, mainly including the so-called Boot Loader and device-specific firmware.
This section will first introduce the Boot Loader , and then introduce the firmware requirements specifications SBSA and SBBR in the ARM server , as well as some important elements involved, such as UEFI, ACPI and ATF (ARM Trusted Firmware) .
1. Boot Loader
Boot Loader is the boot loader, which is an abbreviated version of the word Bootstrap Loader. It is usually the first software after the system is powered on or reset , so it is specific to a specific processor and motherboard.
A rough look at the startup process consists of three main stages:
- The system is powered on, and the hardware loads the Boot Loader ;
- Boot Loader loads the operating system, such as the Linux kernel;
- The operating system loads applications and user data, completing the boot process.
Among them, the main function of the Boot Loader is to act as an intermediary between the hardware and the operating system for loading the operating system. To accomplish this purpose, Boot Loader often finds and releases the operating system, and establishes the basic environment for the operating system to run (such as initializing memory, discovering hardware device parameters and returning them to the operating system, etc.). Some complex Boot Loaders will also have many additional functions, such as supporting multi-stage booting, multiple booting methods (such as Flash memory, disk, network, U disk, CD, etc.), starting multiple operating systems, updating firmware, providing running Time service, support for bottom-level debugging, etc.
In the server field, support for secure boot is also a very important feature.
2. SBSA and SBBR
Different operating systems have different requirements for the system loading process. Soc products in the field of ARM's traditional strengths - embedded devices and mobile terminals - are often customized, differentiated, and price-sensitive , and users rarely change hardware module operating systems. In these cases, the cost of custom software is far less than the cost savings of removing hardware functionality. Therefore, in such cases, the usage plan is mostly highly customized, such as "boot firmware + Boot Loader (u-boot, fastboot) + operating system (Linux) + application software"
But in the field of servers and PCs , the software is usually developed by a third party, and users only need to consider "out of the box" and "modules can be replaced". The cost of custom hardware far exceeds the cost of software. Therefore, the solutions used are generally compatible with standardized interfaces.
SBSA (Server Base Boot Requirements) and SBBR (Server Base Boot Requirements) are specifications proposed by ARM for the basic boot requirements of servers in the field of server applications .
The SBBA specification is a specification based on the hardware architecture of the ARM 64-bit processor architecture. It describes in detail the server operating system software , such as: the operating system, Hypervisor (virtual machine manager) and firmware rely on the features and key aspects of the system architecture. Including CPU, PCIe, timer, IOMMU, UART (Universal Asynchronous Receiver / Transmitter, Universal Asynchronous Receiver Transmitter), watchdog and interrupt, etc., the goal is to have enough standard system architecture to enable a proper system image to
be used in Runs on all compliant system hardware.
The SBSA standard mainly defines the requirements for the following aspects:
1.服务器在加电自检（POST）阶段应该检查的基本硬件组件，例如处理器、内存、硬盘驱动器、键盘和鼠标等。
2.服务器引导过程中需要加载的最小软件集合，包括固件（如BIOS或UEFI固件）、引导加载器（如GRUB或UEFI引导加载器）以及内核等。
3.服务器在引导过程中应该遵循的基本时序和顺序。
4.对于采用多引导架构的系统，SBSA还规定了引导过程中如何处理多个操作系统的引导选项。
The SBBR specification is a specification for system boot firmware , which defines the basic firmware requirements for an operating system or Hypervisor (virtual machine manager) on an ARM AArch64 architecture server that conforms to the SBSA standard to achieve out-of-the-box capabilities , including the required startup and Runtime service and security requirements, and follow UEFI (Unified Extensible Firmware Interface, Unified Extensible Firmware Interface) and ACPI (Advanced Adaptive Power Management Interface Specification)
SBSA/SBBR is the minimum set of requirements for ARM servers to be able to start firmware such as OS or monitors , and at the same time follows industry standards such as UEFI, ACPI, PSCI, and SMBIO. Among them, although SBSA and SBBR have similar names, they actually focus on different aspects. SBSA mainly focuses on the minimum requirements for system startup and operation, including boot loaders, runtime services, firmware abstraction, etc., while SBBR focuses on the minimum requirements for boot programs, such as UEFI's BootServices, RuntimeServices, Protocol and other basic services and protocol interfaces.
At the implementation level, the SBSA and SBBR specifications are mainly implemented through LuvOS, a customized Linux system. LuvOS is based on the Linux kernel and is obtained by compiling the tools of FWTS (Firmware Test Suite) and SBSA-ACS (ARM Server Base Architecture - Automotive and Server Consortium Starter Kit) under Linux with the standard Linux kernel.
3. UEFI
Originally introduced by Intel, UEFI is the successor to the 16-bit x86 "legacy" PC BIOS and is currently maintained by the UEFI Forum .
UEFI (Unified Extensible Firmware Interface) is a graphical standard interface used in computer firmware, which is designed to replace the traditional BIOS. UEFI is defined as an extensible firmware interface specification, which provides a set of standard APIs so that the operating system can interact with the firmware in the pre-boot environment.
The open source reference implementation of the UEFI specification is edk2 or EDK Ⅱ, and the source code is located at https://github.com/tianocore/tianocore.github.io/tree/master/edk2
The upstream development team is the TianoCore community
UEFI is displayed in a graphical interface , which is easier to use and customize than traditional BIOS. In addition, UEFI also provides some advanced features, such as network configuration, hardware diagnostics, and secure boot.
UEFI is jointly formulated by some industry-leading companies, including AMD, Intel, Microsoft, etc. With the development of computer hardware, UEFI is also evolving to meet new needs.
The UEFI specification includes a boot manager BOOT Manager, which will determine how to load executable files (maybe Boot Loader or other image files) according to the parameters in NVRAM (Non-Volatile Random Access Memory, non-volatile random access memory) , EFI (Extensible Firmware Interface) executable file format must conform to PE (Protable Executable, Portable Executable) format, PE is a widely used Windows platform
4. ACPI
ACPI (Advanced Configuration and Power Interface) is an open power management interface specification, which is designed to provide a common and standardized power management method . ACPI defines an interface specification for complete control of power management under the control of the operating system.
ACPI mainly includes the following parts:
- Tables used to describe the power state and device state in the computer system (Tables);
- Interfaces for communication between the operating system and firmware;
- Specifications for describing power supply, thermal management, and system configuration;
- Events (Events) used to provide runtime power management.
ACPI is a relatively complex specification that provides a wealth of power management functions. In the computer field, many new power management features are implemented based on ACPI.
