2019-11-25 18:54:05 +00:00
|
|
|
// SPDX-License-Identifier: MIT OR Apache-2.0
|
2019-11-01 22:03:29 +00:00
|
|
|
//
|
2020-01-01 23:41:03 +00:00
|
|
|
// Copyright (c) 2018-2020 Andre Richter <andre.o.richter@gmail.com>
|
2019-11-01 22:03:29 +00:00
|
|
|
|
|
|
|
// Rust embedded logo for `make doc`.
|
|
|
|
#![doc(html_logo_url = "https://git.io/JeGIp")]
|
|
|
|
|
2020-03-28 12:25:18 +00:00
|
|
|
//! The `kernel` binary.
|
2019-11-01 22:03:29 +00:00
|
|
|
//!
|
2020-03-28 12:25:18 +00:00
|
|
|
//! # TL;DR - Overview of important Kernel entities
|
2019-11-01 22:03:29 +00:00
|
|
|
//!
|
2020-03-28 12:25:18 +00:00
|
|
|
//! - [`bsp::console::console()`] - Returns a reference to the kernel's [console interface].
|
|
|
|
//! - [`bsp::driver::driver_manager()`] - Returns a reference to the kernel's [driver interface].
|
|
|
|
//! - [`time::time_manager()`] - Returns a reference to the kernel's [timer interface].
|
2019-11-01 22:03:29 +00:00
|
|
|
//!
|
2020-03-28 12:25:18 +00:00
|
|
|
//! [console interface]: ../libkernel/console/interface/index.html
|
|
|
|
//! [driver interface]: ../libkernel/driver/interface/trait.DriverManager.html
|
|
|
|
//! [timer interface]: ../libkernel/time/interface/trait.TimeManager.html
|
2019-11-01 22:03:29 +00:00
|
|
|
//!
|
2020-03-28 12:25:18 +00:00
|
|
|
//! # 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 memory subsystem (`src/memory.rs`) would go
|
|
|
|
//! into `src/_arch/aarch64/memory.rs`. The latter file is directly included and re-exported in
|
|
|
|
//! `src/memory.rs`, so that the architectural code parts are transparent with respect to the code's
|
|
|
|
//! module organization. That means a public function `foo()` defined in
|
|
|
|
//! `src/_arch/aarch64/memory.rs` would be reachable as `crate::memory::foo()` only.
|
|
|
|
//!
|
|
|
|
//! The `_` in `_arch` denotes that this folder is not part of the standard module hierarchy.
|
|
|
|
//! Rather, it's contents are conditionally pulled into respective files using the `#[path =
|
|
|
|
//! "_arch/xxx/yyy.rs"]` attribute.
|
|
|
|
//!
|
|
|
|
//! ## 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 transparent re-exporting 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::*`
|
2019-11-01 22:03:29 +00:00
|
|
|
|
|
|
|
#![feature(format_args_nl)]
|
2020-03-28 12:25:18 +00:00
|
|
|
#![feature(naked_functions)]
|
2019-11-01 22:03:29 +00:00
|
|
|
#![feature(panic_info_message)]
|
|
|
|
#![feature(trait_alias)]
|
|
|
|
#![no_main]
|
|
|
|
#![no_std]
|
|
|
|
|
2020-03-28 12:25:18 +00:00
|
|
|
// `mod cpu` provides the `_start()` function, the first function to run. `_start()` then calls
|
|
|
|
// `runtime_init()`, which jumps to `kernel_init()`.
|
2019-11-01 22:03:29 +00:00
|
|
|
|
|
|
|
mod bsp;
|
2020-03-28 12:25:18 +00:00
|
|
|
mod console;
|
|
|
|
mod cpu;
|
|
|
|
mod driver;
|
|
|
|
mod exception;
|
2020-01-04 17:15:43 +00:00
|
|
|
mod memory;
|
2019-11-01 22:03:29 +00:00
|
|
|
mod panic_wait;
|
|
|
|
mod print;
|
2020-03-28 12:25:18 +00:00
|
|
|
mod runtime_init;
|
|
|
|
mod synchronization;
|
|
|
|
mod time;
|
2019-11-01 22:03:29 +00:00
|
|
|
|
|
|
|
/// Early init code.
|
|
|
|
///
|
|
|
|
/// # Safety
|
|
|
|
///
|
|
|
|
/// - Only a single core must be active and running this function.
|
|
|
|
/// - The init calls in this function must appear in the correct order.
|
|
|
|
unsafe fn kernel_init() -> ! {
|
2020-03-28 12:25:18 +00:00
|
|
|
use driver::interface::DriverManager;
|
|
|
|
|
|
|
|
for i in bsp::driver::driver_manager().all_device_drivers().iter() {
|
|
|
|
if i.init().is_err() {
|
2019-11-01 22:03:29 +00:00
|
|
|
panic!("Error loading driver: {}", i.compatible())
|
|
|
|
}
|
|
|
|
}
|
2020-03-28 12:25:18 +00:00
|
|
|
bsp::driver::driver_manager().post_device_driver_init();
|
2019-11-06 21:45:29 +00:00
|
|
|
// println! is usable from here on.
|
2019-11-01 22:03:29 +00:00
|
|
|
|
|
|
|
// Transition from unsafe to safe.
|
|
|
|
kernel_main()
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The main function running after the early init.
|
|
|
|
fn kernel_main() -> ! {
|
2020-03-28 12:25:18 +00:00
|
|
|
use console::interface::All;
|
2019-11-01 22:03:29 +00:00
|
|
|
use core::time::Duration;
|
2020-03-28 12:25:18 +00:00
|
|
|
use driver::interface::DriverManager;
|
|
|
|
use time::interface::TimeManager;
|
2019-11-01 22:03:29 +00:00
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!("Booting on: {}", bsp::board_name());
|
2019-11-01 22:03:29 +00:00
|
|
|
|
2020-03-28 12:25:18 +00:00
|
|
|
let (_, privilege_level) = exception::current_privilege_level();
|
2019-12-19 13:55:24 +00:00
|
|
|
info!("Current privilege level: {}", privilege_level);
|
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!("Exception handling state:");
|
2020-03-28 12:25:18 +00:00
|
|
|
exception::asynchronous::print_state();
|
2019-11-01 22:03:29 +00:00
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!(
|
2019-11-01 22:03:29 +00:00
|
|
|
"Architectural timer resolution: {} ns",
|
2020-03-28 12:25:18 +00:00
|
|
|
time::time_manager().resolution().as_nanos()
|
2019-11-01 22:03:29 +00:00
|
|
|
);
|
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!("Drivers loaded:");
|
2020-03-28 12:25:18 +00:00
|
|
|
for (i, driver) in bsp::driver::driver_manager()
|
|
|
|
.all_device_drivers()
|
|
|
|
.iter()
|
|
|
|
.enumerate()
|
|
|
|
{
|
2019-11-13 08:11:05 +00:00
|
|
|
info!(" {}. {}", i + 1, driver.compatible());
|
2019-11-01 22:03:29 +00:00
|
|
|
}
|
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!("Timer test, spinning for 1 second");
|
2020-03-28 12:25:18 +00:00
|
|
|
time::time_manager().spin_for(Duration::from_secs(1));
|
2019-11-01 22:03:29 +00:00
|
|
|
|
2019-11-13 08:11:05 +00:00
|
|
|
info!("Echoing input now");
|
2019-11-01 22:03:29 +00:00
|
|
|
loop {
|
2020-03-28 12:25:18 +00:00
|
|
|
let c = bsp::console::console().read_char();
|
|
|
|
bsp::console::console().write_char(c);
|
2019-11-01 22:03:29 +00:00
|
|
|
}
|
|
|
|
}
|