be6a343
AXI driven Caliptra recovery flow
This chapter discusses the implementation of AXI based recovery flow, which is an alternative to the standard I3C based flow (see recovery_flow). This feature allows driving the recovery data from within the SoC integrating the I3C core over the AXI bus, bypassing I3C communication.
AXI Recovery flow implementation
The AXI recovery flow reuses the logic already present in the I3C core used in the Caliptra-SS design, with a runtime option essentially bypassing most of the I3C core communication logic (including the I3C recovery flow logic).
The loopback functionality is configurable via a CSR, with the I3C mode set as the default.
Recovery CSRs are accessible from the internal AXI bus. The transactions to the core may be filtered using the AXI ID field (see axi_id_filtering)
The logic is implemented so that the recovery firmware in the Caliptra RoT ROM can operate without any changes.
In order to enable setting W1C fields in recovery registers over AXI, the AXI recovery mode introduces additional register - REC_INTF_REG_W1C_ACCESS.
AXI-based recovery procedure
The Caliptra MCU RISC-V core is responsible for driving the data copied from an external memory (e.g. QSPI interface) to the recovery FIFOs. The ROM running on the MCU core monitors the recovery block registers and performs the recovery flow. During the boot procedure the ROM will have to follow the following procedure:
- Set the I3C block to the "direct AXI" mode
- Set the
REC_INTF_BYPASSbit in theREC_INTF_CFGregister
- Set the
- Poll the
DEVICE_STATUS_0register and wait for the recovery to be enabled by the Caliptra core- Poll
DEVICE_STATUS_0.DEV_STATUSuntil it becomes0x03(Recovery mode - ready to accept recovery image)
- Poll
- Read the
RECOVERY_STATUSregister and check if the recovery flow started- Check whether
RECOVERY_STATUS.DEV_REC_STATUSis0x1(Awaiting recovery image)
- Check whether
- Write to the
RECOVERY_CTRLregister to set the recovery image configuration - Write to the
INDIRECT_FIFO_CTRL_0register to reset the FIFO - Write to the
INDIRECT_FIFO_CTRL_1register to set the recovery image size - Push the recovery image to the recovery interface FIFOs:
- Read the
INDIRECT_FIFO_STATUSregister to determine remaining space in the indirect FIFO- If the indirect FIFO is not full, write a chunk of data to the
TX_DATA_PORTregister - If the indirect FIFO is full, wait for the
INDIRECT_FIFO_STATUS_0.FULLbit to clear
- If the indirect FIFO is not full, write a chunk of data to the
- The above steps should be repeated until the whole recovery image is written to the FIFO
- Read the
- Notify the recovery handler that the final chunk has been sent
- Set the
REC_PAYLOAD_DONEbit in theREC_INTF_CFGregister to raise thepayload_availablesignal for the final time
- Set the
- Activate the new image
- Write
0xf00to theREC_INTF_REG_W1C_ACCESSregister to update theRECOVERY_CTRLfield
- Write
- Read the
RECOVERY_STATUSregister to ensure the image has been activated- Poll
RECOVERY_STATUS.DEV_REC_STATUSuntil it becomes0x3(Recovery successful); before the image is activated, this field will be0x2(Booting recovery image)
- Poll
The recovery image will be written in chunks with length equal to or less than Max transfer size defined in the INDIRECT_FIFO_STATUS register.
Once the last data chunk is written to the FIFO, the Caliptra MCU ROM will write a CSR in the Secure Firmware Recovery register file indicating the transfer is complete.
Recovery Handler bypass
In the regular (I3C) mode of the core, the Recovery Handler strongly relies on communication with the I3C Core internal logic by interfacing with TTI Queues. The bypass implementation modifies the I3C Core logic to allow direct access over the AXI bus to the structures specified by the OCP Secure Firmware Recovery for compliance with the Caliptra Subsystem Recovery Sequence.
The default design of the Recovery Handler includes many blocks specifically designed to translate I3C bus traffic into recovery messages. It also automatically responds to the I3C commands by writing transaction descriptors and data for the TTI Queues. Such a recovery flow is presented in the diagram below.
:::{figure-md} recovery_handler

Recovery Handler in the I3C Core :::
In order enable an alternative recovery mechanism while reusing the existing logic and keeping compliance with Caliptra, the I3C core provides a custom bypass feature allowing direct communication with the Recovery Handler via the AXI bus. The bypass disables the I3C communication logic. Data is routed from the TTI TX Queue to the Recovery Executor block, and written directly to the Indirect Data FIFO. The Caliptra ROM can access the data from the Indirect FIFO over the AXI bus (the same way it does in the regular I3C recovery flow). Data flow in bypass mode, marked with green arrows, is depicted in the diagram below.
:::{figure-md} recovery_handler_with_bypass

Recovery Handler with the I3C Core logic bypass :::
Secure Firmware Recovery CSRs
With the bypass feature enabled, the FIFO status CSRs in the Secure Firmware Recovery CSR file will be updated by the Recovery Handler module.
However, some registers like e.g. INDIRECT_FIFO_CTRL which are updated by I3C commands in a standard recovery flow, will have to be accessed and configured properly from the software running on the Caliptra MCU via the AXI bus.
All configurable registers are writable from software, read only registers provide status information about Recovery Handler internals, e.g. details about size and fill level of the Indirect FIFO.