Compare commits

...

5 Commits

Author SHA1 Message Date
James Zow 502935c676
Translation Chapter 10 (#192) 8 months ago
James Zow aa7413fe79
Translation Chapter 09 (#191) 8 months ago
James Zow 2dfb9e7887
Translation Chapter 7 (#189) 8 months ago
James Zow 9fd529ff80
Translation Chapter 6 (#186) 8 months ago
James Zow daee880368
Translate Chapter 5 and modify the source file format (#187)
* Translation Chapter 05

* Modify RPi3 and RPi4 unified formats
8 months ago

@ -0,0 +1,138 @@
# 教程 05 - 驱动程序: GPIO和UART
## tl;dr
- 添加了用于真实`UART`和`GPIO`控制器的驱动程序。
- **我们将首次能够在真实硬件上运行代码** (请向下滚动查看说明)。
## 简介
在上一篇教程中,我们启用了全局安全变量,为添加第一个真实设备驱动程序奠定了基础。
我们放弃了神奇的QEMU控制台并引入了一个`驱动程序管理器`,允许`BSP`将设备驱动程序注册到`内核`中。
## 驱动程序管理器
第一步是向内核添加一个`driver subsystem`。相应的代码将位于`src/driver.rs`中。
该子系统引入了`interface::DeviceDriver`,这是每个设备驱动程序都需要实现的通用特征,并为内核所知。
在同一文件中实例化的全局`DRIVER_MANAGER`实例(类型为`DriverManager`)作为一个中央实体,可以被调用来管理内核中的所有设备驱动程序。
例如,通过使用全局可访问的`crate::driver::driver_manager().register_driver(...)`,任何代码都可以注册一个实现了`interface::DeviceDriver`特征的具有静态生命周期的对象。
在内核初始化期间,调用`crate::driver::driver_manager().init_drivers(...)`将使驱动程序管理器遍历所有已注册的驱动程序,
并启动它们的初始化,并执行可选的`post-init callback`,该回调可以与驱动程序一起注册。
例如,此机制用于在`UART`驱动程序初始化后将其切换为主系统控制台的驱动程序。
## BSP驱动程序实现
在`src/bsp/raspberrypi/driver.rs`中,函数`init()`负责注册`UART`和`GPIO`驱动程序。
因此,在内核初始化期间,按照以下来自`main.rs`的代码,正确的顺序是:
i首先初始化BSP驱动程序子系统然后ii调用`driver_manager()`。
```rust
unsafe fn kernel_init() -> ! {
// Initialize the BSP driver subsystem.
if let Err(x) = bsp::driver::init() {
panic!("Error initializing BSP driver subsystem: {}", x);
}
// Initialize all device drivers.
driver::driver_manager().init_drivers();
// println! is usable from here on.
```
驱动程序本身存储在`src/bsp/device_driver`中,并且可以在不同的`BSP`之间重复使用
在这些教程中添加的第一个驱动程序是`PL011Uart`驱动程序:它实现了`console::interface::*`特征,并且从现在开始用作主系统控制台。
第二个驱动程序是`GPIO`驱动程序,它根据需要将`RPii's`的`UART`映射(即将来自`SoC`内部的信号路由到实际的硬件引脚)。
请注意,`GPIO`驱动程序区分**RPi 3**和**RPi 4**。它们的硬件不同,因此我们必须在软件中进行适配。
现在,`BSP`还包含了一个内存映射表,位于`src/bsp/raspberrypi/memory.rs`中。它提供了树莓派的`MMIO`地址,
`BSP`使用这些地址来实例化相应的设备驱动程序,以便驱动程序代码知道在内存中找到设备的寄存器的位置。
## SD卡启动
由于我们现在有了真实的`UART`输出,我们可以在真实的硬件上运行代码。
由于前面提到的`GPIO`驱动程序的差异,构建过程在**RPi 3**和**RPi 4**之间有所区别。
默认情况下,所有的`Makefile`目标都将为**RPi 3**构建。
为了**RPi 4**构建,需要在每个目标前加上`BSP=rpi4`。例如:
```console
$ BSP=rpi4 make
$ BSP=rpi4 make doc
```
不幸的是QEMU目前还不支持**RPi 4**,因此`BSP=rpi4 make qemu`无法工作。
**准备SD卡的一些步骤在RPi3和RPi4之间有所不同请在以下操作中小心。**
### 通用步骤
1. 创建一个名为`boot`的`FAT32`分区。
2. 在SD卡上生成一个名为`config.txt`的文件,并将以下内容写入其中:
```txt
arm_64bit=1
init_uart_clock=48000000
```
### RPi 3
3. 从[Raspberry Pi firmware repo](https://github.com/raspberrypi/firmware/tree/master/boot)中将以下文件复制到SD卡上
- [bootcode.bin](https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin)
- [fixup.dat](https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat)
- [start.elf](https://github.com/raspberrypi/firmware/raw/master/boot/start.elf)
4. 运行`make`命令。
### RPi 4
3. 从[Raspberry Pi firmware repo](https://github.com/raspberrypi/firmware/tree/master/boot)中将以下文件复制到SD卡上
- [fixup4.dat](https://github.com/raspberrypi/firmware/raw/master/boot/fixup4.dat)
- [start4.elf](https://github.com/raspberrypi/firmware/raw/master/boot/start4.elf)
- [bcm2711-rpi-4-b.dtb](https://github.com/raspberrypi/firmware/raw/master/boot/bcm2711-rpi-4-b.dtb)
4. 运行`BSP=rpi4 make`命令。
_**注意**: 如果在您的RPi4上无法正常工作请尝试将`start4.elf`重命名为`start.elf` (不带4)
并复制到SD卡上。_
### 再次通用步骤
5. 将`kernel8.img`复制到SD卡上并将SD卡插入RPi。
6. 运行`miniterm` target在主机上打开UART设备
```console
$ make miniterm
```
> ❗ **注意**: `Miniterm`假设默认的串行设备名称为`/dev/ttyUSB0`。Depending on your
> 根据您的主机操作系统,设备名称可能会有所不同。例如,在`macOS`上,它可能是
> `/dev/tty.usbserial-0001`之类的。在这种情况下,请明确提供设备名称:
```console
$ DEV_SERIAL=/dev/tty.usbserial-0001 make miniterm
```
7. 将USB串口连接到主机PC。
- 请参考[top-level README](../README.md#-usb-serial-output)中的接线图。
- **注意**: TX发送线连接到RX接收引脚。
- 确保您**没有**连接USB串口的电源引脚只连接RX/TX和GND引脚。
8. 将RPi连接到USB电源线并观察输出。
```console
Miniterm 1.0
[MT] ⏳ Waiting for /dev/ttyUSB0
[MT] ✅ Serial connected
[0] mingo version 0.5.0
[1] Booting on: Raspberry Pi 3
[2] Drivers loaded:
1. BCM PL011 UART
2. BCM GPIO
[3] Chars written: 117
[4] Echoing input now
```
8. 通过按下<kbd>ctrl-c</kbd>退出。
## 相比之前的变化diff
请检查[英文版本](README.md#diff-to-previous),这是最新的。

@ -54,8 +54,8 @@ The drivers themselves are stored in `src/bsp/device_driver`, and can be reused
first driver added in these tutorials is the `PL011Uart` driver: It implements the
`console::interface::*` traits and is from now on used as the main system console. The second driver
is the `GPIO` driver, which pinmuxes (that is, routing signals from inside the `SoC` to actual HW
pins) the RPi's PL011 UART accordingly. Note how the `GPIO` driver differentiates between **RPi3**
and **RPi4**. Their HW is different, so we have to account for it in SW.
pins) the RPi's PL011 UART accordingly. Note how the `GPIO` driver differentiates between **RPi 3**
and **RPi 4**. Their HW is different, so we have to account for it in SW.
The `BSP`s now also contain a memory map in `src/bsp/raspberrypi/memory.rs`. It provides the
Raspberry's `MMIO` addresses which are used by the `BSP` to instantiate the respective device
@ -64,18 +64,18 @@ drivers, so that the driver code knows where to find the device's registers in m
## Boot it from SD card
Since we have real `UART` output now, we can run the code on the real hardware. Building is
differentiated between the **RPi 3** and the **RPi4** due to before mentioned differences in the
differentiated between the **RPi 3** and the **RPi 4** due to before mentioned differences in the
`GPIO` driver. By default, all `Makefile` targets will build for the **RPi 3**. In order to build
for the the **RPi4**, prepend `BSP=rpi4` to each target. For example:
for the the **RPi 4**, prepend `BSP=rpi4` to each target. For example:
```console
$ BSP=rpi4 make
$ BSP=rpi4 make doc
```
Unfortunately, QEMU does not yet support the **RPi4**, so `BSP=rpi4 make qemu` won't work.
Unfortunately, QEMU does not yet support the **RPi 4**, so `BSP=rpi4 make qemu` won't work.
**Some steps for preparing the SD card differ between RPi3 and RPi4, so be careful in the
**Some steps for preparing the SD card differ between RPi 3 and RPi 4, so be careful in the
following.**
### Common for both
@ -87,7 +87,7 @@ following.**
arm_64bit=1
init_uart_clock=48000000
```
### Pi 3
### RPi 3
3. Copy the following files from the [Raspberry Pi firmware repo](https://github.com/raspberrypi/firmware/tree/master/boot) onto the SD card:
- [bootcode.bin](https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin)
@ -95,7 +95,7 @@ init_uart_clock=48000000
- [start.elf](https://github.com/raspberrypi/firmware/raw/master/boot/start.elf)
4. Run `make`.
### Pi 4
### RPi 4
3. Copy the following files from the [Raspberry Pi firmware repo](https://github.com/raspberrypi/firmware/tree/master/boot) onto the SD card:
- [fixup4.dat](https://github.com/raspberrypi/firmware/raw/master/boot/fixup4.dat)
@ -104,7 +104,7 @@ init_uart_clock=48000000
4. Run `BSP=rpi4 make`.
_**Note**: Should it not work on your RPi4, try renaming `start4.elf` to `start.elf` (without the 4)
_**Note**: Should it not work on your RPi 4, try renaming `start4.elf` to `start.elf` (without the 4)
on the SD card._
### Common again

@ -0,0 +1,116 @@
# 教程06 - UART链加载器
## tl;dr
- 从SD卡上运行是一次不错的体验但是每次都为每个新的二进制文件这样做将非常繁琐。
因此,让我们编写一个[chainloader]。
- 这将是您需要放在SD卡上的最后一个二进制文件。
每个后续的教程都将在`Makefile`中提供一个`chainboot`,让您方便地通过`UART`加载内核。
[chainloader]: https://en.wikipedia.org/wiki/Chain_loading
## 注意
请注意,这个教程中有一些内容仅通过查看源代码很难理解。
大致的意思是,在`boot.s`中,我们编写了一段[position independent code]代码,
它会自动确定固件加载二进制文件的位置(`0x8_0000`),以及链接到的位置(`0x200_0000`,参见 `kernel.ld`)。
然后,二进制文件将自身从加载地址复制到链接地址(也就是"重定位"自身),然后跳转到`_start_rust()`的重定位版本。
由于链加载程序现在已经"脱离了路径",它现在可以从`UART`接收另一个内核二进制文件并将其复制到RPi固件的标准加载地址`0x8_0000`。
最后,它跳转到`0x8_0000`新加载的二进制文件会透明地执行就好像它一直从SD卡加载一样。
在我有时间详细写下这些内容之前,请耐心等待。目前,请将这个教程视为一种便利功能的启用程序,它允许快速启动以下教程。
_对于那些渴望深入了解的人可以直接跳到第[15章](../15_virtual_mem_part3_precomputed_tables)阅读README的前半部分
其中讨论了`Load Address != Link Address`的问题_。
[position independent code]: https://en.wikipedia.org/wiki/Position-independent_code
## 安装并测试它
我们的链加载程序称为`MiniLoad`,受到了[raspbootin]的启发。
您可以按照以下教程尝试它:
1. 根据您的目标硬件运行命令:`make`或`BSP=rpi4 make`。
1. 将`kernel8.img`复制到SD卡中并将SD卡重新插入您的RPi。
1. 运行命令`make chainboot`或`BSP=rpi4 make chainboot`。
1. 将USB串口连接到您的主机PC上。
- 请参考[top-level README](../README.md#-usb-serial-output)中的接线图。
- 确保您**没有**连接USB串口的电源引脚只连接RX/TX和GND。
1. 将RPi连接到USB电源线。
1. 观察加载程序通过`UART`获取内核:
> ❗ **注意**: `make chainboot`假设默认的串行设备名称为`/dev/ttyUSB0`。根据您的主机操作系统,设备名称可能会有所不同。
> 例如,在`macOS`上,它可能是类似于`/dev/tty.usbserial-0001`的名称。
> 在这种情况下,请明确给出设备名称:
```console
$ DEV_SERIAL=/dev/tty.usbserial-0001 make chainboot
```
[raspbootin]: https://github.com/mrvn/raspbootin
```console
$ make chainboot
[...]
Minipush 1.0
[MP] ⏳ Waiting for /dev/ttyUSB0
[MP] ✅ Serial connected
[MP] 🔌 Please power the target now
__ __ _ _ _ _
| \/ (_)_ _ (_) | ___ __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_| |_|_|_||_|_|____\___/\__,_\__,_|
Raspberry Pi 3
[ML] Requesting binary
[MP] ⏩ Pushing 7 KiB ==========================================🦀 100% 0 KiB/s Time: 00:00:00
[ML] Loaded! Executing the payload now
[0] mingo version 0.5.0
[1] Booting on: Raspberry Pi 3
[2] Drivers loaded:
1. BCM PL011 UART
2. BCM GPIO
[3] Chars written: 117
[4] Echoing input now
```
在这个教程中,为了演示目的,加载了上一个教程中的内核版本。在后续的教程中,将使用工作目录的内核。
## 测试它
这个教程中的`Makefile`有一个额外的目标`qemuasm`,它可以让你很好地观察到内核在重新定位后如何从加载地址区域(`0x80_XXX`
跳转到重新定位的代码(`0x0200_0XXX`
```console
$ make qemuasm
[...]
N:
0x00080030: 58000140 ldr x0, #0x80058
0x00080034: 9100001f mov sp, x0
0x00080038: 58000141 ldr x1, #0x80060
0x0008003c: d61f0020 br x1
----------------
IN:
0x02000070: 9400044c bl #0x20011a0
----------------
IN:
0x020011a0: 90000008 adrp x8, #0x2001000
0x020011a4: 90000009 adrp x9, #0x2001000
0x020011a8: f9446508 ldr x8, [x8, #0x8c8]
0x020011ac: f9446929 ldr x9, [x9, #0x8d0]
0x020011b0: eb08013f cmp x9, x8
0x020011b4: 54000109 b.ls #0x20011d4
[...]
```
## 相比之前的变化diff
请检查[英文版本](README.md#diff-to-previous),这是最新的。

@ -0,0 +1,45 @@
# 教程 07 - 时间戳
## tl;dr
- 我们为计时器硬件添加了抽象,并在`_arch/aarch64`中实现了ARM架构计时器。
- 新的计时器函数用于给UART打印添加时间戳并且用于消除`GPIO`设备驱动中基于周期的延迟,从而提高准确性。
- 添加了`warn!()`宏。
## 测试它
请通过 chainboot 进行检查(在上一个教程中添加)。
```console
$ make chainboot
[...]
Minipush 1.0
[MP] ⏳ Waiting for /dev/ttyUSB0
[MP] ✅ Serial connected
[MP] 🔌 Please power the target now
__ __ _ _ _ _
| \/ (_)_ _ (_) | ___ __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_| |_|_|_||_|_|____\___/\__,_\__,_|
Raspberry Pi 3
[ML] Requesting binary
[MP] ⏩ Pushing 12 KiB =========================================🦀 100% 0 KiB/s Time: 00:00:00
[ML] Loaded! Executing the payload now
[ 0.143123] mingo version 0.7.0
[ 0.143323] Booting on: Raspberry Pi 3
[ 0.143778] Architectural timer resolution: 52 ns
[ 0.144352] Drivers loaded:
[ 0.144688] 1. BCM PL011 UART
[ 0.145110] 2. BCM GPIO
[W 0.145469] Spin duration smaller than architecturally supported, skipping
[ 0.146313] Spinning for 1 second
[ 1.146715] Spinning for 1 second
[ 2.146938] Spinning for 1 second
```
## 相比之前的变化diff
请检查[英文版本](README.md#diff-to-previous),这是最新的。

@ -0,0 +1,182 @@
# 教程 09 - 特权级别
## tl;dr
- 在早期引导代码中,我们从`Hypervisor`特权级别AArch64中的`EL2`)过渡到`Kernel` `EL1`)特权级别。
## 目录
- [介绍](#介绍)
- [本教程的范围](#本教程的范围)
- [在入口点检查EL2](#在入口点检查EL2)
- [过渡准备](#过渡准备)
- [从未发生的异常中返回](#从未发生的异常中返回)
- [测试](#测试)
- [相比之前的变化diff](#相比之前的变化diff)
## 介绍
应用级别的CPU具有所谓的`privilege levels`,它们具有不同的目的:
| Typically used for | AArch64 | RISC-V | x86 |
| ------------- | ------------- | ------------- | ------------- |
| Userspace applications | EL0 | U/VU | Ring 3 |
| OS Kernel | EL1 | S/VS | Ring 0 |
| Hypervisor | EL2 | HS | Ring -1 |
| Low-Level Firmware | EL3 | M | |
在AArch64中`EL`代表`Exception Level`(异常级别)。如果您想获取有关其他体系结构的更多信息,请查看以下链接:
- [x86 privilege rings](https://en.wikipedia.org/wiki/Protection_ring).
- [RISC-V privilege modes](https://content.riscv.org/wp-content/uploads/2017/12/Tue0942-riscv-hypervisor-waterman.pdf).
在继续之前,我强烈建议您先浏览一下[Programmers Guide for ARMv8-A]`的第3章`。它提供了关于该主题的简明概述。
[Programmers Guide for ARMv8-A]: http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/DEN0024A_v8_architecture_PG.pdf
## 本教程的范围
默认情况下,树莓派将始终在`EL2`中开始执行。由于我们正在编写一个传统的`Kernel`,我们需要过渡到更合适的`EL1`。
## 在入口点检查EL2
首先,我们需要确保我们实际上是在`EL2`中执行,然后才能调用相应的代码过渡到`EL1`。
因此,我们在`boot.s`的顶部添加了一个新的检查如果CPU核心不在`EL2`中,则将其停止。
```
// Only proceed if the core executes in EL2. Park it otherwise.
mrs x0, CurrentEL
cmp x0, {CONST_CURRENTEL_EL2}
b.ne .L_parking_loop
```
接下来,在`boot.rs`中继续准备从`EL2`到`EL1`的过渡,通过调用`prepare_el2_to_el1_transition()`函数。
```rust
#[no_mangle]
pub unsafe extern "C" fn _start_rust(phys_boot_core_stack_end_exclusive_addr: u64) -> ! {
prepare_el2_to_el1_transition(phys_boot_core_stack_end_exclusive_addr);
// Use `eret` to "return" to EL1. This results in execution of kernel_init() in EL1.
asm::eret()
}
```
## 过渡准备
由于`EL2`比`EL1`更具特权,它可以控制各种处理器功能,并允许或禁止`EL1`代码使用它们。
其中一个例子是访问计时器和计数器寄存器。我们已经在[tutorial 07](../07_timestamps/)中使用了它们,所以当然我们希望保留它们。
因此,我们在[Counter-timer Hypervisor Control register]中设置相应的标志,并将虚拟偏移量设置为零,以获取真实的物理值。
[Counter-timer Hypervisor Control register]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/cnthctl_el2.rs.html
```rust
// Enable timer counter registers for EL1.
CNTHCTL_EL2.write(CNTHCTL_EL2::EL1PCEN::SET + CNTHCTL_EL2::EL1PCTEN::SET);
// No offset for reading the counters.
CNTVOFF_EL2.set(0);
```
接下来,我们配置[Hypervisor Configuration Register],使`EL1`在`AArch64`模式下运行,而不是在`AArch32`模式下运行,这也是可能的。
[Hypervisor Configuration Register]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/hcr_el2.rs.html
```rust
// Set EL1 execution state to AArch64.
HCR_EL2.write(HCR_EL2::RW::EL1IsAarch64);
```
## 从未发生的异常中返回
实际上从较高的EL过渡到较低的EL只有一种方式即通过执行[ERET]指令。
[ERET]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/asm.rs.html#92-101
在这个指令中,它将会将[Saved Program Status Register - EL2]的内容复制到`Current Program Status Register - EL1`,并跳转到存储在[Exception Link Register - EL2]。
这基本上是在发生异常时所发生的相反过程。您将在即将发布的教程中了解更多相关内容。
[Saved Program Status Register - EL2]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/spsr_el2.rs.html
[Exception Link Register - EL2]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/elr_el2.rs.html
```rust
// Set up a simulated exception return.
//
// First, fake a saved program status where all interrupts were masked and SP_EL1 was used as a
// stack pointer.
SPSR_EL2.write(
SPSR_EL2::D::Masked
+ SPSR_EL2::A::Masked
+ SPSR_EL2::I::Masked
+ SPSR_EL2::F::Masked
+ SPSR_EL2::M::EL1h,
);
// Second, let the link register point to kernel_init().
ELR_EL2.set(crate::kernel_init as *const () as u64);
// Set up SP_EL1 (stack pointer), which will be used by EL1 once we "return" to it. Since there
// are no plans to ever return to EL2, just re-use the same stack.
SP_EL1.set(phys_boot_core_stack_end_exclusive_addr);
```
正如您所看到的,我们将`ELR_EL2`的值设置为之前直接从入口点调用的`kernel_init()`函数的地址。最后,我们设置了`SP_EL1`的堆栈指针。
您可能已经注意到,堆栈的地址作为函数参数进行了传递。正如您可能记得的,在`boot.s`的`_start()`函数中,
我们已经为`EL2`设置了堆栈。由于没有计划返回到`EL2`,我们可以直接重用相同的堆栈作为`EL1`的堆栈,
因此使用函数参数将其地址传递。
最后,在`_start_rust()`函数中调用了`ERET`指令。
```rust
#[no_mangle]
pub unsafe extern "C" fn _start_rust(phys_boot_core_stack_end_exclusive_addr: u64) -> ! {
prepare_el2_to_el1_transition(phys_boot_core_stack_end_exclusive_addr);
// Use `eret` to "return" to EL1. This results in execution of kernel_init() in EL1.
asm::eret()
}
```
## 测试
在`main.rs`中,我们打印`current privilege level`,并额外检查`SPSR_EL2`中的掩码位是否传递到了`EL1`
```console
$ make chainboot
[...]
Minipush 1.0
[MP] ⏳ Waiting for /dev/ttyUSB0
[MP] ✅ Serial connected
[MP] 🔌 Please power the target now
__ __ _ _ _ _
| \/ (_)_ _ (_) | ___ __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_| |_|_|_||_|_|____\___/\__,_\__,_|
Raspberry Pi 3
[ML] Requesting binary
[MP] ⏩ Pushing 14 KiB =========================================🦀 100% 0 KiB/s Time: 00:00:00
[ML] Loaded! Executing the payload now
[ 0.162546] mingo version 0.9.0
[ 0.162745] Booting on: Raspberry Pi 3
[ 0.163201] Current privilege level: EL1
[ 0.163677] Exception handling state:
[ 0.164122] Debug: Masked
[ 0.164511] SError: Masked
[ 0.164901] IRQ: Masked
[ 0.165291] FIQ: Masked
[ 0.165681] Architectural timer resolution: 52 ns
[ 0.166255] Drivers loaded:
[ 0.166592] 1. BCM PL011 UART
[ 0.167014] 2. BCM GPIO
[ 0.167371] Timer test, spinning for 1 second
[ 1.167904] Echoing input now
```
## 相比之前的变化diff
请检查[英文版本](README.md#diff-to-previous),这是最新的。

@ -0,0 +1,319 @@
# 教程10 - 虚拟内存第一部分:将所有内容进行身份映射!
## tl;dr
- 打开`MMU`。
- 使用简单的方案:静态的`64 KiB`转换表。
- 为了教学目的,我们将数据写入重新映射的`UART`,并对其他所有内容进行`identity map`。
## 目录
- [介绍](#introduction)
- [MMU和分页理论](#MMU和分页理论)
- [方法](#方法)
* [通用内核代码:`memory/mmu.rs`](#通用内核代码:`memory/mmu.rs`)
* [BSP`bsp/raspberrypi/memory/mmu.rs`](#bsp-bspraspberrypimemorymmurs)
* [AArch64`_arch/aarch64/memory/*`](#aarch64-_archaarch64memory)
* [`kernel.ld`](#kernelld)
- [地址转换示例](#地址转换示例)
* [使用64 KiB页描述符进行地址转换](#使用64KiB页描述符进行地址转换)
- [零成本抽象](#零成本抽象)
- [测试](#测试)
- [相比之前的变化diff](#相比之前的变化diff)
## 介绍
虚拟内存是一个非常复杂但重要且强大的主题。在本教程中,我们从简单易懂的方式开始,
通过打开`MMU`,使用静态转换表和一次性进行`identity-map`
(除了为教育目的而重新映射的`UART`之外;在下一个教程中,这将被取消)。
## MMU和分页理论
在这一点上,我们不会重新发明轮子并详细描述现代应用级处理器中分页的工作原理。
互联网上有很多关于这个主题的优秀资源,我们鼓励您阅读其中一些以获得对该主题的高层理解。
继续阅读本`AArch64`特定的教程,我强烈建议您在此处停下来,首先阅读[ARM Cortex-A Series Programmer's Guide for ARMv8-A]的`第12章`
以便在继续之前获得所有所需的`AArch64`特定知识。
已经阅读完`第12章`了吗?做得好 :+1:!
[ARM Cortex-A Series Programmer's Guide for ARMv8-A]: http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/DEN0024A_v8_architecture_PG.pdf
## 方法
1. 通用的`kernel`部分:`src/memory/mmu.rs`及其子模块提供了与体系结构无关的描述符类型,
用于组合一个高级数据结构,描述内核的虚拟内存布局:`memory::mmu::KernelVirtualLayout`。
2. `BSP`部分:`src/bsp/raspberrypi/memory/mmu.rs`包含一个`KernelVirtualLayout`的静态实例,并通过函数
`bsp::memory::mmu::virt_mem_layout()`使其可访问。
3. `aarch64`部分:`src/_arch/aarch64/memory/mmu.rs`及其子模块包含实际的`MMU`驱动程序。它使用`64 KiB`粒度获取
`BSP`的高级`KernelVirtualLayout`并进行映射。
### 通用内核代码:`memory/mmu.rs`
在这个文件中提供的描述符类型是构建块,用于描述不同内存区域的属性。
例如,`R/W`(读/写)、`no-execute`(不执行)、`cached/uncached`(缓存/非缓存)等等。
这些描述符与硬件`MMU`的实际描述符无关。不同的`BSP`可以使用这些类型来生成内核虚拟内存布局的高级描述。
真实硬件的实际`MMU`驱动程序将使用这些类型作为输入。
通过这种方式,我们在`BSP`和`_arch`代码之间实现了清晰的抽象,这样可以在不需要调整另一个的情况下进行交换。
### BSP: `bsp/raspberrypi/memory/mmu.rs`
这个文件包含了一个`KernelVirtualLayout`的实例,用于存储先前提到的描述符。
将其放在`BSP`中是正确的位置,因为它具有目标板的内存映射知识。
策略是只描述**不是**普通的、可缓存的DRAM的区域。然而如果您希望也可以定义这些区域。
这里是一个设备MMIO区域的示例
```rust
TranslationDescriptor {
name: "Device MMIO",
virtual_range: mmio_range_inclusive,
physical_range_translation: Translation::Identity,
attribute_fields: AttributeFields {
mem_attributes: MemAttributes::Device,
acc_perms: AccessPermissions::ReadWrite,
execute_never: true,
},
},
```
`KernelVirtualLayout`本身实现了以下方法:
```rust
pub fn virt_addr_properties(
&self,
virt_addr: usize,
) -> Result<(usize, AttributeFields), &'static str>
```
它将被`_arch/aarch64`的`MMU`代码使用,用于请求虚拟地址和转换的属性,该转换提供物理输出地址
(返回元组中的`usize`)。该函数扫描包含查询地址的描述符,并返回第一个匹配的条目的相应结果。
如果找不到条目则返回普通可缓存DRAM的默认属性和输入地址从而告诉`MMU`代码请求的地址应该是`identity mapped`。
由于这种默认行为不需要定义普通可缓存DRAM区域。
### AArch64: `_arch/aarch64/memory/*`
这些模块包含了`AArch64`的`MMU`驱动程序。粒度在这里被硬编码为(`64 KiB`页描述符)。
在`translation_table.rs`中,有一个实际的转换表结构的定义,它对`LVL2`表的数量进行了泛化。
后者取决于目标板的内存大小。自然地,`BSP`了解目标板的这些细节,并通过常量
`bsp::memory::mmu::KernelAddrSpace::SIZE`提供大小信息。
`translation_table.rs`使用这些信息来计算所需的`LVL2`表的数量。由于在`64 KiB`配置中,
一个`LVL2`表可以覆盖`512 MiB`,所以只需要将`KernelAddrSpace::SIZE`除以`512 MiB`
(有几个编译时检查确保`KernelAddrSpace::SIZE`是`512 MiB`的倍数)。
最终的表类型被导出为`KernelTranslationTable`。以下是来自`translation_table.rs`的相关代码:
```rust
/// A table descriptor for 64 KiB aperture.
///
/// The output points to the next table.
#[derive(Copy, Clone)]
#[repr(C)]
struct TableDescriptor {
value: u64,
}
/// A page descriptor with 64 KiB aperture.
///
/// The output points to physical memory.
#[derive(Copy, Clone)]
#[repr(C)]
struct PageDescriptor {
value: u64,
}
const NUM_LVL2_TABLES: usize = bsp::memory::mmu::KernelAddrSpace::SIZE >> Granule512MiB::SHIFT;
//--------------------------------------------------------------------------------------------------
// Public Definitions
//--------------------------------------------------------------------------------------------------
/// Big monolithic struct for storing the translation tables. Individual levels must be 64 KiB
/// aligned, hence the "reverse" order of appearance.
#[repr(C)]
#[repr(align(65536))]
pub struct FixedSizeTranslationTable<const NUM_TABLES: usize> {
/// Page descriptors, covering 64 KiB windows per entry.
lvl3: [[PageDescriptor; 8192]; NUM_TABLES],
/// Table descriptors, covering 512 MiB windows.
lvl2: [TableDescriptor; NUM_TABLES],
}
/// A translation table type for the kernel space.
pub type KernelTranslationTable = FixedSizeTranslationTable<NUM_LVL2_TABLES>;
```
在`mmu.rs`中,`KernelTranslationTable`用于创建内核表的最终实例:
```rust
//--------------------------------------------------------------------------------------------------
// Global instances
//--------------------------------------------------------------------------------------------------
/// The kernel translation tables.
static mut KERNEL_TABLES: KernelTranslationTable = KernelTranslationTable::new();
```
它们在`MMU::init()`期间通过调用`KERNEL_TABLES.populate_tt_entries()`进行填充,
该函数利用`bsp::memory::mmu::virt_mem_layout().virt_addr_properties()`和一系列实用函数,将内核通用描述符转换为
`AArch64 MMU`硬件所需的实际`64 bit`整数条目,用于填充转换表数组。
一个值得注意的事情是,每个页描述符都有一个索引(`AttrIndex`),它索引到[MAIR_EL1]寄存器,
该寄存器保存了有关相应页面的缓存属性的信息。我们目前定义了普通可缓存内存和设备内存(不被缓存)。
[MAIR_EL1]: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CIHDHJBB.html
```rust
impl MemoryManagementUnit {
/// Setup function for the MAIR_EL1 register.
fn set_up_mair(&self) {
// Define the memory types being mapped.
MAIR_EL1.write(
// Attribute 1 - Cacheable normal DRAM.
MAIR_EL1::Attr1_Normal_Outer::WriteBack_NonTransient_ReadWriteAlloc +
MAIR_EL1::Attr1_Normal_Inner::WriteBack_NonTransient_ReadWriteAlloc +
// Attribute 0 - Device.
MAIR_EL1::Attr0_Device::nonGathering_nonReordering_EarlyWriteAck,
);
}
```
然后,[Translation Table Base Register 0 - EL1]使用`lvl2`表的基地址进行设置,同时配置[Translation Control Register - EL1]
```rust
// Set the "Translation Table Base Register".
TTBR0_EL1.set_baddr(KERNEL_TABLES.phys_base_address());
self.configure_translation_control();
```
最后,通过[System Control Register - EL1]打开`MMU`。最后一步还启用了数据和指令的缓存。
[Translation Table Base Register 0 - EL1]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/ttbr0_el1.rs.html
[Translation Control Register - EL1]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/tcr_el1.rs.html
[System Control Register - EL1]: https://docs.rs/aarch64-cpu/9.0.0/src/aarch64_cpu/registers/sctlr_el1.rs.html
### `kernel.ld`
我们需要将`code`段对齐到`64 KiB`,这样它就不会与下一个需要读/写属性而不是读/执行属性的部分重叠。
```ld.s
. = ALIGN(PAGE_SIZE);
__code_end_exclusive = .;
```
这会增加二进制文件的大小,但考虑到与传统的`4 KiB`粒度相比,它显著减少了静态分页条目的数量,这是一个小小的代价。
## 地址转换示例
出于教育目的,定义了一个布局,允许通过两个不同的虚拟地址访问`UART`
- 由于我们对整个`Device MMIO`区域进行了身份映射,所以在`MMU`打开后,可以通过断言其物理基地址
`0x3F20_1000`或`0xFA20_1000`取决于使用的是哪个RPi版本来访问它。
- 此外,它还映射到第一个`512 MiB`中的最后一个`64 KiB`槽位,使其可以通过基地址`0x1FFF_1000`访问。
以下块图可视化了第二个映射的底层转换。
### 使用64KiB页描述符进行地址转换
<img src="../doc/11_page_tables_64KiB.png" alt="Page Tables 64KiB" width="90%">
## 零成本抽象
初始化代码再次是展示Rust零成本抽象在嵌入式编程中巨大潜力的一个很好的例子[[1]][[2]]。
让我们再次看一下使用[aarch64-cpu]crate设置`MAIR_EL1`寄存器的代码片段:
[1]: https://blog.rust-lang.org/2015/05/11/traits.html
[2]: https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions
[aarch64-cpu]: https://crates.io/crates/aarch64-cpu
```rust
/// Setup function for the MAIR_EL1 register.
fn set_up_mair(&self) {
// Define the memory types being mapped.
MAIR_EL1.write(
// Attribute 1 - Cacheable normal DRAM.
MAIR_EL1::Attr1_Normal_Outer::WriteBack_NonTransient_ReadWriteAlloc +
MAIR_EL1::Attr1_Normal_Inner::WriteBack_NonTransient_ReadWriteAlloc +
// Attribute 0 - Device.
MAIR_EL1::Attr0_Device::nonGathering_nonReordering_EarlyWriteAck,
);
}
```
这段代码具有超强的表达能力,它利用`traits`,不同的`types`和`constants`来提供类型安全的寄存器操作。
最后,此代码根据数据表将寄存器的前四个字节设置为特定值。查看生成的代码,
我们可以看到,尽管有所有的类型安全和抽象,但它可以归结为两条汇编指令:
```text
800a8: 529fe089 mov w9, #0xff04 // #65284
800ac: d518a209 msr mair_el1, x9
```
## 测试
打开虚拟内存现在是我们在内核初始化过程中要做的第一件事:
```rust
unsafe fn kernel_init() -> ! {
use memory::mmu::interface::MMU;
if let Err(string) = memory::mmu::mmu().enable_mmu_and_caching() {
panic!("MMU: {}", string);
}
```
稍后在引导过程中,可以观察到有关映射的打印:
```console
$ make chainboot
[...]
Minipush 1.0
[MP] ⏳ Waiting for /dev/ttyUSB0
[MP] ✅ Serial connected
[MP] 🔌 Please power the target now
__ __ _ _ _ _
| \/ (_)_ _ (_) | ___ __ _ __| |
| |\/| | | ' \| | |__/ _ \/ _` / _` |
|_| |_|_|_||_|_|____\___/\__,_\__,_|
Raspberry Pi 3
[ML] Requesting binary
[MP] ⏩ Pushing 64 KiB =========================================🦀 100% 0 KiB/s Time: 00:00:00
[ML] Loaded! Executing the payload now
[ 0.811167] mingo version 0.10.0
[ 0.811374] Booting on: Raspberry Pi 3
[ 0.811829] MMU online. Special regions:
[ 0.812306] 0x00080000 - 0x0008ffff | 64 KiB | C RO PX | Kernel code and RO data
[ 0.813324] 0x1fff0000 - 0x1fffffff | 64 KiB | Dev RW PXN | Remapped Device MMIO
[ 0.814310] 0x3f000000 - 0x4000ffff | 17 MiB | Dev RW PXN | Device MMIO
[ 0.815198] Current privilege level: EL1
[ 0.815675] Exception handling state:
[ 0.816119] Debug: Masked
[ 0.816509] SError: Masked
[ 0.816899] IRQ: Masked
[ 0.817289] FIQ: Masked
[ 0.817679] Architectural timer resolution: 52 ns
[ 0.818253] Drivers loaded:
[ 0.818589] 1. BCM PL011 UART
[ 0.819011] 2. BCM GPIO
[ 0.819369] Timer test, spinning for 1 second
[ !!! ] Writing through the remapped UART at 0x1FFF_1000
[ 1.820409] Echoing input now
```
## 相比之前的变化diff
请检查[英文版本](README.md#diff-to-previous),这是最新的。
Loading…
Cancel
Save