Abstract: Based on the theory of embedded operating system hardware abstraction layers (HALs), this paper designs a general-purpose hardware abstraction layer platform for embedded operating system kernel development. The general-purpose hardware abstraction layer can shield the design and development of embedded operating system kernels from the characteristics of specific hardware platforms, providing a unified hardware-related service interface. This allows the design and development of embedded operating system kernels to be independent of specific hardware platforms, while also enhancing the portability of the developed kernels. Keywords: Embedded operating system, General-purpose hardware abstraction layer (HAL), BSP, V development model . Introduction To facilitate the portability of operating systems across different hardware architectures, Microsoft first proposed designing the underlying hardware-related parts of the operating system as a separate hardware abstraction layer (HAL). The introduction of HALs has greatly promoted the versatility of embedded operating systems, making their widespread application possible. However, current BSP-based hardware abstraction layers can only solve the portability of a limited number of operating systems on hardware platforms supported by the same limited number of BSPs. Their effectiveness is very limited for the vast majority of embedded operating systems that need to be specifically customized for different embedded applications. 1 Hardware Abstraction Layer Principles 1.1 Hardware Abstraction Layer Concept Embedded systems are a special type of computer system. They consist of three main parts from bottom to top: the hardware environment, the embedded operating system, and the embedded application. The hardware environment is the hardware platform on which the entire embedded operating system and application run. Different applications typically have different hardware environments; therefore, how to effectively apply embedded operating systems to various application environments is a key issue that must be solved in the development of embedded operating systems. The hardware abstraction layer provides abstracted hardware services to the operating system and application through its interface. When the operating system or application uses the hardware abstraction layer API for design, as long as the hardware abstraction layer API can be implemented on the underlying hardware platform, the operating system and application code can be ported. In this way, the original three-layer structure of embedded systems gradually evolves into a four-layer structure. Figure 1 shows the structure of an embedded system after the introduction of the hardware abstraction layer. The hardware abstraction layer also plays an irreplaceable role in the entire embedded system design process. The traditional design flow adopts a waterfall design and development process, firstly the hardware platform is built and debugged, and then software design is carried out based on the finalized hardware platform. Because hardware and software design processes are sequential, they require a long design cycle. A hardware abstraction layer (BSP) allows software design to begin before hardware design is complete, making the entire embedded system design process a V-mode development process where hardware and software design are parallel, as shown in Figure 2. This allows the two design processes to proceed roughly simultaneously or concurrently, shortening the overall design cycle. 1.2 BSP Analysis As an implementation of the hardware abstraction layer, the Board Support Package (BSP) is a solution adopted by most existing commercial embedded operating systems to achieve portability. The BSP isolates the supported embedded operating system from the underlying hardware platform, enabling the embedded operating system to be used across the hardware platforms supported by the BSP, thereby achieving the portability and cross-platform compatibility of the embedded operating system, as well as its versatility and reusability. However, the widely used BSP-based hardware abstraction layer is designed entirely for porting existing general-purpose or commercial embedded operating systems between different hardware platforms. Therefore, the BSP-based hardware abstraction layer is closely related to the embedded operating system it supports. The BSPs supporting different embedded operating systems on the same embedded microprocessor hardware platform are completely different in terms of composition structure, functions provided to the operating system kernel, and interfaces of defined services. Therefore, the BSP of one embedded operating system cannot be used for other embedded operating systems. This hardware abstraction layer is a closed dedicated hardware abstraction layer. Therefore, we propose to provide an open and general hardware abstraction layer platform for the development and construction of upper-level embedded operating system kernels, so that the development of embedded operating system kernels on a certain hardware platform can be carried out on the hardware abstraction layer that supports this hardware platform. 2 Overall Design of General Hardware Abstraction Layer 2.1 Functional Structure Design of General Hardware Abstraction Layer The general hardware abstraction layer needs to provide unified hardware-related functional services for the upper-level operating system kernel; while the main hardware-related parts of the embedded operating system kernel include system startup initialization, task context management, interrupt exception management, and clock management. Therefore, the general hardware abstraction layer abstracts the basic hardware components of the hardware platform related to the embedded operating system kernel, provides the relevant functions of the embedded operating system kernel hardware platform, and designs the corresponding general hardware abstraction layer API interface. The overall functional structure of the general hardware abstraction layer is shown in Figure 3. (1) System Startup Initialization The startup initialization function provides the necessary hardware and software environment for the startup and operation of the operating system. During startup and initialization, direct access to the hardware platform includes the initialization settings of the CPU core registers and the settings of the port registers that play a role in system control. Through the startup initialization process, the necessary operating environment and foundation for the operation of the entire operating system kernel are provided, isolating the differences in the embedded microprocessor bus structure and storage system structure on different hardware platforms. (2) Task Context Management Task context management is responsible for the creation, deletion and switching of task register contexts in the task management part of the embedded operating system kernel. The register context of a task is an important part of the task managed by the operating system kernel. It is a reflection of the contents of the CPU core registers. Therefore, the implementation of context management depends on the organization of registers in the CPU core and is closely related to the architecture. The task context management of the general hardware abstraction layer uniformly defines the protection format of register contexts in the architecture and provides the API interface for basic operations of task contexts by task management. (3) Interrupt Exception Management Interrupt exception management is an important part of the embedded operating system kernel. The interrupt exception mechanism is an important means for the operating system kernel to communicate with external devices, make task system calls, perform error handling and achieve real-time scheduling of tasks. Therefore, the interrupt system management part of the hardware abstraction layer is the key in the entire hardware abstraction layer. The general hardware abstraction layer provides necessary wrapping for interrupt exception handling, shielding the embedded operating system kernel from the underlying interrupt exception handling. At the same time, since interrupt management must involve operations on the interrupt controller, the design of the general hardware abstraction layer abstracts the peripheral requests controlled by the interrupt controller into a unified IRQ device. The embedded operating system manages the interrupt service routines of peripherals and performs operations on the interrupt controller by operating the abstract IRQ device, thereby shielding the operating system kernel from direct operations on the interrupt controller. (4) Timing Management Timing management is responsible for providing the necessary timing mechanism for the clock tick processing in the operating system kernel, and also provides timing services for system functions outside the kernel, such as the TCP/IP protocol stack. The operating system kernel executes important timing tasks (such as task time allocation, task runtime statistics, task timed waiting for updates, etc.) through clock tick processing. Therefore, the timing function is one of the most basic and important functions that the hardware abstraction layer needs to provide to the operating system kernel. The general hardware abstraction layer (HAL) provides a unified abstract timer device for the operating system kernel based on the abstraction of hardware timers, and wraps the timer interrupt service routine. This allows the embedded operating system kernel to directly interact with the unified, general abstract timer device, implementing timing services through operations on the abstract timer, without having to directly manipulate the hardware timer. 2.2 Hierarchical Design of the General Hardware Abstraction Layer The design of the general hardware abstraction layer is to provide unified hardware platform-related functions for the development of embedded operating system kernels on various hardware platforms. Therefore, the hardware abstraction layer itself must be easily expandable and portable to different hardware platforms to support the development of embedded operating system kernels on such hardware platforms. Hardware platform-related software is divided into architecture-related and peripheral port register operation-related parts. The architecture-related software can be used on different embedded microprocessors compatible with the CPU core architecture, while the operation of peripheral port registers differs for each embedded microprocessor. Therefore, the implementation design of the general hardware abstraction layer is a three-layer structure as shown in Figure 4: a general layer, an architecture layer, and a peripheral layer. This three-layer division maximizes code reusability. (1) General Layer: The general layer is written in C language, does not involve specific operations on the architecture and peripheral port registers, and is applicable to various hardware platforms. The general layer includes: a general implementation of unified, compiler-independent data types, data structure definitions for abstract devices, and interfaces for providing various unified operation services for abstract devices to the embedded operating system kernel. The operations on CPU core registers and peripheral I/O port registers involved in the implementation of abstract device operations in the general layer are performed by calling the interfaces uniformly defined in the architecture layer and the peripheral layer. When extended or ported to other hardware platforms, the upper layer does not need to be modified, but only the lower layer needs to be replaced. (2) Architecture Layer: The architecture layer needs to be designed and implemented separately for the architecture of various embedded microprocessor CPU cores. The architecture layer defines architecture-related data types and data structures, including the definition of register context storage format and the starting address of interrupt exception vectors, the entry offset of various exception and interrupt handling, etc., and is responsible for the implementation of the architecture-related parts of the general hardware abstraction layer functions. The implementation mainly involves accessing various registers in the CPU core, operating on the interrupt exception vector table, and handling interrupts and exceptions at the lower level. The implementation of the architecture layer is carried out according to the calling interface specified by the upper layer. Therefore, the upper general layer does not need to be modified for different architectures. The operation of I/O port registers in the architecture layer is implemented by calling the peripheral layer interface. The architecture layer designed and implemented for a certain architecture can be used on the hardware platform of embedded microprocessors that are compatible with the CPU core architecture, thus making it easy to extend and port the hardware abstraction layer on the hardware platform of the embedded microprocessor that is compatible with the architecture. (3) Peripheral layer The peripheral layer is designed and implemented separately for various embedded microprocessors. The peripheral layer mainly includes the definition of peripheral I/O interfaces and device attributes (including the number of peripherals connected to the interrupt controller, the number of timers, etc.), and is responsible for accessing the port registers of each peripheral I/O device. The implementation of the peripheral layer needs to be based on the interface defined by the upper layer. The peripheral layer of the general hardware abstraction layer must provide access functions for the I/O port registers of basic I/O interfaces and devices such as memory control, bus control, interrupt controller, timer controller, and UART. The peripheral layer corresponds one-to-one with various embedded microprocessors. The peripheral layer is not universal between hardware platforms that use different embedded microprocessors. Therefore, for the extension or porting of the general hardware abstraction layer of a new embedded microprocessor, the peripheral layer needs to be redesigned and implemented. (4) Design of inter-layer interfaces In addition to providing a unified functional service interface for the embedded operating system kernel, the general hardware abstraction layer also designs a unified calling interface between the calls of each layer in order to facilitate the extension and porting to other hardware platforms. The implementation of the functions of the lower layer needs to be carried out in accordance with the interface specifications determined with the upper layer. Some interfaces between the upper and lower layers, especially the interface between the peripheral layer and the upper layer, are carried out using macro definitions. Macro definitions are replaced during pre-compilation without any performance loss during execution. On the contrary, using macro definitions directly for the operation of the lower layer can improve the execution efficiency, especially for the operation of the peripheral port register. Since the execution time of the operation itself is short, while the general function call requires the return address, parameter push, etc., these overheads may exceed the access time of these I/O port registers. Using macro definitions will not have call overhead, so the interface can directly access the lower port registers without losing the efficiency of the operation.