A Minimal Rust Kernel

[utterances-bot]

This is a general purpose comment thread for the “A Minimal Rust Kernel” post.

[Redrield]

I'm not really a fan of using this magic utility to turn our blob of Rust into a bootable image. The parts in raw assembly in the first edition were a bit tedious but I liked how they gave us a deeper understanding about how the process worked. I hope that this utility won't be sticking around for the post on UEFI booting...

[pixelherodev]

"They are designed to make the bootloader simple instead of the kernel. For example, the kernel needs to be linked with an adjusted default page size, because GRUB can't find the Multiboot header otherwise."

WRONG!

That is true of Multiboot2, a later standard which is less used and NOT multiboot-compatible.

However, the actual Multiboot standard does not have that problem at all.

[phil-opp]

@Redrield Fair point. On the other hand we already used grub-mkrescue as such a magic utility in the first edition, which did exactly the same thing (transforming a Rust binary into a bootable image). The only difference was that GRUB only put us into protected mode, so we had to do the last steps ourselves.

Apart from a less tedious start, the new bootloader gives us an opportunity for an even deeper understanding of the boot process than before: We're planning to write several posts on how the tool and the underlying bootloader works, in a similar fashion as the other posts (i.e. every line of code is in the post and you can follow along). Thus, we can hide the complexity at the beginning of the main post series and directly start with the more interesting part, but also provide resources to those who want to understand it all the way down.

[phil-opp]

@pixelherodev Huh? I was under the impression that Multiboot2 was the successor of Multiboot? Either way, Multiboot 1 is not a better solution for us since it does have other problems (if I remember correctly it does not support 64-bit ELF files at all).

[pixelherodev]

Fair enough. Multiboot 2 is essentially the spiritual successor to multiboot IIRC. I also remember multiboot being easier to get started with, but that's neither here nor there :p Honestly, while I don't think ignoring multiboot was a good idea, I can understand why you did so.

[phil-opp]

Honestly, while I don't think ignoring multiboot was a good idea, I can understand why you did so.

Yeah, there are clear tradeoffs in this case. I really like the idea behind multiboot, but the standard and the implementation not so much. I plan to add grub compatibility to the bootimage tool, so that you can boot it in a multi-OS setting too.

[ghost]

First of all, great tutorial, thanks a lot for the effort!
If you're on Ubuntu, like me, and building openssl-sys when trying to cargo install bootimage fails, make sure you have libssl-dev installed!

[phil-opp]

@FuzzyHerbivore Thanks a lot! I added a hint to the post in 5f195a8.

[kylegalloway]

Disclaimer: I'm on Windows.

There is a problem with running qemu-system-x86_64 -drive format=raw,file=bootimage.bin on windows. QEMU opens and flashes but doesn't display the "Hello World!" text.

Also, converting to a VDI for VirtualBox doesn't seem to work. I get:

$ VBoxManage convertdd .\bootimage.bin bootimage.vdi --format VDI
Converting from raw image file=".\bootimage.bin" to file="bootimage.vdi"...
Creating dynamic image with size 86016 bytes (1MB)...
VBoxManage.exe: error: Cannot create the disk image "bootimage.vdi": VERR_VD_INVALID_SIZE

[LuCC-que]

qemu-system-x86_64.exe

[LuCC-que]

qemu-system-x86_64.exe is how you start qemu in window

[bjorn3]

qemu-system-x86_64 on windows will run qemu-system-x86_64.exe, so that can't be the problem for them.

[tsatke]

What do you mean by "flashes"? Do you get a black screen? Does the boot loader run / get stuck?

[AaronCoad]

@kyle I'm also using Windows with cargo 1.26.0 nightly and xargo 0.3.11. Are these the same versions for you? I'm stuck with building using xargo:

xargo build --target hyenaos results in error: multiple input filenames provided
set RUST_TARGET_PATH=cd xargo build --target hyenaos results in nothing (including no build folder) as does RUST_TARGET_PATH=cd xargo build --target hyenaos.

Using cargo 1.26.0 nightly and xargo 0.3.11.

