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

Update repository URL (it was renamed to blog_os)

Browse Source
This commit is contained in:
Philipp Oppermann
2015-10-06 16:18:44 +02:00
parent 99a3979c68
commit 282206e3ff
3 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
_posts/2015-08-18-multiboot-kernel.md
View File

@@ -9,7 +9,7 @@ I tried to explain everything in detail and to keep the code as simple as possib
[Rust]: http://www.rust-lang.org/
[create an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
[source code]: https://github.com/phil-opp/blogOS/tree/multiboot_bootstrap/src/arch/x86_64
[source code]: https://github.com/phil-opp/blog_os/tree/multiboot_bootstrap/src/arch/x86_64
## Overview
When you turn on a computer, it loads the [BIOS] from some special flash memory. The BIOS runs self test and initialization routines of the hardware, then it looks for bootable devices. If it finds one, the control is transferred to its _bootloader_, which is a small portion of executable code stored at the device's beginning. The bootloader has to determine the location of the kernel image on the device and load it into memory. It also needs to switch the CPU to the so-called [protected mode] because x86 CPUs start in the very limited [real mode] by default (to be compatible to programs from 1978).

2
_posts/2015-08-25-entering-longmode.md
View File

@@ -12,7 +12,7 @@ I tried to explain everything in detail and to keep the code as simple as possib
[protected mode]: https://en.wikipedia.org/wiki/Protected_mode
[long mode]: https://en.wikipedia.org/wiki/Long_mode
[create an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
[source code]: https://github.com/phil-opp/blogOS/tree/entering_longmode/src/arch/x86_64
[source code]: https://github.com/phil-opp/blog_os/tree/entering_longmode/src/arch/x86_64
## Some Tests
To avoid bugs and strange errors on old CPUs we should test if the processor supports every needed feature. If not, the kernel should abort and display an error message. To handle errors easily, we create an error procedure in `boot.asm`. It prints a rudimentary `ERR: X` message, where X is an error code letter, and hangs:

4
_posts/2015-09-02-setup-rust.md
View File

@@ -11,7 +11,7 @@ This blog post tries to setup Rust step-by-step and point out the different prob
[long mode post]: {{ site.url }}{{ page.previous.url }}
[Rust]: https://www.rust-lang.org/
[file an issue]: https://github.com/phil-opp/phil-opp.github.io/issues
[Github repository]: https://github.com/phil-opp/blogOS/tree/setup_rust
[Github repository]: https://github.com/phil-opp/blog_os/tree/setup_rust
## Installing Rust
We need a nightly compiler, as we need to use many unstable features. To manage Rust installations I highly recommend brson's [multirust]. It allows you to install nightly, beta, and stable compilers side-by-side and makes it easy to update them. After installing you can just run `multirust update nightly` to install or update to the latest Rust nightly.
@@ -79,7 +79,7 @@ We added a new `cargo` target that just executes `cargo build` and modified the
But now `cargo build` is executed on every `make`, even if no source file was changed. And the ISO is recreated on every `make iso`/`make run`, too. We could try to avoid this by adding dependencies on all rust source and cargo configuration files to the `cargo` target, but the ISO creation takes only half a second on my machine and most of the time we will have changed a Rust file when we run `make`. So we keep it simple for now and let cargo do the bookkeeping of changed files (it does it anyway).
[github makefile]: https://github.com/phil-opp/blogOS/blob/setup_rust/Makefile
[github makefile]: https://github.com/phil-opp/blog_os/blob/setup_rust/Makefile
## Calling Rust
Now we can call the main method in `long_mode_start`: