Flash Yocto images to embedded Linux boards remotely with fernsteuerung.io
Yocto & CI/CD

Flash Yocto Images to Embedded Linux Boards Remotely

Your bitbake build finishes. Now what? Stop hunting for SD cards and USB readers. Flash your image to a real board with a single fernctl command — from anywhere.

Feb 17, 2026 · 8 min read

The last mile of every Yocto build

After hours of BitBake builds, your embedded Linux .wic image is finally sitting in tmp/deploy/images/, ready to go. Now comes the tedious part:

  • Eject the SD card from the board
  • Plug it into a USB reader on your laptop
  • Run bmaptool copy or dd
  • Swap the card back into the board
  • Power-cycle and hope the serial cable is still connected

This works for one embedded Linux board on your desk. It falls apart with multiple boards, remote teammates, or a CI/CD pipeline that needs to test on real hardware.

This post shows how to skip the SD-card shuffle entirely. Your new workflow: build → upload → flash → boot → verify, all without leaving your terminal.

What you need for remote Yocto flashing

Before we start, here is the setup:

  • A Yocto build environment — any release works.
  • A board registered on fernsteuerung.io — with a USB-SD-Mux or another method for flashing .wic images to the board.
  • The fernctl CLI — download it from the fernsteuerung.io dashboard. Run fernctl config to set your server URL and API token.

If you do not have a board set up yet, the minimal setup guide walks you through the hardware side.

Step 1 — Find your Yocto images

After your BitBake build finishes, the output lands in the deploy directory. Navigate there and look for the .wic artifacts:

cd tmp/deploy/images/<MACHINE>/
ls | grep wic
core-image-minimal-<MACHINE>.rootfs.wic.bmap
core-image-minimal-<MACHINE>.rootfs.wic.xz

The .wic.xz is your compressed disk image. The .bmap file is a block map that makes flashing faster — fernsteuerung.io uses bmaptool under the hood, so keep both files.

Step 2 — Upload the image

fernsteuerung.io provides an S3-backed image hub. Upload both the image and its bmap file with fernctl:

fernctl image upload core-image-minimal-<MACHINE>.rootfs.wic.xz
Initiating upload for "core-image-minimal-<MACHINE>.rootfs.wic.xz"...
Uploading... 62.0 MiB / 62.0 MiB (100%)
Upload complete.

fernctl image upload core-image-minimal-<MACHINE>.rootfs.wic.bmap
Initiating upload for "core-image-minimal-<MACHINE>.rootfs.wic.bmap"...
Uploading... 3.9 KiB / 3.9 KiB (100%)
Upload complete.

You can verify both files are in the image hub at any time:

fernctl image list
ID  NAME                                              SIZE      TAGS  LAST MODIFIED
11  core-image-minimal-<MACHINE>.rootfs.wic.bmap    3.9 KiB  -     2026-03-28 12:16:05
10  core-image-minimal-<MACHINE>.rootfs.wic.xz     62.0 MiB  -     2026-03-28 12:15:59

Step 3 — Lease a device and flash

Before flashing, you need to lease the target board. A lease is an exclusive lock — it guarantees nobody else will power-cycle or flash your board while you are using it.

fernctl lease acquire electra --ttl 30
Lease acquired for 30m0s (expires 2026-03-28 12:24 UTC)

With the lease active, flash the image:

fernctl flash core-image-minimal-<MACHINE>.rootfs.wic.xz \
  --bmap core-image-minimal-<MACHINE>.rootfs.wic.bmap electra
Starting flash...
Flashing... 100%
Flash complete.

Behind the scenes, the node server uses bmaptool to write the image — fast, verified block copies with no wasted writes.

The fernctl flash command waits for the operation to complete and shows real-time progress inline — no need to poll a separate endpoint.

Step 4 — Power-cycle and watch the boot

Once the flash completes, power-cycle the board to boot from the freshly written image:

fernctl power off electra
fernctl power on electra

Now open the serial console. You can use the web dashboard, or connect directly from your terminal with fernctl:

fernctl console electra
Connecting to device 97d2efd2-8bc4-436c-b6f7-33074716bc47...
Connected. Press Ctrl+A q to disconnect.

U-Boot SPL 2025.07 (Feb 11 2026 - 09:38:01 +0000)
...
U-Boot 2025.07 (Feb 11 2026 - 09:38:01 +0000)

SoC:   AM64X SR2.0 HS-FS
Model: PHYTEC phyBOARD-Electra-AM64x RDK
DRAM:  1.8 GiB
...
Hit any key to stop autoboot:  0
=>

You are watching your Yocto image boot on real hardware — from a coffee shop, a home office, or a CI runner in the cloud.

Why remote flashing matters for embedded Linux teams

Yocto builds are slow. A full build can take hours. When the output finally lands, the feedback loop to real hardware should be as short as possible — especially for hardware-in-the-loop testing where every cycle counts. Every manual step between bitbake completing and seeing a login prompt on the serial console is wasted time and a chance for human error.

With remote flashing, you get:

  • Faster iteration — flash and boot in the time it takes to grab a coffee, not setting up a board at your desk
  • Hardware-in-the-loop CI — Jenkins, GitLab CI, or GitHub Actions can flash real boards as a pipeline stage, catching BSP regressions before they reach QA
  • Team access — any engineer with a browser can flash and test, regardless of where the hardware physically sits

Recipes for common Yocto and BSP testing scenarios

Testing a device-tree change

You modified a .dts file and rebuilt. Flash the new image and check the serial console for probe errors or missing nodes. No need to swap cables or find the right board — just pick the device in the dashboard and flash.

Bisecting a boot regression

You have five candidate images from different commits. Upload them all, then flash each one in sequence. The serial console gives you instant visibility into where the boot breaks. What used to take an afternoon of SD-card swapping becomes a scripted loop.

Multi-board validation

Your BSP layer supports three machine configs: imx8mm-evk, raspberrypi4-64, and beaglebone-yocto. Build all three, upload the images, and flash them to their respective boards in parallel. One pipeline, three boards, zero hallway walks.

From BitBake to boot — embedded Linux automation in action

The gap between bitbake finishing and seeing your image run on hardware does not have to involve USB readers, SD cards, or setting up a board at your desk. With a USB-SD-Mux, a power switch, and the fernctl CLI, the entire flash-and-boot cycle becomes a scriptable, repeatable operation — the foundation for embedded Linux automation.

Whether you are a solo developer iterating on a BSP or a team running hardware-in-the-loop CI, the workflow is the same: build → upload → flash → boot → verify.

Ready to connect your first board? Create a free account and follow the minimal setup guide to get started.

What's coming next

Remote flashing and console access are just the beginning. Here is what we are working on to make board management even more powerful:

MCP server for board management

fernctl now ships a built-in Model Context Protocol server that exposes your boards as tools for AI agents. Your coding assistant can flash a new image, read the serial console, and power-cycle your board — all on its own, right from your IDE.

A polished terminal UI

The fernctl CLI gets the job done, but we want it to feel great. We are working on a rich terminal UI that lets you browse your devices, watch console output, trigger flashes, and manage leases — all from a single interactive view. Think of it as a dashboard for your terminal: fast, keyboard-driven, and zero context-switching.

Stay tuned — we will share more as these features take shape.