[AaronCoad]

@kylegalloway sorry

[AaronCoad]

Feeling a little silly, still stuck on the above, but realised I was setting the path incorrectly. The following steps still fail:

set RUST_TARGET_PATH=C:\HyenaOS\ or set RUST_TARGET_PATH=C:\HyenaOS
xargo build --target hyenaos or xargo build --target C:\HyenaOS\hyenaos

These are always with the multiple input filenames provided error.

Apologies for the multiple posts.

[phil-opp]

@kylegalloway

There is a problem with running qemu-system-x86_64 -drive format=raw,file=bootimage.bin on windows. QEMU opens and flashes but doesn't display the "Hello World!" text.

I pushed a new version of the bootloader yesterday, seems like this is the cause of the error. I reverted the change for now, so it should work again. Thanks for reporting!

Also, converting to a VDI for VirtualBox doesn't seem to work. I get:

Hmm, I have no idea about this error. I only found https://forum.lede-project.org/t/error-convert-img-to-vdi/152, which indicates that the image needs to be padded somehow before converting.

[phil-opp]

@AaronCoad Strange, I've never seen this error. Could you try it with --verbose?

[SomeAnotherDude]

Hi, I have a little problem with bootimage.
When I run it in debug mode and pass a created "bootimage.bin" file to qemu it fails with this:

    qemu-system-x86_64: Trying to execute code outside RAM or ROM at 0x000000018d47f075
    This usually means one of the following happened:

    (1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
    (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
    (3) Your guest kernel has a bug and crashed by jumping off into nowhere

    This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
    If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

    Execution cannot continue; stopping here.

But when I run it with --release flag everything works properly. Why could it happen?

.S my host OS is Kubuntu 17.10

[olest]

Hi, great tutorial! I am really enjoying it, but I running into the following problem:

I am trying to run cargo install bootimage but I get this error -Zbuild-std requires --target.

When I change the command to cargo install bootimage --target x86_64-blog_os.json, I get this error:

Updating crates.io index
Installing bootimage v0.10.3
Updating crates.io index
Compiling compiler_builtins v0.1.93
Compiling core v0.0.0 
Compiling proc-macro2 v1.0.63
Compiling unicode-ident v1.0.10
Compiling quote v1.0.29
Compiling serde v1.0.166
Compiling serde_json v1.0.100
Compiling thiserror v1.0.42
Compiling anyhow v1.0.71
Compiling syn v2.0.23
Compiling thiserror-impl v1.0.42
Compiling serde_derive v1.0.166
Compiling rustc-std-workspace-core v1.99.0 
Compiling semver-parser v0.7.0
Compiling ryu v1.0.14
error[E0463]: can't find crate for `std`

= note: the x86_64-rust_os target may not support the standard library
= note: std is required by serde because it does not declare #![no_std]
= help: consider building the standard library from source with cargo build -Zbuild-std

This is followed by several thousand more errors during the compilation of the `serde` lib. 

What am I missing?

[bjorn3]

You have to move to a different directory which doesn't contain the .cargo/config.toml you created to be able to do cargo install. Otherwise .cargo/config.toml applies to cargo install too.

[olest]

Hi @bjorn3 thanks for the quick response.

That solved it ... could have thought it about this myself. Thanks!

[Joelcgx]

hi

I get this when I load install bootimage --target x86_64-specs.json

This is how we put it in the json file

I appreciate the following:

PS E:\OS\blog_os> load boot image --target x86_64-specs.json
WARNING: environment variable CARGO_MANIFEST_DIR is not set
Construction core
Development target(s) [non-optimized + debug info] finished in 0.09s
Building bootloader
Build Bootloader v0.9.23 (C:\Users\Joel.cargo\registry\src\index.crates.io-6f17d22bba15001f\bootloader-0.9.23)
error: Could not run custom build command for bootloader v0.9.23 (C:\Users\Joel\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bootloader-0.9.23)

Caused by:
The process did not exit correctly: E:\OS\blog_os\target\bootimage\bootloader\release\build\bootloader-d6ed16076e08b61f\build-script-build (exit code: 101)
--- standard
The 'main' thread panicked at build.rs:160:9:
The kernel executable has an empty text section. Maybe the entry point was set incorrectly?

Kernel executable at E:\OS\blog_os\target\x86_64-specs\debug\blog_os

note: run with environment variable RUST_BACKTRACE=1 to show a trace
Error: Bootloader compilation failed.
standard:

[phil-opp]

This is the relevant part of the error message: "The kernel executable has an empty text section. Maybe the entry point was set incorrectly?"

Perhaps you forgot the no_mangle attribute on your _start function? If you have your code online somewhere I can take a quick look if you like.

[enidisepic]

I have the same issue that others had already, just that sadly I didn't have any luck getting it to work.

When trying to boot (either my own codebase or the post-02 branch of the repo) via QEMU I get a black screen and that's it. I don't get any errors in my terminal nor on screen and it seems that something happens right at the start (there's a flash where the text would be but it's too fast to see if it's the text or something else).

QEMU version is 8.1.1 on an M2 Pro MacBook, latest Rust nightly version as of right now and bootimage 0.9.23.

[AtomicGamer9523]

could you send what qemu-system version is installed ?

info

[lvauvillier]

qemu-system-x86_64 --version
QEMU emulator version 8.1.2
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

[lvauvillier]

I brew uninstall / reinstall. Same issue. even if i added the --build-from-source flag
If i can avoid to install Nix as @enidisepic did...

[lvauvillier]

Ok, i confirm the nix qemu version (same: 8.1.2) is working. Weird...
If someone understand why, i'll be happy to come back to brew :)

[phil-opp]

There were some related issue reports in #1249, with a potential fix in #1252. I haven't had time to review it yet, but I try to get to it soon.

[guilherme13c]

I get a linking error when I run cargo build and I have no idea on how to solve it

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/guilherme13c/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files/Python312/Scripts/:/mnt/c/Program Files/Python312/:/mnt/c/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v12.3/bin:/mnt/c/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v12.3/libnvvp:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/Go/bin:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/e/Windows Kits/10/Windows Performance Toolkit/:/mnt/c/Program Files/NVIDIA Corporation/Nsight Compute 2023.3.0/:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/Users/guilh/.cargo/bin:/mnt/c/Users/guilh/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/guilh/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/guilh/AppData/Local/Programs/oh-my-posh/bin:/mnt/c/Users/guilh/go/bin:/mnt/c/MinGW/bin:/mnt/c/Program Files (x86)/GnuWin32/bin:/mnt/c/Program Files/CMake/bin:/mnt/c/Program Files/Neovim/bin:/snap/bin" VSLANG="1033" "cc" "-m64" "/tmp/rustc55oTFZ/symbols.o" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a.2ulcca1rdi3w638p.rcgu.o" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a.33eq4o4iaq361tx9.rcgu.o" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a.3czxg1qgwc7mv2fi.rcgu.o" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a.bz2j0r8bqnqqdro.rcgu.o" "-Wl,--as-needed" "-L" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps" "-L" "/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-9686387289eaa322.rlib" "/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-632ae0f28c5e55ff.rlib" "/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-8ebeba8f78436673.rlib" "-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/guilherme13c/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: /usr/bin/ld: /mnt/c/Users/guilh/dev/nan_os/target/debug/deps/nan_os-2570a244fadd786a.33eq4o4iaq361tx9.rcgu.o: in function `_start':
          /mnt/c/Users/guilh/dev/nan_os/src/main.rs:14: multiple definition of `_start'; /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o:(.text+0x0): first defined here
          /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
          (.text+0x1b): undefined reference to `main'
          /usr/bin/ld: (.text+0x21): undefined reference to `__libc_start_main'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `nan_os` (bin "nan_os") due to previous error

[phil-opp]

Do you have your code online somewhere, so I can take a look?

[guilherme13c]

No i don't, but I can upload it when I get home today.

[guilherme13c]

here

[guilherme13c]

I just got it to work somehow (no idea how I did it). Thanks for the help anyway!

[phil-opp]

Great!

[DanielHuey]

Hi guys. I also got a compilation error message but Rust has said i should try out this command:

cargo build -Zbuild-std --target x86_64-your-os.json

Hope it helps another soul there.

[guilherme13c]

Probably something wrong on .cargo/config.toml. If you configurated that file as the blog says, you wouldn't need to pass any argument

[DanielHuey]

ohh yeah, thanks. i still get other errors though, so im gonna start that section afresh

[DanielHuey]

I kinda fixed them. bootloader dependency had to be 0.9.8, not 0.11.4 for me

[AltheimIcarus]

Hi everyone,

Can anyone guide me on how to boot the kernel using qemu-system-riscv64.exe?
I am particularly interested in building an OS for a RISC-V microcontroller board, but I just cannot get it running.

[AtomicGamer9523]

@AltheimIcarus this tutorial is for x86-64. To my understanding RISC-V works differently, so you will have to use different addresses, etc.

[phil-opp]

Yes, RISC-V is a different architecture so booting and many other things are done differently. I recommend to check out other tutorials, such as https://blog.henrygressmann.de/rust-os/1-hello-riscv/ or https://osblog.stephenmarz.com/.

[AltheimIcarus]

Thanks man, the link you provided is very helpful to me.
Your tutorial is easy to follow and interesting at the same time.

[Raine-Yang-UofT]

This tells cargo that it should recompile the core and compiler_builtins libraries. The latter is required because it is a dependency of core. In order to recompile these libraries, cargo needs access to the rust >source code, which we can install with rustup component add rust-src.

Just a reminder that during this part, after running rustup component add rust-src, we need to also run rustup update to actually download to rust source code for recompile

[Raine-Yang-UofT]

Sorry, never mind. It turns out we don't have to do that, previously I didn't update the Rust version to nightly and that caused the problem

[goesbyabhi]

Just a heads-up for anyone who is doing this, I am on Windows 11 and facing a lot of compilation errors due to serde library. That's because I did cargo add bootloader. So to fix this, I had to revert back to the version that the author is using. Or just version 0.9.* in general. So manually configure your Cargo.toml accordingly lol.

[ncdanie]

Much appreciated!

[trevorbeingtrevor]

For those running QEMU on Windows 10 (and probably 11). I would recommend following the first 3mins of the video below to get it installed properly. Also, I had to run my terminal (or vscode) as an admin for it to recognize the command

Installing QEMU video link
https://www.youtube.com/watch?v=al1cnTjeayk

In general, I would recommend comparing your files to the repository for this post if you get stuck
https://github.com/phil-opp/blog_os/tree/post-02

[goesbyabhi]

You can try adding the QEMU path to the System Path too. This might fix the constant Admin requirement issue. And would recommend Powershell over Command Prompt. For me, I guess I have only one account on my laptop so it might be assuming me as the Admin but that shouldn't be the issue because an emulator shouldn't ask for admin rights lol

[trevorbeingtrevor]

I was using Powershell as well, sorry I didn't specify. Also, I added "C:\Program Files\qemu" to the user and system path. I still need to run it as an admin for it to recognize the command. I am the only account as well.

[goesbyabhi]

Really weird tbh.

[trevorbeingtrevor]

Definitely weird. I just tried it again and now it's decided to work without running as an admin. Maybe it needed to be run once as admin or something idk. I would definitely still recommend trying it if you are having issues. It was the final piece of the puzzle earlier for me. I ran the command (non-admin) and it was not recognized. Then, I tried again with admin privileges and it worked.

[iambenkay]

Hello, Thanks for the wonderful resource. I am following it and all is going well but I got confused when I tried to run the image in QEMU. It runs successfully without any error but the "hello world!" text does not show up on the screen

I am running it on macos if that helps. I followed tutorial down to the letter except for changing name of target to my own name. Since it compiles successfully I don't think that is the cause of the issue.

[lpicanco]

See this.

[Saveriokarol]

Hi, i'm on a Kali Linux environment, i've compiled successfully the code, but when i ran the output image with QEMU, it showed me a kernel panic or something referred to panics, the error was on the file src/page_table.rs and i didnt found any of this, do some people got this error?

[Saveriokarol]

Here is the image of what looks:
https://snipboard.io/AvJn0Y.jpg

[Saveriokarol]

Ive fixed the problem: i'm a failure following the steps here, and i know everyone makes mistakes in their life, some video tutorials helped me and i'm glad now to have a Rust-based OS, thank you @phil-opp :)

[RileyMeta]

I learned that you can use a rust-toolchain.toml in the root of the project to specify that you want to use Rust Nightly. I found this necessary on Arch Linux.

[toolchain]
channel = "nightly"

[tsatke]

You can also add components and set a target there. I've configured my project in a way that I really just need rustup installed, and when I check it out on a completely new machine with just rustup installed, it installs a nightly toolchain, adds the llvm-preview, miri and rust-src components and adds the x86_64-unknown-none target to the toolchain. It's a really nice feature.

https://github.com/tsatke/devos/blob/841ffb4f01c947c24fbbb5f95beb6539635b770d/rust-toolchain.toml

[GuusNijhuis]

When i am building the Kernel, I get the following error:
PS C:\Users\UserName\RustroverProjects\OS> & cargo build --target x86_64-blog_os.json
error: failed to run rustc to learn about target-specific information

Caused by:
process didn't exit successfully: C:\Users\Guusn\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\rustc.exe - --crate-name ___ --print=file-names --target \\?\C:\Users\Guus n\RustroverProjects\OS\x86_64-blog_os.json --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings (exit code: 1)
--- stderr
error: Error loading target specification: expected value at line 1 column 1. Run rustc --print target-list for a list of built-in targets

[GuusNijhuis]

fixed it.... Apparently RustRover adds BOM (Byte Order Mark) to a JSON file

[IneptMantis4061]

I'm having a problem when building the binary crate for bare metal hardware. When I run cargo build --target x86_64-blog_os.json, I get the following error:

`error: failed to run 'rustc' to learn about target-specific information

Caused by:
process didn't exit successfully: '/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names --target /home/user/blog_os/x86_64-blog_os.json --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings' (exit status: 1)
--- stderr
error: Error loading target specification: target feature 'soft-float' is incompatible with the ABI but gets enabled in target spec. Run 'rustc --print target-list' for a list of built-in targets`

I am running this on the source code provided at https://github.com/phil-opp/blog_os on the post-02 branch. Has anyone else ran into this issue?

[ChocolateLoverRaj]

Idk but you can try replacing the custom target with just x86_64-unknown-none

[ViktorPopp]

I'm having a problem when building the binary crate for bare metal hardware. When I run cargo build --target x86_64-blog_os.json, I get the following error:

`error: failed to run 'rustc' to learn about target-specific information

Caused by: process didn't exit successfully: '/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names --target /home/user/blog_os/x86_64-blog_os.json --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings' (exit status: 1) --- stderr error: Error loading target specification: target feature 'soft-float' is incompatible with the ABI but gets enabled in target spec. Run 'rustc --print target-list' for a list of built-in targets`

I am running this on the source code provided at phil-opp/blog_os on the post-02 branch. Has anyone else ran into this issue?

There was a breaking change about the soft-float feature recently. See #1387

[IneptMantis4061]

I'm having a problem when building the binary crate for bare metal hardware. When I run cargo build --target x86_64-blog_os.json, I get the following error:
error: failed to run 'rustc' to learn about target-specific information Caused by: process didn't exit successfully: '/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names --target /home/user/blog_os/x86_64-blog_os.json --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings' (exit status: 1) --- stderr error: Error loading target specification: target feature 'soft-float' is incompatible with the ABI but gets enabled in target spec. Run 'rustc --print target-list' for a list of built-in targets
I am running this on the source code provided at phil-opp/blog_os on the post-02 branch. Has anyone else ran into this issue?

There was a breaking change about the soft-float feature recently. See #1387

Ah, thank you. Following the suggested change works for me