<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Kernel &#8211; jcomes.org</title>
	<atom:link href="https://jcomes.org/category/knl/feed" rel="self" type="application/rss+xml" />
	<link>https://jcomes.org</link>
	<description></description>
	<lastBuildDate>Sun, 26 Apr 2026 16:35:31 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
<site xmlns="com-wordpress:feed-additions:1">204893580</site>	<item>
		<title>An AArch64 OS in Rust – Implementing Virtual Memory I</title>
		<link>https://jcomes.org/an-aarch64-os-in-rust-implementing-virtual-memory-i</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 31 Mar 2026 07:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Memory]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1590</guid>

					<description><![CDATA[In the previous post, we moved from structural parsing to semantic interpretation of the Device Tree, allowing our kernel to dynamically discover peripheral addresses and interrupt lines. But while we have successfully purged hardcoded addresses from the assembly in favor of dynamic discovery, we are still operating in a flat, unprotected physical address space. To [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1590</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Parsing the Device Tree II</title>
		<link>https://jcomes.org/aarch64-os-dtb-parsing-ii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 03 Feb 2026 07:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1519</guid>

					<description><![CDATA[In the previous post, we built a structural parser that transformed the raw Device Tree Blob (DTB) into a searchable table of PlatformDevice entries. While we can now traverse the tree and see property names like reg or compatible, these properties are still just raw, big-endian byte buffers. Our kernel knows a device exists, but [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1519</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Parsing the Device Tree I</title>
		<link>https://jcomes.org/aarch64-os-dtb-parsing-i</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 20 Jan 2026 07:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1502</guid>

					<description><![CDATA[In my previous post, I built a minimal bootloader to load the kernel and pass the address of the Device Tree Blob (DTB) via the x0 register. Up until now, my kernel has been &#8220;cheating&#8221; &#8211; I hardcoded peripheral addresses like the UART (0x09000000) and the GIC (0x08000000) directly into the source code. While this [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1502</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Writing a Minimal Bootloader</title>
		<link>https://jcomes.org/aarch64-os-minimal-bootloader</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Wed, 29 Oct 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1082</guid>

					<description><![CDATA[As part of continuing the work on my AArch64 kernel, I’ve reached the point where it makes sense to introduce a minimal loader. Until now, I’ve been running the kernel directly, but going forward, I want a more realistic setup — one where a small bootloader is responsible for loading the kernel image, passing the [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1082</post-id>	</item>
		<item>
		<title>OS Dev Log I: The Road to a Real Kernel</title>
		<link>https://jcomes.org/os-dev-log-i</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 29 Jul 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=886</guid>

					<description><![CDATA[In the previous posts, we successfully set up our development environment, wrote a minimal kernel to handle booting, and initialized the UART to get a &#8220;Hello, world!&#8221; message printing to a serial console. This was a critical milestone, proving that our code can boot and run correctly within the QEMU emulator on the virt AArch64 [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">886</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Interrupt Handling III</title>
		<link>https://jcomes.org/aarch64-os-interrupt-handling-iii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 15 Jul 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=866</guid>

					<description><![CDATA[In my last post, I laid the groundwork for interrupt handling in my AArch64 OS in Rust. Now, it&#8217;s time to put that foundation to good use and switch our UART from a polling-based approach to an interrupt-driven one. In this post, I&#8217;ll go over how I made that change and what it means for [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">866</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Interrupt Handling II</title>
		<link>https://jcomes.org/aarch64-os-interrupt-handling-ii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Thu, 12 Jun 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=823</guid>

					<description><![CDATA[In the last post, we built the foundation for exception handling on AArch64 by focusing on synchronous exceptions like svc calls. This was an essential first step, but synchronous exceptions are only part of the picture. To fully embrace event-driven design — and move beyond polling — we now need to handle asynchronous exceptions, namely [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">823</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Interrupt Handling I</title>
		<link>https://jcomes.org/aarch64-os-interrupt-handling-i</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 06 May 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=801</guid>

					<description><![CDATA[In the previous post, we got our UART up and running using simple polling to send and receive data. While polling is straightforward, it&#8217;s also inefficient — the CPU must constantly check for new input, wasting cycles that could be used more effectively elsewhere. Now it&#8217;s time to take the next step: setting up a [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">801</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – UART Configuration</title>
		<link>https://jcomes.org/aarch64-os-setting-uart</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 29 Apr 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=772</guid>

					<description><![CDATA[In the last post, we successfully bootstrapped the very first steps of our AArch64 operating system. We wrote a minimal boot.s assembly file to set up the stack and called into Rust code, where we printed a simple &#8220;Hello, World!&#8221; message to the screen using the semihosting feature of QEMU.This gave us a first taste [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">772</post-id>	</item>
		<item>
		<title>From Scratch: An AArch64 OS in Rust &#8211; Hello World</title>
		<link>https://jcomes.org/aarch64-os-hello_world</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Wed, 16 Apr 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Kernel]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=723</guid>

					<description><![CDATA[Introduction I&#8217;ve been passionate about low-level systems and cybersecurity for years. Recently, I’ve felt the urge to go deeper — to build something from scratch. Inspired by the QEMU AArch64 Bare Bones guide, I decided to take on a new challenge: writing an operating system targeting the AArch64 architecture. But there’s a twist — instead [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">723</post-id>	</item>
	</channel>
</rss>
