Infrabase's build infrastructure — based on BitBake and OpenEmbedded, but optimized for simplicity and flexibility — continues to evolve, with numerous improvements since our initial release. Today’s guide walks through source-level debugging of an LVGL application, all inside a QEMU/virt64 environment. No hardware needed — just a modern Linux host and developer tools Today we’ll dive into the execution of an LVGL application and explore the LVGL library internals — all inside a QEMU/virt64 emulated environment. Yep: no hardware required. 🙂 What you’ll do • Build the default Infrabase environment and QEMU. • Enable debug symbols for your LVGL app and the LVGL library. • Launch the emulated GUI and attach VS Code + gdb-multiarch. • Inspect the call stack and step through the LVGL main loop. 1) Build the base system From a fresh clone, bootstrap and build the default configuration: $ source env.sh $ build.sh -a The first build takes ~45 minutes (it compiles a Buildroot-based root filesystem). Since we’re using an emulated target, build QEMU as well: $ build.sh -q Start the graphical environment: $ ./stg.sh You should see the LVGL demo windows pop up in a desktop-like session. Tip: stg.sh launches QEMU with a GDB server so your debugger can attach on localhost:1234. The lvglsim application running in the QEMU/virt64 environment 2) Turn on debug symbols for the app and LVGL We want source-level debugging with function names and line info. Edit linux/usr/src/lvgl/lv_port_linux/CMakeLists.txt and set a debug build. If there’s a line that sets CMAKE_BUILD_TYPE to Debug, uncomment it (or add this if needed): set(CMAKE_BUILD_TYPE Debug) Uncomment the line to enable Debug (line 13) Then clean the user build and rebuild with debug info: $ cd linux/usr $ rm -rf build/ $ ./build.sh # or from repo root: $ build.sh -u This ensures your binaries are compiled with -g. Heads-up: Make sure any stripping step is disabled for your debug build (don’t strip symbols). 3) VS Code debug configuration Install the C/C++ extension (Microsoft) and ensure gdb-multiarch is available on your host (e.g., sudo apt install gdb-multiarch on Debian/Ubuntu). Create or update .vscode/launch.json with: { "version": "0.2.0", "configurations": [ { "name": "(gdb) USR lvglsim", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/linux/usr/build/bin/lvglsim", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "/usr/bin/gdb-multiarch", "miDebuggerServerAddress": "localhost:1234", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true }, { "text": "set remote Z-packet on" }, { "text": "set output-radix 16" } ] } ] } Why this works: When stg.sh starts QEMU, it exposes a GDB server on localhost:1234. VS Code’s cppdbg connects to it using gdb-multiarch, while program points to your local ELF with symbols so the debugger can resolve sources. 4) Attach, pause, and inspect the stack • Launch the “(gdb) USR lvglsim” configuration in VS Code. • It will auto-connect to QEMU (localhost:1234). • Hit Pause to freeze the target and open the Call Stack. You should land somewhere inside the LVGL driver/timer machinery. Inspect the source code and stack trace of a running LVGL application  Typical path: main() → run_loop_fbdev() → lv_timer_handler() → lv_timer_exec() // internal timer execution → … draw/invalidations … LVGL runs a timer-driven event loop that triggers area invalidation and re-drawing. Stepping through this loop is incredibly useful for understanding rendering flow, timing, and where your app’s events slot in. 5) Handy breakpoints to try • main() — entry point of your app. • run_loop_fbdev() — where the frame-buffer loop hooks into LVGL. • lv_timer_handler() — heart of LVGL’s scheduling. • lv_refr_area() / lv_disp_refr_* — screen refresh paths. • Your widget callbacks (e.g., event handlers) — to trace UI interaction flow. Pro-tip: If you see an enormous stack, use stack filtering in VS Code and add function breakpoints for specific LVGL symbols to jump right where it matters. 6) Troubleshooting • Can’t connect to localhost:1234?Make sure stg.sh/QEMU is running. If your setup uses a different port, update miDebuggerServerAddress. • No source lines / function names?Confirm CMAKE_BUILD_TYPE=Debug is active and that you rebuilt after cleaning linux/usr/build/. Check your final binary with file linux/usr/build/bin/lvglsim (should mention “with debug_info”). • Wrong architecture warnings in gdb?Use gdb-multiarch (not the host’s default gdb). The target is aarch64/virt64. What you learn • How LVGL’s timer engine orchestrates redraws. • Where your app code participates in the event → draw pipeline. • How to pause anywhere, read a precise call stack, and step through rendering. That’s it — enjoy LVGL debugging with Infrabase! If you haven’t read the intro to our BitBake/OpenEmbedded setup yet, start here.Questions or tips from your own sessions are very welcome in the thread!

