michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-16 14:27:49 +00:00
Code Issues Projects Releases Wiki Activity

Fixes bootloader version

Browse Source 
Adds a note about using a custom physical memory offset and its caveats
This commit is contained in:
seewishnew
2022-11-24 20:42:22 -08:00
committed by GitHub
parent a108367d71
commit b63ce2dc3c
8 changed files with 9 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.fa.md
View File

@@ -414,7 +414,7 @@ pub extern "C" fn _start() -> ! {
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.9.8" bootloader = "0.9.23"
``` ```
افزودن بوت‌لودر به عنوان وابستگی برای ایجاد یک دیسک ایمیج قابل بوت کافی نیست. مشکل این است که ما باید هسته خود را با بوت لودر پیوند دهیم، اما کارگو از [اسکریپت های بعد از بیلد] پشتیبانی نمی‌کند. افزودن بوت‌لودر به عنوان وابستگی برای ایجاد یک دیسک ایمیج قابل بوت کافی نیست. مشکل این است که ما باید هسته خود را با بوت لودر پیوند دهیم، اما کارگو از [اسکریپت های بعد از بیلد] پشتیبانی نمی‌کند.

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.ja.md
View File

@@ -411,7 +411,7 @@ pub extern "C" fn _start() -> ! {
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.9.8" bootloader = "0.9.23"
``` ```
bootloaderを依存として加えることだけでブータブルディスクイメージが実際に作れるわけではなく、私達のカーネルをコンパイル後にブートローダーにリンクする必要があります。問題は、cargoが[<ruby>ビルド後<rp> (</rp><rt>post-build</rt><rp>) </rp></ruby>にスクリプトを走らせる機能][post-build scripts]を持っていないことです。 bootloaderを依存として加えることだけでブータブルディスクイメージが実際に作れるわけではなく、私達のカーネルをコンパイル後にブートローダーにリンクする必要があります。問題は、cargoが[<ruby>ビルド後<rp> (</rp><rt>post-build</rt><rp>) </rp></ruby>にスクリプトを走らせる機能][post-build scripts]を持っていないことです。

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.ko.md
View File

@@ -418,7 +418,7 @@ pub extern "C" fn _start() -> ! {
# Cargo.toml 에 들어갈 내용 # Cargo.toml 에 들어갈 내용
[dependencies] [dependencies]
bootloader = "0.9.8" bootloader = "0.9.23"
``` ```
부트로더를 의존 크레이트로 추가하는 것만으로는 부팅 가능한 디스크 이미지를 만들 수 없습니다. 커널 컴파일이 끝난 후 커널을 부트로더와 함께 링크할 수 있어야 하는데, cargo는 현재 [빌드 직후 스크립트 실행][post-build scripts] 기능을 지원하지 않습니다. 부트로더를 의존 크레이트로 추가하는 것만으로는 부팅 가능한 디스크 이미지를 만들 수 없습니다. 커널 컴파일이 끝난 후 커널을 부트로더와 함께 링크할 수 있어야 하는데, cargo는 현재 [빌드 직후 스크립트 실행][post-build scripts] 기능을 지원하지 않습니다.

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.md
View File

@@ -403,7 +403,7 @@ Instead of writing our own bootloader, which is a project on its own, we use the
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.9.8" bootloader = "0.9.23"
``` ```
Adding the bootloader as a dependency is not enough to actually create a bootable disk image. The problem is that we need to link our kernel with the bootloader after compilation, but cargo has no support for [post-build scripts]. Adding the bootloader as a dependency is not enough to actually create a bootable disk image. The problem is that we need to link our kernel with the bootloader after compilation, but cargo has no support for [post-build scripts].

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.ru.md
View File

@@ -411,7 +411,7 @@ pub extern "C" fn _start() -> ! {
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.9.8" bootloader = "0.9.23"
``` ```
Добавление загрузчика в качестве зависимости недостаточно для создания загрузочного образа диска. Проблема в том, что нам нужно связать наше ядро с загрузчиком после компиляции, но в cargo нет поддержки [скриптов после сборки][post-build scripts]. Добавление загрузчика в качестве зависимости недостаточно для создания загрузочного образа диска. Проблема в том, что нам нужно связать наше ядро с загрузчиком после компиляции, но в cargo нет поддержки [скриптов после сборки][post-build scripts].

2
blog/content/edition-2/posts/02-minimal-rust-kernel/index.zh-CN.md
View File

@@ -313,7 +313,7 @@ pub extern "C" fn _start() -> ! {
# in Cargo.toml # in Cargo.toml
[dependencies] [dependencies]
bootloader = "0.9.3" bootloader = "0.9.23"
``` ```
只添加引导程序为依赖项，并不足以创建一个可引导的磁盘映像；我们还需要内核编译完成之后，将内核和引导程序组合在一起。然而，截至目前，原生的 cargo 并不支持在编译完成后添加其它步骤（详见[这个 issue](https://github.com/rust-lang/cargo/issues/545)）。 只添加引导程序为依赖项，并不足以创建一个可引导的磁盘映像；我们还需要内核编译完成之后，将内核和引导程序组合在一起。然而，截至目前，原生的 cargo 并不支持在编译完成后添加其它步骤（详见[这个 issue](https://github.com/rust-lang/cargo/issues/545)）。

2
blog/content/edition-2/posts/09-paging-implementation/index.ja.md
View File

@@ -281,7 +281,7 @@ frame.map(|frame| frame.start_address() + u64::from(addr.page_offset()))
```toml ```toml
[dependencies] [dependencies]
bootloader = { version = "0.9.8", features = ["map_physical_memory"]} bootloader = { version = "0.9.23", features = ["map_physical_memory"]}
``` ```
この機能を有効化すると、ブートローダは物理メモリの全体を、ある未使用の仮想アドレス空間にマッピングします。この仮想アドレスの範囲をカーネルに伝えるために、ブートローダは**boot information**構造体を渡します。 この機能を有効化すると、ブートローダは物理メモリの全体を、ある未使用の仮想アドレス空間にマッピングします。この仮想アドレスの範囲をカーネルに伝えるために、ブートローダは**boot information**構造体を渡します。

3
blog/content/edition-2/posts/09-paging-implementation/index.md
View File

@@ -278,7 +278,7 @@ We choose the first approach for our kernel since it is simple, platform-indepen
```toml ```toml
[dependencies] [dependencies]
bootloader = { version = "0.9.8", features = ["map_physical_memory"]} bootloader = { version = "0.9.23", features = ["map_physical_memory"]}
``` ```
With this feature enabled, the bootloader maps the complete physical memory to some unused virtual address range. To communicate the virtual address range to our kernel, the bootloader passes a _boot information_ structure. With this feature enabled, the bootloader maps the complete physical memory to some unused virtual address range. To communicate the virtual address range to our kernel, the bootloader passes a _boot information_ structure.
@@ -292,6 +292,7 @@ The `bootloader` crate defines a [`BootInfo`] struct that contains all the infor
- The `memory_map` field contains an overview of the available physical memory. This tells our kernel how much physical memory is available in the system and which memory regions are reserved for devices such as the VGA hardware. The memory map can be queried from the BIOS or UEFI firmware, but only very early in the boot process. For this reason, it must be provided by the bootloader because there is no way for the kernel to retrieve it later. We will need the memory map later in this post. - The `memory_map` field contains an overview of the available physical memory. This tells our kernel how much physical memory is available in the system and which memory regions are reserved for devices such as the VGA hardware. The memory map can be queried from the BIOS or UEFI firmware, but only very early in the boot process. For this reason, it must be provided by the bootloader because there is no way for the kernel to retrieve it later. We will need the memory map later in this post.
- The `physical_memory_offset` tells us the virtual start address of the physical memory mapping. By adding this offset to a physical address, we get the corresponding virtual address. This allows us to access arbitrary physical memory from our kernel. - The `physical_memory_offset` tells us the virtual start address of the physical memory mapping. By adding this offset to a physical address, we get the corresponding virtual address. This allows us to access arbitrary physical memory from our kernel.
- This physical memory offset can be customized by adding a `[package.metadata.bootloader]` table in Cargo.toml and setting the field `physical-memory-offset = "0x0000f00000000000"` (or any other value). However, note that the bootloader can panic if it runs into physical address values that start to overlap with the the space beyond the offset, i.e., areas it would have previously mapped to some other early physical addresses. So in general, the higher the value (> 1 TiB), the better.
The bootloader passes the `BootInfo` struct to our kernel in the form of a `&'static BootInfo` argument to our `_start` function. We don't have this argument declared in our function yet, so let's add it: The bootloader passes the `BootInfo` struct to our kernel in the form of a `&'static BootInfo` argument to our `_start` function. We don't have this argument declared in our function yet, so let's add it: