Merge fb096a7484 into 647b509971

blog/content/edition-3/posts/02-booting/index.md

@@ -75,7 +75,7 @@ This structure has the following general format:
 | 446    | partition entry 1 | 16   |
 | 462    | partition entry 2 | 16   |
 | 478    | partition entry 3 | 16   |
-| 494    | partition entry 4 | 16   |
+| 444    | partition entry 4 | 16   |
 | 510    | boot signature    | 2    |
 
 The bootstrap code is commonly called the _bootloader_ and responsible for loading and starting the operating system kernel.
@@ -706,7 +706,7 @@ We then use the the `create_uefi_image` and `create_bios_image` methods to creat
 [requires build scripts]: https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script
 [`join`]: https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.join
 
-We can now use a simple `cargo build` to cross-compile our kernel, build the bootloader, and combine them to create a bootable disk image:
+We can now use use a simple `cargo build` to cross-compile our kernel, build the bootloader, and combine them to create a bootable disk image:
 
 ```
 ❯ cargo build
@@ -1011,35 +1011,27 @@ Now we can create our `qemu-uefi` executable at `src/bin/qemu-uefi.rs`:
 
 ```rust ,hl_lines=3-15
 // src/bin/qemu-uefi.rs
+
 use std::{
-    env, process::{self, Command}
+    env,
+    process::{self, Command},
 };
 
-use ovmf_prebuilt::{Arch, FileType, Prebuilt, Source};
-
 fn main() {
-    let prebuilt =
-        Prebuilt::fetch(Source::LATEST, "target/ovmf").unwrap();
-    let ovmf_code = prebuilt.get_file(Arch::X64, FileType::Code);
-    let ovmf_vars = prebuilt.get_file(Arch::X64, FileType::Vars);
     let mut qemu = Command::new("qemu-system-x86_64");
-    qemu.args([
+    qemu.arg("-drive");
-        "-drive",
+    qemu.arg(format!("format=raw,file={}", env!("UEFI_IMAGE")));
-        &format!("format=raw,if=pflash,readonly=on,file={}", ovmf_code.display()),
+    qemu.arg("-bios").arg(ovmf_prebuilt::ovmf_pure_efi());
-        "-drive",
-        &format!("format=raw,if=pflash,file={}", ovmf_vars.display()),
-        "-drive",
-        &format!("format=raw,file={}", env!("UEFI_IMAGE")),
-    ]);
     let exit_status = qemu.status().unwrap();
     process::exit(exit_status.code().unwrap_or(-1));
 }
 ```
 
 It's very similar to our `qemu-bios` executable.
-The only two differences are that it passes two additional `-drive if=pflash,..` arguments to load UEFI firmware (`OVMF_CODE.fd`) and writable NVRAM (`OVMF_VARS.fd`), and that it uses the `UEFI_IMAGE` instead of the `BIOS_IMAGE`.
+The only two differences are that it passes an additional `-bios` argument and that it uses the `UEFI_IMAGE` instead of the `BIOS_IMAGE`.
 Using a quick `cargo run --bin qemu-uefi`, we can confirm that it works as intended.
 
+
 ### Screen Output
 
 While we see some screen output from the bootloader, our kernel still does nothing.

blog/content/edition-3/posts/03-screen-output/index.md

@@ -149,6 +149,8 @@ In the new module, we create basic structs for representing pixel positions and
 ```rust ,hl_lines=3-16
 // in new kernel/src/framebuffer.rs file
 
