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

Make internal links relative

Browse Source
This commit is contained in:
Philipp Oppermann
2015-11-23 23:42:35 +01:00
parent 5137ad103a
commit 43924afbbf
5 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
pages/cross-compile-libcore.md
View File

@@ -7,7 +7,7 @@ So you're getting an ``error: can't find crate for `core` [E0463]`` when using `
**If you have an x86_64 processor and want a quick fix**, try it with `x86_64-pc-windows-gnu` or `x86_64-apple-darwin` (or simply omit the explicit `--target`). **If you have an x86_64 processor and want a quick fix**, try it with `x86_64-pc-windows-gnu` or `x86_64-apple-darwin` (or simply omit the explicit `--target`).
The idiomatic alternative and the only option for non x86_64 CPUs is described below. Note that you need to [cross compile binutils], too. The idiomatic alternative and the only option for non x86_64 CPUs is described below. Note that you need to [cross compile binutils], too.
[cross compile binutils]: {{ site.url }}/cross-compile-binutils.html [cross compile binutils]: /cross-compile-binutils.html
## Libcore ## Libcore
The core library is a dependency-free library that is added implicitly when using `#![no_std]`. It provides basic standard library features like Option or Iterator. The core library is installed together with the rust compiler (just like the std library). But the installed libcore is specific to your architecture. If you aren't working on x86_64 Linux and pass `‑‑target x86_64‑unknown‑linux‑gnu` to cargo, it can't find a x86_64 libcore. To fix this, you can either download it or build it using cargo. The core library is a dependency-free library that is added implicitly when using `#![no_std]`. It provides basic standard library features like Option or Iterator. The core library is installed together with the rust compiler (just like the std library). But the installed libcore is specific to your architecture. If you aren't working on x86_64 Linux and pass `‑‑target x86_64‑unknown‑linux‑gnu` to cargo, it can't find a x86_64 libcore. To fix this, you can either download it or build it using cargo.

6
posts/2015-08-18-multiboot-kernel.md
View File

@@ -172,7 +172,7 @@ Idx Name Size VMA LMA File off Algn
CONTENTS, ALLOC, LOAD, READONLY, CODE CONTENTS, ALLOC, LOAD, READONLY, CODE
``` ```
_Note_: The `ld` and `objdump` commands are platform specific. If you're _not_ working on x86_64 architecture, you will need to [cross compile binutils]. Then use `x86_64‑elf‑ld` and `x86_64‑elf‑objdump` instead of `ld` and `objdump`. _Note_: The `ld` and `objdump` commands are platform specific. If you're _not_ working on x86_64 architecture, you will need to [cross compile binutils]. Then use `x86_64‑elf‑ld` and `x86_64‑elf‑objdump` instead of `ld` and `objdump`.
[cross compile binutils]: {{ site.url }}/cross-compile-binutils.html [cross compile binutils]: /cross-compile-binutils.html
## Creating the ISO ## Creating the ISO
The last step is to create a bootable ISO image with GRUB. We need to create the following directory structure and copy the `kernel.bin` to the right place: The last step is to create a bootable ISO image with GRUB. We need to create the following directory structure and copy the `kernel.bin` to the right place:
@@ -211,7 +211,7 @@ Now it's time to boot our OS. We will use [QEMU]:
``` ```
qemu-system-x86_64 -hda os.iso qemu-system-x86_64 -hda os.iso
``` ```
![qemu output]({{ site.url }}/images/qemu-ok.png) ![qemu output](/images/qemu-ok.png)
Notice the green `OK` in the upper left corner. If it does not work for you, take a look at the comment section. Notice the green `OK` in the upper left corner. If it does not work for you, take a look at the comment section.
@@ -297,5 +297,5 @@ Now we can invoke `make` and all updated assembly files are compiled and linked.
In the [next post] we will create a page table and do some CPU configuration to switch to the 64-bit [long mode]. In the [next post] we will create a page table and do some CPU configuration to switch to the 64-bit [long mode].
[next post]: {{ site.url }}{{ page.next.url }} [next post]: {{ page.next.url }}
[long mode]: https://en.wikipedia.org/wiki/Long_mode [long mode]: https://en.wikipedia.org/wiki/Long_mode

