Hardware Abstraction Layer
Posted: Wed Nov 27, 2013 1:30 pm
Recently, I've started focusing more on the design of my operating system. I'm beginning to post it here so the people here can review it and help me improve. I started by posting my general design overview at http://forum.osdev.org/viewtopic.php?f=15&t=27431, but now I'm going to go more into detail about each component. Hopefully, by focusing on one component at a time, I'll get more feedback.
The first component I'm focusing on is the Hardware Abstraction Layer, or HAL. The HAL is the lowest-level component in the OS. It implements machine-specific code, which is code that differs between machines with the same processor architectures, like IRQ controllers, system timers, real time clocks, and CPU topology detection. By abstracting different hardware configurations, the HAL provides the kernel with a consistent platform to run on.
For an example of how the HAL is implemented, I'll look at both x86-based and ARM-based systems. x86-based systems often have many differences in hardware from one system to the next, like uniprocessor vs. multiprocessor, legacy vs. ACPI, 8259 vs. APIC, PIT vs. APIC timer vs. HPET). From this, we can tell that there are many combinations of HALs that exist. Here would be all of them, and an overview of each:
On ARM-based systems, this would be somewhat different. On PCs, hardware does vary, but there's always a standard set. However, ARM-based systems can vary greatly in hardware configuration. For this reason, there will be one HAL for each different ARM-based system. There would be a BeagleBone HAL, a BCM2835 HAL, etc. This allows for there to be one kernel for each ARM architecture, and then for each kernel, have a bunch of HALs.
The first component I'm focusing on is the Hardware Abstraction Layer, or HAL. The HAL is the lowest-level component in the OS. It implements machine-specific code, which is code that differs between machines with the same processor architectures, like IRQ controllers, system timers, real time clocks, and CPU topology detection. By abstracting different hardware configurations, the HAL provides the kernel with a consistent platform to run on.
For an example of how the HAL is implemented, I'll look at both x86-based and ARM-based systems. x86-based systems often have many differences in hardware from one system to the next, like uniprocessor vs. multiprocessor, legacy vs. ACPI, 8259 vs. APIC, PIT vs. APIC timer vs. HPET). From this, we can tell that there are many combinations of HALs that exist. Here would be all of them, and an overview of each:
- Uniprocessor
- Legacy
- 8259 and PIT
Used on very old systems - APIC and APIC timer
Uniprocessor system with a usable APIC
- 8259 and PIT
Used on very old systems - APIC and APIC timer
Uniprocressor system with a usable APIC - APIC and HPET
Uniprocessor system with a usable APIC and HPET
- 8259 and PIT
- Legacy
- APIC and APIC timer
Old multiprocessor system, with MP tables used for detecting CPU topology
- APIC and APIC timer
Multiprocessor system without HPET, with ACPI used for detecting CPU topology - APIC and HPET
Multiprocessor system with HPET, with ACPI used for detecting CPU topology
- APIC and APIC timer
- Legacy
On ARM-based systems, this would be somewhat different. On PCs, hardware does vary, but there's always a standard set. However, ARM-based systems can vary greatly in hardware configuration. For this reason, there will be one HAL for each different ARM-based system. There would be a BeagleBone HAL, a BCM2835 HAL, etc. This allows for there to be one kernel for each ARM architecture, and then for each kernel, have a bunch of HALs.