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