Hi Alistair, > -----Original Message----- > From: Alistair Francis <[email protected]> > Sent: Wednesday, April 29, 2026 12:10 PM > To: Steven Lee <[email protected]> > Cc: Cédric Le Goater <[email protected]>; Peter Maydell > <[email protected]>; Troy Lee <[email protected]>; Jamin Lin > <[email protected]>; Kane Chen <[email protected]>; > Andrew Jeffery <[email protected]>; Joel Stanley > <[email protected]>; Pierrick Bouvier <[email protected]>; open > list:All patches CC here <[email protected]>; open list:ASPEED BMCs > <[email protected]>; Troy Lee <[email protected]>; > [email protected]; Yunlin Tang <[email protected]> > Subject: Re: [RFC PATCH v1 1/1] hw/arm: aspeed: Add PoC integration for > Caliptra Root of Trust > > On Mon, Apr 27, 2026 at 6:48 PM Steven Lee via qemu development > <[email protected]> wrote: > > > > 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. > > > > The official `caliptra-sw` project provides a fully functional > > emulator with C-bindings. As a Proof of Concept, this RFC integrates > > the external `caliptra-sw` C-binding model into QEMU to enable booting > > the AST2700fc machine. > > > > This RFC does not propose merging the current PoC design as-is. > > Instead, it is intended to explore possible approaches for adding > > Caliptra support in QEMU and to gather early feedback from the > > community on architecture and integration strategy. > > What about a socket approach instead? That's what QEMU currently uses for > TPM and SPDM support. It means there are no build time dependencies, > you can just launch the Caliptra "server" and have QEMU connect to it. > > Then the "server" will be a simple translation layer between requests on the > socket and the C-bindings you talk about above. >
Thank you for the suggestion; this is a very clean approach. In my initial PoC, I focused on the C-binding interface provided by the Caliptra project and built the integration around it, so I didn’t really consider moving the model out-of-process. Based on your feedback, I’ll try a different direction: implementing a Caliptra server prototype that uses the Caliptra hw-model crate directly to instantiate the emulator, and communicates with QEMU over a socket interface. This should avoid the C-binding dependency and better align with existing QEMU patterns. Thanks again for your guidance. Best regards, Steven > > > > 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 the PoC > > detects the generated `caliptra-sw` c-binding header and static > > library in the expected sibling source tree. A mergeable version > > would need an explicit configure option and a proper dependency > integration. > > This sounds tricky to get distros to pick up this dependency. > > > > > For context, the actual hardware boot flow on the AST2700fc relies on > > a dedicated RISC-V core (bootmcu) to orchestrate the secure boot: > > > > 1. bootmcu executes its ROM code. > > 2. bootmcu releases the Caliptra core from reset. > > 3. Caliptra requests its FMC and Runtime (RT) firmware. > > 4. bootmcu loads the Caliptra FMC/RT images into Caliptra's mailbox. > > 5. Caliptra ROM verifies the signature of the Caliptra FMC/RT images. > > 6. Caliptra boots into its FMC and RT environments. > > 7. bootmcu requests Caliptra RT to verify the bootmcu's own FMC. > > 8. bootmcu executes its FMC. > > 9. bootmcu requests Caliptra to verify the BMC (Cortex-A35) firmware. > > In the server model this would all happen outside QEMU, QEMU would just > wait for reset to be released > > Alistair >
