<?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>Tue, 27 Oct 2026 21:10:19 +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 III</title>
		<link>https://jcomes.org/an-aarch64-os-in-rust-implementing-virtual-memory-iii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 20 Oct 2026 06:55:00 +0000</pubDate>
				<category><![CDATA[Arm]]></category>
		<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Memory]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1910</guid>

					<description><![CDATA[In the previous post, we built the physical frame allocator required to construct page tables dynamically. Until now, the kernel has relied on an identity mapping, with virtual addresses equal to physical addresses, which was enough to enable the MMU and continue execution with address translation enabled. The next step is to map the kernel [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1910</post-id>	</item>
		<item>
		<title>An AArch64 OS in Rust – Implementing Virtual Memory II</title>
		<link>https://jcomes.org/an-aarch64-os-in-rust-implementing-virtual-memory-ii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Thu, 24 Sep 2026 07:13:45 +0000</pubDate>
				<category><![CDATA[Arm]]></category>
		<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Memory]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1813</guid>

					<description><![CDATA[In the previous post, we laid the hardware foundation for our virtual memory subsystem: configuring the MMU, setting up MAIR attributes, and establishing an identity mapping to ensure our kernel survived the transition to address translation. While we successfully enabled translation without crashing, our current translation tables are backed by statically reserved storage. To build [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1813</post-id>	</item>
		<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, 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 platform. However, our [&#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>
	</channel>
</rss>