8
posts/2015-08-25-entering-longmode.md
View File

@@ -8,7 +8,7 @@ In the [previous post] we created a minimal multiboot kernel. It just prints `OK
I tried to explain everything in detail and to keep the code as simple as possible. If you have any questions, suggestions, or issues, please leave a comment or [create an issue] on Github. The source code is available in a [repository][source code], too. I tried to explain everything in detail and to keep the code as simple as possible. If you have any questions, suggestions, or issues, please leave a comment or [create an issue] on Github. The source code is available in a [repository][source code], too.
[previous post]: {{ site.url }}{{ page.previous.url }} [previous post]: {{ page.previous.url }}
[Rust]: http://www.rust-lang.org/ [Rust]: http://www.rust-lang.org/
[protected mode]: https://en.wikipedia.org/wiki/Protected_mode [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
[long mode]: https://en.wikipedia.org/wiki/Long_mode [long mode]: https://en.wikipedia.org/wiki/Long_mode
@@ -34,7 +34,7 @@ error:
At address `0xb8000` begins the so-called [VGA text buffer]. It's an array of screen characters that are displayed by the graphics card. A [future post] will cover the VGA buffer in detail and create a Rust interface to it. But for now, manual bit-fiddling is the easiest option. At address `0xb8000` begins the so-called [VGA text buffer]. It's an array of screen characters that are displayed by the graphics card. A [future post] will cover the VGA buffer in detail and create a Rust interface to it. But for now, manual bit-fiddling is the easiest option.
[VGA text buffer]: https://en.wikipedia.org/wiki/VGA-compatible_text_mode [VGA text buffer]: https://en.wikipedia.org/wiki/VGA-compatible_text_mode
[future post]: {{ site.url }}{{ page.next.next.url }} [future post]: {{ page.next.next.url }}
A screen character consists of a 8 bit color code and a 8 bit [ASCII] character. We used the color code `4f` for all characters, which means white text on red background. `0x52` is an ASCII `R`, `0x45` is an `E`, `0x3a` is a `:`, and `0x20` is a space. The second space is overwritten by the given ASCII byte. Finally the CPU is stopped with the `hlt` instruction. A screen character consists of a 8 bit color code and a 8 bit [ASCII] character. We used the color code `4f` for all characters, which means white text on red background. `0x52` is an ASCII `R`, `0x45` is an `E`, `0x3a` is a `:`, and `0x20` is a space. The second space is overwritten by the given ASCII byte. Finally the CPU is stopped with the `hlt` instruction.
@@ -179,7 +179,7 @@ Each page table contains 512 entries and one entry is 8 bytes, so they fit exact
[^virtual_physical_translation_source]: Image source: [Wikipedia](https://commons.wikimedia.org/wiki/File:X86_Paging_64bit.svg), with modified font size, page table naming, and removed sign extended bits. The modified file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. [^virtual_physical_translation_source]: Image source: [Wikipedia](https://commons.wikimedia.org/wiki/File:X86_Paging_64bit.svg), with modified font size, page table naming, and removed sign extended bits. The modified file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
![translation of virtual to physical addresses in 64 bit mode]({{ site.url }}/images/X86_Paging_64bit.svg) ![translation of virtual to physical addresses in 64 bit mode](/images/X86_Paging_64bit.svg)
1. Get the address of the P4 table from the CR3 register 1. Get the address of the P4 table from the CR3 register
2. Use bits 39-47 (9 bits) as an index into P4 (`2^9 = 512 = number of entries`) 2. Use bits 39-47 (9 bits) as an index into P4 (`2^9 = 512 = number of entries`)
@@ -492,4 +492,4 @@ It's time to finally leave assembly behind[^leave_assembly_behind] and switch to
[^leave_assembly_behind]: Actually we will still need some assembly in the future, but I'll try to minimize it. [^leave_assembly_behind]: Actually we will still need some assembly in the future, but I'll try to minimize it.
[Rust]: https://www.rust-lang.org/ [Rust]: https://www.rust-lang.org/
[next post]: {{ site.url }}{{ page.next.url }} [next post]: {{ page.next.url }}

12
posts/2015-09-02-setup-rust.md
View File

@@ -7,8 +7,8 @@ In the previous posts we created a [minimal Multiboot kernel][multiboot post] an
This blog post tries to setup Rust step-by-step and point out the different problems. If you have any questions, problems, or suggestions please [file an issue] or create a comment at the bottom. The code from this post is in a [Github repository], too. This blog post tries to setup Rust step-by-step and point out the different problems. If you have any questions, problems, or suggestions please [file an issue] or create a comment at the bottom. The code from this post is in a [Github repository], too.
[multiboot post]: {{ site.url }}{{ page.previous.previous.url }} [multiboot post]: {{ page.previous.previous.url }}
[long mode post]: {{ site.url }}{{ page.previous.url }} [long mode post]: {{ page.previous.url }}
[Rust]: https://www.rust-lang.org/ [Rust]: https://www.rust-lang.org/
[file an issue]: https://github.com/phil-opp/blog_os/issues [file an issue]: https://github.com/phil-opp/blog_os/issues
[Github repository]: https://github.com/phil-opp/blog_os/tree/setup_rust [Github repository]: https://github.com/phil-opp/blog_os/tree/setup_rust
@@ -73,7 +73,7 @@ We can now build it using `cargo build`. To make sure, we are building it for th
cargo build --target=x86_64-unknown-linux-gnu cargo build --target=x86_64-unknown-linux-gnu
``` ```
It creates a static library at `target/x86_64-unknown-linux-gnu/debug/libblog_os.a`, which can be linked with our assembly kernel. If you're getting an error about a missing `core` crate, [look here][cross compile libcore]. It creates a static library at `target/x86_64-unknown-linux-gnu/debug/libblog_os.a`, which can be linked with our assembly kernel. If you're getting an error about a missing `core` crate, [look here][cross compile libcore].
[cross compile libcore]: {{ site.url }}/cross-compile-libcore.html [cross compile libcore]: /cross-compile-libcore.html
To build and link the rust library on `make`, we extend our `Makefile`([full file][github makefile]): To build and link the rust library on `make`, we extend our `Makefile`([full file][github makefile]):
@@ -318,7 +318,7 @@ The code is from the great [OSDev Wiki][osdev sse] again. Notice that it sets/un
When we insert a `call setup_SSE` right before calling `rust_main`, our Rust code will finally work. When we insert a `call setup_SSE` right before calling `rust_main`, our Rust code will finally work.
[32-bit error function]: {{ site.url }}{{ page.previous.url }}#some-tests [32-bit error function]: {{ page.previous.url }}#some-tests
[osdev sse]: http://wiki.osdev.org/SSE#Checking_for_SSE [osdev sse]: http://wiki.osdev.org/SSE#Checking_for_SSE
### “OS returned!” ### “OS returned!”
@@ -376,10 +376,10 @@ Some notes:
### Stack Overflows ### Stack Overflows
Since we still use the small 64 byte [stack from the last post], we must be careful not to [overflow] it. Normally, Rust tries to avoid stack overflows through _guard pages_: The page below the stack isn't mapped and such a stack overflow triggers a page fault (instead of silently overwriting random memory). But we can't unmap the page below our stack right now since we currently use only a single big page. Fortunately the stack is located just above the page tables. So some important page table entry would probably get overwritten on stack overflow and then a page fault occurs, too. Since we still use the small 64 byte [stack from the last post], we must be careful not to [overflow] it. Normally, Rust tries to avoid stack overflows through _guard pages_: The page below the stack isn't mapped and such a stack overflow triggers a page fault (instead of silently overwriting random memory). But we can't unmap the page below our stack right now since we currently use only a single big page. Fortunately the stack is located just above the page tables. So some important page table entry would probably get overwritten on stack overflow and then a page fault occurs, too.
[stack from the last post]: {{ site.url }}{{ page.previous.url }}#creating-a-stack [stack from the last post]: {{ page.previous.url }}#creating-a-stack
[overflow]: https://en.wikipedia.org/wiki/Stack_overflow [overflow]: https://en.wikipedia.org/wiki/Stack_overflow
## What's next? ## What's next?
Until now we write magic bits to some memory location when we want to print something to screen. In the [next post] we create a abstraction for the VGA text buffer that allows us to print strings in different colors and provides a simple interface. Until now we write magic bits to some memory location when we want to print something to screen. In the [next post] we create a abstraction for the VGA text buffer that allows us to print strings in different colors and provides a simple interface.
[next post]: {{ site.url }}{{ page.next.url }} [next post]: {{ page.next.url }}

4
posts/2015-10-23-printing-to-screen.md
View File

@@ -5,7 +5,7 @@ redirect_from: "/2015/10/23/printing-to-screen/"
--- ---
In the [previous post] we switched from assembly to [Rust], a systems programming language that provides great safety. But so far we are using unsafe features like [raw pointers] whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer. It will support Rust's [formatting macros], too. In the [previous post] we switched from assembly to [Rust], a systems programming language that provides great safety. But so far we are using unsafe features like [raw pointers] whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer. It will support Rust's [formatting macros], too.
[previous post]: {{ site.url }}{{ page.previous.url }} [previous post]: {{ page.previous.url }}
[Rust]: https://www.rust-lang.org/ [Rust]: https://www.rust-lang.org/
[raw pointers]: https://doc.rust-lang.org/book/raw-pointers.html [raw pointers]: https://doc.rust-lang.org/book/raw-pointers.html
[formatting macros]: https://doc.rust-lang.org/std/fmt/#related-macros [formatting macros]: https://doc.rust-lang.org/std/fmt/#related-macros
@@ -426,7 +426,7 @@ Now that you know the very basics of OS development in Rust, you should also che
_Note_: You need to [cross compile binutils] to build it (or you create some symbolic links[^fn-symlink] if you're on x86_64). _Note_: You need to [cross compile binutils] to build it (or you create some symbolic links[^fn-symlink] if you're on x86_64).
[Rust Bare-Bones Kernel]: https://github.com/thepowersgang/rust-barebones-kernel [Rust Bare-Bones Kernel]: https://github.com/thepowersgang/rust-barebones-kernel
[higher half]: http://wiki.osdev.org/Higher_Half_Kernel [higher half]: http://wiki.osdev.org/Higher_Half_Kernel
[cross compile binutils]: {{ site.url }}/cross-compile-binutils.html [cross compile binutils]: /cross-compile-binutils.html
[^fn-symlink]: You will need to symlink `x86_64-none_elf-XXX` to `/usr/bin/XXX` where `XXX` is in {`as`, `ld`, `objcopy`, `objdump`, `strip`}. The `x86_64-none_elf-XXX` files must be in some folder that is in your `$PATH`. But then you can only build for your x86_64 host architecture, so use this hack only for testing. [^fn-symlink]: You will need to symlink `x86_64-none_elf-XXX` to `/usr/bin/XXX` where `XXX` is in {`as`, `ld`, `objcopy`, `objdump`, `strip`}. The `x86_64-none_elf-XXX` files must be in some folder that is in your `$PATH`. But then you can only build for your x86_64 host architecture, so use this hack only for testing.
- [RustOS]: More advanced kernel that supports allocation, keyboard inputs, and threads. It also has a scheduler and a basic network driver. - [RustOS]: More advanced kernel that supports allocation, keyboard inputs, and threads. It also has a scheduler and a basic network driver.