<?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>ARM &#8211; jcomes.org</title>
	<atom:link href="https://jcomes.org/category/arm/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>AFL++ Instrumentation in Practice: A Trace from Compilation to Fuzz II</title>
		<link>https://jcomes.org/afl-from-compilation-to-fuzz-ii</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 16 Sep 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Binary explotation]]></category>
		<category><![CDATA[Fuzzing]]></category>
		<category><![CDATA[RISC-V]]></category>
		<category><![CDATA[Userland]]></category>
		<category><![CDATA[x86_64]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=1037</guid>

					<description><![CDATA[In the previous post, we stopped at the point where AFL++ had produced instrumented binaries with PCGUARD and LTO. In this installment, we pick up the story at runtime: tracing the execution of those binaries, observing how coverage signals are collected, and following how afl-fuzz consumes that feedback to discover new paths. This is where [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">1037</post-id>	</item>
		<item>
		<title>AFL++ Instrumentation in Practice: A Trace from Compilation to Fuzz I</title>
		<link>https://jcomes.org/afl-from-compilation-to-fuzz-i</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 09 Sep 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Binary explotation]]></category>
		<category><![CDATA[Fuzzing]]></category>
		<category><![CDATA[RISC-V]]></category>
		<category><![CDATA[Userland]]></category>
		<category><![CDATA[x86_64]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=953</guid>

					<description><![CDATA[In the previous post, we laid out the theoretical map of AFL++’s instrumentation modes, from the classic edge coverage to modern LLVM-based techniques. With that foundation in place, it’s time to move from theory to practice. This article focuses on the compilation process with afl-cc: how LTO and PCGUARD instrumentation are inserted into the binary, [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">953</post-id>	</item>
		<item>
		<title>An Introduction to AFL++ Instrumentation Modes</title>
		<link>https://jcomes.org/afl-instrumentation-modes</link>
		
		<dc:creator><![CDATA[Jcomes]]></dc:creator>
		<pubDate>Tue, 02 Sep 2025 06:55:00 +0000</pubDate>
				<category><![CDATA[ARM]]></category>
		<category><![CDATA[Binary explotation]]></category>
		<category><![CDATA[Fuzzing]]></category>
		<category><![CDATA[RISC-V]]></category>
		<category><![CDATA[Userland]]></category>
		<category><![CDATA[x86_64]]></category>
		<guid isPermaLink="false">https://jcomes.org/?p=893</guid>

					<description><![CDATA[AFL++ has earned its reputation as a top-tier fuzzer thanks to its clever use of code coverage to guide the search for bugs. This series takes a deep dive into that process. In this first post, we’ll explore the instrumentation modes AFL++ uses to generate coverage—from the classic AFL edge hash to modern LLVM-based approaches. [&#8230;]]]></description>
		
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">893</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>
	</channel>
</rss>
