How to Build an Embedded Linux Lab From Scratch

You do not need expensive equipment to build an embedded Linux lab. Start in QEMU with no hardware at all, then add one well-documented board and a 3.3V USB-to-serial adapter, then a logic analyzer, and finally a JTAG debugger only when a real problem needs one. Each stage builds a specific, practical skill, and spending in that order keeps you learning instead of shopping.

Most people who want to learn embedded Linux spend the first month deciding what to buy. That is the wrong first question. A good embedded Linux lab is a small, deliberate set of tools that lets you practise the core tasks of the field: booting a board, reaching a serial console, bringing up a peripheral, and finding out why something does not work. The value is in the tasks you can perform, not the hardware you own. This tutorial builds the lab in four stages, cheapest first, and names the skill each stage teaches you.

Why an embedded Linux lab matters

Reading documentation does not teach you what to do when you connect a serial cable, get nothing, and have to work out whether the fault is the baud rate, the wiring, or a kernel that never reached the console. An embedded Linux lab gives you a place to make those mistakes on your own time and to build real, repeatable practice. Every stage below is something you can set up this week, and each one leaves you able to say, in specific terms, "I brought up this board, the console was silent, and here is how I traced it."

What you need

This tutorial assumes a Linux host. Ubuntu or Debian is shown throughout; on Windows, use WSL2 and run the same commands inside it. Install the host tools once, before you start:

[e-mail]:~$ sudo apt update
[e-mail]:~$ sudo apt install build-essential git bc libncurses-dev qemu-system-arm picocom i2c-tools

That single set covers every stage below: build-essential, git, bc, and libncurses-dev for building Buildroot and running make menuconfig; qemu-system-arm for Stage 1; picocom for the serial console in Stage 2; and i2c-tools for Stage 3.

Stage 1: Start in QEMU, before you buy anything

The cheapest board is no board. QEMU boots a full ARM or ARM64 Linux system on your laptop, so you can learn the entire build-and-boot workflow for free. This is where your first few weeks should go. Buildroot ships ready-made configurations that target QEMU machines. On the Linux host:

[e-mail]:~$ git clone https://git.buildroot.net/buildroot
[e-mail]:~$ cd buildroot
[e-mail]:~$ make list-defconfigs | grep qemu
[e-mail]:~$ make qemu_aarch64_virt_defconfig
[e-mail]:~$ make menuconfig
[e-mail]:~$ make

At the make menuconfig step you can accept the defaults the first time — it is there so you can change options later, not something you must edit now. The build then produces a kernel image and a root filesystem. The simplest way to launch is the ready-to-run start-qemu.sh script Buildroot writes into the output directory:

[e-mail]:~$ ./output/images/start-qemu.sh

If you prefer to see the full command, this is the equivalent direct invocation:

[e-mail]:~$ qemu-system-aarch64 -M virt -cpu cortex-a53 -nographic -kernel output/images/Image -append "rootwait root=/dev/vda console=ttyAMA0" -drive file=output/images/rootfs.ext4,if=virtio,format=raw

To leave a -nographic QEMU session, press Ctrl-A and then x. With this alone you can practise kernel configuration, rebuild after a config change, and cross-compile a program for the target. The skills you build here — cross-compiling, configuring a kernel, and assembling a root filesystem — are the same ones a BSP (Board Support Package) job needs. The only thing QEMU cannot teach you is real hardware behaviour, which is Stage 2.

Try this → Before spending any money, build and boot one Buildroot image in QEMU, then rebuild it after adding a single package. If you can do that from memory, you are ready for a real board.

Stage 2: Your first board and a serial console

When you move to hardware, choose documentation and mainline support over raw speed. A board with a full technical reference manual and an upstream kernel teaches cleaner workflows than a faster board with a partly closed boot process.

The BeagleBone Black is a strong first choice: a Texas Instruments AM335x SoC (single-core Cortex-A8), supported in the mainline kernel and U-Boot, and documented down to the schematic. A Raspberry Pi 4 or 5 also works and has a large community, but its boot path starts in a proprietary VideoCore firmware stage before the ARM cores run, so it teaches less about a standard embedded boot flow. Both are fine; just know what each is teaching you.

The single most important tool after the board is a 3.3V USB-to-TTL serial adapter. This is how you reach the debug console — the output from U-Boot and the kernel before any network exists. Adapters built on the FT232R, CP2102, or PL2303 chips are inexpensive. It must be a 3.3V adapter: a 5V one can damage the board's UART pins.

Wire three lines to the board's debug serial header (on the BeagleBone Black this is the 6-pin J1 header), and cross transmit and receive: adapter TX to board RX, adapter RX to board TX, and GND to GND. Do not connect the adapter's Vcc or 5V pin — the board powers itself. Then open a terminal:

[e-mail]:~$ picocom -b 115200 /dev/ttyUSB0

If that fails with a permission error, your user is not in the dialout group. Add it once and log back in:

[e-mail]:~$ sudo usermod -aG dialout $USER