+use bootloader_api::info::FrameBuffer;
+
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 pub struct Position {
     pub x: usize,
@@ -163,7 +165,7 @@ pub struct Color {
 }
 ```
 
-By marking the structs and their fields as `pub`, we make them accessible from the parent `kernel` module.
+By marking the sturcts and their fields as `pub`, we make them accessible from the parent `kernel` module.
 We use the `#[derive]` attribute to implement the [`Debug`], [`Clone`], [`Copy`], [`PartialEq`], and [`Eq`] traits of Rust's core library.
 These traits allow us to duplicate, compare, and print the structs.
 
@@ -178,7 +180,7 @@ Next, we create a function for setting a specific pixel in the framebuffer to a
 ```rust ,hl_lines=3 5-39
 // in new kernel/src/framebuffer.rs file
 
-use bootloader_api::info::{FrameBuffer, PixelFormat};
+use bootloader_api::info::PixelFormat;
 
 pub fn set_pixel_in(framebuffer: &mut FrameBuffer, position: Position, color: Color) {
     let info = framebuffer.info();
@@ -310,46 +312,31 @@ Fortunately, there is the nice `no_std`-compatible [`embedded-graphics`] crate,
 
 ```rust ,hl_lines=3
 // in kernel/src/framebuffer.rs
-use embedded_graphics::{
-    Pixel,
-    draw_target::DrawTarget,
-    geometry::{OriginDimensions, Size},
-    pixelcolor::{Rgb888, RgbColor},
-};
 
-pub struct Display<'f> {
+pub struct Display {
-    framebuffer: &'f mut FrameBuffer,
+    framebuffer: Framebuffer,
 }
 
-impl<'f> Display<'f> {
+impl Display {
-    pub fn new(framebuffer: &'f mut FrameBuffer) -> Display {
+    pub fn new(framebuffer: Framebuffer) -> Display {
-        Display { framebuffer }
+        Self { framebuffer }
     }
 
-    fn draw_pixel(&mut self, Pixel(coordinates, color): Pixel<Rgb888>) {
+    fn draw_pixel(&mut self, pixel: Pixel) {
-        // ignore any out of bounds pixels
+        // ignore any pixels that are out of bounds.
         let (width, height) = {
             let info = self.framebuffer.info();
-
             (info.width, info.height)
-        };
+        }
-
+        if let Ok((x @ 0..width, y @ 0..height)) = coordinates.try_into() {
-        let (x, y) = {
-            let c: (i32, i32) = coordinates.into();
-            (c.0 as usize, c.1 as usize)
-        };
-
-        if (0..width).contains(&x) && (0..height).contains(&y) {
             let color = Color { red: color.r(), green: color.g(), blue: color.b()};
-
+            set_pixel_in(&mut self.framebuffer, Position { x, y }, color);
-            set_pixel_in(self.framebuffer, Position { x, y }, color);
         }
     }
 }
 
-
+impl embedded_graphics::draw_target::DrawTarget for Display {
-impl<'f> DrawTarget for Display<'f> {
+    type Color = embedded_graphics::pixelcolor::Rgb888;
-    type Color = Rgb888;
 
     /// Drawing operations can never fail.
     type Error = core::convert::Infallible;
@@ -358,21 +345,12 @@ impl<'f> DrawTarget for Display<'f> {
     where
         I: IntoIterator<Item = Pixel<Self::Color>>,
     {
-        for pixel in pixels.into_iter() {
+        for Pixel(coordinates, color) in pixels.into_iter() {
             self.draw_pixel(pixel);
         }
-
         Ok(())
     }
 }
-
-impl<'f> OriginDimensions for Display<'f> {
-    fn size(&self) -> Size {
-        let info = self.framebuffer.info();
-
-        Size::new(info.width as u32, info.height as u32)
-    }
-}
 ```
 
 ---
@@ -382,7 +360,7 @@ impl<'f> OriginDimensions for Display<'f> {
 
 
 
-So far, we have drawn shapes and pixels directly onto the framebuffer. That's fine and all, but how is one able to go from that to displaying text on the screen? Understanding this requires taking a deep dive into how characters are rendered behind the scenes.
+  draw shapes and pixels directly onto the framebuffer. That's fine and all, but how is one able to go from that to displaying text on the screen? Understanding this requires taking a deep dive into how characters are rendered behind the scenes.
 
 When a key is pressed on the keyboard, it sends a character code to the CPU. It's the CPU's job at that point to then interpret the character code and match it with an image to draw on the screen. The image is then sent to either the GPU or the framebuffer (the latter in our case) to be drawn on the screen, and the user sees that image as a letter, number, CJK character, emoji, or whatever else he or she wanted to have displayed by pressing that key.
 
@@ -472,7 +450,7 @@ fn kernel_main(boot_info: &'static mut bootloader_api::BootInfo) -> ! {
     let frame_buffer_struct = frame_buffer_option.unwrap();
     
     // extract the framebuffer info and, to satisfy the borrow checker, clone it
-    let frame_buffer_info = frame_buffer_struct.info().clone();
+    let frame_buffer_info = frame_buffer.info().clone();
     
     // get the framebuffer's mutable raw byte slice
     let raw_frame_buffer = frame_buffer_struct.buffer_mut();