update blog

Signed-off-by: Henry Gressmann <[email protected]>

Author: explodingcamera

content/rust-os/1-hello-riscv/assets/boot1.svg

@@ -129,7 +129,9 @@ SBI (Supervisor Binary Interface) is a standard interface for interacting with t
 
 The version shipping with QEMU uses a Jump Address ([_FW_JUMP_](https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_jump.md)), in this case, `0x80200000`, which is where we'll be putting our kernel. QEMU will load our kernel into memory and jump to `0x80000000`, from where OpenSBI will then jump to `0x80200000`, where our kernel is located.
 
-{{ figure(caption = "RISC-V Boot Flow", position="center", src="./assets/boot.svg") }}
+{{ figure(caption = "Traditional Boot Flow", position="center", src="./assets/boot1.svg") }}
+
+{{ figure(caption = "QEMU RISC-V Boot Flow", position="center", src="./assets/boot.svg") }}
 
 This architecture has a lot of benefits: SBI puts an abstraction layer between the kernel and the hardware, which allows us to write a single kernel that can run on any RISC-V CPU, regardless of the extensions it supports, as long as it has an SBI implementation. SBI also provides many functions like printing to and reading from the console, and it loads a flattened device tree (FDT) into memory, which we'll also be using later on to get information about the hardware.
 

content/rust-os/1-hello-riscv/index.md

@@ -3,13 +3,18 @@ transparent = true
 title = "Creating a Kernel in Rust #2: Shell"
 description = "Creating a simple shell for our kernel to run commands and help us debug"
 date = 2023-05-14
-draft = true
 
 [taxonomies]
 tags = ["rust", "riscv", "kernel"]
 series = ["rust-os"]
 +++
 
+{% quote (class="info")%}
+
+This is a series of posts about my journey creating a kernel in rust. You can find the code for this project [here](https://github.com/explodingcamera/pogos/tree/part-1) and all of the posts in this series [here](/series/os-dev/).
+
+{% end %}
+
 Now that we have a basic kernel that can print to the screen, we can start building out some more functionality.
 The first thing I want to do is create a simple shell that will allow us to run some commands and more easily interact with our system.
 
@@ -33,20 +38,29 @@ First, we'll create a new file `src/linear-allocator.rs` and will create the bas
 
 use core::sync::atomic::{AtomicUsize};
 
-pub struct LinearAllocator<const T: usize> {
+pub struct LinearAllocator {
     head: AtomicUsize, // the current index of the buffer
     // AtomicUsize is a special type that allows us to safely share data
     // between threads without using locks
 
-    memory: [u8; T], // our in-memory "arena"
+    start: *mut u8, // raw pointer to the start of the heap
+    end: *mut u8,   // raw pointer to the end of the heap
 }
-
 // allow our allocator to be shared between threads
 unsafe impl Sync for LinearAllocator {}
 
 impl LinearAllocator {
-    pub fn init(buffer: &'static mut [u8]) -> Self {
-        Self { head: AtomicUsize::new(0), memory }
+    pub const fn empty() -> Self {
+        Self {
+            head: AtomicUsize::new(0),
+            start: core::ptr::null_mut(),
+            end: core::ptr::null_mut(),
+        }
+    }
+
+    pub fn init(&mut self, start: usize, size: usize) {
+        self.start = start as *mut u8;
+        self.end = unsafe { self.start.add(size) };
     }
 }
 ```
@@ -60,8 +74,8 @@ use core::alloc::{GlobalAlloc, Layout};
 use core::ptr::NonNull;
 use core::sync::atomic::{Ordering};
 
-unsafe impl<const T: usize> GlobalAlloc for LinearAllocator<T> {
-    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
+unsafe impl GlobalAlloc for LinearAllocator {
+        unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
         /* The byte multiple that our allocated memory must start at
           most hardware architectures perform better when reading/writing
           data at aligned addresses (e.g. 4 bytes, 8 bytes, etc.) so we