Debugging LVGL with QEMU/aarch64
Debugging embedded applications — especially graphical ones — without hardware can be challenging.
Fortunately, emulated environments like QEMU offer an ideal solution for running and debugging cross-compiled ARM64 applications. Using QEMU with IDEs such as Eclipse or VSCode provides a powerful and flexible setup for developers.
Personally, after many years of experience with Eclipse + GDB, I still consider it among the best free solutions for graphical debugging. That said, VSCode has made significant strides recently, offering a smooth and efficient debugging experience.
Why QEMU for LVGL Development?
In this new series of articles, we will explore the fascinating world of QEMU emulation, with a focus on debugging LVGL applications — a library we actively deploy across various hardware platforms.
In this first post, we will cover the basics of how to set up a GDB debugging environment with QEMU (AArch64).
QEMU + VSCode/GDB Debugging Setup
Here’s how the key components fit together:
QEMU emulates various embedded peripherals such as UART, framebuffer, SPI, and more.
QEMU's built-in GDB server enables interaction with the emulated CPU without requiring hardware debuggers or JTAG. Simply use the -s option when launching QEMU to enable this feature (detailed command-line instructions will be provided in the next article).
VSCode, with the appropriate extensions, acts as the GDB client. It connects to QEMU via a standard TCP/IP connection (typically localhost:1234, the default port for QEMU’s GDB server).
Additionally:
QEMU can launch a window that emulates the embedded framebuffer, allowing you to view the graphical output as if it were displayed on a real device.
The UART interface can be redirected to your terminal window (where QEMU runs), letting you see logs (e.g., from U-Boot) and interact with the emulated target. Yes, this means you can even debug U-Boot — more on that in future posts.
Complete Software Emulation
In this setup, the LVGL application runs entirely within the emulated environment, whether under Linux, bare-metal, or another RTOS. The full software stack resides on emulated storage, such as a virtual SD card, attached to QEMU through its MMC/MMIO controller.
What’s Next?
With the context and setup now sketched out, our next article will dive deeper into the technical details — including QEMU command-line options and practical debugging scenarios. Stay tuned!