Hi all, The ASPEED AST2700fc SoC integrates the Caliptra Root of Trust (Caliptra 1.2 core). Moving forward, we expect more SoCs to adopt Caliptra cores (e.g., Caliptra 2.x). Currently, QEMU does not have a native Caliptra emulator.
This RFC explores possible approaches for supporting Caliptra in QEMU. The included patch provides a Proof of Concept (PoC) integration using the external `caliptra-sw` C-binding emulator to enable booting the AST2700fc machine. This RFC does not propose merging the current PoC design as-is. Instead, it is intended to gather early feedback on architecture and integration strategy. In this PoC, the `caliptra-sw` emulator is used as a reference model to enable early bring-up and validation of the AST2700fc secure boot flow, rather than as a final implementation choice. The integration is based on the `caliptra-1.2` branch of the official repository: https://github.com/chipsalliance/caliptra-sw/tree/caliptra-1.2 To avoid making normal ASPEED/AArch64 builds depend on a local external checkout, the c-binding backend is compiled only when this PoC detects the generated `caliptra-sw` c-binding header and static library in an expected sibling source tree. A mergeable version would need an explicit configure option and a proper dependency integration. Since QEMU currently lacks a `bootmcu` model and the associated mailbox interactions with Caliptra, the PoC simplifies the boot flow by using a background thread and the `caliptra_model_boot_default` C-binding to simulate early boot stages. To approximate the hardware behavior where the Cortex-A35 CPUs remain in reset until secure boot is completed, the PoC uses `vm_stop_force_state()` as a temporary approximation. This approach is intentionally simplified and not intended to reflect the final QEMU design. In particular, the use of a background thread and global VM control APIs may not align with QEMU device model expectations. Support for the `bootmcu` model and a more accurate secure boot flow is planned for future work. Discussion points: 1. Emulator strategy: For early enablement, is it acceptable to rely on an external reference model such as `caliptra-sw`, or would the community prefer focusing directly on a native QEMU QOM device model? 2. Build system integration: If using the external `caliptra-sw` library is acceptable, what is the preferred integration method (e.g., git submodule, meson subproject, or system-installed library via pkg-config)? 3. Boot synchronization: In real hardware, CPUs are held in reset until the secure boot flow completes. What is the recommended way in QEMU to model such dependencies between devices and CPU startup? Feedback and suggestions are highly appreciated. Thanks, Steven Steven Lee (1): hw/arm: aspeed: Add PoC integration for Caliptra Root of Trust MAINTAINERS | 2 + docs/system/arm/aspeed.rst | 20 +++ include/hw/arm/aspeed_caliptra_emu.h | 17 ++ hw/arm/aspeed_ast27x0-fc.c | 60 +++++++ hw/arm/aspeed_caliptra_emu.c | 259 +++++++++++++++++++++++++++ hw/arm/meson.build | 31 +++- 6 files changed, 388 insertions(+), 1 deletion(-) create mode 100644 include/hw/arm/aspeed_caliptra_emu.h create mode 100644 hw/arm/aspeed_caliptra_emu.c -- 2.43.0
