SoCks - Simplifying Firmware and Software Integration for Heterogeneous SoCs

TL;DR

SoCks introduces a block-based build framework for heterogeneous SoCs that partitions a bootable image into manageable, interchangeable blocks with standardized interfaces. Implemented in Python using a facade and per-block builders, it enables containerized builds, incremental processing, and CI/CD workflows, dramatically reducing build times and host-resource requirements compared to Yocto or Buildroot. The framework supports flexible root-filesystem choices (including conventional distributions like Debian/AlmaLinux) and uses a single, centralized YAML project configuration with architecture-specific defaults, promoting reuse and distributed collaboration. Performance evaluations show substantial speedups and reduced disk usage, underscoring SoCks’ practicality for lab-scale teams and research environments. The work points toward expanding block coverage for AMD’s Zynq us+ and Versal ecosystems, including RT cores and AI accelerators, while maintaining open-source accessibility.

Abstract

Modern heterogeneous System-on-Chip (SoC) devices integrate advanced components into a single package, offering powerful capabilities while also introducing significant complexity. To manage these sophisticated devices, firmware and software developers need powerful development tools. However, as these tools become increasingly complex, they often lack adequate support, resulting in a steep learning curve and challenging troubleshooting. To address this, this work introduces System-on-Chip blocks (SoCks), a flexible and expandable build framework that reduces complexity by partitioning the SoC image into high-level units called blocks. SoCks builds each firmware and software block in an encapsulated way, independently from other components of the image, thereby reducing dependencies to a minimum. While some information exchange between the blocks is unavoidable to ensure seamless runtime integration, this interaction is standardized via interfaces. A small number of dependencies and well-defined interfaces simplify the reuse of existing block implementations and facilitate seamless substitution between versions-for instance, when choosing root file systems for the embedded Linux operating system. Additionally, this approach facilitates the establishment of a decentralized and partially automated development flow through Continuous Integration and Continuous Delivery (CI/CD). Measurement results demonstrate that SoCks can build a complete SoC image up to three times faster than established tools.

Figures (13)

• Figure 1: Dependency graph of a Yocto project targeting an AMD Zynq us+ mpsoc fuchs_2025_17131066. Each blue rectangle in the graph represents one BitBake recipe. The edges between the recipes represent the dependencies.
• Figure 2: Data flow graph of a socks project targeting an AMD Zynq us+ mpsoc. This example shows the partitioning of a complete image at the abstraction level of socks. "RAM File System" and "Root File System" are optional blocks and therefore dark blue. An soc image utilizing an embedded Linux os can have either one of the two file systems or both. The latter approach corresponds to a Linux os with an initramfs.
• Figure 3: Blocks of an AMD Zynq us+ mpsoc image with associated builders. Tiles with an AMD icon in the top left corner indicate that the builder is optimized for source code that has been adapted by the manufacturer for the target architecture.
• Figure 4: Architecture of the socks Python application. The selection of builders shown is symbolic and not complete.
• Figure 5: Access of a builder to programs on the host system and in the associated container. An external program is always accessed via a defined command interpreter (sh or bash), which ensures a uniform interface.