Infrabase is a lightweight build and deployment environment tailored for embedded systems development. Although it leverages BitBake as its core build engine, it differs significantly from Yocto in design and philosophy — prioritizing simplicity, efficiency, and flexibility over complexity. Unlike traditional Linux distributions, Infrabase does not come pre-packaged with system layers or components. Instead, it provides the foundational tools necessary to build a variety of distributions — including Buildroot, debootstrap, and even Yocto/Poky — depending on the requirements of your project. In this article, we'll demonstrate how to use Infrabase to build and deploy a basic LVGL (Light and Versatile Graphics Library) application running on a Linux system emulated using QEMU in virt64 mode. Our chosen distribution for this setup is Buildroot. ⚠️ Note: The default Buildroot configuration for the QEMU/virt64 machine includes a significant number of components (such as graphics libraries, DRM, kmscube, mesa3d-demos, etc.). These are not strictly necessary for running a framebuffer-based LVGL application. Additionally, this setup uses systemd as the system and service manager. Prerequisites Before proceeding, ensure that: • You have experience with embedded Linux development. • A compatible ARM AArch64 toolchain is installed on your system. Step 1: Clone the Infrabase Repository Start by cloning the Infrabase repository from GitHub: git clone https://github.com/EDGEMTech/infrabase Step 2: Build the Environment Navigate to the repository root and initiate the build with: ./build.sh -a Since we use QEMU/virt64, we need to build it with: ./build.sh -q This command launches a full build process, compiling: • The U-Boot bootloader • The Linux kernel • A Buildroot-based root filesystem • All defined user-space applications 🕒 Depending on your system, the build may take up to an hour, as the current Buildroot setup includes numerous components. Step 3: Deploy the System After the build completes, deploy the environment using: ./deploy.sh -a The script performs the following: • Creates a virtual SD card image under the filesystem/ directory. • Partitions and populates the image: • Partition 1: U-Boot bootloader • Partition 2: ITB (Image Tree Blob) file containing the kernel, device tree (DT), and a minimal initrd • Partition 3 (rootfs): Full Buildroot root filesystem • /root directory: All user-space applications 💡 Note: Although the bootloader is written to the SD card (as required for real hardware), QEMU uses the bootloader directly via its command-line arguments during emulation. Step 4: Launch the Emulated System To start the emulated environment with graphical support, run: ./stg You should now see two separate windows: Starting the emulated environment (automatic login without password is configured) 1. A serial console window (acting as a virtual UART) 2. A framebuffer window (displaying the graphical output) Step 5: Run the LVGL Application In the serial console window, launch the LVGL demo with: ./lvglsim This will start the simple LVGL application, displaying the familiar LVGL demo interface in the framebuffer window. Starting lvglsim application initiates the framebuffer and displays the LVGL widgets You move your mouse cursor to the GUI and should be able to navigate within the application and interacts with it. Infrabase: A Growing Project Infrabase is still in its early stages of development. While it already provides a functional and streamlined environment for embedded Linux system builds, there is still much room for improvement and optimization. So, don't be too rude and thank you for your understanding and patience. We are actively working to expand its capabilities, improve usability, and support more platforms and configurations. Your feedback, ideas, and contributions are not only welcome — they’re essential to the project’s growth. Whether you’re interested in improving build scripts, enhancing documentation, adding support for new distributions, or fixing bugs, we’d be happy to have you on board. Infrabase is a constantly evolving toolset, and the community around it is key to its success. What’s Next In the next article, we will explore how to debug the LVGL application running in QEMU using Visual Studio Code with a GDB GUI frontend — enabling a more interactive and developer-friendly debugging experience.

