emulator: Add event bus between Caliptra, MCU, BMC, etc. #1938
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
swenson
requested review from
korran,
fdamato,
jlmahowa-amd,
mhatrevi,
jhand2,
vsonims,
rusty1968,
bluegate010,
ajisaxena and
JohnTraverAmd
as code owners
swenson
added a commit
to chipsalliance/caliptra-mcu-sw
that referenced
this pull request
Feb 3, 2025
We start implementing a simulated recovery flow engine in a fake BMC, and having it work with Caliptra Core and MCU bootup. This depends on an event bus being hooked up between Caliptra Core, the MCU, and our fake BMC, which is processed on each end to translate events. For example, recovery block reads and writes from the BMC are translated to recovery registers available through AXI in Caliptra Core. This flow is a bit complex, and is not 100% finished yet. Currently it is working well enough that: * Emulators start and enable active mode * MCU ROM boots and sets up Caliptra Core's fuse registers * MCU ROM starts the recovery flow * Calipta Core ROM boots and requests the first recovery image (Caliptra's own firmware) * Caliptra Core downloads the firmware successfully The next step will be to get through validation and handle the SoC manifest and MCU firmware in Caliptra's runtime code. But, I wanted to do a check in so that these PRs don't become too overwhelming. Assuming you have `caliptra-sw` in `../caliptra-sw`, have built the ROM (`cd rom/dev && make build-rom`) and the signed Caliptra firmware (`cd rom/dev && make build-fw-image`), and have a file (doesn't yet matter the contents) `soc-manifest.bin`, you can test this whole flow with: ```shell-session $ cargo xtask runtime --caliptra-rom ../caliptra-sw/target/riscv32imc-unknown-none-elf/firmware/caliptra-rom.bin --caliptra-firmware ../caliptra-sw/target/riscv32imc-unknown-none-elf/firmware/caliptra-rom-test-fw --soc-manifest soc-manifest.bin --active-mode ... [ldev] Signing Cert with MLDSA AUTHORITY.KEYID = 8 [ldev] -- [fwproc] Wait for Commands... [fwproc] Recv command 0x52494644 [emulator bmc recovery] Recovery state transition: ReadDeviceStatus -> WaitForRecoveryStatus [emulator bmc recovery] Sending recovery image 0 [emulator bmc recovery] Recovery state transition: WaitForRecoveryStatus -> WaitForRecoveryPending [fwproc] Waiting for payload available signal... [fwproc] Recovery payload of 131072 bytes available [fwproc] Received Image from Recovery Interface of size 131072 bytes ROM Fatal Error: 0x000B0003 ``` (The fatal error is signature validation failure, which is to be expected.) Depends on chipsalliance/caliptra-sw#1938
swenson
force-pushed
the
communicate-with-mcu-bmc
branch
from
e7927e4 to
9aacda2
Compare
swenson
force-pushed
the
communicate-with-mcu-bmc
branch
from
0e91c77 to
479be86
Compare
And hook it up to the emulated AXI bus for DMA transfers. The events are used to simulate some of the ways that Caliptra communicates with others in hardware, in particular, I3C, writing to MCU's memory aperture, and the recovery communications. We wire these up in the emulated AXI DMA controller and recovery interface. This PR will be coordinated with a PR on the MCU repository, which will provide the emulated MCU and BMC cores, and will test the interactions.
… image length in emulator
instead of duplicating the length.
downloaded And fix the AXI to AXI transfer mechanism so that a fixed FIFO address can output to a non-fixed MCU SRAM address.
swenson
force-pushed
the
communicate-with-mcu-bmc
branch
from
fd766d6 to
7b2835a
Compare
swenson
added a commit
to chipsalliance/caliptra-mcu-sw
that referenced
this pull request
Feb 8, 2025
We start implementing a simulated recovery flow engine in a fake BMC, and having it work with Caliptra Core and MCU bootup. This depends on an event bus being hooked up between Caliptra Core, the MCU, and our fake BMC, which is processed on each end to translate events. For example, recovery block reads and writes from the BMC are translated to recovery registers available through AXI in Caliptra Core. This flow is a bit complex, and is not 100% finished yet. Currently it is working well enough that: * Emulators start and enable active mode * MCU ROM boots and sets up Caliptra Core's fuse registers * MCU ROM starts the recovery flow * Calipta Core ROM boots and requests the first recovery image (Caliptra's own firmware) * Caliptra Core downloads the firmware successfully The next step will be to get through validation and handle the SoC manifest and MCU firmware in Caliptra's runtime code. But, I wanted to do a check in so that these PRs don't become too overwhelming. Assuming you have `caliptra-sw` in `../caliptra-sw`, have built the ROM (`cd rom/dev && make build-rom`) and the signed Caliptra firmware (`cd rom/dev && make build-fw-image`), and have a file (doesn't yet matter the contents) `soc-manifest.bin`, you can test this whole flow with: ```shell-session $ cargo xtask runtime --caliptra-rom ../caliptra-sw/target/riscv32imc-unknown-none-elf/firmware/caliptra-rom.bin --caliptra-firmware ../caliptra-sw/target/riscv32imc-unknown-none-elf/firmware/caliptra-rom-test-fw --soc-manifest soc-manifest.bin --active-mode ... [ldev] Signing Cert with MLDSA AUTHORITY.KEYID = 8 [ldev] -- [fwproc] Wait for Commands... [fwproc] Recv command 0x52494644 [emulator bmc recovery] Recovery state transition: ReadDeviceStatus -> WaitForRecoveryStatus [emulator bmc recovery] Sending recovery image 0 [emulator bmc recovery] Recovery state transition: WaitForRecoveryStatus -> WaitForRecoveryPending [fwproc] Waiting for payload available signal... [fwproc] Recovery payload of 131072 bytes available [fwproc] Received Image from Recovery Interface of size 131072 bytes ROM Fatal Error: 0x000B0003 ``` (The fatal error is signature validation failure, which is to be expected.) Depends on chipsalliance/caliptra-sw#1938
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
And hook it up to the emulated AXI bus for DMA transfers.
The events are used to simulate some of the ways that Caliptra communicates with others in hardware, in particular, I3C, writing to MCU's memory aperture, and the recovery communications.
We wire these up in the emulated AXI DMA controller and recovery interface.
We also have to modify the emulated AXI DMA controller to support asynchronous reads and writes, which should more accurately emulates how the hardware works anyway.
This PR will be coordinated with a PR on the MCU repository, which will provide the emulated MCU and BMC cores, and will test the interactions.
I've run this with the MCU and BMC code through loading the recovery image from the recovery interface in the ROM's cold reset flow and gotten it to key verification.
Builds on some of the DMA changes in #1904.