Ep.08 - S2|E1: My Journey into Embedded Linux & Kernel Development

In this season premiere of Build, Create & Learn – A Maker’s Journey, I begin a brand-new adventure: diving into Embedded Linux and Kernel Driver Development.

 

After years of working with microcontrollers and maker projects, I wanted to understand what really happens under the hood — how Linux talks to hardware, what lives inside the kernel, and why that matters for anyone building modern embedded systems.

 

I share how I set up a dedicated Linux environment, wrote my first “Hello Kernel” module, and what I learned along the way about the invisible bridge between user space and kernel space. It’s the start of a deeper exploration into the layers that make our devices tick — from bootloaders to drivers and everything in between.

 

Thanks for tuning in to this new season. Here’s to more building, creating, and learning — this time, inside the Linux kernel!

Episode Transcript

(00:00):
Hey everybody, welcome back to Build, Create & Learn A Maker’s Journey.
I’m your host Stefan and today marks the start of a brand new chapter.
After finishing my first podcast season where I built and tested my drone telemetry system, I wanted to go even deeper.

(00:23):
This new season is all about embedded Linux and Linux kernel development.
A topic that sits right at the intersection between hardware and software, between embedded tinkering and serious system programming.
I’m always been fascinated by what happened beneath the surface, beyond the firmware and beyond the C code, down in the layers where the operating system talks directly to the hardware.

(00:49):
And this season I want to finally explore this world.
Let’s start why I chose this topic.
My first real contact with Linux goes way back, almost 20 years ago when I was experimenting with Fedora and SUSE Linux during my time in my first company.

(01:13):
I used it for some development and a bit of system tinkering, but when I switched to macOS later I stayed within the Unix family.
macOS always felt like a comfortable middle ground, the polish of the Apple ecosystem, but the power of the Unix shell right underneath.
Over the years I kept jumping between platforms depending on what project I was doing, but the more I was working on embedded systems, the more I realized if you really want to understand how your program interacts with the hardware, Linux is the place to learn.

(01:51):
It’s open and it’s transparent and it’s the foundation of everything from Raspberry Pies to Rockets.
So lately I have had a growing urge to understand what’s actually happening under the hood.
What’s the difference between the kernel space and the user space?
How do systems call really work?

(02:11):
And how exactly do applications talk to the hardware through drivers, interrupts or memory?
For me these are not just technical details, these shape how I think about programming as a whole.
This kind of low level exploration teaches you how to write better, more efficient and more intentional code.

(02:34):
It’s not about control for the control’s sake, it’s about understanding.
One of the first things I had to confront on the journey was the distinction between a micro-controller and a microprocessor.

(02:56):
Now that sounds like a simple difference, but it’s surprisingly fundamental.
I’ve built tons of projects over the years using Raspberry Pies, ESP32 boards and the Arduino, but I never really thought deeply about the boundary between them.
A micro-controller is self-contained.

(03:18):
It has a CPU, memory and peripherals all on one chip.
It’s perfect for running small firmware loops, reading sensors or toggling pins.
The microprocessor on the other hand is designed to run a full operating system like Linux, with virtual memory, multitasking and user space separation.

(03:42):
When you compare the specs of a Raspberry Pi and the RP2040 board, the difference becomes obvious.
Boards like the ESP32 and the STM32 simply don’t have enough RAM and processing power to host a real operating system.
At best you can run a real-time operating system, something that schedules tasks efficiently but doesn’t have a file system or processor in the same sense as Linux.

(04:14):
But this realization sparked an idea.
What’s the lowest possible hardware that could still run Linux?
Could you build a minimal Linux system on a low power, low end hardware?
That’s the question I will definitely explore later in this series, because it feels like an ultimate make a challenge.

(04:44):
But before diving into the kernel code, I need the right environment.
I decided to start clean, setting up a fresh Linux VM just for kernel and driver development.
I’ve always liked Debian based distributions and Ubuntu has to be my go-to choice for many years.

(05:04):
For this project I’ve chosen the latest Ubuntu 25, it’s stable, modern and has a great package management, which makes life easier when you are constantly installing build tools and dependencies.
For the virtualization I switched to UTM, it runs on my Macbook and uses QMUE under the hood.

(05:29):
I’ve tried parallels and VMWareFusion in the past, but I’ve found UTM to be surprisingly smooth and lightweight.
And honestly, like having something that’s open source and transparent is always my preferred choice.
Normally, I work in a terminal only set up, but since the project involves writing and building quite a bit of code, I went with the desktop version of Ubuntu.

(05:56):
It’s nice to have a browser, a terminal and an editor as side by side.
So the first thing I always do on a new machine is to set up the terminal.
For me it’s not about which shell is best, I’ve used the bash shell, fish shell and zsh, but I’ve stuck with the zsh for a couple of years now, mainly because it has a great collection of plugins and themes and it’s well tuned as a terminal and feels like home.

