Reducing Friction in Testing Using QEMU and Labgrid for Yocto-based Products
summary
Prototype test infrastructure combines Yocto-built images with QEMU ARM64 instances controlled by Labgrid, using ephemeral snapshots so each test starts clean. Update-system tests run on a Raspberry Pi 4 and QEMU VM; parallelizing five tests across eight workers yields about 4–5× faster feedback and only ~14% differing packages between VM and hardware. Machine configs and piest fixtures automate target selection; the proof‑of‑concept works but secure‑boot and some peripherals need extra engineering.
AI-written summary · about
chapters (18)
- 0:00Emulation and testing challenges
- 2:12Slow test cycles in embedded
- 4:45Test scenarios for emulation
- 10:32Yocto workflows with emulation
- 13:43Testing environment setup
- 15:33QEMU system definition walkthrough
- 18:24QEMU machine definitions
- 21:39Labgrid test environments
- 23:27Test cases for emulated targets
- 24:52Hardware vs emulation performance
- 27:23Speed gains and test selection
- 28:50Economic feasibility and effort
- 29:54When emulation is worth it
- 30:35Q&A on power cuts and emulation
- 36:03Time to set up emulation
- 37:18Boot time comparison
- 38:43Network in QEMU
- 40:13Secure boot emulation status
related talks
29mTesting, a Journey from Testing Kernels to Testing Debian and Yocto- 29mTesting, a Journey from Testing Kernels to Testing Debian and Yocto
40mAutomated Full System Testing on Hardware with OpenQA
39mTesting Your Yocto Proj: from Ptest & Testimage to LAVA
22mKnow your QEMU and KVM Test Frameworks
48mPrimer: Testing Your Embedded System - What is a ptest, Lava, Fuego and...?
29mQEMU & KVM Automated Performance Benchmarking @ SUSE
33mAutomated Testing for Embedded Development: Next Generation Board Farming