In industrial automation, robotics, and CNC systems, achieving hard real-time determinism is crucial for safety, precision, and performance. Many systems rely on costly proprietary solutions to meet those demands—but OpenCN offers an open, modular alternative specifically built for embedded motion control with microsecond-level timing precision. Released under the GPLv2 license, OpenCN promotes transparency, adaptability, and long-term sustainability—making it an excellent foundation for building reliable, real-time automation systems without vendor lock-in. OpenCN is ideal for developers and integrators looking for affordable, real-time, and production-grade control systems that don't compromise on timing guarantees or long-term maintainability. OpenCN originates from the well-known LinuxCNC project, whose architecture has powered machine tools and motion platforms for decades. However, traditional LinuxCNC relies on either soft real-time or hybrid userspace/hard real-time setups, often with considerable complexity or overhead. 🧠 Real-Time Core: Xenomai/Cobalt, Streamlined and Evolved At the foundation of OpenCN lies a customized hard real-time core based on Xenomai/Cobalt. Unlike traditional implementations, OpenCN’s version removes the I-Pipe layer—a legacy abstraction once required to enable real-time co-kernels within Linux. This results in a lighter, cleaner, and more maintainable integration with the Linux kernel. This architecture not only reduces latency and jitter but aligns with the forward-looking design principles of Xenomai 4 / EVL—while retaining the mature and proven scheduling and interrupt management features of Cobalt. Benefits include: • Hard real-time determinism • Reduced system overhead • Compatibility with recent Linux kernels • Customizability for embedded deployments The overall picture below shows the general OpenCN environment. OpenCN General Architecture ⚙️ Multicore Isolation for Determinism OpenCN fully leverages asymmetric multicore processing, a key strategy for ensuring hard real-time behavior in modern multi-core systems. This allows: • Time-critical control loops to run on dedicated CPU cores • Background tasks such as networking, data logging, or user interfaces to be confined to separate cores • A predictable and interference-free real-time environment This isolation model is essential for systems where control loops must execute with fixed cycle times, regardless of system load. 💻 Runs on x86 and Raspberry Pi 4/5 OpenCN runs natively on both: • x86 industrial PCs for performance-intensive applications • ARM-based platforms, including Raspberry Pi 4 and 5, for compact and low-cost deployments This range of support makes it well-suited for: • Prototyping motion systems • Retrofitting legacy equipment • Deploying cost-sensitive automation solutions • Educational and academic use cases Despite its efficiency, OpenCN delivers the hard real-time behavior expected in high-end industrial controllers. 🔌 EtherCAT for Real-Time Industrial Communication OpenCN includes native support for EtherCAT drivers, allowing deterministic, synchronized communication with: • Servo and stepper motor drives • I/O expansion modules • Distributed sensors and actuators • EtherCAT is the primary fieldbus supported, ensuring seamless integration into modern industrial automation ecosystems. This makes OpenCN particularly well-suited for motion control platforms, where high-speed field communication is critical. 📡 User Interface and System Monitoring OpenCN includes a remote user interface, which can run on a separate PC or tablet. This interface allows users to: • Configure the system • Monitor machine operations in real time • Visualize and log control signals • Optimize control parameters based on process feedback Such capabilities are essential for maintaining high precision and quality in automated machining and robotic workflows. 🛠 EDGEMTech: Your Partner for Real-Time Embedded Control At EDGEMTech, we have deep experience with OpenCN—many of our engineers were directly involved in its development and deployment. We offer: • Long-term support and maintenance • Custom adaptations to specific hardware platforms or motor drive integrations • Kernel and driver-level customization to meet hard real-time requirements • Consulting on deploying OpenCN in production systems or as part of Industry 4.0 strategies Whether you’re building a CNC machine, an advanced robot, or a precision automation line, EDGEMTech can provide the expertise and support to make OpenCN a stable, tailored, and sustainable solution. 🔧 Summary OpenCN proves that hard real-time control, open-source freedom, and embedded efficiency can go hand in hand.With native EtherCAT support, deterministic execution, and lightweight architecture, it offers a powerful foundation for next-generation control systems. 🔗 Learn more about OpenCN We invite you to share your experiences, ask technical questions, or explore OpenCN's capabilities with us here in the Realtime Systems section. Let’s build deterministic systems—together.

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 environment with VSCode/GDB 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!

