Hi,

This series is an RFC for modelling the Caliptra Root of Trust found
in the ASPEED ast27x0 family.

ast27x0 integrates a Caliptra 1.2 core as an on-die RoT block.
From the host side, the visible interface is a Caliptra APB register
window rather than a standardized external command protocol. QEMU does
not currently have a Caliptra emulator, and there is not yet an agreed
upstream model for how ASPEED Caliptra support should be structured.

On the real ast27x0, Caliptra bring-up and secure-boot
orchestration are handled by bootmcu rather than by the CA35 host CPUs.
In particular, bootmcu is expected to own the mailbox-driven
interaction with the Caliptra core during firmware loading and
verification. At a high level:

- bootmcu releases the Caliptra core from reset
- bootmcu loads the Caliptra FMC/runtime firmware through the mailbox path
- Caliptra verifies the images and boots to runtime-ready
- bootmcu then relies on Caliptra services as part of the platform
  secure-boot flow before CA35 firmware starts

QEMU does not currently model bootmcu or that orchestration flow.
Accordingly, this RFC does not attempt to model the final ast27x0
boot architecture. Instead, it uses the CA35-visible Caliptra MMIO/APB
window as an initial integration point to validate the
transport/backend split. A subsequent revision would wire this into
the proper bootmcu-owned boot path.

Changes since RFC v1:
- reworked the PoC to remove the direct `caliptra-sw` C-binding
  dependency from the QEMU build.
- dropped the sibling-tree auto-detection of external headers and
  libraries.
- replaced the in-process Caliptra model with an external
  `caliptra-server` backend reached over a Unix socket.
- replaced the v1 worker-thread-based boot sequencing with a model
  where the backend is started independently and is already
  runtime-ready when QEMU connects.
- removed the use of `vm_stop_force_state()` to hold the CA35 until
  Caliptra boot completion.
- narrowed the QEMU-side PoC to the CA35-visible Caliptra MMIO/APB
  window on ast2700fc machine.

The patch in this RFC:
- adds an ASPEED-specific sysbus device for Caliptra emulation.
- exposes a 128 KiB MMIO window at 0x14c60000 on ast2700fc machine.
- forwards guest MMIO accesses to an external backend as APB
  read/write transactions over a Unix socket.
- assumes the backend is already running and ready before QEMU starts.

Current limitations of the PoC:
- no boot handshake between QEMU and the backend.
- synchronous socket round-trips on guest register access.
- no reset/migration/lifecycle integration.
- minimal wire protocol, designed to be replaced with a standardized
  IPC scheme.
- no modeling of bootmcu or the full secure-boot orchestration flow.

Testing:

  # Terminal 1: start the external backend and wait for runtime-ready.
  caliptra-server \
      --socket /tmp/caliptra.sock \
      --rom images/caliptra-rom.bin \
      --firmware images/caliptra-fw.bundle

  # The server boots caliptra-sw independently, then prints that it is
  # listening on the socket after boot_status reaches runtime-ready.

  # Terminal 2: launch QEMU after the socket is ready.
  qemu-system-aarch64 \
      -M ast2700fc,caliptra-socket=/tmp/caliptra.sock \
      ...

  # In the guest, exercise the Caliptra MMIO window and confirm the
  # APB transactions are forwarded to caliptra-server.
  #
  # The sequence below drives the mailbox CSR block at 0x30020000
  # through the AST2700fc window:
  #   0x00  LOCK     - confirm the mailbox CSR block is reachable
  #   0x08  CMD      - program the mailbox command opcode
  #   0x0c  DLEN     - declare the payload length
  #   0x10  DATAIN   - provide the checksum word required by CAPS
  #   0x18  EXECUTE  - doorbell to start command processing
  #   0x1c  STATUS   - read back the command result

md 0x14c60000 1        # Read LOCK to confirm the Caliptra mailbox CSR window is accessible.
mw 0x14c60008 0x43415053  # Write CMD = OP_CAPABILITIES ("CAPS").
mw 0x14c6000c 4        # Write DLEN = 4 bytes; CAPABILITIES carries only the checksum word.
mw 0x14c60010 0xFFFFFED9  # Write the checksum word expected by caliptra-sw for this CAPS request.
mw 0x14c60018 1        # Write EXECUTE = 1 to kick off mailbox command processing.
md 0x14c6001c 1        # Read STATUS to verify the command completed successfully.

The backend used for evaluation is currently based on the
`caliptra-1.2` branch of:
  https://github.com/chipsalliance/caliptra-sw

The reference `caliptra-server` implementation used in this RFC is
available at:
  https://github.com/stevenlee7189/caliptra-server

The intent here is not to propose this PoC as merge-ready. The goal is
to get feedback on whether this general direction makes sense for
ASPEED.

In particular, feedback is welcome on the following:

- Is a socket-connected external backend an acceptable direction for
  supporting a Caliptra core on ASPEED platforms, or should we pursue
  an alternative approach such as an in-process model or a different
  IPC mechanism?

Other comments on the design are also welcome.

Thanks,
Steven Lee

Steven Lee (1):
  hw/arm: aspeed: PoC integration for Caliptra Root of Trust

 MAINTAINERS                          |   2 +
 docs/system/arm/aspeed.rst           |  35 +++
 include/hw/arm/aspeed_caliptra_emu.h |  29 +++
 hw/arm/aspeed_ast27x0-fc.c           |  55 +++++
 hw/arm/aspeed_caliptra_emu.c         | 338 +++++++++++++++++++++++++++
 hw/arm/meson.build                   |   1 +
 6 files changed, 460 insertions(+)
 create mode 100644 include/hw/arm/aspeed_caliptra_emu.h
 create mode 100644 hw/arm/aspeed_caliptra_emu.c

-- 
2.43.0