2022-05-02 21:24:29 +00:00
|
|
|
// SPDX-License-Identifier: MIT OR Apache-2.0
|
|
|
|
//
|
|
|
|
// Copyright (c) 2018-2022 Andre Richter <andre.o.richter@gmail.com>
|
|
|
|
|
|
|
|
// Rust embedded logo for `make doc`.
|
|
|
|
#![doc(
|
|
|
|
html_logo_url = "https://raw.githubusercontent.com/rust-embedded/wg/master/assets/logo/ewg-logo-blue-white-on-transparent.png"
|
|
|
|
)]
|
|
|
|
|
|
|
|
//! The `kernel` library.
|
|
|
|
//!
|
|
|
|
//! Used to compose the final kernel binary.
|
|
|
|
//!
|
|
|
|
//! # Code organization and architecture
|
|
|
|
//!
|
|
|
|
//! The code is divided into different *modules*, each representing a typical **subsystem** of the
|
|
|
|
//! `kernel`. Top-level module files of subsystems reside directly in the `src` folder. For example,
|
|
|
|
//! `src/memory.rs` contains code that is concerned with all things memory management.
|
|
|
|
//!
|
|
|
|
//! ## Visibility of processor architecture code
|
|
|
|
//!
|
|
|
|
//! Some of the `kernel`'s subsystems depend on low-level code that is specific to the target
|
|
|
|
//! processor architecture. For each supported processor architecture, there exists a subfolder in
|
|
|
|
//! `src/_arch`, for example, `src/_arch/aarch64`.
|
|
|
|
//!
|
|
|
|
//! The architecture folders mirror the subsystem modules laid out in `src`. For example,
|
|
|
|
//! architectural code that belongs to the `kernel`'s MMU subsystem (`src/memory/mmu.rs`) would go
|
|
|
|
//! into `src/_arch/aarch64/memory/mmu.rs`. The latter file is loaded as a module in
|
|
|
|
//! `src/memory/mmu.rs` using the `path attribute`. Usually, the chosen module name is the generic
|
|
|
|
//! module's name prefixed with `arch_`.
|
|
|
|
//!
|
|
|
|
//! For example, this is the top of `src/memory/mmu.rs`:
|
|
|
|
//!
|
|
|
|
//! ```
|
|
|
|
//! #[cfg(target_arch = "aarch64")]
|
|
|
|
//! #[path = "../_arch/aarch64/memory/mmu.rs"]
|
|
|
|
//! mod arch_mmu;
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! Often times, items from the `arch_ module` will be publicly reexported by the parent module.
|
|
|
|
//! This way, each architecture specific module can provide its implementation of an item, while the
|
|
|
|
//! caller must not be concerned which architecture has been conditionally compiled.
|
|
|
|
//!
|
|
|
|
//! ## BSP code
|
|
|
|
//!
|
|
|
|
//! `BSP` stands for Board Support Package. `BSP` code is organized under `src/bsp.rs` and contains
|
|
|
|
//! target board specific definitions and functions. These are things such as the board's memory map
|
|
|
|
//! or instances of drivers for devices that are featured on the respective board.
|
|
|
|
//!
|
|
|
|
//! Just like processor architecture code, the `BSP` code's module structure tries to mirror the
|
|
|
|
//! `kernel`'s subsystem modules, but there is no reexporting this time. That means whatever is
|
|
|
|
//! provided must be called starting from the `bsp` namespace, e.g. `bsp::driver::driver_manager()`.
|
|
|
|
//!
|
|
|
|
//! ## Kernel interfaces
|
|
|
|
//!
|
|
|
|
//! Both `arch` and `bsp` contain code that is conditionally compiled depending on the actual target
|
|
|
|
//! and board for which the kernel is compiled. For example, the `interrupt controller` hardware of
|
|
|
|
//! the `Raspberry Pi 3` and the `Raspberry Pi 4` is different, but we want the rest of the `kernel`
|
|
|
|
//! code to play nicely with any of the two without much hassle.
|
|
|
|
//!
|
|
|
|
//! In order to provide a clean abstraction between `arch`, `bsp` and `generic kernel code`,
|
|
|
|
//! `interface` traits are provided *whenever possible* and *where it makes sense*. They are defined
|
|
|
|
//! in the respective subsystem module and help to enforce the idiom of *program to an interface,
|
|
|
|
//! not an implementation*. For example, there will be a common IRQ handling interface which the two
|
|
|
|
//! different interrupt controller `drivers` of both Raspberrys will implement, and only export the
|
|
|
|
//! interface to the rest of the `kernel`.
|
|
|
|
//!
|
|
|
|
//! ```
|
|
|
|
//! +-------------------+
|
|
|
|
//! | Interface (Trait) |
|
|
|
|
//! | |
|
|
|
|
//! +--+-------------+--+
|
|
|
|
//! ^ ^
|
|
|
|
//! | |
|
|
|
|
//! | |
|
|
|
|
//! +----------+--+ +--+----------+
|
|
|
|
//! | kernel code | | bsp code |
|
|
|
|
//! | | | arch code |
|
|
|
|
//! +-------------+ +-------------+
|
|
|
|
//! ```
|
|
|
|
//!
|
|
|
|
//! # Summary
|
|
|
|
//!
|
|
|
|
//! For a logical `kernel` subsystem, corresponding code can be distributed over several physical
|
|
|
|
//! locations. Here is an example for the **memory** subsystem:
|
|
|
|
//!
|
|
|
|
//! - `src/memory.rs` and `src/memory/**/*`
|
|
|
|
//! - Common code that is agnostic of target processor architecture and `BSP` characteristics.
|
|
|
|
//! - Example: A function to zero a chunk of memory.
|
|
|
|
//! - Interfaces for the memory subsystem that are implemented by `arch` or `BSP` code.
|
|
|
|
//! - Example: An `MMU` interface that defines `MMU` function prototypes.
|
|
|
|
//! - `src/bsp/__board_name__/memory.rs` and `src/bsp/__board_name__/memory/**/*`
|
|
|
|
//! - `BSP` specific code.
|
|
|
|
//! - Example: The board's memory map (physical addresses of DRAM and MMIO devices).
|
|
|
|
//! - `src/_arch/__arch_name__/memory.rs` and `src/_arch/__arch_name__/memory/**/*`
|
|
|
|
//! - Processor architecture specific code.
|
|
|
|
//! - Example: Implementation of the `MMU` interface for the `__arch_name__` processor
|
|
|
|
//! architecture.
|
|
|
|
//!
|
|
|
|
//! From a namespace perspective, **memory** subsystem code lives in:
|
|
|
|
//!
|
|
|
|
//! - `crate::memory::*`
|
|
|
|
//! - `crate::bsp::memory::*`
|
|
|
|
//!
|
|
|
|
//! # Boot flow
|
|
|
|
//!
|
|
|
|
//! 1. The kernel's entry point is the function `cpu::boot::arch_boot::_start()`.
|
|
|
|
//! - It is implemented in `src/_arch/__arch_name__/cpu/boot.s`.
|
|
|
|
//! 2. Once finished with architectural setup, the arch code calls `kernel_init()`.
|
|
|
|
|
|
|
|
#![allow(clippy::upper_case_acronyms)]
|
|
|
|
#![allow(incomplete_features)]
|
|
|
|
#![feature(asm_const)]
|
|
|
|
#![feature(core_intrinsics)]
|
|
|
|
#![feature(format_args_nl)]
|
|
|
|
#![feature(generic_const_exprs)]
|
2022-05-16 20:14:02 +00:00
|
|
|
#![feature(int_roundings)]
|
2022-05-16 19:55:17 +00:00
|
|
|
#![feature(is_sorted)]
|
2022-05-02 21:24:29 +00:00
|
|
|
#![feature(linkage)]
|
|
|
|
#![feature(panic_info_message)]
|
|
|
|
#![feature(step_trait)]
|
|
|
|
#![feature(trait_alias)]
|
|
|
|
#![no_std]
|
|
|
|
// Testing
|
|
|
|
#![cfg_attr(test, no_main)]
|
|
|
|
#![feature(custom_test_frameworks)]
|
|
|
|
#![reexport_test_harness_main = "test_main"]
|
|
|
|
#![test_runner(crate::test_runner)]
|
|
|
|
|
|
|
|
mod panic_wait;
|
|
|
|
mod synchronization;
|
|
|
|
|
|
|
|
pub mod backtrace;
|
|
|
|
pub mod bsp;
|
|
|
|
pub mod common;
|
|
|
|
pub mod console;
|
|
|
|
pub mod cpu;
|
|
|
|
pub mod driver;
|
|
|
|
pub mod exception;
|
|
|
|
pub mod memory;
|
|
|
|
pub mod print;
|
|
|
|
pub mod state;
|
|
|
|
pub mod symbols;
|
|
|
|
pub mod time;
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------------------------------------
|
|
|
|
// Public Code
|
|
|
|
//--------------------------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
/// Version string.
|
|
|
|
pub fn version() -> &'static str {
|
|
|
|
concat!(
|
|
|
|
env!("CARGO_PKG_NAME"),
|
|
|
|
" version ",
|
|
|
|
env!("CARGO_PKG_VERSION")
|
|
|
|
)
|
|
|
|
}
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------------------------------------
|
|
|
|
// Testing
|
|
|
|
//--------------------------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
/// The default runner for unit tests.
|
|
|
|
pub fn test_runner(tests: &[&test_types::UnitTest]) {
|
|
|
|
// This line will be printed as the test header.
|
|
|
|
println!("Running {} tests", tests.len());
|
|
|
|
|
|
|
|
for (i, test) in tests.iter().enumerate() {
|
|
|
|
print!("{:>3}. {:.<58}", i + 1, test.name);
|
|
|
|
|
|
|
|
// Run the actual test.
|
|
|
|
(test.test_func)();
|
|
|
|
|
|
|
|
// Failed tests call panic!(). Execution reaches here only if the test has passed.
|
|
|
|
println!("[ok]")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The `kernel_init()` for unit tests.
|
|
|
|
#[cfg(test)]
|
|
|
|
#[no_mangle]
|
|
|
|
unsafe fn kernel_init() -> ! {
|
2022-05-16 19:55:17 +00:00
|
|
|
use driver::interface::DriverManager;
|
|
|
|
|
2022-05-02 21:24:29 +00:00
|
|
|
exception::handling_init();
|
2022-05-16 20:14:02 +00:00
|
|
|
memory::init();
|
2022-05-16 19:55:17 +00:00
|
|
|
bsp::driver::driver_manager().qemu_bring_up_console();
|
2022-05-02 21:24:29 +00:00
|
|
|
|
|
|
|
test_main();
|
|
|
|
|
|
|
|
cpu::qemu_exit_success()
|
|
|
|
}
|