Build a cloud-native hardware lab with only three building blocks
fernsteuerung.io turns any embedded board into a remote hardware lab you can share with teammates, partners, and customers. Everything is reachable through the browser and APIs, so engineers can debug boards from anywhere.
The goal: show how much you can achieve with the smallest possible setup. You only need three devices:
- USB-controlled power switch — remote power cycling and recovery
- Serial debug adapter — full-console access for any board
- USB-SD-mux — remote flashing and SD card control
With just these pieces, you can do serious embedded Linux and software development, plus demo work, without flying hardware around or blocking a local bench.
Why are only three lab essentials enough?
When fernsteuerung.io manages the connections, the power switch, SD-mux, and serial port behave like a shared, scriptable lab slot. Power, storage, and console show up as APIs that CI/CD, QA rigs, and developers can drive. No VPN tricks, no brittle remote desktops. It is a repeatable workflow: assign a slot, run tests, collect logs, and hand the slot to the next team.
USB-SD-mux: Remote flashing and booting
The SD-mux sits between the board and its microSD card, switching ownership between host and target in milliseconds. From the dashboard or your pipeline you can:
- Flash .wic images, Debian ISOs, Buildroot images, or custom system builds
- Program single components such as bootloaders and firmware blobs
- Pull images from S3 or use fernsteuerung.io hosted storage for repeatable provisioning
It is a simple, generic way to flash and boot almost any board without touching hardware.
USB power switch: Your daily recovery tool
A controllable relay seems boring until a test fails. Integrated with fernsteuerung.io it becomes the safety net for every experiment:
- Power-cycle devices
- Recover from broken images, kernel panics, or stuck boot sequences
- Validate boot sequences
Because power control is scriptable, you can make recovery part of the pipeline instead of an after-hours task.
Serial debug adapter: Full visibility into the system
Serial access completes the minimal kit, giving you visibility into U-Boot, the kernel, and user space without being on-site.
Through the browser console or a WebSocket, you can:
- Watch boot logs for regressions and probing failures of drivers
- Drop into interactive shells for quick triage and log collection
- Investigate early-boot or secure-boot issues while coordinating with teammates
Logs and transcripts stay with the slot, so handoffs are simple and you can trace exactly what happened during a test window.
What you get out of the box
- A cloud-native hardware lab you can check into CI/CD like any other environment
- Fewer bench visits and fewer blocked engineers when hardware is offsite
- Shared, auditable access for teams and partners who need to see real-device behavior
- A baseline setup you can expand later with more slots, GPIO control, or custom automation
Start with just three hardware add-ons. Integrate them with fernsteuerung.io. You get a remote lab that is reliable enough for engineers and ready for automation-driven embedded software development. Here is what that looks like on day one. Let's walk through a first example.
A concrete first use case
You just built a Yocto image. What now? The usual next step is digging through a box of eval kits, cables, and serial adapters, hoping you pick the right header for the right board spin. Most embedded engineers juggle multiple revisions and vendor variants, each with slightly different layouts and boot quirks. Instead, open the fernsteuerung.io dashboard. Pick your slot — that is the board you assigned — flash the image to the SD card, power the board, and watch the serial console boot. No hardware setup knowledge required beyond knowing which slot you assigned.
What you can exercise with this minimal setup
Even without external peripherals, you can cover a wide set of internal SoC features, on-board hardware, and system behaviors — all from the browser or your pipeline.
On-board features you can check remotely
These cover critical SoC and board subsystems without extra gear:
- CPU bring-up, core initialization, and frequency scaling
- Thermal management, throttling, and temperature telemetry
- Hardware watchdogs along with power and reset domains
- Secure boot stages, TrustZone flows, and bootloader logic (U-Boot, TF-A)
- Interrupt controllers and low-level timers such as GPT or HPET
- Clock tree, PLL, and clock-gating behavior
- PMIC communication, regulator drivers, and other built-in sensor probes
- RTC bring-up and persistence
- On-board flash devices like eMMC or NAND/NOR plus firmware loading
- Early GPU or display driver logs and audio codec initialization
- Networking, USB, and PCIe controller bring-up even without cabling
You may not verify full peripheral behavior without physical hardware, but you can confirm driver initialization, firmware loading, and the low-level hardware path.
System-level behavior you can exercise
- Debug and Test OS images
- Measure boot times
- Trigger kernel crashes and fault injection for resilience checks
- Test kernel modules
- Run filesystem integrity checks
- Validate systemd services
- Experiment with any user space Application
- Audit security configuration
- Trial device-tree changes for regressions
All of this happens remotely through fernsteuerung.io, using the same three-device setup you started with.