Yocto is a powerful distro and build system environment. It enables developers to build a complete distribution from scratch, allowing full customization of the root filesystem's content. Widely used in embedded systems development, Yocto provides a structured framework for package management and system customization. By defining recipes, the build system automatically downloads the required packages based on configuration settings and generates an image that can be easily deployed to the target device. Yocto’s Evolution Since its launch in 2010, Yocto has undergone significant development. The environment is built on BitBake, which was created in 2003 and serves as the build system's core engine. Primarily developed in Python, BitBake was initially part of the OpenEmbedded project, where a vast collection of recipes and functions were developed. Yocto, which builds upon OpenEmbedded, has introduced additional tools, scripts, and package-building functionalities to accommodate a broad range of Linux-based embedded systems. Finally, an additional layer of recipes and functions is provided through Poky, which constitutes a "true" distribution (often referred to simply as "Yocto"). The Yocto Learning Curve Mastering the Yocto ecosystem requires a considerable effort. The sheer number of predefined variables can be overwhelming, discouraging some developers. However, Yocto remains an essential tool for production environments with a large number of deployed devices. It provides effective version control for both software and hardware components, making it a go-to solution for long-term embedded projects. Buildroot: A Simpler Alternative In contrast, Buildroot (2001) offers a much simpler alternative, following a monolithic approach primarily based on Makefiles. While it achieves similar goals to Yocto, it is more limited in flexibility but easier to use and leads to significantly shorter build times, typically around 45 minutes, compared to 2+ hours for Yocto (depending on hardware capabilities). A New Approach: InfraBase (IB) At EDGEMTech, we sought to combine the power of BitBake and its highly modular recipe-based approach with the ability to integrate prebuilt packages within the BitBake ecosystem. This vision stems from years of experience in R&D projects and the embedded Linux environment, where the typical stack consists of: • A bootloader like U-Boot • The Linux kernel • The root filesystem • A set of user-space applications As shown in the diagram below, additional components, such as a hypervisor and one or more guest operating systems, can also be part of the system architecture. Typical embedded software architecture QEMU is widely used for target emulation, providing a powerful debugging environment. Given the complexity of different targets, it is crucial to support multiple configurations. We call this new approach InfraBase (IB). The diagram below illustrates the distinction between Yocto and IB. IB embraces all core concepts of Yocto while extending its capabilities. It allows the build system to interface not only with Buildroot but also with debootstrap or any other build system. Structurally, IB consists of a build/ directory, which contains all meta-layers, configurations, and classes, while maintaining a standard filesystem hierarchy with bootloader, kernel, root filesystem, applications, QEMU, and more. It efficiently manages files using symbolic links or direct copies from BitBake-generated elements. InfraBase: Open Source Release Coming Soon! We'd love to hear about your needs and your opinion of Yocto. We look forward to hearing from you! We will soon release InfraBase as an open-source project in collaboration with HEIG-VD. Stay tuned! 🚀

The Yocto Project is an open-source collaboration that provides templates, tools, and methods to create custom Linux-based systems. Yocto offers unparalleled flexibility and control. 🔧 Why Yocto? ✔ Customizability: Tailor your Linux distribution to meet specific project needs. ✔ Scalability: Easily adapt to different hardware platforms. ✔ Community Support: Leverage a vibrant community for continuous improvement and innovation. Incorporating Yocto into the workflow enables the dev team to streamline development, reduce time-to-market, and maintain robust, secure systems.

Have you ever thought that x86 would gradually leave the world of embedded systems? The Sapphire Edge+ VPR-4616-MB is a Mini-ITX motherboard that includes the AMD Versal AI Edge VE2302 device plus an AMD Ryzen Embedded R2314 processor, along with a flexible I/O interface to connect to various peripherals and sensors. Our Engineers are on hand to give you the necessary expertises in hard realtime systems based on Linux for your new development, if you envisage to start a new product or to port an existing realtime systems.