The debug console runs at 115200 baud, 8 data bits, no parity, 1 stop bit (written 8N1). minicom and screen /dev/ttyUSB0 115200 do the same job. Some adapters appear as /dev/ttyACM0 rather than /dev/ttyUSB0. The first time you power the board and see U-Boot print its output, you have moved from theory into real embedded work.

Try this → Get a serial console on a real board and interrupt U-Boot at its countdown. Learning to stop at the U-Boot prompt and read the environment is a skill you will use on every project.

Stage 3: Talking to real peripherals

Once the board boots, the next skill is connecting a device and driving it from Linux. A cheap sensor breakout on the I2C bus, such as a TMP102 temperature sensor, is enough. First list the I2C buses the kernel exposes, so you use the right bus number (the number does not always match the header label):

[e-mail]:~$ sudo i2cdetect -l
i2c-1   i2c OMAP I2C adapter    I2C adapter

Then scan that bus for your device. Use sudo, as the I2C device nodes are not world-accessible by default:

[e-mail]:~$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
...
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --

An address that appears (here 0x48) tells you the device is wired and powered correctly. If the scan shows only dashes, either the wiring is wrong or the bus is not enabled — on many boards the I2C controller and its pins must be turned on in the device tree before the bus works.

You then describe the device to the kernel through the device tree so a driver can claim it. The essential part is a child node under the I2C controller, giving the device's compatible string and its bus address in reg. As a device tree overlay it looks like this:

&i2c1 {
    status = "okay";

    tmp102@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
    };
};

Compiling and loading the overlay is board-specific and worth learning on its own, but the effect is the same everywhere: once a matching driver binds, the device shows up in sysfs, named by bus and address:

[e-mail]:~$ ls /sys/bus/i2c/devices/
1-0048  i2c-1

This costs very little — a few sensor modules and jumper wires — but it is where driver and device-tree skills become real. Adding a device to the device tree and watching the kernel bind a driver to it is exactly what board bring-up work involves.

Stage 4: A logic analyzer and a JTAG debugger

The last two tools are for when something does not work and the console cannot tell you why. Buy them when you hit a problem that needs them, not before.

A low-cost USB logic analyzer lets you see the actual signals on an I2C, SPI, or UART line. The open-source sigrok project and its PulseView front end drive many inexpensive analyzers and decode these protocols for you. When a sensor returns nonsense, the analyzer shows whether the bus is even producing the bits you expect, which turns guessing into measuring.

A JTAG or SWD debugger comes last. With OpenOCD and an FTDI-based probe or a J-Link — or a Black Magic Probe, which has its own built-in GDB server and needs no OpenOCD — you can halt the processor and step through low-level code. This is most useful for debugging the bootloader or very early kernel start-up before the console is alive. A beginner rarely needs it in the first several months, so it should not be an early purchase.

A basic digital multimeter is worth keeping on the bench throughout: checking a voltage rail or continuity often explains a "dead" board faster than any software tool. If you want to go deeper into the full board bring-up and driver workflow these tools support, that is the core of our Embedded Linux Mastery Track.

Try this → Do not buy a logic analyzer or JTAG probe on day one. Add each one the first time a real bug makes you wish you had it — you will understand the tool far better for having needed it.

Key takeaways

• Free: QEMU plus Buildroot on the PC you already own teaches the full build-and-boot workflow before you spend anything.
• Low cost: your first purchases are one well-documented, mainline-supported board and a 3.3V USB-to-serial adapter — the debug console (115200 8N1) is the tool you will use on every project.
• Low cost: a few sensor breakouts and jumper wires turn device-tree and driver knowledge into real skill.
• Buy when needed: add a logic analyzer, and later a JTAG or SWD probe, only when a bug makes you wish you had it.
• Let each purchase be driven by the task you are trying to learn, and a basic multimeter stays useful throughout.

Frequently asked questions

Do I need to buy hardware to start learning embedded Linux?
No. QEMU boots a full ARM or ARM64 Linux system on your PC, and Buildroot ships ready-made QEMU configurations, so you can learn cross-compiling, kernel configuration, and root filesystem building with no hardware at all.

Which board should I buy first?
Choose documentation and mainline support over speed. A fully documented, mainline-supported board like the BeagleBone Black teaches cleaner workflows than a Raspberry Pi, whose boot process begins in proprietary firmware. Both work; pick the one that is better documented for what you want to learn.

What is the most important tool after the board?
A 3.3V USB-to-TTL serial adapter. It lets you reach the debug console, where U-Boot and the kernel print before any network exists. Use a 3.3V adapter, not a 5V one, to avoid damaging the board.

Do I need a JTAG debugger as a beginner?
No. A JTAG or SWD debugger is most useful for bootloader and very early boot debugging and should be your last purchase. Add it only when you hit a problem the serial console cannot explain.

Further reading

• The Buildroot user manual — defconfigs, the QEMU targets, and adding packages.
• Buildroot qemu_aarch64_virt_defconfig — the exact configuration used above.
• BeagleBone Black documentation — reference manual, headers, and serial debug.
• sigrok / PulseView — open-source logic analyzer software and protocol decoders.
• OpenOCD documentation — JTAG/SWD debugging with common probes.

---

Originally published on TECH VEDA.