(06:28):
It’s where I spend most of my time.
I also installed Git, some other core utilities and then customized my .zshrc file with my favorite aliases and plugins.
It’s a small ritual, but it sets the mood.

(06:50):
You are not just setting up a tool, you are preparing a workshop.
For code editing I decided to start with VS Code.
It’s lightweight, cross-platform and it integrates with the build tools and debuggers.
That said, I’ve been a JetBrains user for more than a decade, so at some point in time I might switch to C-Lion, their C and C++ IDE once I’ve started working on more complex modules.

(07:19):
Then came the big step, writing my first Hello World kernel module.
I started by installing the build essential packages and the Linux kernel headers from my system.

(07:40):
Then I followed a tutorial that walked through the basic structure of a loadable kernel model.
You start with a couple of header includes, defining some metadata with macros like the module license, the module author and the description for the module.

(08:01):
Then you implement two functions, one for the initialization and one for the cleanup, which the kernel uses to hook your module into its system.
After writing the code I created a make file for the build process.
I run make and of course it didn’t compile the first time missing semicolon classic.

(08:27):
After some small fixes it builds successfully.
Then I run `sudo insmod hello.ko` to register the module in the kernel and the command loads it directly into the kernel.
At first nothing appeared on the screen.

(08:47):
That’s when I realized kernel models don’t print to the terminal.
They write to the kernel log.
So I used the message and there it was, my first kernel message.
Hello world from my kernel.
It’s a tiny simple thing, but seeing your own code executed by the kernel itself feels different.

(09:13):
It’s not like running a Python script or compiling C on the user side.
It feels like you’re stepping behind the curtain into the backstage of the operating system.
That was my first micro-milestone and it reminded me why I love learning by doing.

(09:39):
As part of my preparation I also started a Udemy course about the Linux internals.
It’s helping me connecting the dots between everything happening during the system startup and what I see in my VM.
For example before the kernel even loads there are three boot stages.
The ROM bootloader, the first stage bootloader and the second bootloader.

(10:03):
Finally after these steps are done the kernel starts and begins the initialization of the system.
Mounting the file system, setting up the memory and starting the first user space processes.
Learning about this sequence was actually eye-opening.

(10:23):
I made me, it made me realize how much happened before that blinking login prompt even appears.
There’s a level of complexity in how Linux initializes itself that’s truly fascinating.
If you’ve ever worked on a robotics, IoT or drone you will eventually cross paths with Linux.

(10:49):
Once your system becomes complex enough whether it’s handling multiple sensors or implementing AI or managing multiple camera feeds you need more than a microcontroller.
That’s where Embedded Linux comes in.
It bridges the gap between the low level control and the high level computation.

(11:12):
And what’s even more exciting today is the variety of single board computers available.
The Raspberry Pi isn’t the only option anymore.
There are tons of alternatives, Rock Pi, Beagleboard, Orange Pi, Radxa and more each suitable for a different use case or a price point.

(11:34):
Many of these boards expose some GPIO pins that can be accessed directly from Linux but to do that properly especially for performance and safety you often need the kernel driver.
Sure, there are Python libraries for user space wrappers that let you talk your pins or read sensor data quickly.

(11:57):
But I want to understand what happens underneath.
What makes these libraries work?
How does Linux give you access to this hardware?
That’s what I’m setting out to learn and share in this season.
Beyond the technical side this journey is also about shaping my C programming skills.
Last season working on the STM32 and RP2040 boards I realized there is still so much depth to see that I haven’t fully explored.

(12:26):
To work comfortably in the kernel space where you can’t just print a debug statement or rely on external libraries you need to be precise.
And I actually find that exciting.
It’s like learning to drive on a racetrack after years of regular traffic.

(12:48):
Everything matters and every small mistake teaches you something new.
In the next episode I will try to cross compile my first kernel module for a Raspberry Pi taking the code from the virtual environment and running it on a real hardware.

(13:10):
That means setting up the right tool chain, configuring the kernel headers for ARM architecture and learning how to build modules remotely.
Along the way I will keep sharing my process, not just what works but also what doesn’t.
Because as always the goal of this podcast isn’t to pretend to be an expert.

(13:31):
It’s the documentation of the process and learning in public.
If you enjoy these first steps into the kernel world make sure to subscribe to the Makers Logbook, my weekly newsletter where I share behind the scene notes, project updates and extra resources.
And if you are listening on YouTube or Spotify leave a comment and subscribe to help others discover this show.

(13:58):
Thanks for joining me on the start of this new season.
Until next time and let’s keep building, creating and learning together.