Diff: Subsystem Hardware Specification

@@ -1,5 +1,5 @@
1	1	<div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;">
2		-📄 Source: <a href="https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/docs/CaliptraSSHardwareSpecification.md" target="_blank">chipsalliance/caliptra-ss/docs/CaliptraSSHardwareSpecification.md</a> @ <code>9022fc2</code>
	2	+📄 Source: <a href="https://github.com/chipsalliance/caliptra-ss/blob/0968cfe1b94ef358cb97017fd0772765013eda7b/docs/CaliptraSSHardwareSpecification.md" target="_blank">chipsalliance/caliptra-ss/docs/CaliptraSSHardwareSpecification.md</a> @ <code>0968cfe</code>
3	3	</div>
4	4
5	5	<div align="center">
@@ -7,7 +7,7 @@
7	7	</div>
8	8
9	9	<h1 align="center"> Caliptra Subsystem Hardware Specification </h1>
10		-<h3 align="center"> Version 2.0.1 </h3>
	10	+<h3 align="center"> Version 2p2 (WIP) </h3>
11	11
12	12	- [Scope](#scope)
13	13	- [Document Version](#document-version)
@@ -17,29 +17,40 @@
17	17	- [Caliptra-subsystem-mode](#caliptra-subsystem-mode)
18	18	- [Caliptra Subsystem Architectural Requirements](#caliptra-subsystem-architectural-requirements)
19	19	- [Caliptra Subsystem HW Requirements](#caliptra-subsystem-hw-requirements)
20		- - [Caliptra 2.0 HW requirements (Subsystem Support)](#caliptra-20-hw-requirements-subsystem-support)
21		- - [Caliptra 2.0 HW requirements (Not subsystem related)](#caliptra-20-hw-requirements-not-subsystem-related)
	20	+ - [Caliptra 2.0/2.1 HW requirements (Subsystem Support)](#caliptra-2021-hw-requirements-subsystem-support)
	21	+ - [Caliptra 2.2 HW requirements (Subsystem Support)](#caliptra-22-hw-requirements-subsystem-support)
	22	+ - [Caliptra 2.0/2.1 HW requirements (Not subsystem related)](#caliptra-2021-hw-requirements-not-subsystem-related)
	23	+ - [Caliptra Potential Future HW Features](#caliptra-potential-future-hw-features)
22	24	- [MCU HW requirements](#mcu-hw-requirements)
23		- - [Subsystem Components HW requirements](#subsystem-components-hw-requirements)
	25	+ - [Caliptra 2.0/2.1 Subsystem Components HW requirements](#caliptra-2021-subsystem-components-hw-requirements)
24	26	- [Fabric](#fabric)
25	27	- [MCU SRAM](#mcu-sram)
26	28	- [MCU ROM](#mcu-rom)
27	29	- [I3C](#i3c)
28	30	- [Fuse Controller](#fuse-controller)
29	31	- [MCI](#mci)
	32	+ - [Caliptra 2.2 Subsystem Components HW requirements](#caliptra-22-subsystem-components-hw-requirements)
	33	+ - [USB](#usb)
	34	+ - [SPI](#spi)
30	35	- [Caliptra Subsystem Hardware Block Diagram](#caliptra-subsystem-hardware-block-diagram)
31	36	- [Caliptra Subsystem Architectural Flows](#caliptra-subsystem-architectural-flows)
32		-- [I3C Streaming Boot (Recovery) Interface](#i3c-streaming-boot-recovery-interface)
33		- - [Streaming Boot (Recovery) Interface hard coded logic](#streaming-boot-recovery-interface-hard-coded-logic)
34		- - [Hardware Registers](#hardware-registers)
35		- - [Streaming Boot (Recovery) Interface Wires](#streaming-boot-recovery-interface-wires)
36		- - [I3C Streaming Boot (Recovery) Flow](#i3c-streaming-boot-recovery-flow)
37		- - [Caliptra ROM Requirements for OCP Streaming Boot](#caliptra-rom-requirements-for-ocp-streaming-boot)
38		- - [I3C and Caliptra-AXI Interactions](#i3c-and-caliptra-axi-interactions)
	37	+ - [USB Streaming Boot (Caliptra SS 2.2)](#usb-streaming-boot-caliptra-ss-22)
	38	+ - [I3C Streaming Boot (Recovery) Interface](#i3c-streaming-boot-recovery-interface)
	39	+ - [Streaming Boot (Recovery) Interface hard coded logic](#streaming-boot-recovery-interface-hard-coded-logic)
	40	+ - [Hardware Registers](#hardware-registers)
	41	+ - [Streaming Boot (Recovery) Interface Wires](#streaming-boot-recovery-interface-wires)
	42	+ - [I3C Streaming Boot (Recovery) Flow](#i3c-streaming-boot-recovery-flow)
	43	+ - [Caliptra ROM Requirements for OCP Streaming Boot](#caliptra-rom-requirements-for-ocp-streaming-boot)
	44	+ - [I3C and Caliptra-AXI Interactions](#i3c-and-caliptra-axi-interactions)
	45	+ - [AXI Streaming Boot (Recovery) Interface](#axi-streaming-boot-recovery-interface)
	46	+ - [AXI Streaming Boot Flow implementation](#axi-streaming-boot-flow-implementation)
	47	+ - [AXI Streaming Boot Handler](#axi-streaming-boot-handler)
	48	+ - [AXI Streaming Boot CSRs](#axi-streaming-boot-csrs)
39	49	- [Caliptra Core AXI Manager \& DMA assist](#caliptra-core-axi-manager--dma-assist)
40	50	- [AXI Feature Support](#axi-feature-support)
41	51	- [Routes](#routes)
42	52	- [OCP Streaming Boot Payloads](#ocp-streaming-boot-payloads)
	53	+ - [AES Mode](#aes-mode)
43	54	- [Programming Flowchart {#programming-flowchart}](#programming-flowchart-programming-flowchart)
44	55	- [Descriptor](#descriptor)
45	56	- [Caliptra Subsystem Fuse Controller](#caliptra-subsystem-fuse-controller)
@@ -51,10 +62,11 @@
51	62	- [Locking the Validated Public Key Partition](#locking-the-validated-public-key-partition)
52	63	- [Hardware Integrity Checker](#hardware-integrity-checker)
53	64	- [Purpose](#purpose)
54		- - [Zeroization Flow for Secret FUSEs](#zeroization-flow-for-secret-fuses)
55		- - [Conditions for Zeroization](#conditions-for-zeroization)
56		- - [Zeroization Process](#zeroization-process)
57		- - [Cold Reset and Final Zeroization](#cold-reset-and-final-zeroization)
	65	+ - [Debug Intent Secret Zeroization](#debug-intent-secret-zeroization)
	66	+ - [Effective debug intent](#effective-debug-intent)
	67	+ - [Secret hardware-digest read masking](#secret-hardware-digest-read-masking)
	68	+ - [Secret partition zeroization](#secret-partition-zeroization)
	69	+ - [`SECRET_DIGEST_READ_LOCK`](#secret_digest_read_lock)
58	70	- [Notes](#notes)
59	71	- [General Guidance](#general-guidance)
60	72	- [Reset Considerations](#reset-considerations)
@@ -66,7 +78,7 @@
66	78	- [LCC State and State Decoder Output Ports](#lcc-state-and-state-decoder-output-ports)
67	79	- [TAP Pin Muxing](#tap-pin-muxing)
68	80	- [How does Caliptra Subsystem enable manufacturing debug mode?](#how-does-caliptra-subsystem-enable-manufacturing-debug-mode)
69		- - [Flow Explanation:](#flow-explanation)
	81	+ - [Flow Explanation](#flow-explanation)
70	82	- [Production Debug Unlock Architecture](#production-debug-unlock-architecture)
71	83	- [Overview of Debug Unlock Initiation](#overview-of-debug-unlock-initiation)
72	84	- [Secure Debug Unlock Protocol](#secure-debug-unlock-protocol)
@@ -84,11 +96,14 @@
84	96	- [MCI CSR Access Restrictions](#mci-csr-access-restrictions)
85	97	- [MCI Straps](#mci-straps)
86	98	- [Subsystem Boot Finite State Machine (CSS-BootFSM)](#subsystem-boot-finite-state-machine-css-bootfsm)
	99	+ - [CSS-BootFSM Glitch Protection](#css-bootfsm-glitch-protection)
87	100	- [Watchdog Timer](#watchdog-timer)
88	101	- [MCU Mailbox](#mcu-mailbox)
89	102	- [MCU Mailbox Limited Trusted AXI users](#mcu-mailbox-limited-trusted-axi-users)
90	103	- [MCU Mailbox Locking](#mcu-mailbox-locking)
91	104	- [MCU Mailbox Target User](#mcu-mailbox-target-user)
	105	+ - [MCU Mailbox SRAM Ownership](#mcu-mailbox-sram-ownership)
	106	+ - [MCU Mailbox Status Registers](#mcu-mailbox-status-registers)
92	107	- [MCU Mailbox Fully addressable SRAM](#mcu-mailbox-fully-addressable-sram)
93	108	- [MCU Mailbox SRAM Clearing](#mcu-mailbox-sram-clearing)
94	109	- [MCU Mailbox Interrupts](#mcu-mailbox-interrupts)
@@ -103,6 +118,7 @@
103	118	- [MCI Fuse Storage Support](#mci-fuse-storage-support)
104	119	- [MCU Timer](#mcu-timer)
105	120	- [MCU Trace Buffer](#mcu-trace-buffer)
	121	+ - [Trace Source Select (MCU vs Caliptra core)](#trace-source-select-mcu-vs-caliptra-core)
106	122	- [MCU Trace Buffer SW Interface](#mcu-trace-buffer-sw-interface)
107	123	- [MCU Trace Buffer Packet](#mcu-trace-buffer-packet)
108	124	- [MCU Trace Buffer Extraction](#mcu-trace-buffer-extraction)
@@ -120,34 +136,42 @@
120	136	- [MCI Boot FSM Breakpoint Flow](#mci-boot-fsm-breakpoint-flow)
121	137	- [MCI Design for Test (DFT)](#mci-design-for-test-dft)
122	138	- [Reset Controls](#reset-controls)
123		-
	139	+- [Caliptra SS USB2](#caliptra-ss-usb2)
	140	+ - [Combo AXI memory map](#combo-axi-memory-map)
	141	+ - [Ownership and access](#ownership-and-access)
	142	+ - [AXI USER filtering](#axi-user-filtering)
	143	+ - [DWORD-only accesses](#dword-only-accesses)
124	144
125	145	# Scope
126	146
127	147	This document defines technical specifications for a subsystem design utilizing Caliptra RoT in Subystem Mode. This document, along with [Caliptra Hardware Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md), shall comprise the Caliptra Subsystem technical specification.
128	148
129	149	## Document Version
	150	+
130	151	<div align="center">
131	152
132	153	\| Date \| Document Version \| Description \|
133	154	\| ----------------- \| -------------------- \| ------------------- \|
134	155	\| Jan 31st, 2025 \| v0p8 \| Work in progress \|
135		-\| Apr 30th, 2025 \| v1p0-rc1 \| Initial release candidate of Caliptra Gen 2.0 Subsystem Documents.<br>Specifications updated with:<br> - Updated details on component features (MCU mailbox, MCU trace buffer, MCI error aggregation, FC fuse zeroization)<br> - Details on design connectivity with top-level ports<br> - Port and register updates \|
136		-\| Oct 29th, 2025 \| v2.0.1 \| Patch release of 2.0.1 with clarifications on several doc sections \|
	156	+\| Apr 30th, 2025 \| v1p0-rc1 \| Initial release candidate of Caliptra Gen 2.0 Subsystem Documents.<br>Specifcations updated with:<br> - Updated details on component features (MCU mailbox, MCU trace buffer, MCI error aggregation, FC fuse zeroization)<br> - Details on design connectivity with top-level ports<br> - Port and register updates \|
	157	+\| Oct 12th, 2025 \| v2p1 \| Final release of Caliptra Subsystem 2.1 \|
137	158
138	159
139	160	</div>
140	161
141	162	# Caliptra Subsystem Requirements
	163	+
142	164	## Definitions
143		-* RA: Recovery Agent / Streaming boot Agent
144		-* MCI: Manufacturer Control Interface
145		-* MCU: Manufacturer Control Unit
146		-
	165	+- RA: Recovery Agent / Streaming boot Agent
	166	+- MCI: Manufacturer Control Interface
	167	+- MCU: Manufacturer Control Unit
	168	+
147	169	## Caliptra-Passive-Mode (Legacy)
	170	+
148	171	SOC manages boot media peripherals and Caliptra is used as Root of trust for measurements.
149	172
150		-## Caliptra-subsystem-mode
	173	+## Caliptra-subsystem-mode
	174	+
151	175	Caliptra owns the recovery interface (peripheral independent) and Caliptra is THE RoT of the SoC. Any SOC specific variables that needs to be stored and retrieved securely from NV storage is handled using Caliptra.
152	176
153	177	## Caliptra Subsystem Architectural Requirements
@@ -156,10 +180,12 @@
156	180	2. MCU will use Caliptra RT FW to auth/measure/load all of the FW belonging to the SOC.
157	181	3. MCU ROM/FW on MCU should be capable of performing SOC specific initialization.
158	182	4. MCU ROM/FW should be able to perform SoC management functions including performing reset control, SoC specific security policy enforcement, SOC initial configuration (eg. any GPIO programming, glitch detection circuits, reading/moving non-secret fuses etc.).
159		- * Note: Widgets that toggle the reset or other wires that set security permissions are SOC specific implementations.
	183	+
	184	+- Note: Widgets that toggle the reset or other wires that set security permissions are SOC specific implementations.
	185	+
160	186	6. Fuse controller for provisioning Caliptra fuses -> IFP (In-field programmable) fusing is performed by MCU RT; SW partition fuses in fuse controller are managed by MCU (ROM or RT); Caliptra HW is responsible for reading the secret fuses (Caliptra ROM, MCU ROM or any other SOC ROM or any RT FW should NOT have access to read the secret fuses in production).
161		-7. Recovery stack must be implemented. Please refer to I3C recovery section for more details and references.
162		-OCP Recovery registers implemented in I3C must follow the security filtering requirements specified in the recovery implementation spec (eg. MCU can ONLY access subset of the recovery registers as defined by the recovery implementation).
	187	+7. Recovery stack must be implemented. Please refer to I3C and USB recovery section for more details and references.
	188	+OCP Recovery registers implemented in I3C and USB must follow the security filtering requirements specified in the recovery implementation spec (eg. MCU can ONLY access subset of the recovery registers as defined by the recovery implementation).
163	189	8. Supports silicon t0 boot to load and run required FW across chiplets.
164	190	9. OCP recovery stack is implemented in Caliptra for Caliptra-subsystem-mode
165	191	10. MCU SRAM (or part of the SRAM that is mapped for Code/Data execution) should be readable/writeable ONLY by Caliptra until Caliptra gives permission to MCU to use it.
@@ -172,31 +198,66 @@
172	198
173	199	## Caliptra Subsystem HW Requirements
174	200
175		-### Caliptra 2.0 HW requirements (Subsystem Support)
	201	+### Caliptra 2.0/2.1 HW requirements (Subsystem Support)
	202	+
176	203	1. Full AXI read/write channels (aka AXI manager) for subsystem (for MCU and Caliptra)
177	204	a. For backward compatibility, AXI mgr. interface can be a no-connect and that configuration is validated.
178	205	2. HW logic/Programmable DMA
179		- * Read MMIO space for variable length.
180		- * Data returned from the above read can be exposed directly to the FW OR allow it to be written to a subsystem/SOC destination as programmed by ROM/FW.
181		- * Programmable logic to allow for SOC directed writes (from FW or from the above route back) to be sent through the SHA accelerator.
182		- * (Future open/stretch goal): If AES engine accelerator is integrated into Caliptra, then implement decryption before sending the writes back to the destination programmed by the ROM/FW.
183		- * This widget should have accessibility in manufacturing and debug mode over JTAG (can be exposed using the same JTAG interface as Caliptra 1.0). Ensure through validation that no asset can be read using this widget in those modes.
	206	+
	207	+- Read MMIO space for variable length.
	208	+- Data returned from the above read can be exposed directly to the FW OR allow it to be written to a subsystem/SOC destination as programmed by ROM/FW.
	209	+- Programmable logic to allow for SOC directed writes (from FW or from the above route back) to be sent through the SHA accelerator.
	210	+- If AES engine accelerator is integrated into Caliptra, then implement decryption before sending the writes back to the destination programmed by the ROM/FW.
	211	+- This widget should have accessibility in manufacturing and debug mode over JTAG (can be exposed using the same JTAG interface as Caliptra 1.0). Ensure through validation that no asset can be read using this widget in those modes.
	212	+
184	213	3. Expand manuf flow register to include UDS programming request steps
185		-4. SOC Key Release HW (Required for OCP Lock flow too)
186		- * Separate SOC Key Vault must be implemented (it is a separate structure from the current Caliptra KV).
187		- * In at least one configuration, the SOC KV must be implemented as an SRAM that is external and configurable by the SOC OR or an internal configurable SOC KV structure. If this is achievable within the Caliptra 2.0 milestone, only one of these would be the chosen implementation and configuration. This will be a design decision based on effort & schedule.
188		- * If implemented as a SRAM, data written and read into the SOC KV SRAM is decrypted & encrypted so that SOC DFT or other side channels cannot exfilterate the data.
189		- * Caliptra FW will indicate to the SOC KV Release HW to release the key by supplying the key handle to read from.
190		- * Destination address to which the key must be written to is programmed by the Caliptra FW into AXI MGR DMA HW.
191		- * SOC KV must have the same attributes as Caliptra internal KV. Additionally, it must also have an attribute of read-once and clear.
192		-
193		-### Caliptra 2.0 HW requirements (Not subsystem related)
	214	+4. SOC Key Release HW (Required for OCP Lock flow too) - 2.1 Note: Was implemented for OCP LOCK but didnt follow SOC KV implementation requirement below
	215	+
	216	+- Separate SOC Key Vault must be implemented (it is a separate structure from the current Caliptra KV).
	217	+- In at least one configuration, the SOC KV must be implemented as an SRAM that is external and configurable by the SOC OR or an internal configurable SOC KV structure. If this is achievable within the Caliptra 2.0 milestone, only one of these would be the chosen implementation and configuration. This will be a design decision based on effort & schedule.
	218	+- If implemented as a SRAM, data written and read into the SOC KV SRAM is decrypted & encrypted so that SOC DFT or other side channels cannot exfilterate the data.
	219	+- Caliptra FW will indicate to the SOC KV Release HW to release the key by supplying the key handle to read from.
	220	+- Destination address to which the key must be written to is programmed by the Caliptra FW into AXI MGR DMA HW.
	221	+- SOC KV must have the same attributes as Caliptra internal KV. Additionally, it must also have an attribute of read-once and clear.
	222	+
	223	+### Caliptra 2.2 HW requirements (Subsystem Support)
	224	+
	225	+1. Shall include Dual-noise source support
	226	+
	227	+ Two independent physical noise sources are carried to the subsystem boundary,
	228	+ each with its own external request output, so an integrator can attach two
	229	+ distinct noise-generation technologies:
	230	+
	231	+ - Source 0 (primary): `cptra_ss_cptra_core_etrng0_req_o`,
	232	+ `cptra_ss_cptra_core_itrng0_data_i`, `cptra_ss_cptra_core_itrng0_valid_i`
	233	+ - Source 1 (secondary): `cptra_ss_cptra_core_etrng1_req_o`,
	234	+ `cptra_ss_cptra_core_itrng1_data_i`, `cptra_ss_cptra_core_itrng1_valid_i`
	235	+ - Mode select: `cptra_ss_cptra_core_itrng1_en_i`
	236	+
	237	+ Inside the Caliptra core each source is conditioned by its own `entropy_src`,
	238	+ and the `entropy_combiner` merges the two conditioned outputs as
	239	+ `SHA3-384(ES0\|\|ES1)` into the single CSRNG seed. When
	240	+ `cptra_ss_cptra_core_itrng1_en_i` is 0 the combiner is transparently bypassed
	241	+ (source 0 straight to CSRNG) and the source-1 pins may be left unconnected, so
	242	+ single-noise-source integrations are unaffected. See the Caliptra Core
	243	+ hardware specification, Dual iTRNG entropy combiner, for the combiner
	244	+ architecture, its ROM power-on KAT, and the write-once AHB lock.
	245	+
	246	+2. Shall upgrade ABR to the latest source (ABR 3.0)
	247	+
	248	+### Caliptra 2.0/2.1 HW requirements (Not subsystem related)
	249	+
194	250	1. Ability to use two or more cryptos concurrently
195	251	2. Change APB -> AXI-Sub with the same capabilities (AXI USERID filtering replaces PAUSER based filtering, multiple targets for SHA acc, mailbox, fuses, registers etc. all)
196		-3. Future/Stretch Goal: Parity support on AXI-SUB & MGR
197		-
	252	+
	253	+### Caliptra Potential Future HW Features
	254	+
	255	+1. Parity support on AXI-SUB & MGR
	256	+2. Dual core lock step for VeeR EL2 on Caliptra core
	257	+3. MCU VeeR Data caching
198	258
199	259	### MCU HW requirements
	260	+
200	261	1. MCU should not be in the FIPS boundary and must not have any crypto functions. MCU must use Caliptra for any security flows (eg. security policy authorization) or traditional RoT support (eg. SPDM).
201	262	2. MCU VeeR must support PMP & User mode.
202	263	3. MCU AXI is directly connected to the SOC fabric in a way that allows a MMIO based control of the SoC as required for SOC security, manageability and boot functionality.
@@ -205,17 +266,21 @@
205	266	6. MCU uses instruction cache for speed up
206	267	7. It is required that all NV read/writes (eg. NV variables in flash) that require a RoT support to securely store/restore must go through Caliptra.
207	268	8. NV-storage peripheral shall be built in such a way that it will only accept transactions from MCU.
208		-9. Support for MCU first fetch vector to direct towards MCU SRAM post reset
209		-
210		-
211		-### Subsystem Components HW requirements
	269	+9. Support for MCU first fetch vector to direct towards MCU SRAM post reset
	270	+
	271	+### Caliptra 2.0/2.1 Subsystem Components HW requirements
	272	+
212	273	#### Fabric
	274	+
213	275	1. AXI Interconnect connects Caliptra, I3C, Fuse Controller, Life Cycle Controller, MCU and its memory components with the rest of the SOC.
214		- * Note: Because each SOC integration model is different, AXI interconnect is NOT implemented by the subsystem but subsystem must validate using an AXI interconnect VIP to ensure all the components operate per the flows documented in this specification.
215		- * For the VIP interconnect configuration, all subtractively decoded transactions are sent towards SoC. AXI interconnect & Subsystem is validated with the assumption that all of them are running on the same clock domain.
	276	+
	277	+- Note: Because each SOC integration model is different, AXI interconnect is NOT implemented by the subsystem but subsystem must validate using an AXI interconnect VIP to ensure all the components operate per the flows documented in this specification.
	278	+- For the VIP interconnect configuration, all subtractively decoded transactions are sent towards SoC. AXI interconnect & Subsystem is validated with the assumption that all of them are running on the same clock domain.
	279	+
216	280	2. To be documented: AXI-USERID requirements
217	281
218		-#### MCU SRAM
	282	+#### MCU SRAM
	283	+
219	284	1. Since it's used for instruction and data execution – therefore requires AXI Sub with USERID filtering.
220	285	2. Provide JTAG accessibility to allow for SRAM to be populated in a secured debug mode at power on time (debug policies will be same as Caliptra)
221	286	3. MCU SRAM should have an aperture that can only be unlocked by Caliptra after it loads the image
@@ -223,17 +288,19 @@
223	288	5. MCU SRAM supports an aperture to be used as a MCU Mailbox.
224	289
225	290	#### MCU ROM
226		-* MCU ROM also needs to have AXI Sub for any data access from MCU and thereby requires AXI-ID/USERID filtering.
227		-
228		-#### I3C
	291	+- MCU ROM also needs to have AXI Sub for any data access from MCU and thereby requires AXI-ID/USERID filtering.
	292	+
	293	+#### I3C
	294	+
229	295	1. I3C on AXI interconnect with AXI Subordinate
230	296	2. Spec 1.1.1 aligned, but only with optional features that are required per PCIe ECN # <>
231	297	3. AXI Sub must be supported.
232	298	4. UserID to MCU and Caliptra
233	299	5. MCU access lock for I3C recovery and data (FIFO) registers until recovery flow is completed. In other words, MCU ROM must not impact the data flow into Recovery IFC registers.
234		-Stretch Goal: DMA data payload back to destination (Caliptra or MCU)
	300	+Stretch Goal (Met in 2.0/2.1): DMA data payload back to destination (Caliptra)
235	301
236	302	#### Fuse Controller
	303	+
237	304	1. AXI sub interface
238	305	2. Secrets (separate USERID and access constraints) vs SW partition separation
239	306	3. Registers implemented for “Secrets” should follow the same rules as Caliptra (no scan, clear on specific life cycle/security states)
@@ -242,67 +309,137 @@
242	309	6. When debug mode is intended to be enabled & when enabled, all secrets/assets as defined should be wiped and provide the indication to SOC for any secrets/assets it may have.
243	310
244	311	#### MCI
245		-* HW logic to move secret fuses from Fuse controller to Caliptra.
	312	+- HW logic to move secret fuses from Fuse controller to Caliptra (2.0/2.1 note: Implemented by MCU ROM for all non-secret fuses and secret fuses directly go to Caliptra core without any ROM or additional HW involvement).
	313	+
	314	+### Caliptra 2.2 Subsystem Components HW requirements
	315	+
	316	+#### USB
	317	+
	318	+1. USB2 integration with streaming boot support
	319	+2. USB2 shall implement two devices - one for Caliptra subsystem usage and one for SOC usage
	320	+3. USB2 access must follow the [ownership and AXI USER filtering policy](#ownership-and-access) and [DWORD-only access requirement](#dword-only-accesses).
	321	+
	322	+#### SPI
	323	+
	324	+SPI shall be supported along with AXI streaming boot block
246	325
247	326	## Caliptra Subsystem Hardware Block Diagram
248	327
249		-Figure: Caliptra Subsystem Block Diagram
	328	+Figure: Caliptra 2.0/2.1 Subsystem Block Diagram
250	329
251	330	![](https://github.com/chipsalliance/Caliptra/blob/main/doc/images/Subsystem.png)
252	331
253		-
	332	+Figure: Caliptra 2.2 Subsystem Block Diagram
	333	+![](../images/caliptra-ss/docs/images/CSS2p2.png)
	334	+Notes:
	335	+1. If an integration chooses to use USB for all the SOC/Platform facing flows, then it has an integration option to remove I3C
	336	+2. SOCs will also have a choice of keeping both USB2 and I3C (USB2 shall always be there)
	337	+
254	338	# Caliptra Subsystem Architectural Flows
	339	+
255	340	Please refer to [Caliptra Security Subsystem Specification](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#caliptra-security-subsystem) for more details.
256	341
257		-# I3C Streaming Boot (Recovery) Interface
	342	+## USB Streaming Boot (Caliptra SS 2.2)
	343	+=================== Coming Soon ===========================
	344	+
	345	+## I3C Streaming Boot (Recovery) Interface
	346	+
258	347	The I3C recovery interface acts as a standalone I3C target device for recovery. It will have a unique address compared to any other I3C endpoint for the device. It will comply with I3C Basic v1.1.1 specification. It will support I3C read and write transfer operations. It must support Max read and write data transfer of 1-256B excluding the command code (1 Byte), length (2 Byte), and PEC (1 Byte), total 4 Byte I3C header. Therefore, max recovery data per transfer will be limited to 256-byte data.
259		-
260		-I3C recovery interface is responsible for the following list of actions:
	348	+
	349	+I3C recovery interface is responsible for the following list of actions:
	350	+
261	351	1. Responding to command sent by Recovery Agent (RA)
262	352	2. Updating status registers based on interaction of AC-RoT and other devices
263	353	3. Asserting / Deasserting “payload_available” & “image_activated” signals
264	354
265		-## Streaming Boot (Recovery) Interface hard coded logic
	355	+### Streaming Boot (Recovery) Interface hard coded logic
	356	+
266	357	Hardware registers size is fixed to multiple of 4 bytes, so that firmware can read or write with word boundary. Address offset will be programmed outside of the I3C device. Register access size must be restricted to individual register space and burst access with higher size must not be allowed.
267	358
268	359	Figure: I3C Streaming Boot (Recovery) Interface Logic Block Diagram
269	360
270	361	![](../images/caliptra-ss/docs/images/I3C-Recovery-IFC.png)
271	362
272		-## Hardware Registers
	363	+### Hardware Registers
	364	+
273	365	Hardware registers size is fixed to multiple of 4 bytes, so that firmware can read or write with word boundary. Address offset will be programmed outside of the I3C device. Register access size must be restricted to individual register space and burst access with higher size must not be allowed.
274	366
275		-Note: Accessing the same address for INDIRECT_FIFO_DATA register will write or read the FIFO. It will not be available to access randomly as specified by the specification.
	367	+Note: Accessing the same address for INDIRECT_FIFO_DATA register will write or read the FIFO. It will not be available to access randomly as specified by the specification.
276	368
277	369	TODO: Add a link to rdl -> html file
278	370
279		-## Streaming Boot (Recovery) Interface Wires
280		-
	371	+### Streaming Boot (Recovery) Interface Wires
	372	+
281	373	1. Payload available
282		- * The Recovery Interface (I3C target) should receive a write transaction to INDIRECT_FIFO_DATA reg from BMC - 256B + 4B (Header), and wait for each I3C write to finish. Once I3C write transaction to INDIRECT_FIFO_DATA register is completed and PEC verification is successful, then the I3C target must assert "payload_available". DMA assist must wait for "payload_available" before reading. It must read 256B or last read with remaining data.
283		- * The "payload_available" signal remains asserted until Recovery Interface receives Read from DMA over AXI for INDIRECT_FIFO_DATA.
	374	+
	375	+- The Recovery Interface (I3C target) should receive a write transaction to INDIRECT_FIFO_DATA reg from BMC - 256B + 4B (Header), and wait for each I3C write to finish. Once I3C write transaction to INDIRECT_FIFO_DATA register is completed and PEC verification is successful, then the I3C target must assert "payload_available". DMA assist must wait for "payload_available" before reading. It must read 256B or last read with remaining data.
	376	+- The "payload_available" signal remains asserted until Recovery Interface receives Read from DMA over AXI for INDIRECT_FIFO_DATA.
	377	+
284	378	2. Image_activated
285		- * The I3C target will assert "image_activated" signal as soon as write to RECOVERY_CTRL register is received.
286		- * ROM will clear “image_activated” bit by writing to RECOVERY_CTRL register via DMA assist after the image is authenticated. As defined in the OCP Recovery Specification, RECOVERY_CTRL, byte 2 is used to specify the image activation control, and is Write-1-Clear. ROM must write 0xFF to this field to clear the image recovery status, which will also result in the Recovery Interface deasserting the “image_activated” signal to Caliptra.
287		-
288		-## I3C Streaming Boot (Recovery) Flow
	379	+
	380	+- The I3C target will assert "image_activated" signal as soon as write to RECOVERY_CTRL register is received.
	381	+- ROM will clear “image_activated” bit by writing to RECOVERY_CTRL register via DMA assist after the image is authenticated. As defined in the OCP Recovery Specification, RECOVERY_CTRL, byte 2 is used to specify the image activation control, and is Write-1-Clear. ROM must write 0xFF to this field to clear the image recovery status, which will also result in the Recovery Interface deasserting the “image_activated” signal to Caliptra.
	382	+
	383	+### I3C Streaming Boot (Recovery) Flow
289	384
290	385	Please refer to [Caliptra Subsystem OCP Streaming Boot Sequence](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#caliptra-subsystem-streaming-boot-sequence).
291	386
292	387	Figure: Caliptra Subsystem I3C Streaming Boot (Recovery) Flow
293	388	![](../images/caliptra-ss/docs/images/CSS-Recovery-Flow.png)
294	389
295		-## Caliptra ROM Requirements for OCP Streaming Boot
	390	+### Caliptra ROM Requirements for OCP Streaming Boot
	391	+
296	392	Caliptra firmware must follow these rules when implementing the OCP Streaming Boot flow:
297	393	* Caliptra ROM and RT Firmware must wait for "image_activated" signal to assert before processing the image.
298	394	* When image is sent to Caliptra Subsystem, Caliptra ROM & RT firmware must program DMA assist according to the rules defined in [OCP Streaming Boot Payloads](#ocp-streaming-boot-payloads).
299	395	* Once the image is processed, Caliptra ROM & RT firmware must initiate a write with data 1 via DMA to clear byte 2 “Image_activated” of the RECOVERY_CTRL register. This will allow BMC (or streaming boot initiator) to initiate subsequent image writes.
300	396
301		-## I3C and Caliptra-AXI Interactions
	397	+### I3C and Caliptra-AXI Interactions
	398	+
302	399	Received transfer data can be obtained by the driver via a read from XFER_DATA_PORT register. Received data threshold is indicated to BMC by the controller with TX_THLD_STAT interrupt if RX_THLD_STAT_EN is set. The RX threshold can be set via RX_BUF_THLD. In case of a read when no RX data is available, the controller shall raise an error on the frontend bus interface (AHB / AXI).
303	400
	401	+## AXI Streaming Boot (Recovery) Interface
	402	+
	403	+This feature allows streaming data or firmware by MCU over the AXI bus of the I3C module which is repurposed as a streaming boot interface while disabling I3C usage.
	404	+
	405	+### AXI Streaming Boot Flow implementation
	406	+
	407	+The AXI Streaming Boot 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).
	408	+The loopback functionality is configurable via the [REC_INTF_CFG](https://chipsalliance.github.io/i3c-core/registers.html#rec-intf-cfg-register) CSR which is set to I3C mode by default.
	409	+Streaming boot CSRs are accessible over AXI.
	410	+In both I3C and AXI streaming boot modes, I3C AXI access must comply with [I3C AXI USER Filtering](CaliptraSSIntegrationSpecification.md#i3c-axi-user-filtering).
	411	+The logic is implemented so that the streaming boot implementation in the Caliptra core (HW & ROM) can operate without any changes.
	412	+In order to enable setting W1C streaming boot registers, AXI streaming mode introduces an additional register - `REC_INTF_REG_W1C_ACCESS`.
	413	+
	414	+### AXI Streaming Boot Handler
	415	+
	416	+In the regular (I3C) mode of the core, the Streaming Boot (Recovery) Handler strongly relies on the communication with the I3C Core internal logic by interfacing with TTI Queues.
	417	+The bypass implementation modifies the I3C Core logic to allow direct access over the AXI bus to the structures specified by the OCP Streaming boot for compliance with the [Caliptra Subsystem Streaming Boot Sequence](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#caliptra-subsystem-streaming-boot-interface-hardware).
	418	+
	419	+The default design of the Streaming Boot Handler includes many blocks specifically designed to translate I3C bus traffic into recovery messages.
	420	+It also automatically responds to the I3C commands by writing transaction descriptors and data for the TTI Queues.
	421	+
	422	+Figure: Streaming Boot (Recovery) Handler in the I3C Core
	423	+![](../images/caliptra-ss/docs/images/AXI-Recovery-Handler.png)
	424	+
	425	+In order enable the AXI streaming boot mechanism while reusing the existing logic and keeping compliance with Caliptra, the I3C core provides a custom bypass feature allowing direct communication with the Streaming Boot Handler via the AXI bus.
	426	+The bypass disables the I3C communication logic.
	427	+Data is routed from the TTI TX Queue to the Recovery Executor block, and written directly to the Indirect Data FIFO.
	428	+The Caliptra ROM can access the data from the Indirect FIFO over the AXI bus (the same way it does in the regular I3C streaming boot flow).
	429	+The dataflow in bypass mode (marked with green arrows) is depicted in the diagram below.
	430	+
	431	+Figure: AXI Streaming Boot Handler in I3C Bypass Mode
	432	+![](../images/caliptra-ss/docs/images/AXI-Recovery-Handler-Bypass.png)
	433	+
	434	+### AXI Streaming Boot CSRs
	435	+
	436	+With the bypass feature enabled, the FIFO status CSRs in the Streaming Boot CSR file will be updated by the Streaming Bott Handler module.
	437	+However, some registers like e.g. `INDIRECT_FIFO_CTRL` which are updated by I3C commands in a standard streaming boot flow, will have to be accessed and configured properly from the software running on the Caliptra MCU via the AXI bus.
	438	+All configurable registers are writable from software, read only registers provide status information about Streaming Boot Handler internals, e.g. details about size and fill level of the Indirect FIFO.
	439	+
304	440	# Caliptra Core AXI Manager & DMA assist
305		-SOC\_IFC includes a hardware-assist block that is capable of initiating DMA transfers to the attached SoC AXI interconnect. The DMA transfers include several modes of operation, including raw transfer between SoC (AXI) addresses, moving data into or out of the SOC\_IFC mailbox, and directly driving data through AHB CSR accesses to datain/dataout registers. One additional operating mode allows the DMA engine to autonomously wait for data availability via the OCP Recovery interface (which will be slowly populated via an I3C or similar interface).
	441	+
	442	+SOC\_IFC includes a hardware-assist block that is capable of initiating DMA transfers to the attached SoC AXI interconnect. The DMA transfers include several modes of operation, including raw transfer between SoC (AXI) addresses, moving data into or out of the SOC\_IFC mailbox, directly encrypting/decrypting images with the AES block, and directly driving data through AHB CSR accesses to datain/dataout registers. One additional operating mode allows the DMA engine to autonomously wait for data availability via the OCP Recovery interface (which will be slowly populated via an I3C or similar interface).
306	443
307	444	Caliptra arms transfers by populating a transaction descriptor to the AXI DMA CSR block via register writes over the internal AHB bus. Once armed, the DMA will autonomously issue AXI transactions to the SoC until the requested data movement is completed. The DMA uses an internal FIFO to buffer transfer data. For any transfer using AXI Writes (Write Route is not disabled), the DMA waits until sufficient data is available in the FIFO before initiating any AXI write requests.
308	445
@@ -311,18 +448,19 @@
311	448	![](../images/caliptra-ss/docs/images/Caliptra-AXI-DMA.png)
312	449
313	450	## AXI Feature Support
	451	+
314	452	The DMA assist initiates transactions on the AXI manager interface in compliance with the AXI specification. The generated AXI transactions adhere to the following rules:
315		-* All address requests will be aligned to the data width of the interface, which is configured as 32-bit in the 2.0 release.
316		-* The DMA will not issue Narrow transfers. That is, AxSIZE will always be set to match the data width of the interface (4 bytes).
317		-* All data lanes are used on all transfers. That is, the AXI manager Write channel will always set WSTRB to all 1s.
318		-* At most, 2 reads and 2 writes will be initiated at any time.
319		- * When using a non-zero block\_size for the transfer, in accordance with the [Streaming Boot](#Streaming-Boot-Payloads) feature, at most 1 read and 1 write will be issued concurrently.
320		-* All transactions are initiated with AxID = 0, meaning that both reads and writes require in-order responses.
321		-* The maximum burst length initiated is constrained by the following parameters:
322		- * Any transfer using the INCR burst type is restricted by both the maximum allowable length of an AXI transaction (AxLEN=255 or total byte count of 4KiB, whichever is smaller) and the size of the internal FIFO. In the 2.0 release the internal FIFO is configured with a depth of 512 bytes; the maximum transaction size allowed is 256 bytes, to allow up to 2 transactions to be outstanding at a time. In summary, the transfer size will always be 256 bytes or less (AxLEN = 63), as this is the smallest of (AxLEN = 255 -> 1KiB, 4KiB, and 256 bytes).
323		- * Any transfer using the FIXED burst type is restricted by the AXI specification to a burst length of 16.
324		- * When the block\_size field is set to a non-zero value when arming the DMA, all transfers are restricted in size to specified block_size, in bytes.
325		- * AXI transactions must not cross a 4KiB boundary, per the specification. If the transfer size requires crossing a boundary, the DMA will break it into smaller transactions that will go up to the boundary, then start from the next alignment boundary.
	453	+- All address requests will be aligned to the data width of the interface, which is configured as 32-bit in the 2.0 release.
	454	+- The DMA will not issue Narrow transfers. That is, AxSIZE will always be set to match the data width of the interface (4 bytes).
	455	+- All data lanes are used on all transfers. That is, the AXI manager Write channel will always set WSTRB to all 1s.
	456	+- At most, 2 reads and 2 writes will be initiated at any time.
	457	+ - When using a non-zero block\_size for the transfer, in accordance with the [Streaming Boot](#Streaming-Boot-Payloads) feature, at most 1 read and 1 write will be issued concurrently.
	458	+- All transactions are initiated with AxID = 0, meaning that both reads and writes require in-order responses.
	459	+- The maximum burst length initiated is constrained by the following parameters:
	460	+ - Any transfer using the INCR burst type is restricted by both the maximum allowable length of an AXI transaction (AxLEN=255 or total byte count of 4KiB, whichever is smaller) and the size of the internal FIFO. In the 2.0 release the internal FIFO is configured with a depth of 512 bytes; the maximum transaction size allowed is 256 bytes, to allow up to 2 transactions to be outstanding at a time. In summary, the transfer size will always be 256 bytes or less (AxLEN = 63), as this is the smallest of (AxLEN = 255 -> 1KiB, 4KiB, and 256 bytes).
	461	+ - Any transfer using the FIXED burst type is restricted by the AXI specification to a burst length of 16.
	462	+ - When the block\_size field is set to a non-zero value when arming the DMA, all transfers are restricted in size to specified block_size, in bytes.
	463	+ - AXI transactions must not cross a 4KiB boundary, per the specification. If the transfer size requires crossing a boundary, the DMA will break it into smaller transactions that will go up to the boundary, then start from the next alignment boundary.
326	464
327	465	## Routes
328	466
@@ -344,133 +482,181 @@
344	482
345	483	![](../images/caliptra-ss/docs/images/Caliptra-AXI-DMA-RD-WR.png)
346	484
347		-
348	485	## OCP Streaming Boot Payloads
349	486
350		-The DMA block supports a special mode of operation that is intended for use in reading Firmware Image Payloads (for Streaming Boot) from the Recovery Interface, present in the Caliptra Subsystem. This operation mode relies on three key control signals: the payload\_available signal input from the recovery interface, the read\_fixed control bit, and the block\_size register (from the DMA control CSR block).
	487	+The DMA block supports a special mode of operation that is intended for use in reading Firmware Image Payloads (for Streaming Boot) from the Recovery Interface, present in the Caliptra Subsystem. This operation mode relies on three key control signals: the payload\_available signal input from the recovery interface, the read\_fixed control bit, and the block\_size register (from the DMA control CSR block).
351	488
352	489	This special mode of operation is only used for AXI Reads. To trigger the DMA to operate in this mode, Caliptra Firmware must program the block\_size register to a non-zero value that is a power-of-two. Caliptra Firmware must also program the read\_fixed control bit. Once the “go” bit is set, causing the DMA to begin operation, the DMA control logic will wait for the payload\_available input to trigger. When this occurs, the DMA controller issues a read that has a size equal to (or smaller) than the configured block\_size (the read may be smaller if required by AXI rules). This process repeats until the amount of data indicated in the byte\_size register has been transferred.
353	490
354	491	When programming an AXI to AXI transfer for a Streaming Boot Payload (e.g., to transfer an SoC Firmware manifest into an AXI-attached SRAM), firmware must also follow these rules:
355		-* Programmed value of block\_size must not exceed the largest legal AXI transaction size for a FIXED burst type. The DMA assist has a native data width of 4-bytes, so transaction size is restricted to 64-bytes due to the AXI specification limit of AxLEN == 15 for FIXED transactions.
356		-* Destination address must be aligned to the programmed value of block\_size. For example, if block\_size is set to 64-bytes, destination address must be an integer multiple of 0x40.
	492	+- Programmed value of block\_size must not exceed the largest legal AXI transaction size for a FIXED burst type. The DMA assist has a native data width of 4-bytes, so transaction size is restricted to 64-bytes due to the AXI specification limit of AxLEN == 15 for FIXED transactions.
	493	+- Destination address must be aligned to the programmed value of block\_size. For example, if block\_size is set to 64-bytes, destination address must be an integer multiple of 0x40.
357	494
358	495	In all cases other than reading Recovery Interface Payloads, the block\_size register must be programmed to 0\.
359	496
	497	+## AES Mode
	498	+
	499	+The DMA block can directly stream images from AXI to AES for decrypt/encrypt, and then stream the processed image over AXI to some SOC storage. This can be done by configuring the AXI DMA as:
	500	+
	501	+- AES Mode == 1
	502	+- (optional) aes_gcm_mode in DMA == 1
	503	+- Read Route == AXI
	504	+- Write Route == AXI
	505	+- Block Size == 0 (OCP Stream Boot Disabled)
	506	+- Read/Write Fixed == 0
	507	+- Source Address == Start of image
	508	+- Destination Address == Start address where processed image should be stored
	509	+- Configure Byte Count - must be DWORD aligned
	510	+
	511	+Other Read/Write Routes and Block sizes are not supported.
	512	+
	513	+The AXI DMA AES Mode ONLY streams the image into and out of AES. It is Firmware's responsibility to:
	514	+
	515	+1. Fully configure AES before streaming the image via AXI DMA
	516	+2. Push the IV, AAD header, and any other data into AES before streaming the image via AXI DMA
	517	+3. Retrieve any tags from AES after the image has been processed.
	518	+
	519	+If the input image size is not a multiple of 4 DWORDS, the AES FSM will properly pad the AES input data with 0s. When streaming the image out it reads all 4 DWORDS from the AES, but only writes up to the last DWORD of the image to the destination. If ``aes_gcm_mode`` register is set, at the start of the transfer it updates the GCM shadow byte count and phase registers in AES to the appropriate byte count and GCM_TEXT phase. Before the last block transfer to the AES it will again update the GCM shadow register to the appropriate values.
	520	+
	521	+Input images can be in little endian or big endian. It is FW's responsibility to configure the AES wrapper's ENDIAN_SWAP register.
	522	+
	523	+If AXI DMA encounters any errors (AXI or other errors) it will finish the transfer and report an error. It is the Firmware's responsibility to clear the error in the AXI DMA and flush the AES if required.
	524	+
	525	+When AXI DMA is using AES Caliptra shall not try to access AES via AHB until AXI DMA has completed.
	526	+
	527	+AES is not directly exposed on the AXI bus for external entities, it is protected behind the AXI DMA and can only be accessed via Caliptra uC AHB or the Caliptra DMA.
	528	+
	529	+AES Mode: Read Route \== AXI, Write Route \== AXI, AES Mode \== 1
	530	+
	531	+![](../images/caliptra-ss/docs/images/Caliptra-AXI-DMA-AES.png)
	532	+
360	533	## Programming Flowchart {#programming-flowchart}
361	534
362	535	General Rules:
363	536
364		-1. If either Read or Write route is configured to AXI RD \-\> AXI WR, both routes must be configured as AXI RD \-\> AXI WR.
365		-2. Read Route and Write Route must not both be disabled.
366		-3. If Read Route is enabled to any configuration other than AXI RD-\> AXI WR, Write route must be disabled.
367		-4. If Read Route is disabled, Write route must be enabled to a configuration that is not AXI RD \-\> AXI WR.
368		-5. If Read Route is disabled, Read Fixed field is ignored.
369		-6. If Write Route is disabled, Write Fixed field is ignored.
	537	+1. If either Read or Write route is configured to AXI RD \-\> AXI WR, both routes must be configured as AXI RD \-\> AXI WR.
	538	+2. Read Route and Write Route must not both be disabled.
	539	+3. If Read Route is enabled to any configuration other than AXI RD-\> AXI WR, Write route must be disabled.
	540	+4. If Read Route is disabled, Write route must be enabled to a configuration that is not AXI RD \-\> AXI WR.
	541	+5. If Read Route is disabled, Read Fixed field is ignored.
	542	+6. If Write Route is disabled, Write Fixed field is ignored.
370	543	7. Addresses and Byte Counts must be aligned to AXI data width (1 DWORD).
371		-
372	544	8. Block Size is used only for reads from the Subsystem Recovery Interface. When block size has a non-zero value, the DMA will only issue AXI read requests when the payload available input signal is set to 1, and will limit the size of read requests to the value of block size. For all other transactions (such as AXI writes, or any single-dword access to a subsystem register via the DMA), block size shall be set to a value of 0 for every transaction.
	545	+9. AES mode is only valid with Read/Write routes AXI RD -> AXI WR, Read/Write Fixed = 0, and Block Size 0.
373	546
374	547	Steps:
375	548
376		-1. Write Byte Count
377		-2. Write Block Size
378		-3. Write Source Addr (value is ignored if data is from AHB)
379		-4. Write Dest Addr (value is ignored if data is to AHB).
380		- 1. To perform an accelerated SHA operation on incoming read data, firmware sets the Read/Write route to AXI RD-\> AXI WR, and the destination address to the SoC address for the SHA Acceleration data in aperture.
381		-5. Set Interrupt Enables (optional)
382		-6. If Mailbox R/W: Acquire Mailbox Lock
383		-7. If SHA Acc Op:
384		- 1. First acquire Sha Accel Lock via AXI by using this flow (with the AHB-\> AXI WR route) to initiate AXI manager action
385		- 2. Initiate Sha Accel streaming operation via AXI by using this flow (with the AHB-\> AXI WR route) to initiate AXI manager action
386		- 3. Run this operation with the AXI RD \-\> AXI WR route to move data from SoC location into Sha Accelerator
387		-8. Set Control Register
388		- 1. Set Read/Write Routes
389		- 2. Set Read/Write Fixed=0/1
390		- 3. GO
391		- 4. (All 3 may be single write or separate, GO must be last bit to set)
392		-9. If AHB data: Wait for RD FIFO not empty or WR FIFO not full
393		- 1. Push/Pop data (using Rd Data/Wr Data register offsets) until all requested bytes transferred
394		- 2. If AHB Error – check status0 for Error, then check for “Command Error”
395		-10. Wait for TXN Done Interrupt (or Poll Status0)
396		-11. Read Status0, confirm Busy=0, Error=0
	549	+1. Write Byte Count
	550	+2. Write Block Size
	551	+3. Write Source Addr (value is ignored if data is from AHB)
	552	+4. Write Dest Addr (value is ignored if data is to AHB).
	553	+ 1. To perform an accelerated SHA operation on incoming read data, firmware sets the Read/Write route to AXI RD-\> AXI WR, and the destination address to the SoC address for the SHA Acceleration data in aperture.
	554	+5. Set Interrupt Enables (optional)
	555	+6. If Mailbox R/W: Acquire Mailbox Lock
	556	+7. If SHA Acc Op:
	557	+ 1. First acquire Sha Accel Lock via AXI by using this flow (with the AHB-\> AXI WR route) to initiate AXI manager action
	558	+ 2. Initiate Sha Accel streaming operation via AXI by using this flow (with the AHB-\> AXI WR route) to initiate AXI manager action
	559	+ 3. Run this operation with the AXI RD \-\> AXI WR route to move data from SoC location into Sha Accelerator
	560	+8. If AES Mode:
	561	+ 1. Fully configure AES with IV/KEY see [AES spec for more details](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#aes)
	562	+ 2. Stream in any header info to AES like AAD
	563	+ 3. Set read/write routes to AXI
	564	+ 4. Set AES_MODE in DMA
	565	+ 5. Set aes_gcm_mode in DMA if this is the AES mode
	566	+9. Set Control Register
	567	+ 1. Set Read/Write Routes
	568	+ 2. Set Read/Write Fixed=0/1
	569	+ 3. GO
	570	+ 4. (All 3 may be single write or separate, GO must be last bit to set)
	571	+10. If AHB data: Wait for RD FIFO not empty or WR FIFO not full
	572	+ 1. Push/Pop data (using Rd Data/Wr Data register offsets) until all requested bytes transferred
	573	+ 2. If AHB Error – check status0 for Error, then check for “Command Error”
	574	+11. Wait for TXN Done Interrupt (or Poll Status0)
	575	+12. Read Status0, confirm Busy=0, Error=0
397	576
398	577	## Descriptor
399	578
400		-https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.axi_dma_reg
	579	+<https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.axi_dma_reg>
401	580
402	581	# Caliptra Subsystem Fuse Controller
403	582
404		-FUSE controller is an RTL module that is responsible for programming and reading the FUSEs. This module has an AXI interface that is connected to Caliptra Subsystem’s AXI interconnect. This module provides the device with one-time programming functionality, resulting in non-volatile programming that cannot be reversed. This functionality is delivered via an open-source FUSE Controller and a proprietary FUSE/OTP Macro. This RTL module manages the following FUSE partition mapping, which can be found in the [Fuse Controller Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/src/fuse_ctrl/doc/otp_ctrl_mmap.md).
405		-
	583	+FUSE controller is an RTL module that is responsible for programming and reading the FUSEs. This module has an AXI interface that is connected to Caliptra Subsystem’s AXI interconnect. This module provides the device with one-time programming functionality, resulting in non-volatile programming that cannot be reversed. This functionality is delivered via an open-source FUSE Controller and a proprietary FUSE/OTP Macro. This RTL module manages the following FUSE partition mapping, which can be found in the [Fuse Controller Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/0968cfe1b94ef358cb97017fd0772765013eda7b/src/fuse_ctrl/doc/otp_ctrl_mmap.md).
406	584
407	585	## Partition Details
408	586
409		-The Fuse Controller is configured a total of 16 partitions (See [Fuse Controller's Fuse Partition Map](https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/src/fuse_ctrl/doc/otp_ctrl_mmap.md)), while it can support different number of partitions based on SoC product requirements. Secret FUSE partitions are prefixed with the word "Secret" and are associated with specific Life Cycle (LC) states, such as "MANUF" or "PROD." This naming convention indicates the LC state required to provision each partition.
410		-
411		-### Key Characteristics of Secret Partitions:
412		-1. Programming Access:
	587	+The Fuse Controller is configured a total of 16 partitions (See [Fuse Controller's Fuse Partition Map](https://github.com/chipsalliance/caliptra-ss/blob/0968cfe1b94ef358cb97017fd0772765013eda7b/src/fuse_ctrl/doc/otp_ctrl_mmap.md)), while it can support different number of partitions based on SoC product requirements. Secret FUSE partitions are prefixed with the word "Secret" and are associated with specific Life Cycle (LC) states, such as "MANUF" or "PROD." This naming convention indicates the LC state required to provision each partition.
	588	+
	589	+### Key Characteristics of Secret Partitions
	590	+
	591	+1. Programming Access:
413	592	- `UDS_SEED` and `FIELD_ENTROPY` partitions can only be programmed by the Caliptra Core.
414		- - Secret partitions are buffered, meaning they are stored in registers and are erased (temporarily zeroized) if Caliptra-SS enters debug mode.
415		-2. Locking Mechanism:
416		- - Write access to a partition can be permanently locked when no further updates are required.
	593	+ - Secret partitions are buffered, meaning they are stored in registers and are erased (temporarily zeroized) if Caliptra-SS enters debug mode.
	594	+2. Locking Mechanism:
	595	+ - Write access to a partition can be permanently locked when no further updates are required.
417	596	- To lock a partition, an integrity constant is calculated and programmed alongside the data for that partition.
418	597
419	598	## Partition-Specific Behaviors
420	599
421	600	### Life Cycle Partition
422		-- The life cycle partition remains active across all stages and cannot be locked.
423		-- This ensures that the device can transition back to the RMA state in case of unexpected failures during production.
	601	+
	602	+- The life cycle partition remains active across all stages and cannot be locked.
	603	+- This ensures that the device can transition back to the RMA state in case of unexpected failures during production.
424	604
425	605	### Vendor Test Partition
426		-- The vendor test partition is used for FUSE programming smoke checks during manufacturing.
	606	+
	607	+- The vendor test partition is used for FUSE programming smoke checks during manufacturing.
427	608	- Unlike other partitions, ECC uncorrectable errors in this partition do not trigger fatal errors or alerts due to the nature of FUSE smoke checks, which may leave certain FUSE words in inconsistent states.
428	609
429		-
430	610	## Locking the Validated Public Key Partition
	611	+
431	612	<a name="locking-the-validated-public-key-partition"></a>
432	613
433		-During firmware authentication, the ROM validates the vendor public keys provided in the firmware payload. These keys, which support ECC, MLDSA, and LMS algorithms, are individually hashed and compared against stored fuse values (e.g., `CPTRA_CORE_VENDOR_PK_HASH_n`). Once a valid key is identified, the ROM locks that specific public key hash and all higher-order public key hash entries until the next cold reset. This ensures that the validated key’s fuse entry remains immutable. Importantly, the locking mechanism is applied only to the public key hashes. The associated revocation bits, which allow for runtime key revocation, remain unlocked. To support this, the fuse controller (FC) implements two distinct partitions:
434		-
435		-1. PK Hash Partition
436		- - Purpose:
	614	+During firmware authentication, the ROM validates the vendor public keys provided in the firmware payload. These keys, which support ECC, MLDSA, and LMS algorithms, are individually hashed and compared against stored fuse values (e.g., `CPTRA_CORE_VENDOR_PK_HASH_n`). Once a valid key is identified, the ROM locks that specific public key hash and all higher-order public key hash entries for the remainder of the current boot. This ensures that the validated key’s fuse entry remains immutable until the next subsystem reset (warm or cold) re-runs the boot flow. Importantly, the locking mechanism is applied only to the public key hashes. The associated revocation bits, which allow for runtime key revocation, remain unlocked. To support this, the fuse controller (FC) implements two distinct partitions:
	615	+
	616	+1. PK Hash Partition
	617	+ - Purpose:
437	618	- Contains the `CPTRA_CORE_VENDOR_PK_HASH[i]` registers for i ranging from 1 to N.
438		- - Once a key is validated, the corresponding hash and all higher-order hashes are locked by MCU ROM, making them immutable until a cold reset.
439		- - Layout & Details:
440		- - Partition Items: `CPTRA_CORE_VENDOR_PK_HASH[i]` where i ranges from 1 to N.
441		- - Default N: 1
442		- - Maximum N: 16
443		- - Size: N × 384 bits (each hash is 384-bit)
444		- - Programming:
445		- - The first key (i=1) is programmed during the manufacturing phase.
	619	+ - Once a key is validated, the corresponding hash and all higher-order hashes are locked by MCU ROM via the volatile lock CSR, making them immutable for the rest of the current boot. The lock clears on any subsystem reset (warm or cold), at which point the FC re-runs OTP init and ROM re-validates.
	620	+ - Layout & Details:
	621	+ - Partition Items: `CPTRA_CORE_VENDOR_PK_HASH[i]` where i ranges from 1 to N.
	622	+ - Default N: 1
	623	+ - Maximum N: 16
	624	+ - Size: N × 384 bits (each hash is 384-bit)
	625	+ - Programming:
	626	+ - The first key (i=1) is programmed during the manufacturing phase.
446	627	- The remaining keys (if any, i.e., N–1) can be programmed during manufacturing or in the field (production).
447	628	- Partition Item:
448	629	- `CPTRA_CORE_VENDOR_PK_HASH_VALID` is used to indicate which of the N keys is valid. Therefore, the length is N to support N-bit hot-encoding.
449		-
450		-2. PK Hash Revocation Partition
451		- - Purpose:
	630	+
	631	+2. PK Hash Revocation Partition
	632	+ - Purpose:
452	633	This partition stores runtime-updateable revocation bits and PQC type information.
453		- - Layout & Details:
454		- - For each vendor public key (`VENDOR_PK_HASH[i]`), the partition contains:
455		- - ECC Revocation Bits: 4 bits (e.g., `CPTRA_CORE_ECC_REVOCATION[i]`)
456		- - LMS Revocation Bits: 32 bits (e.g., `CPTRA_CORE_LMS_REVOCATION[i]`)
457		- - MLDSA Revocation Bits: 4 bits (e.g., `CPTRA_CORE_MLDSA_REVOCATION[i]`)
	634	+ - Layout & Details:
	635	+ - For each vendor public key (`VENDOR_PK_HASH[i]`), the partition contains:
	636	+ - ECC Revocation Bits: 4 bits (e.g., `CPTRA_CORE_ECC_REVOCATION[i]`)
	637	+ - LMS Revocation Bits: 32 bits (e.g., `CPTRA_CORE_LMS_REVOCATION[i]`)
	638	+ - MLDSA Revocation Bits: 4 bits (e.g., `CPTRA_CORE_MLDSA_REVOCATION[i]`)
458	639	- PQC Key Type Bits: 1-bit one-hot encoded selection (e.g., `CPTRA_CORE_PQC_KEY_TYPE[i]`)
459		- - Attributes:
	640	+ - Attributes:
460	641	- This partition is kept separate from the PK hash partition to allow for runtime updates even after the validated public key is locked.
461		-3. Volatile Locking Mechanism
462		- - To ensure that the validated public key remains immutable once selected, the FC uses a volatile lock mechanism implemented via the new register `otp_ctrl.VENDOR_PK_HASH_LOCK`.
463		- - Once the ROM determines the valid public key (e.g., the 3rd key is selected), it locks the corresponding fuse entries in the PK hash partition.
464		- - The lock is applied by writing a specific value to `otp_ctrl.VENDOR_PK_HASH_LOCK`.
	642	+3. Volatile Locking Mechanism
	643	+
	644	+ - The FC implements volatile write locks with sticky W1S CSRs. Each lock bit is effectively write-once per boot: writing a 1 sets the selected lock bit; writing 0 cannot clear an already-set bit. Once set, the bit remains set for the rest of the current boot and clears on the next subsystem reset (warm or cold), at which point the FC re-runs OTP init.
	645	+ - `MANUF_PK_HASH_VOLATILE_LOCK` bit 0 locks `CPTRA_CORE_VENDOR_PK_HASH_0` and `CPTRA_CORE_PQC_KEY_TYPE_0` in `VENDOR_HASHES_MANUF_PARTITION`. This is a volatile-only manufacturing safety lock; lifecycle state already prevents MANUF partition writes after manufacturing closure.
	646	+ - `VENDOR_PK_HASH_VOLATILE_LOCK` bit i locks production vendor hash i+1 (`CPTRA_CORE_VENDOR_PK_HASH_1` through `CPTRA_CORE_VENDOR_PK_HASH_N`) and the associated PQC key type entry.
	647	+ - If OCP L.O.C.K. ratchet seed partitions are enabled by the integrator, `RATCHET_SEED_VOLATILE_LOCK` bit i locks ratchet seed partition `CPTRA_SS_LOCK_HEK_PROD_i`. The CSR is a fixed 32-bit W1S register and is always present in the SoC address map regardless of `num_ratchet_seed_partitions`, but only the first `num_ratchet_seed_partitions` bits carry semantic meaning; bits beyond that index are reserved/RAZ. When `num_ratchet_seed_partitions == 0` the CSR remains accessible for SW ABI stability but never gates a partition.
	648	+ - These fields are bit masks with one bit per lock target; they are not threshold or ordinal encodings.
465	649	- Example:
	650	+
466	651	```c
467		- // Lock the 3rd vendor public key hash and all higher order key hashes
468		- write_register(otp_ctrl.VENDOR_PK_HASH_LOCK, 0xFFF2);
	652	+ // Lock CPTRA_CORE_VENDOR_PK_HASH_3 and its associated PQC key type.
	653	+ write_register(otp_ctrl.VENDOR_PK_HASH_VOLATILE_LOCK, 1u << 2);
469	654	// This operation disables any further write updates to the validated public key fuse region.
470	655	```
	656	+
471	657	- The ROM polls the [`STATUS`](../src/fuse_ctrl/doc/registers.md#status) register until the Direct Access Interface (DAI) returns to idle, confirming the completion of the lock operation. If any errors occur, appropriate error recovery measures are initiated.
472	658	- Once locked, the PK hash partition cannot be modified, ensuring that the validated public key remains unchanged, thereby preserving the secure boot chain.
473		- - If there needs to be update or programming sequence in PK_HASH set, it needs to be in ROM execution time based on a valid request. Therefore, requires cold-reset.
	659	+ - If there needs to be update or programming sequence in PK_HASH set, it needs to be in ROM execution time based on a valid request, which requires a subsystem reset (warm or cold) to clear the volatile lock and re-enter ROM.
474	660	- The PK hash revocation partition remains unlocked. This design allows the chip owner to update revocation bits and PQC type settings at runtime, enabling the dynamic revocation of keys without affecting the locked public key.
475	661
476	662	---
@@ -479,57 +665,71 @@
479	665
480	666	Once partitions are locked, the hardware integrity checker performs two primary integrity checks to ensure the consistency of the volatile buffer registers:
481	667
482		-1. ECC Protection:
	668	+1. ECC Protection:
483	669	- All buffered partitions include additional ECC protection (8-bit ECC for each 64-bit block), which is monitored concurrently.
484	670
485		-2. Digest Verification:
	671	+2. Digest Verification:
486	672	- The digest of each partition is recomputed at semi-random intervals and compared to the digest stored alongside the partition.
487	673
488	674	### Purpose
	675	+
489	676	These integrity checks verify whether the contents of the buffer registers remain consistent with the calculated digest. They do not verify the consistency between storage flops and the FUSE.
490	677
491		-## Zeroization Flow for Secret FUSEs
492		-
493		-The secret FUSE partitions are zeroized when the Caliptra-SS Life Cycle Controller (LCC) enters the SCRAP state. However, due to lifecycle constraints, the zeroization process requires a transient condition before the system reaches the SCRAP state.
494		-
495		-### Conditions for Zeroization
496		-
497		-Zeroization occurs under the following conditions:
498		-
499		-1. Persistent Condition:
500		- - The Life Cycle Controller (LCC) must be in the SCRAP state.
501		- - This transition to SCRAP occurs only after a cold reset followed by SCRAP state transition request.
502		-
503		-2. Transient Condition (Before Cold Reset):
504		- - The `cptra_ss_FIPS_ZEROIZATION_PPD_i` GPIO pin must be asserted high.
505		- - MCU ROM support is needed.
506		-
507		-### Zeroization Process
508		-
509		-1. A new input port, `cptra_ss_FIPS_ZEROIZATION_PPD_i`, is introduced in the Caliptra Subsystem. SoC integrator needs to connect this signal to MCI generic input wires (see [MCI Generic Input Allocation](./CaliptraSSIntegrationSpecification.md#mci-integration-requirements)).
510		-2. When this signal is asserted, it triggers preemptive zeroization of secret FUSEs before the SCRAP state transition.
511		-3. The MCU ROM samples `cptra_ss_FIPS_ZEROIZATION_PPD_i` by reading the corresponding register storing its value.
512		-4. If `cptra_ss_FIPS_ZEROIZATION_PPD_i == HIGH`, the MCU ROM executes a Life Cycle Controller (LCC) transition request to switch to the SCRAP state.
513		-
514		-- Note: The LCC state transition to SCRAP is completed only after a cold reset.
515		-
516		-
517		-### Cold Reset and Final Zeroization
518		-
519		-- The system remains in a transient zeroization state managed by:
520		- - `cptra_ss_FIPS_ZEROIZATION_PPD_i`
521		- - `ss_soc_MCU_ROM_zeroization_mask_reg`
522		-- After the cold reset, the LCC enters SCRAP state.
523		-- All secret FUSEs are permanently zeroized as a direct result of the SCRAP state transition.
524		-
525	678	---
526	679
	680	+## Debug Intent Secret Zeroization
	681	+
	682	+As a defense-in-depth enhancement, the Fuse Controller hides the hardware digests of provisioned secret partitions from software while debug intent is asserted.
	683	+
	684	+### Effective debug intent
	685	+
	686	+MCI forms the centralized debug-intent signal distributed across the Caliptra Subsystem (including the Fuse Controller) as the logical OR of two sources:
	687	+
	688	+- The physical debug-intent strap, captured once during the cold-boot reset window into the `SS_DEBUG_INTENT` register.
	689	+- The `SS_DEBUG_INTENT_MCU` register — a write-1-set (W1S) bit that MCU ROM (or the SoC Config Agent) may set over AXI, but only before `SS_CONFIG_DONE_STICKY` is set. It is retained across warm reset and cleared only on cold reset, and once set it cannot be cleared by software (a write of 0 has no effect). This lets the MCU assert debug intent from a register write instead of relying solely on the GPIO strap.
	690	+
	691	+The physical strap is sampled before the Fuse Controller initializes, so partitions are never sensed when the strap drives debug intent. `SS_DEBUG_INTENT_MCU` can be set by MCU ROM after the Fuse Controller has already sensed the partitions; in that case the buffers already hold the provisioned values, but the digest-read masking below still prevents software from reading the real digests.
	692	+
	693	+### Secret hardware-digest read masking
	694	+
	695	+While debug intent is asserted, every secret partition that carries a hardware digest — including `SECRET_LC_TRANSITION_PARTITION` — hides its digest from software:
	696	+
	697	+- The named digest CSR returns only a provisioned indicator: all-ones when the sensed digest is non-zero (provisioned), or zero when the sensed digest is zero (unprovisioned, or flushed by the zeroization below). The real digest value is never returned.
	698	+- The Direct Access Interface (DAI) hardware-digest read returns zero.
	699	+
	700	+### Secret partition zeroization
	701	+
	702	+In addition, when debug intent is asserted before Fuse Controller initialization (i.e., driven by the physical strap before sensing), every secret partition that carries a hardware digest except `SECRET_LC_TRANSITION_PARTITION` is flushed:
	703	+
	704	+- The partition is not sensed into its buffer registers; the buffer contents stay at their reset value (zero).
	705	+- The PRESENT scrambler key used to descramble the partition is forced to zero, so no `RndCnstKey`-derived value is latched into the scrambler key state.
	706	+- The background integrity and consistency checks are acknowledged without accessing the fuse macro, so they neither run nor fail for these partitions.
	707	+- Because the buffer stays zero, the digest-read masking above returns zero for these partitions.
	708	+
	709	+`SECRET_LC_TRANSITION_PARTITION` is intentionally excluded from the zeroization (buffer flush) so that the Life Cycle Controller (LCC) can still perform conditional state transitions while debug intent is asserted:
	710	+
	711	+- The partition is sensed and descrambled with its real key, and its tokens are broadcast to the LCC.
	712	+- Its background integrity and consistency checks run normally.
	713	+- The tokens are stored only as cSHAKE128 hashes rather than raw secrets, and the partition stays read-locked, so its raw contents are not exposed. Its hardware digest is still masked as described above — all-ones on the named digest CSR (because the partition is sensed and provisioned) and zero on the DAI read — so the real digest is not exposed.
	714	+
	715	+- A secret partition's data field (as opposed to its digest field) is never readable by software regardless of this digest hardening: the secret data is broadcast only over a dedicated port and has no software read path.
	716	+
	717	+### `SECRET_DIGEST_READ_LOCK`
	718	+
	719	+Independently of debug intent, the Fuse Controller provides the `SECRET_DIGEST_READ_LOCK` CSR — a write-1-set (W1S) lock (a write of 0 has no effect). When set, it applies the same secret hardware-digest read masking described above (provisioned indicator on the named digest CSR, zero on the DAI read) to every secret partition that carries a hardware digest, without flushing the buffers or otherwise altering partition sensing. This lets software hide the secret digests on demand even when debug intent is not asserted.
	720	+
	721	+This enhancement protects the secrets provisioned in the manufacturing and production states. It is an additional layer of defense and does not remove the scan-path exclusion requirements described in the [Integration Specification](CaliptraSSIntegrationSpecification.md).
	722	+
	723	+---
	724	+
527	725	## Notes
528		-- Zeroization of Secret Partitions:
	726	+
	727	+- Zeroization of Secret Partitions:
529	728	Secret partitions are temporarily zeroized when Caliptra-SS enters debug mode to ensure security.
530		-- Locking Requirement:
	729	+- Debug Intent and Secret Partitions: See [Debug Intent Secret Zeroization](#debug-intent-secret-zeroization).
	730	+- Locking Requirement:
531	731	After the device finishes provisioning and transitions into production, partitions that no longer require updates should be locked to prevent unauthorized modifications.
532		-- Further Information:
	732	+- Further Information:
533	733	For more information about the conditional states, please refer to [OpenTitan open-source silicon Root of Trust (RoT) project](https://opentitan.org/book/hw/ip/lc_ctrl/doc/theory_of_operation.html).
534	734
535	735	## General Guidance
@@ -545,11 +745,14 @@
545	745	OTP words cannot be programmed twice, and doing so may damage the memory array.
546	746	Hence the OTP controller performs a blank check and returns an error if a write operation is issued to an already programmed location.
547	747
548		-
549	748	# Caliptra Subsystem Life Cycle Controller
	749	+
550	750	It is an overview of the architecture of the Life-Cycle Controller (LCC) Module for its use in the Caliptra Subsystem. The LCC is responsible for managing the life-cycle states of the system, ensuring secure transitions between states, and enforcing security policies.
551	751
552	752	## Caliptra Subsystem, SOC Debug Architecture Interaction
	753	+
	754	+Note — sources of debug intent: Throughout this section, "debug intent" refers to the effective debug-intent signal that MCI distributes across the Caliptra Subsystem, not to the physical strap alone. As described in [Effective debug intent](#effective-debug-intent), this signal is the logical OR of the physical `DEBUG_INTENT_STRAP` (captured once during the cold-boot reset window into the `SS_DEBUG_INTENT` register) and the MCU-writable `SS_DEBUG_INTENT_MCU` register (a W1S bit settable only before `SS_CONFIG_DONE_STICKY`). The strap is therefore not the only way to assert debug intent; the MCU can also assert it through `SS_DEBUG_INTENT_MCU`. The two sources also differ in how they affect the secret digest CSRs: because the physical strap suppresses fuse-macro sensing entirely (the secret partitions are never read into their buffers), their named digest CSRs always read back as zero and can never return the all-ones provisioned indicator, whereas `SS_DEBUG_INTENT_MCU` (like `SECRET_DIGEST_READ_LOCK`) masks the digests only after the partitions have already been sensed, so the CSR still reflects whether each digest field is provisioned (all-ones) or unprovisioned (zero).
	755	+
553	756	Figure below shows the Debug Architecture of the Caliptra Subsystem and some important high-level signals routed towards SOC. The table in Key Components and Interfaces section shows all the signals that are available to SOC (outside of Caliptra Subsystem usage).
554	757
555	758	Figure: Caliptra Subsystem & SOC Debug Architecture Interaction
@@ -572,15 +775,14 @@
572	775	\| TEST_UNLOCKED{N} \| FUSE \| Transition from RAW state using token stored in FUSE. This state is used for manufacturing and production testing. During this state: CLTAP (chip level TAPs) is enabled; Debug functions are enabled; DFT functions are enabled. It is expected that LCC tokens will be provisioned into FUSE during these states. Once provisioned, these tokens are no longer readable by software. \|
573	776	\| MANUF \| FUSE \| Transition from TEST_UNLOCKED state using token stored in FUSE. This is a mutually exclusive state to PROD and PROD_END. To enter this state, MANUF_TOKEN is required. This state is used for developing provisioning and mission mode. In this state, UDS and Field Entropy FUSE partitions can be provisioned. During this state: CLTAP (chip level TAPs) is enabled; Debug functions are enabled; DFT functions are disabled \|
574	777	\| PROD \| FUSE \| Transition from MANUF state using token stored in FUSE. PROD is a mutually exclusive state to MANUF and PROD_END. To enter this state, PROD_TOKEN is required. This state is used both for provisioning and mission mode. During this state: CLTAP is disabled; Debug functions are disabled; DFT functions are disabled; Caliptra Subsytem can grant SoC debug unlock flow if the conditions provided in “SoC Debug Flow and Architecture for Production Mode” section are satisfied. SoC debug unlock overwrites the signals and gives the following cases: CLTAP is enabled; Debug functions are enabled based on the defined debug policy; DFT is enabled but this DFT enable is called SOC_DFT_EN, which has less capabilities than DFT_EN granted in TEST_UNLOCKED. \|
575		-\| PROD_END \| FUSE \| This state is identical in functionality to PROD, except the device is never allowed to transition to RMA state. To enter this state, a PROD_END token is required. It also means that Caliptra-SS cannot enter debug mode anymore. Only transition to SCRAP mode is allowed. \|
	778	+\| PROD_END \| FUSE \| This state is identical in functionality to PROD, except the device is never allowed to transition to RMA state. To enter this state, a PROD_END token is required. Only transition to SCRAP mode is allowed. \|
576	779	\| RMA \| FUSE \| Transition from TEST_UNLOCKED / PROD / MANUF using token stored in FUSE. It is not possible to reach this state from PROD_END. If the RMA transition is requested, the request must follow the asserted RMA PPD pin. Without this pin, RMA request is discarded. See `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` in [Caliptra Subsystem Integration Specification Document](CaliptraSSIntegrationSpecification.md). When transitioning from PROD or MANUF, an RMA_UNLOCK token is required. When transitioning from TEST_UNLOCKED, no RMA_UNLOCK token is required. During this state: CLTAP is enabled; Debug functions are enabled; DFT functions are enabled \|
577	780	\| SCRAP \| FUSE \| Transition from any state. If the SCRAP transition is requested, the request must follow the asserted SCRAP PPD pin. Without this pin, SCRAP request is discarded. See `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` in [Caliptra Subsystem Integration Specification Document](CaliptraSSIntegrationSpecification.md). During SCRAP state the device is completely dead. All functions, including CPU execution are disabled. The only exception is the TAP of the life cycle controller which is always accessible so that the device state can be read out. No owner consent is required to transition to SCRAP. Note also, SCRAP is meant as an EOL manufacturing state. Transition to this state is always purposeful and persistent, it is NOT part of the device’s native security countermeasure to transition to this state. \|
578	781	\| INVALID \| FUSE \| Invalid is any combination of FUSE values that do not fall in the categories above. It is the “default” state of life cycle when no other conditions match. Functionally, INVALID is identical to SCRAP in that no functions are allowed and no transitions are allowed. A user is not able to explicitly transition into INVALID (unlike SCRAP), instead, INVALID is meant to cover in-field corruptions, failures or active attacks. \|
579	782
580	783
581	784	Note
582		-* The LCC performs state transitions in a forward-only manner. It begins in the RAW state and follows the sequence: TEST_UNLOCKED and TEST_LOCKED, then MANUF, then PROD, and finally either PROD_END or RMA. After transitioning to TEST_UNLOCKED, the LCC can branch to any of the following states: MANUF, PROD, PROD_END, or RMA. However, once the LCC transitions to PROD, PROD_END, or RMA, it cannot return to the MANUF state. Additionally, note that the LCC cannot branch to RMA from PROD_END.
583		-
	785	+- The LCC performs state transitions in a forward-only manner. It begins in the RAW state and follows the sequence: TEST_UNLOCKED and TEST_LOCKED, then MANUF, then PROD, and finally either PROD_END or RMA. After transitioning to TEST_UNLOCKED, the LCC can branch to any of the following states: MANUF, PROD, PROD_END, or RMA. However, once the LCC transitions to PROD, PROD_END, or RMA, it cannot return to the MANUF state. Additionally, note that the LCC cannot branch to RMA from PROD_END.
584	786
585	787	## DFT & DFD Life-cycle States
586	788
@@ -595,32 +797,33 @@
595	797
596	798	In the manufacturing phase, the Caliptra Subsystem asserts SOC_HW_DEBUG_EN high, with the signal being controlled by the LCC. In PROD mode, this signal is low. However, the SoC integrator has the flexibility to enable CLTAP during production debug mode by incorporating additional logic, such as an OR gate, to override the SOC_HW_DEBUG_EN signal, like DFT_EN. This architecture provides a mask register that allows SoC to program/configure this overriding mechanism at integration time or using MCU ROM. This allows the SoC to maintain control over hardware debug access while preserving the intended security protections in production.
597	799
598		-
599	800	Table: LCC State and State Decoder output ports
	801	+
600	802	## LCC State and State Decoder Output Ports
	803	+
601	804	\| LCC State\Decoder Output \| DFT_EN \| SOC_DFT_EN \| SOC_HW_DEBUG_EN \|
602	805	\| :--------- \| :--------- \| :--------- \| :--------- \|
603	806	\| RAW \| Low \| Low \| Low \|
604	807	\| TEST_LOCKED \| Low \| Low \| Low \|
605	808	\| TEST_UNLOCKED \| High \| High \| High \|
606		-\| MANUF* \| Low \| Low \| High \|
	809	+\| MANUF* \| Low \| TOKEN - CONDITIONED** \| High \|
607	810	\| PROD* \| Low \| TOKEN - CONDITIONED \| TOKEN - CONDITIONED \|
608	811	\| PROD_END \| Low \| Low \| Low \|
	812	+\| PROD_END* \| Low \| TOKEN - CONDITIONED \| TOKEN - CONDITIONED \|
609	813	\| RMA \| High*** \| High \| High \|
610	814	\| SCRAP \| Low \| Low \| Low \|
611	815	\| INVALID \| Low \| Low \| Low \|
612	816	\| POST_TRANSITION \| Low \| Low \| Low \|
613	817
614	818
615		-
616		-
617		-*: Caliptra can enter debug mode and update these signals even though LCC is in MANUF or PROD states. This case is explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”.
	819	+*: Caliptra can enter debug mode and update these signals even though LCC is in MANUF or PROD, PROD_END states. This case is explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”.
618	820
619	821	**: SOC_DFT_EN and SOC_HW_DEBUG_EN can be high if Caliptra SS grants debug mode (either manufacturing or production). This case is explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”. SOC_HW_DEBUG_EN is set high to open CLTAP and SOC_DFT_EN enables DFT by SoC design support. However, this condition also needs to go through the flow described in “SoC Debug Flow and Architecture for Production Mode”. Caliptra Subsystem state should be set to either the manufacturing mode debug unlock or Level 0 of the production debug unlock.
620	822
621		-***: RMA state enables DFT_EN but Caliptra Core enters the debug mode when LCC enters RMA state. Thus, Caliptra Core clears UDS and Field Entropy secrets.
	823	+***: RMA state enables DFT_EN but Caliptra Core enters the debug mode when LCC enters RMA state. Thus, Caliptra Core clears UDS and Field Entropy secrets.
622	824
623	825	## TAP Pin Muxing
	826	+
624	827	The LCC includes a TAP interface, which operates on its own dedicated clock and is used for injecting tokens into the LCC. Notably, the LCC TAP interface remains accessible in all life cycle states, providing a consistent entry point for test and debug operations. This TAP interface can be driven by either the TAP GPIO pins or internal chip-level wires, depending on the system's current configuration.
625	828
626	829	Figure: Caliptra Subsystem Life Cycle Controller Summary
@@ -629,14 +832,13 @@
629	832
630	833	SOC logic incorporates the TAP pin muxing to provide the integration support and manage the connection between the TAP GPIO pins and the Chip-Level TAP (CLTAP). As illustrated in figure above, this muxing logic determines the source that drives the LCC TAP interface. The selection between these two sources is controlled by the SOC_HW_DEBUG_EN signal. When SOC_HW_DEBUG_EN is set to high, control is handed over to the CLTAP, allowing for chip-level debug access through the TAP GPIO pins. Conversely, when SOC_HW_DEBUG_EN is low, the TAP GPIO pins take control, enabling external access to the LCC TAP interface.
631	834
632		-[LCC State and State Decoder Output Ports Table](#lcc-state-and-state-decoder-output-ports) outlines the specific LCC states that enable the SOC_HW_DEBUG_EN signal. These states include TEST_UNLOCK, MANUF, PROD (debug unlocked version only), and RMA. In these states, the LCC allows internal chip-level debug access via CLTAP, thereby facilitating advanced debugging capabilities. This muxing approach ensures that the TAP interface is appropriately secured, and that access is granted only under specific conditions, aligning with the overall security and functional requirements of the Caliptra Subsystem.
	835	+[LCC State and State Decoder Output Ports Table](#lcc-state-and-state-decoder-output-ports) outlines the specific LCC states that enable the SOC_HW_DEBUG_EN signal. These states include TEST_UNLOCK, MANUF, PROD (debug unlocked version only), and RMA. In these states, the LCC allows internal chip-level debug access via CLTAP, thereby facilitating advanced debugging capabilities. This muxing approach ensures that the TAP interface is appropriately secured, and that access is granted only under specific conditions, aligning with the overall security and functional requirements of the Caliptra Subsystem.
633	836	Note: It is important to note that CLTAP provides access to the TAP interfaces of the LCC, MCU, or Caliptra Core. This functionality is managed by SoC logic, not by Caliptra-SS. Consequently, the SoC integration effort should ideally include an additional mux after CTAP to route the connection to one of the following: the LCC TAP, MCU TAP, or Caliptra Core TAP.
634	837
635	838	TAP pin muxing also enables routing to Caliptra TAP. This selection happens when DEBUG_INTENT_STRAP is high. This selection is done through the GPIO and indicates that Caliptra will enter debug mode if the secret tokens are provided. Caliptra Subsystem has two debug modes: manufacturing debug and production debug. Entering these debug flows are explained in the following sections:
636		-**[How does Caliptra Subsystem enable manufacturing debug mode?](#how-does-caliptra-subsystem-enable-manufacturing-debug-mode),
	839	+**[How does Caliptra Subsystem enable manufacturing debug mode?](#how-does-caliptra-subsystem-enable-manufacturing-debug-mode),
637	840	[SoC Debug Flow and Architecture for Production Mode](#soc-debug-flow-and-architecture-for-production-mode) and
638	841	[Masking Logic for Debugging Features in Production Debug Mode](#masking-logic-for-debugging-features-in-production-debug-mode)**
639		-
640	842
641	843	Note: The Caliptra TAP can run exact flow with AXI, targeting the mailbox and SOC provides that interface to platform.
642	844
@@ -648,7 +850,7 @@
648	850	![](../images/caliptra-ss/docs/images/Manuf-Debug-LifeCycle.png)
649	851	Note: The flow diagram on the right side shows the LCC states (grey boxes) and their transitions, while the flow diagram on the left illustrates Caliptra SS’s enhancements to the LCC for the manufacturing phase. Specifically, the flow on the left depicts the routine for entering manufacturing debug mode.
650	852
651		-#### Flow Explanation:
	853	+#### Flow Explanation
652	854
653	855	1. (Platform) Assert BootFSMBrk : Temporarily halting the Caliptra HW bootfsm boot process to allow for secure operations like token injection and verification.
654	856	2. (Platform) Assert DEBUG_INTENT_STRAP: If Caliptra core HW samples this pin as high and sees that LCC is in MANUF mode, it prepares itself for entering debug mode. Once the DEBUG_INTENT_STRAP is detected, Caliptra HW immediately wipes out its secret assets, including the Unique Device Secret (UDS) and Field entropy, ensuring that no sensitive data remains accessible. If this Pin is not high, Caliptra continues always in non-debug mode without taking any further action listed with the following states.
@@ -666,20 +868,24 @@
666	868
667	869	The Caliptra Subsystem includes SoC debugger logic that supports Caliptra’s production debug mode. This debugger logic extends the capabilities of the Lifecycle Controller (LCC) by providing a production debug mode architecture that the LCC does not inherently support, except in the RMA state. This architecture manages the initiation and handling of the production debug mode separately from the LCC's lifecycle states.
668	870
669		-The process of enabling production debug mode begins when the DEBUG_INTENT_STRAP pin is asserted high via the SoC’s GPIO. This pin signals Caliptra to start the debug mode when the LCC is in the PROD state. Before the debug unlock flow, the MCU reads all hashed public keys from the fuse macros and writes them to the `SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK` registers. Additionally, the MCU sets the number of public keys used for production debug unlock by writing to the `SS_NUM_OF_PROD_DEBUG_UNLOCK_AUTH_PK_HASHES` register. The value `DEBUG_AUTH_PK_HASH_REG_BANK_OFFSET` represents an address offset, while `NUM_OF_DEBUG_AUTH_PK_HASHES` defines how many public keys are available for reading. These two values establish the debug policy depth for different debugging levels.
	871	+The process of enabling production debug mode begins when the DEBUG_INTENT_STRAP pin is asserted high via the SoC’s GPIO. This pin signals Caliptra to start the debug mode when the LCC is in the PROD and PROD_END states. Before the debug unlock flow, the MCU reads all hashed public keys from the fuse macros and writes them to the `SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK` registers. Additionally, the MCU sets the number of public keys used for production debug unlock by writing to the `SS_NUM_OF_PROD_DEBUG_UNLOCK_AUTH_PK_HASHES` register. The value `DEBUG_AUTH_PK_HASH_REG_BANK_OFFSET` represents an address offset, while `NUM_OF_DEBUG_AUTH_PK_HASHES` defines how many public keys are available for reading. These two values establish the debug policy depth for different debugging levels.
670	872
671	873	### Overview of Debug Unlock Initiation
672	874
673	875	The process begins when the platform sets three conditions:
	876	+
674	877	- The `DEBUG_INTENT` field in the `SS_DEBUG_INTENT` register.
675	878	- The `PROD_DEBUG_UNLOCK_REQ` bit in the `SS_DBG_MANUF_SERVICE_REG_REQ` register.
676		-- The `BOOTFSM_GO_ADDR` to allow Caliptra Core to continue its execution.
	879	+- The `CPTRA_BOOT_GO` allows Caliptra Core to continue its execution.
677	880	On reset, the Caliptra ROM checks these two signals. If both are asserted, the ROM begins the production debug unlock process.
678	881	Upon detecting a valid debug intent:
679	882	- Caliptra hardware erases its secret assets, including the Unique Device Secret (UDS) and Field Entropy, before exposing any debug interfaces, ensuring sensitive data is irreversibly destroyed.
680	883	- Caliptra ROM sets the `TAP_MAILBOX_AVAILABLE` and `PROD_DBG_UNLOCK_IN_PROGRESS` bits in the `SS_DBG_MANUF_SERVICE_REG_RSP` register.
681	884
	885	+Note: Similar to the manufacturing debug flow, BootFSMBrk must be asserted to halt Caliptra ROM execution. Otherwise, the ROM may advance past the debug request before `PROD_DEBUG_UNLOCK_REQ` is populated. BootFSMBrk is a prerequisite for entering the debug flow ONLY if Caliptra core ROM needs to be debugged; for run-time injection of prod debug unlock token, setting BootFSMBrk is not required.
	886	+
682	887	### Secure Debug Unlock Protocol
	888	+
683	889	- The production debug unlock flow uses a challenge-response authentication model involving public key verification and hybrid cryptography (ECC and MLDSA). The flow includes the following steps:
684	890	- AUTH_DEBUG_UNLOCK_REQ Command: Caliptra ROM polls the Mailbox interface, awaiting an `AUTH_DEBUG_UNLOCK_REQ` from the platform.
685	891	- The request payload includes:
@@ -701,6 +907,7 @@
701	907	\| Length \| 4 \| Should be 21 DWORDs. \|
702	908	\| Unique Device Identifier \| 32 \| Caliptra device identifier. \|
703	909	\| Challenge \| 48 \| Randomly generated nonce. \|
	910	+
704	911
705	912	- The platform signs the challenge data and sends an `AUTH_DEBUG_UNLOCK_TOKEN`:
706	913
@@ -716,22 +923,26 @@
716	923	\| ECC Signature \| 96 \| Signature of challenge message. \|
717	924	\| MLDSA Signature \| 4628 \| Signature of challenge message. \|
718	925
719		-- Finally, Caliptra ROM reads the expected SHA2-384 public key hash from the corresponding register by using the following equation:
	926	+
	927	+- Finally, Caliptra ROM reads the expected SHA2-384 public key hash from the corresponding register by using the following equation:
720	928	- SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET + ((Unlock Level - 1) * 48 bytes)
721	929	- If hash of `AUTH_DEBUG_UNLOCK_CHALLENGE`'s MLDSA and ECC public keys match with the read value from `SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET`, ROM uses these MLDSA and ECC public keys to perform the authentication.
722		-- Upon successful validation:
	930	+- Upon successful validation:
723	931	- Sets the `PROD_DBG_UNLOCK_SUCCESS` bit.
724	932	- Writes the `CALIPTRA_SS_SOC_DEBUG_UNLOCK_LEVEL` register granted debug level with a one-hot encoding result (1 << (Unlock Level - 1)).
725	933	- Clears the `TAP_MAILBOX_AVAILABLE` bit.
726	934	- Clears the `PROD_DBG_UNLOCK_IN_PROGRESS` bit.
727	935	- Exits the debug unlock process.
728	936
729		-
730	937	Granting Production Debug Mode:
731		-* If authentication succeeds, Caliptra ROM does not immediately grant full production debug mode. Instead, the ROM sets the appropriate "debug level" signal, which corresponds to the type of debug access being requested.
732		-* Caliptra ROM writes CALIPTRA_SS_SOC_DEBUG_UNLOCK_LEVEL register, which will be wired to the specific debug enable signal. This signal is part of an N-wide signal that is mapped to the payload encoding received during the debug request. N is defined by NUM_OF_ DEBUG_AUTH_PK_HASHES. The default version of N is 8. The payload encoding can either be one-hot encoded or a general encoded format, and this signal is passed to the SoC to allow it to make the final decision about the level of debug access that should be granted. In Caliptra’s subsystem-specific implementation, the logic is configured to handle one-hot encoding for these 8 bits. The level 0 bit is routed to both Caliptra and the MCU TAP interface, allowing them to unlock based on this level of debug access. This granular approach ensures that the system can selectively unlock different levels of debugging capability, depending on the payload and the authorization level provided by the debugger.
	938	+- If authentication succeeds, Caliptra ROM does not immediately grant full production debug mode. Instead, the ROM sets the appropriate "debug level" signal, which corresponds to the type of debug access being requested.
	939	+- Caliptra ROM writes CALIPTRA_SS_SOC_DEBUG_UNLOCK_LEVEL register, which will be wired to the specific debug enable signal. This signal is part of an N-wide signal that is mapped to the payload encoding received during the debug request. N is defined by NUM_OF_DEBUG_AUTH_PK_HASHES. The default version of N is 8. The payload encoding can either be one-hot encoded or a general encoded format, and this signal is passed to the SoC to allow it to make the final decision about the level of debug access that should be granted. In Caliptra’s subsystem-specific implementation, the logic is configured to handle one-hot encoding for these 8 bits. The level 0 bit is routed to both Caliptra and the MCU TAP interface, allowing them to unlock based on this level of debug access. This granular approach ensures that the system can selectively unlock different levels of debugging capability, depending on the payload and the authorization level provided by the debugger.
	940	+
	941	+Granting Production Debug Mode with Caliptra Runtime FW:
	942	+Although the flow above describes ROM-based authentication, the same challenge–response mechanism may be executed by Caliptra Runtime Firmware. In this case, RT FW performs the challenge-response authentication steps via mailbox commands, which will be used to update the debug unlock level. The DEBUG_INTENT_STRAP must still be asserted high before Caliptra subsystem is out of reset. This ensures that even RT-based debug enablement remains gated by hardware intent and cannot be triggered purely through software.
733	943
734	944	## Masking Logic for Debugging Features in Production Debug Mode (MCI)
	945	+
735	946	In the production debug mode, the SoC can enable certain debugging features—such as DFT_EN and SOC_HW_DEBUG_EN—using a masking mechanism implemented within the Manufacturer Control Interface (MCI). This masking infrastructure allows the SoC to selectively control debug features that are normally gated by Caliptra’s internal signals. The masking logic functions as a set of registers, implemented in the MCI, that can be written by the SoC to override or enable specific debugging functionalities in production debug mode.
736	947	The masking registers in the MCI act as an OR gate with the existing debug signals. For instance, if DFT_EN is controlled by Caliptra, the SoC can assert the corresponding mask register to enable Design for Test (DFT) capabilities in the SoC, even if Caliptra has not explicitly enabled it. Similarly, the SOC_HW_DEBUG_EN signal can be masked through the MCI registers, giving the SoC the flexibility to unlock TAP interfaces and provide the required debugging in production.
737	948
@@ -740,6 +951,7 @@
740	951
741	952	This mechanism is only authorized when both the LCC and Caliptra core are in the PROD state and operating in production debug mode. The masking logic ensures that these features are enabled securely, in line with the production debug flow described in the "SoC Debug Flow and Architecture for Production Mode" section. By leveraging the MCI’s masking infrastructure, the SoC integrator has greater flexibility to implement custom debugging options during production without compromising the security framework established by Caliptra.
742	953
	954	+**Note: Unlike the production state, the manufacturing state supports only a single debug level. Although it uses the same masking register to override DFT_EN, only the register’s least significant bit is used in manufacturing debug mode.
743	955
744	956	## LCC Interpretation for Caliptra “Core” Security States
745	957
@@ -757,11 +969,11 @@
757	969
758	970	Manufacturing Non-Debug Mode: This state occurs when the LCC is in the MANUF state, with SOC_HW_DEBUG_EN high and DFT_EN and SOC_DFT_EN low. In this state, the secrets have been programmed into the system, and the Caliptra can generate CSR (Certificate Signing Request) upon request. However, it remains in a secure, non-debug mode to prevent reading secrets through the debugging interfaces.
759	971
760		-Manufacturing Debug Mode: Also occurring in the MANUF state, this mode is enabled when SOC_HW_DEBUG_EN is high. Here, the Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. In this state, DFT_EN is low. However, it is important to note that it is up to SoC integrator if there is a need to enable DFT_EN with another set of mask register since LCC state is reflected to SoC.
	972	+Manufacturing Debug Mode: Also occurring in the MANUF state, this mode is enabled when SOC_HW_DEBUG_EN is high. Here, the Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. In this state, DFT_EN is low. However, SOC_DFT_EN can be set high if LSB of `MCI_REG_SOC_DFT_EN_0` is set to high in MANUF debug state [MCI-LCC-Signal-Masking](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#masking-logic-for-debugging-features-in-production-debug-mode-mci).
761	973
762	974	Production Non-Debug Mode: This state is active when the LCC is in the PROD or PROD_END states, with all debug signals (DFT_EN, SOC_HW_DEBUG_EN) set to low. The Caliptra Core operates in a secure mode with no debug access, suitable for fully deployed production environments.
763	975
764		-Production Debug Mode: This state is active when the LCC is in the PROD, with debug DFT_EN, SOC_HW_DEBUG_EN set to low. Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. However, SOC_DFT_EN can be set high and CLTAP can be open if MCI masking logic is used.
	976	+Production Debug Mode: This state is active when the LCC is in the PROD or PROD_END states, with debug DFT_EN, SOC_HW_DEBUG_EN set to low. Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. However, SOC_DFT_EN and SOC_HW_DEBUG_EN can be set high with MCI masking registers [MCI-LCC-Signal-Masking](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#masking-logic-for-debugging-features-in-production-debug-mode-mci).
765	977
766	978	Production Debug Mode in RMA: In the RMA state, all debug signals are set high, allowing full debugging access. This state is typically used for end-of-life scenarios where detailed inspection of the system's operation is required.
767	979
@@ -775,20 +987,22 @@
775	987	\| TEST_LOCKED \| Low \| Low \| Low \| Prod Non-Debug \|
776	988	\| TEST_UNLOCKED \| High \| High \| High \| Unprovisioned Debug \|
777	989	\| MANUF \| Low \| Low \| High \| Manuf Non-Debug \|
778		-\| MANUF* \| Low \| Low \| High \| Manuf Debug \|
	990	+\| MANUF* \| Low \| High** \| High \| Manuf Debug \|
779	991	\| PROD \| Low \| Low \| Low \| Prod Non-Debug \|
780	992	\| PROD* \| Low \| High \| High \| Prod Debug \|
781	993	\| PROD_END \| Low \| Low \| Low \| Prod Non-Debug \|
	994	+\| PROD_END* \| Low \| High \| High \| Prod Debug \|
782	995	\| RMA \| High \| High \| High \| Prod Debug \|
783	996	\| SCRAP \| Low \| Low \| Low \| Prod Non-Debug \|
784	997	\| INVALID \| Low \| Low \| Low \| Prod Non-Debug \|
785	998
786	999
787	1000	Note: In RAW, TEST_LOCKED, SCRAP and INVALID states, Caliptra “Core” is not brought out of reset.
788		-*: These states are Caliptra SS’s extension to LCC. Although the LCC is in either MANUF or PROD states, Caliptra core can grant debug mode through the logics explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”.
789		-**: SOC_HW_DEBUG_EN and DFT_EN can be overridden by SoC support in PROD state.
	1001	+*: These states are Caliptra SS’s extension to LCC. Although the LCC is in either MANUF or PROD, PROD_END states, Caliptra core can grant debug mode through the logics explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”.
	1002	+**: SOC_HW_DEBUG_EN and DFT_EN can be overridden by SoC support in debug mode of MANUF and PROD, PROD_END states.
790	1003
791	1004	## Exception: Non-Volatile Debugging Infrastructure and Initial RAW State Operations
	1005	+
792	1006	The Caliptra Subsystem features a non-volatile debugging infrastructure that allows the SoC integrator to utilize a dedicated SRAM for early-stage debugging during the VolatileUnlock state. This SRAM provides a means to store executable content for the MCU, enabling early manufacturing debug operations.
793	1007
794	1008	It is important to note that the VolatileUnlock state is not a standard LCC state but rather a temporary state. Unlike other LCC states, the LCC can transition to this state without requiring a power cycle, provided the necessary global VolatileUnlock token is passed. This token is unique in that it is not stored in the FUSE partition but is instead a global netlist secret.
@@ -832,11 +1046,10 @@
832	1046	For conditional transitions, the LCC can also branch different states (TEST_UNLOCK, MANUF, PROD, PROD_EN, RMA) based on the received token through the TAP interface and compared the received tokens against the ones stored in FUSE . This branching is called conditional transitions. For more information about the conditional states, please refer to [OpenTitan open-source silicon Root of Trust (RoT) project](https://opentitan.org/book/hw/ip/lc_ctrl/doc/theory_of_operation.html).
833	1047
834	1048	Notes:
835		-* Some tokens are hardcoded design constants (specifically for RAW to TEST_UNLOCK), while others are stored in FUSE.
836		-* Conditional transitions will only be allowed if the FUSE partition holding the corresponding token has been provisioned and locked.
837		-* For transition counter limits and token hashing mechanism, please refer to OpenTitan open-source silicon Root of Trust (RoT) project [1].
838		-* The LCC enters the post transition handling routine after completing conditional and unconditional transitions. During this routine, the LCC disables all of its decoded outputs and puts the system in an inert state.
839		-
	1049	+- Some tokens are hardcoded design constants (specifically for RAW to TEST_UNLOCK), while others are stored in FUSE.
	1050	+- Conditional transitions will only be allowed if the FUSE partition holding the corresponding token has been provisioned and locked.
	1051	+- For transition counter limits and token hashing mechanism, please refer to OpenTitan open-source silicon Root of Trust (RoT) project [1].
	1052	+- The LCC enters the post transition handling routine after completing conditional and unconditional transitions. During this routine, the LCC disables all of its decoded outputs and puts the system in an inert state.
840	1053
841	1054	# Manufacturer Control Unit (MCU)
842	1055
@@ -845,18 +1058,21 @@
845	1058	If the MCU VeeR instance must be regenerated with new configuration, a shell script is available in the Caliptra Subsystem repository. The script is located at `tools/scripts/veer_build_command.sh`.
846	1059
847	1060	# Manufacturer Control Interface (MCI)
	1061	+
848	1062	## Overview
	1063	+
849	1064	The Manufacturer Control Interface (MCI) is a critical hardware block designed to supplement the Manufacturer Control Unit (MCU) within a System on Chip (SoC). The primary functions of the MCI include providing an SRAM bank, facilitating restricted communication through a mailbox from external entities, and managing a bank of Control/Status Registers (CSRs). Additionally, the MCI incorporates a Watchdog Timer and a Boot Sequencing Finite State Machine (FSM) to manage timing and control during the SoC boot sequence after power application. This boot sequence encompasses reset deassertion, initialization of the Fuse Controller, initialization of the Lifecycle Controller, and enabling the JTAG block for debugging and manufacturing processes.
850	1065
851	1066	The following diagram illustrates the internal components of the MCI.
852	1067	![](../images/caliptra-ss/docs/images/MCI-Integ-Block-Diagram.png)
853	1068
854	1069	## MCI Feature Descriptions
	1070	+
855	1071	### Control/Status Registers (CSRs)
	1072	+
856	1073	The Control/Status Registers (CSRs) within the MCI are designed to provide critical control and status monitoring functions for the SoC. These registers include configuration settings, status indicators, and control bits that allow communication and management of the various operations of the MCI. The CSR bank is accessible via the AXI interface and is mapped into the memory space to facilitate straightforward access and manipulation.
857	1074
858	1075	[MCI Reg Spec](https://chipsalliance.github.io/caliptra-ss/main/regs/?p=soc.mci_top.mci_reg)
859		-
860	1076
861	1077	#### MCI CSR Access Restrictions
862	1078
@@ -865,18 +1081,17 @@
865	1081	1. AXI User
866	1082	2. Lock bits (SS_CONFIG_DONE, CAP_LOCK, etc.)
867	1083
868		-The privilaged users for the MCI CSRs are:
	1084	+The privileged users for the MCI CSRs are:
869	1085
870	1086	1. MCU
871	1087	2. MCI SOC Config User (MSCU)
872	1088	3. MCU SRAM Config User (MSRCU)
873	1089
874		-All of these AXI Users come from straps and are not modifiable by SW. MCU is given the highest level of access and is expected to configure MCI registers and lock the configuration with various SS_CONFIG_DONE and LOCK bits. It also has access to certain functionalality like timers that are needed by the SOC but are critical for MCU functionality.
875		-
876		-The MSCU is meant as a secondary config agent if the MCU is unable to configure MCI. Example when in the no ROM config it is expected the MCSCU can configure and lock down the MCI configuration. MSCU can be disabled by setting the strap to 0x0. For debug the MSCU strap can be set to all 1s meaning every access will give this level of privilege.
877		-The MCRCU populates the MCU FW update in MCU SRAM. There are a few registers within the MCI register bank it has special access to for facilitating the FW update.
	1090	+All of these AXI Users come from straps and are not modifiable by SW. MCU is given the highest level of access and is expected to configure MCI registers and lock the configuration with various SS_CONFIG_DONE and LOCK bits. It also has access to certain functionality like timers that are needed by the SOC but are critical for MCU functionality.
	1091	+
	1092	+The MSCU is meant as a secondary config agent if the MCU is unable to configure MCI. Example when in the no ROM config it is expected the MSCU can configure and lock down the MCI configuration. MSCU can be disabled by setting the strap to 0x0. For debug the MSCU strap can be set to all 1s meaning every access will give this level of privilege.
	1093	+The MCRCU populates the MCU FW update in MCU SRAM. There are a few registers within the MCI register bank it has special access to for facilitating the FW update.
878	1094	The registers can be split up into a few different categories:
879		-
880	1095
881	1096	\| Write restrictions \| Description \|
882	1097	\| :--------- \| :--------- \|
@@ -887,14 +1102,13 @@
887	1102	\| Sticky MCU or MSCU and CONFIG locked \| Locked configuration by MCU ROM/MSCU and configured after each cold reset \|
888	1103	\| Locked by SS_CONFIG_DONE_STICKY \| Configuration once per cold reset. \|
889	1104	\| Locked by SS_CONFIG_DONE \| Configuration once per warm reset. \|
890		-\| MCU or MSCU until CAP_LOCK \| Configured by a trusted agent to show HW/FW capabilieds then locked until next warm reset \|
891		-\| MBOX_USER_LOCK \| Mailbox specific configuration locked by it's own LOCK bit. Configured afer each arem reset. \|
892		-
	1105	+\| MCU or MSCU until CAP_LOCK \| Configured by a trusted agent to show HW/FW capabilities then locked until next warm reset \|
	1106	+\| MBOX_USER_LOCK \| Mailbox-specific configuration locked by its own LOCK bit. Configured afer each warm reset. \|
893	1107
894	1108
895	1109	### MCI Straps
896	1110
897		-All MCI straps shall be static before mci_rst_b is deasserted. Some straps have further restrictions as described below.
	1111	+All MCI straps shall be static before mci_rst_b is deasserted. Some straps have further restrictions as described below.
898	1112
899	1113	MCI has the following types of straps:
900	1114
@@ -903,7 +1117,6 @@
903	1117	\| Non-configurable Direct \| Direct \| Used directly by MCI and not sampled at all. These shall be constant non-configurable inputs to CSS/MCI. Inside MCI these are not overridable by SW. \|
904	1118	\| Non-configurable Sampled \| Sampled* \| Sampled once per cold boot and not overridable by SW \|
905	1119	\| Configurable Sampled \| Sampled** \| Sampled once per warm boot and SW can override via MCI Register Bank until SS_CONFIG_DONE is set. \|
906		-
907	1120
908	1121
909	1122	*NOTE: Strap sampling occurs when mci_rst_b is deasserted and is typically performed once per cold boot. This process is controlled by the SS_CONFIG_DONE_STICKY register; when set, sampling is skipped. If a warm reset happens before SS_CONFIG_DONE_STICKY is set, the straps will be sampled again, although this is not the usual behavior.
@@ -917,8 +1130,7 @@
917	1130	\| `strap_mcu_sram_config_axi_user` \| Non-configurable Direct \| MCU SRAM Config agent who is given special access to MCU SRAM Execution region to load FW image. Typically set to Caliptra's AXI User. \|
918	1131	\| `strap_mci_soc_config_axi_user` \| Non-configurable Direct \| MCI SOC Config User (MSCU). AXI agent with MCI configuration access. \|
919	1132	\| `strap_mcu_reset_vector` \| Configurable Sampled \| Default MCU reset vector. \|
920		-\| `ss_debug_intent` \| Non-configurable Sampled \| Provides some debug access to MCI. Show the intent to put the part in a debug unlocked state. Although not writable by SW via AXI. This is writable via DMI. \|
921		-
	1133	+\| `ss_debug_intent` \| Non-configurable Sampled \| Provides some debug access to MCI. Shows the intent to put the part in a debug-unlocked state. This strap is not writable by SW via AXI, and it is read-only over DMI. Debug intent can additionally be asserted by the MCU through the AXI-writable `SS_DEBUG_INTENT_MCU` register (W1S, settable only before `SS_CONFIG_DONE_STICKY`); that register is OR'd with this strap to form the effective debug intent. \|
922	1134
923	1135
924	1136	### Subsystem Boot Finite State Machine (CSS-BootFSM)
@@ -930,37 +1142,39 @@
930	1142	Note: SOC may have other HW FSM steps that were done before Caliptra (CSS) is brought out of reset such as locking a PLL or calibrating a CRO, setting up GPIOs, test logic bring up etc. using SOC HW FSM.
931	1143
932	1144	1. SOC asserts Caliptra SS powergood and desserts Caliptra SS reset to MCI
933		-
	1145	+
934	1146	a. SOC may choose to connect the same signals to the AXI fabric or bring it out of reset using a different signals. But the requirement is that before MCU is out of reset, fabric should be operational.
935	1147
936	1148	2. CSS-BootFSM will sample straps in MCI and will drive its outputs to reset defaults.
937		-
	1149	+
938	1150	c. Note: In allowed LCC states, MCU TAP will be available when MCI is brought out of reset. Uncore registers in MCI will be available, but Core registers within MCU will only be available when MCU reset is deasserted.
939	1151
940	1152	3. CSS-BootFSM will go through Caliptra Subsystem Fuse controller (CSS FC) Init Sequence Init Sequence/handshakes
941	1153	4. CSS-BootFSM will go through Caliptra Subsystem Life Cycle Controller (CSS LCC) Init Sequence/handshakes
942		-
	1154	+
943	1155	a. SOC Note: Note that LCC shall start on an SOC generated internal clock to prevent clock stretch attacks
944		-
	1156	+
945	1157	b. SOC Note: If the life cycle state is in RAW, TEST* or RMA, and if TRANSITION_CTRL.EXT_CLOCK_EN is set to one, the CLK_BYP_REQ signal is asserted in order to switch the main system clock to an external clock signal. This functionality is needed in certain life cycle states where the SOC internal clock source may not be fully calibrated yet, since the FUSE macro requires a stable clock frequency in order to reliably program the fuse array. Note that the TRANSITION_CTRL.EXT_CLOCK_EN register can only be set to one if the transition interface has been claimed via the CLAIM_TRANSITION_IF mutex. This function is not available in production life cycle states.
946	1158
947	1159	5. If MCU-No-ROM-Config strap is not set, then CSS-BootFSM will bring MCU out of reset and MCU ROM will start executing.
948		-
	1160	+
949	1161	a. Note: MCU ROM may be used by some SOCs for doing additional SOC specific initializations.An example of such a SoC construction is MCI, MCU, CSS Fabric are running on external clock initially. MCU brings up PLL, some GPIO peripherals, does I3C init sequence etc and then performs clock switch to internal PLL clock domain so that the fabric is running on the internal clock domain before secrets are read on it from the fuse controller.
950		-
	1162	+
	1163	+ b. USB AXI filtering configuration must follow the [configuration and locking requirements](CaliptraSSIntegrationSpecification.md#axi-user-filtering).
	1164	+
951	1165	6. If MCU-No-ROM-Config is not set, MCU ROM will bring Caliptra out of reset by writing a MCI register (CPTRA_BOOT_GO)
952	1166	7. If MCU-No-ROM-Config is set, CSS-BootFSM waits for a Caliptra GO write from SOC to bring Caliptra out of reset.
953		-
	1167	+
954	1168	a. Note: MCU Reset Vector will be strapped to the MCU SRAM executable location at integration time.
955		-
956		- b. Note: MCI will allow "MCI SOC CONFIG" AXI User to configure MCI registers MCU typically configures.
957		-
	1169	+
	1170	+ b. Note: MCI will allow "MCI SOC CONFIG" AXI User to configure MCI registers MCU typically configures.
	1171	+
958	1172	b. Note: MCI will allow any AXI User to write into SRAM if the LCC & debug state allows. SOC will have flexibility to implement desired logic to write to MCU SRAM to skip MCU ROM and a register bit to bring MCU out of reset. MCU will start executing from the reset vector that was strapped which enables the first fetch vector to access MCI SRAM
959	1173	8. Caliptra reset (cptra_rst_b) is deasserted.
960	1174	9. Caliptra BootFSM will go through its own boot flow as documented in Caliptra spec, reads secret fuses and sets “ready_for_fuses” to MCI.
961	1175
962		- Note: In MCU-NO-ROM-CONFIG, steps 11 through 14 & steps 16 through 18 are done by a SOC entity. Otherwise, MCU ROM will do the below steps.
963		-
	1176	+ Note: In MCU-NO-ROM-CONFIG, steps 11 through 14 & steps 16 through 18 are done by a SOC entity. Otherwise, MCU ROM will do the below steps.
	1177	+
964	1178	10. MCU ROM will be polling for this indication
965	1179	11. MCU ROM will now read FC’s SW partition for all the required fuses including its own and also write Caliptra fuses. Note that only non-secret fuses are accessible for MCU ROM by fuse controller construction.
966	1180	a. Note: All fuses will be zero if FC is not programmed
@@ -971,9 +1185,113 @@
971	1185	16. CSS-BootFSM waits for MCU to request the reset. Then CSS-BootFSM will do a halt req/ack handshake with MCU and assert the MCU reset after the MCU reports that it has successfully halted.
972	1186	17. MCU ROM will read the reset reason in the MCI and execute from MCU SRAM
973	1187
974		-![](../images/caliptra-ss/docs/images/Caliptra-SS-BootFSM.png)
	1188	+The diagram below shows the MCI boot FSM in normal functional operation (`scan_mode == 0`). Circles name the encoded states; state actions are listed below. Edge labels name signals unless marked with `*`, which identifies a descriptive label or condition rather than a signal.
	1189	+
	1190	+```mermaid
	1191	+---
	1192	+config:
	1193	+ theme: base
	1194	+ themeCSS: ".edgeLabel { font-family: Arial, sans-serif; } .flowchart-link { stroke-width: 2.5px; }"
	1195	+ themeVariables:
	1196	+ fontFamily: Arial, sans-serif
	1197	+ fontSize: 20px
	1198	+ lineColor: "#17647f"
	1199	+ edgeLabelBackground: "#ffffff"
	1200	+ block:
	1201	+ padding: 16
	1202	+---
	1203	+block-beta
	1204	+ columns 9
	1205	+ %% Fixed-size labels keep every encoded-state circle the same size.
	1206	+ space:3 RESET_EVENT((" ")) space:5
	1207	+ space:3 BOOT_IDLE(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_IDLE</div>")) space:5
	1208	+ space BOOT_RST_MCU(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_<br/>RST_MCU</div>")) space:3 BOOT_OTP_FC(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_OTP_FC</div>")) space:3
	1209	+ BOOT_WAIT_MCU_HALTED(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_WAIT_<br/>MCU_HALTED</div>")) space:5 BOOT_LCC(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_LCC</div>")) space:2
	1210	+ BOOT_HALT_MCU(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_<br/>HALT_MCU</div>")) space:2 SPACING["<div style='width:236px;height:196px'></div>"] space:2 BOOT_BREAKPOINT_CHECK(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_<br/>BREAKPOINT_<br/>CHECK</div>")) space:2
	1211	+ BOOT_WAIT_MCU_RST_REQ(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_WAIT_<br/>MCU_RST_REQ</div>")) space:5 BOOT_BREAKPOINT(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_<br/>BREAKPOINT</div>")) space ROM_SELECT((" "))
	1212	+ space BOOT_CPTRA(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_CPTRA</div>")) space:3 BOOT_MCU(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_MCU</div>")) space:3
	1213	+ space:3 BOOT_WAIT_CPTRA_GO(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_WAIT_<br/>CPTRA_GO</div>")) space:4 NO_ROM_CORNER((" "))
	1214	+ space:2 BAD_VALUE((" ")) space BOOT_ERROR(("<div style='width:156px;height:88px;display:flex;align-items:center;justify-content:center'>BOOT_ERROR</div>")) space:4
	1215	+
	1216	+ RESET_EVENT -- "Warm / power-good reset*" --> BOOT_IDLE
	1217	+ BOOT_IDLE -- "!warm_reset" --> BOOT_OTP_FC
	1218	+ BOOT_OTP_FC -- "fc_opt_done" --> BOOT_LCC
	1219	+ BOOT_LCC -- "lc_done" --> BOOT_BREAKPOINT_CHECK
	1220	+ BOOT_BREAKPOINT_CHECK -- "mci_boot_seq_brkpoint" --> BOOT_BREAKPOINT
	1221	+ BOOT_BREAKPOINT_CHECK -- "!mci_boot_seq_brkpoint" --> ROM_SELECT
	1222	+ BOOT_BREAKPOINT -- "mci_bootfsm_go" --> ROM_SELECT
	1223	+ ROM_SELECT -- "!mcu_no_rom_config" --> BOOT_MCU
	1224	+ ROM_SELECT -- "mcu_no_rom_config" --- NO_ROM_CORNER
	1225	+ NO_ROM_CORNER --> BOOT_WAIT_CPTRA_GO
	1226	+ BOOT_MCU -- "!from_mcu_reset*" --> BOOT_WAIT_CPTRA_GO
	1227	+ BOOT_MCU -- "from_mcu_reset*" --> BOOT_WAIT_MCU_RST_REQ
	1228	+ BOOT_WAIT_CPTRA_GO -- "caliptra_boot_go" --> BOOT_CPTRA
	1229	+ BOOT_CPTRA --> BOOT_WAIT_MCU_RST_REQ
	1230	+ BOOT_WAIT_MCU_RST_REQ -- "mcu_rst_req" --> BOOT_HALT_MCU
	1231	+ BOOT_HALT_MCU -- "mcu_cpu_halt_ack_i" --> BOOT_WAIT_MCU_HALTED
	1232	+ BOOT_WAIT_MCU_HALTED -- "mcu_cpu_halt_status_i" --> BOOT_RST_MCU
	1233	+ BOOT_RST_MCU -- "reset_ready*" --> BOOT_MCU
	1234	+ BAD_VALUE -- "Bad FSM register value*" --> BOOT_ERROR
	1235	+
	1236	+ classDef normal fill:#17647f,stroke:#17647f,color:#fff,font-family:Arial
	1237	+ classDef error fill:#8b3030,stroke:#642222,color:#fff,font-family:Arial
	1238	+ classDef entry fill:none,stroke:none
	1239	+ classDef junction fill:#17647f,stroke:#17647f
	1240	+ class BOOT_IDLE,BOOT_OTP_FC,BOOT_LCC,BOOT_BREAKPOINT_CHECK,BOOT_BREAKPOINT,BOOT_MCU,BOOT_WAIT_CPTRA_GO,BOOT_CPTRA,BOOT_WAIT_MCU_RST_REQ,BOOT_HALT_MCU,BOOT_WAIT_MCU_HALTED,BOOT_RST_MCU normal
	1241	+ class BOOT_ERROR error
	1242	+ class RESET_EVENT,BAD_VALUE,SPACING entry
	1243	+ class ROM_SELECT,NO_ROM_CORNER junction
	1244	+```
	1245	+
	1246	+The reset-entry arrow applies to every state, including BOOT\_ERROR. `mci_pwrgood = 0` asynchronously resets the FSM to BOOT\_IDLE; `warm_reset` returns it to BOOT\_IDLE on a clock edge.
	1247	+
	1248	+\| State \| Output actions \|
	1249	+\| --- \| --- \|
	1250	+\| `BOOT_IDLE` \| `cptra_ss_rst_b_o = 0`, `mcu_rst_b = 0`, `cptra_rst_b = 0` \|
	1251	+\| `BOOT_OTP_FC` \| `fc_opt_init = 1`, `cptra_ss_rst_b_o = 1` \|
	1252	+\| `BOOT_LCC` \| `lc_init = 1` \|
	1253	+\| `BOOT_BREAKPOINT_CHECK` \| None \|
	1254	+\| `BOOT_BREAKPOINT` \| None \|
	1255	+\| `BOOT_MCU` \| `mcu_rst_b = 1` \|
	1256	+\| `BOOT_WAIT_CPTRA_GO` \| None \|
	1257	+\| `BOOT_CPTRA` \| `cptra_rst_b = 1` \|
	1258	+\| `BOOT_WAIT_MCU_RST_REQ` \| None \|
	1259	+\| `BOOT_HALT_MCU` \| `mcu_cpu_halt_req_o = 1` \|
	1260	+\| `BOOT_WAIT_MCU_HALTED` \| None \|
	1261	+\| `BOOT_RST_MCU` \| `mcu_rst_b = 0`, `mcu_reset_once = 1` \|
	1262	+\| `BOOT_ERROR` \| `mcu_rst_b = 0`, `cptra_rst_b = 0`, `cptra_ss_rst_b_o = 1`, `fsm_error = 1` \|
	1263	+
	1264	+
	1265	+
	1266	+\| Diagram label or reset signal \| Meaning \|
	1267	+\| --- \| --- \|
	1268	+\| `reset_ready*` \| `min_mcu_rst_count_elapsed && mcu_sram_fw_exec_region_lock` \|
	1269	+\| `from_mcu_reset` \| `boot_fsm_prev == BOOT_RST_MCU`; `!from_mcu_reset` means the comparison is false \|
	1270	+\| `Warm / power-good reset*` \| Global reset entry: `warm_reset` forces idle on a clock edge, or `mci_pwrgood = 0` asynchronously resets the FSM \|
	1271	+\| `Bad FSM register value*` \| The state register contains an unused encoding; selects BOOT\_ERROR unless overridden by reset \|
	1272	+\| `warm_reset` \| Active-high, synchronized and delayed indication of active-low `cptra_ss_rst_b_i` (`mci_rst_b` inside MCI) \|
	1273	+
	1274	+
	1275	+#### CSS-BootFSM Glitch Protection
	1276	+
	1277	+The CSS-BootFSM uses state encodings with a minimum Hamming distance of 5 to detect state-register corruption. This protection detects invalid state encodings; it does not detect corruption that changes one valid encoding into another.
	1278	+
	1279	+In normal operation (`scan_mode == 0`), detection of an invalid state encoding causes the following:
	1280	+
	1281	+1. The FSM enters BOOT\_ERROR and holds MCU and Caliptra in reset, without the MCU halt handshake.
	1282	+2. Subsystem reset (`cptra_ss_rst_b_o`) is deasserted so the SOC can access MCI registers.
	1283	+3. HW\_ERROR\_FATAL.fsm\_error is set and `all_error_fatal` is asserted. This error cannot be masked.
	1284	+4. HW\_FLOW\_STATUS.boot\_fsm reports 0xF. Normal-state values remain 0x0 through 0xB; the CSR and DMI addresses are unchanged.
	1285	+
	1286	+Recovery
	1287	+
	1288	+1. Apply warm reset or cycle power-good to return the FSM to BOOT\_IDLE and clear `all_error_fatal`.
	1289	+2. After warm reset, clear the retained HW\_ERROR\_FATAL.fsm\_error bit using write-one-to-clear (W1C). Power-good reset clears this bit automatically.
	1290	+
	1291	+A software clear alone does not exit BOOT\_ERROR or clear the fatal output. The status bit can be set again while the FSM remains in BOOT\_ERROR.
975	1292
976	1293	### Watchdog Timer
	1294	+
977	1295	The Watchdog Timer within the MCI is a crucial component designed to enhance the reliability and robustness of the SoC. This timer monitors the operation of the system and can trigger a system reset if it detects that the system is not functioning correctly. The Watchdog Timer is configurable through CSRs and provides various timeout periods and control mechanisms to ensure the system operates within defined parameters.
978	1296	The Watchdog timer contains two different timers. These timers can be configured in two different modes:
979	1297
@@ -986,7 +1304,7 @@
986	1304	2. Timer 2 will start counting
987	1305
988	1306	If the WDT is not serviced before Timer 2 times out two things happen:
989		-
	1307	+
990	1308	1. NMI output pin is asserted
991	1309	2. NMI HW_ERROR_FATAL is triggered which can assert an error_fatal on the MCI port.
992	1310
@@ -1002,48 +1320,149 @@
1002	1320
1003	1321	Any untrusted AXI user trying to read or write the mailbox will receive an AXI error response ([MCU Mailbox Errors](#mcu-mailbox-errors)).
1004	1322
1005		-Trusted users always have read access to the CSRs in the mailbox, but require a [lock](#mcu-mailbox-locking) to write the CSRs or read/write the SRAM.
	1323	+Trusted users always have read access to the CSRs in the mailbox, but require MBOX [lock](#mcu-mailbox-locking) to write the CSRs. SRAM reads and writes require the trusted user to be the current [exclusive SRAM owner](#mcu-mailbox-sram-ownership).
1006	1324
1007	1325	#### MCU Mailbox Locking
1008	1326
1009		-A Requester will read the "LOCK" register to obtain a lock on the mailbox. This is a read-set register, the lock is acquired when read returns 0. The Requester must be a [Trusted user](#mcu-mailbox-limited-trusted-axi-users). Once the lock is obtained the Requestor has read access to the entire mailbox and write access to:
1010		-
1011		-- All mailbox registers except the following will be RO:
1012		- - CMD_STATUS
1013		- - TARGET_STATUS
1014		- - TARGET_DONE
1015		- - TARGET_USER
1016		-- Mailbox SRAM
1017		-Unlocking/releasing occurs when the requestor writes 0 to the EXECUTE register. After releasing the mailbox the SRAM is zeroed out([MCU Mailbox SRAM Clearing](#mcu-mailbox-sram-clearing)).
1018		-
1019		-On MCI reset release the MCU MBOX is locked for MCU. The MCU shall set the DLEN to the size of the SRAM and release the MBOX, causing the SRAM to be zeroed. This is done to prevent data leaking between warm resets via the SRAM.
	1327	+A Requester will read the "LOCK" register to obtain a lock on the mailbox. This is a read-set register, the lock is acquired when read returns 0. The Requester must be a [Trusted user](#mcu-mailbox-limited-trusted-axi-users). Once the lock is obtained the Requester has read access to the mailbox CSRs and write access to:
	1328	+
	1329	+- CMD and EXECUTE registers
	1330	+- DLEN register and mailbox SRAM while the Requester is the current [SRAM owner](#mcu-mailbox-sram-ownership)
	1331	+
	1332	+Unlocking/releasing occurs when the Requester writes 0 to the EXECUTE register. After releasing the mailbox the SRAM is zeroed out([MCU Mailbox SRAM Clearing](#mcu-mailbox-sram-clearing)).
	1333	+
	1334	+On MCI reset release the MCU MBOX is locked for MCU. The MCU shall set the DLEN to the size of the SRAM and release the MBOX, causing the SRAM to be zeroed. This is done to prevent data leaking between warm resets via the SRAM.
1020	1335
1021	1336	#### MCU Mailbox Target User
1022	1337
1023		-A Target user is an additional user that can access and process the MBOX request. This user can only be setup by MCU and only valid when the TARGET_USER_VALID bit is set.
1024		-
1025		-One example of when a Target user becomes necessary is when the SOC wants Caliptra to process a MBOX request. The SOC will obtain a lock, MCU will see the command request is for Caliptra, MCU will add Caliptra as the Target user and notify Caliptra.
1026		-
1027		-Another example is when MCU itself obtains the mailbox lock. It will add a Target user and notify the Target user via AXI or some other mechanism.
1028		-
1029		-A Target user has read access to the entire mailbox and write access to:
1030		-
1031		-- DLEN register
	1338	+A Target user is a
	1339	+[trusted AXI user](#mcu-mailbox-limited-trusted-axi-users) that Root selects to
	1340	+participate in a mailbox transaction. Root, typically MCU, is the only agent
	1341	+that programs `TARGET_USER` and `TARGET_USER_VALID`.
	1342	+
	1343	+Root shall write the Target AXI identity to `TARGET_USER` and then write
	1344	+`TARGET_USER_VALID=1`. The numeric value in `TARGET_USER` has no ownership
	1345	+meaning while valid is 0.
	1346	+
	1347	+While `TARGET_USER_VALID=0`, Root may write either target configuration
	1348	+register. Writing `TARGET_USER_VALID=1` locks both registers against all
	1349	+software writes. Software cannot retarget the mailbox or clear valid after the
	1350	+grant. Hardware clears and unlocks both registers on a terminal
	1351	+`TARGET_STATUS` write or when the mailbox is released.
	1352	+
	1353	+One example of when a Target user becomes necessary is when the SOC wants
	1354	+Caliptra to process a MBOX request. The SOC will obtain a lock, MCU will see the
	1355	+command request is for Caliptra, MCU will program Caliptra as the Target user,
	1356	+set `TARGET_USER_VALID`, and notify Caliptra.
	1357	+
	1358	+Another example is when MCU itself obtains the mailbox lock. It will program a
	1359	+Target user, set `TARGET_USER_VALID`, and notify the Target user via AXI or
	1360	+some other mechanism.
	1361	+
	1362	+A Target user has read access to the mailbox CSRs, and write access to:
	1363	+
1032	1364	- TARGET_STATUS register
1033		-- TARGET_DONE register
1034		-- Mailbox SRAM
1035		-
1036		-The Target user will notify MCU it is done processing by setting TARGET_STATUS and TARGET_DONE. Setting TARGET_DONE will interrupt MCU. If required, MCU will then update the CMD_STATUS register with the final status of the command for the Requestor.
1037		-
1038		-If a second Target user is required it is the MCU's responsibility to:
1039		-
1040		-1. Clear TARGET_STATUS
1041		-2. Clear TARGET_DONE
1042		-3. Set new TARGET_USER
1043		-
1044		-Otherwise these registers are cleared when the mailbox lock is released.
1045		-
1046		-Target users must be an [MCU Mailbox trusted user](mcu-mailbox-limited-trusted-AXI-user)
	1365	+- DLEN register and mailbox SRAM while it is the current [SRAM owner](#mcu-mailbox-sram-ownership)
	1366	+
	1367	+The Target user shall finish all SRAM and DMA accesses before writing a
	1368	+terminal `TARGET_STATUS` value, because that write ends its
	1369	+[SRAM ownership](#mcu-mailbox-sram-ownership).
	1370	+
	1371	+If a second Target user is required, MCU shall wait for the first Target to
	1372	+publish a terminal `TARGET_STATUS` during normal operation. Hardware clears
	1373	+`TARGET_USER` and `TARGET_USER_VALID` on that write, after which MCU can
	1374	+program and validate the next Target user. `EXECUTE` remains 1 and the SRAM
	1375	+contents are preserved, so a re-grant does not require releasing the mailbox.
	1376	+
	1377	+
	1378	+#### MCU Mailbox SRAM Ownership
	1379	+
	1380	+The SRAM owner is derived from mailbox state. Ownership is a combinational function of the mailbox
	1381	+registers, evaluated in the following precedence order.
	1382	+
	1383	+```mermaid
	1384	+%%{init: {"flowchart": {"curve": "basis"}}}%%
	1385	+flowchart TD
	1386	+ accTitle: MCU mailbox SRAM owner resolution
	1387	+ accDescr: A decision tree resolving the single exclusive SRAM owner from the lock, zeroization, EXECUTE, TARGET_USER_VALID, and CMD_STATUS state.
	1388	+
	1389	+ Q1{"MBOX_LOCK set?"}
	1390	+ Q2{"SRAM zeroizing?"}
	1391	+ Q3{"EXECUTE = 1?"}
	1392	+ Q4{"TARGET_USER_VALID = 1?"}
	1393	+ Q5{"CMD_STATUS = BUSY?"}
	1394	+
	1395	+ NONE(["No software owner"])
	1396	+ TGTO(["TARGET_USER agent"])
	1397	+ ROOTO(["Root AXI user"])
	1398	+ HOLD(["Lock holder"])
	1399	+
	1400	+ Q1 -- No --> NONE
	1401	+ Q1 -- Yes --> Q2
	1402	+ Q2 -- Yes --> NONE
	1403	+ Q2 -- No --> Q3
	1404	+ Q3 -- No --> HOLD
	1405	+ Q3 -- Yes --> Q4
	1406	+ Q4 -- No --> Q5
	1407	+ Q4 -- Yes --> TGTO
	1408	+ Q5 -- No --> HOLD
	1409	+ Q5 -- Yes --> ROOTO
	1410	+```
	1411	+
	1412	+Because ownership is combinational, each register write below is what moves
	1413	+the exclusive owner from one agent to the next.
	1414	+
	1415	+\| Event \| New exclusive SRAM owner \|
	1416	+\| --- \| --- \|
	1417	+\| MCI reset \| Root, as the reset lock holder \|
	1418	+\| `LOCK` read returns 0 \| The reading agent becomes lock holder \|
	1419	+\| `EXECUTE=1` while `TARGET_USER_VALID=0` \| Root \|
	1420	+\| Root writes `TARGET_USER_VALID=1` while `EXECUTE=1` \| The agent named by `TARGET_USER` \|
	1421	+\| Target writes terminal `TARGET_STATUS` \| Root, and hardware clears `TARGET_USER` and `TARGET_USER_VALID` \|
	1422	+\| MCU writes non-BUSY `CMD_STATUS` \| Lock holder \|
	1423	+\| `EXECUTE=0` \| None, and hardware begins zeroization \|
	1424	+\| Zeroization completes \| None, `LOCK` clears and the mailbox is reusable \|
	1425	+
	1426	+
	1427	+Writing `EXECUTE=0` always revokes all software SRAM access and enters
	1428	+zeroization, including while a Target owns the SRAM.
	1429	+
	1430	+`DLEN` write access follows SRAM ownership. Only the current SRAM owner may
	1431	+write `DLEN`, so the agent that produced the data in the SRAM is the agent that
	1432	+reports its length.
	1433	+
	1434	+#### MCU Mailbox Status Registers
	1435	+
	1436	+`CMD_STATUS` and `TARGET_STATUS` use the following encodings:
	1437	+
	1438	+\| Value \| Meaning \|
	1439	+\| ---: \| --- \|
	1440	+\| 0 \| BUSY \|
	1441	+\| 1 \| DATA_READY \|
	1442	+\| 2 \| COMPLETE \|
	1443	+\| 3 \| FAILURE \|
	1444	+
	1445	+
	1446	+The two status registers serve different polling domains. Only MCU writes
	1447	+`CMD_STATUS`, and the original Requester polls it. Only the current Target
	1448	+writes `TARGET_STATUS`, and MCU reads it. A terminal Target status shall not be
	1449	+visible as command completion to the original Requester until MCU separately
	1450	+writes a terminal `CMD_STATUS`.
	1451	+
	1452	+Hardware resets `TARGET_STATUS` to BUSY on each Target handoff.
	1453	+
	1454	+`CMD_STATUS` is not used when MCU is the Requester, because there is no
	1455	+external Requester to serve. In that case MCU reads `TARGET_STATUS` directly.
	1456	+
	1457	+`MBOX_HW_STATUS.SRAM_OWNER` reports the current exclusive SRAM owner:
	1458	+
	1459	+\| Value \| Owner \|
	1460	+\| ---: \| --- \|
	1461	+\| 0 \| None \|
	1462	+\| 1 \| Requester/lock holder \|
	1463	+\| 2 \| Root AXI user, typically MCU \|
	1464	+\| 3 \| Target selected by `TARGET_USER` while `TARGET_USER_VALID=1` \|
	1465	+
1047	1466
1048	1467	#### MCU Mailbox Fully addressable SRAM
1049	1468
@@ -1053,7 +1472,7 @@
1053	1472
1054	1473	Max Size: 2MB
1055	1474
1056		-If set to 0 the mailbox is not instantiated.
	1475	+If set to 0 the mailbox is not instantiated.
1057	1476
1058	1477	Accesses must be DWORD aligned and BYTE accesses are not supported by the SRAM.
1059	1478
@@ -1066,7 +1485,7 @@
1066	1485	3. MCU SRAM clearing ends
1067	1486	4. Mailbox is unlocked
1068	1487
1069		-The Requester is locked out of the mailbox after step 1, even though the lock isn't cleared until step 4.
	1488	+The Requester is locked out of the mailbox after step 1, even though the lock isn't cleared until step 4.
1070	1489
1071	1490	It is expected that agents write their content from 0 to DLEN. If an agent writes outside of this SRAM area, there is no security guarantee for that content because that data would not be zeroized between mailbox operations.
1072	1491
@@ -1076,18 +1495,24 @@
1076	1495
1077	1496	The following interrupts are sent to MCU:
1078	1497
1079		-\| Interrupt \| Description \|
1080		-\| :--------- \| :--------- \|
1081		-\| SOC request MBOX \| Asserted when MCU has MBOX lock and an SOC agent tries to obtain the lock. MCU can decide to release the mailbox if this happens. \|
1082		-\| Mailbox data available from SOC \| Asserted when a SOC agent gets lock and assert the EXECUTE register, indicating data is availalbe for MCU. \|
1083		-\| Target Done \| Asserted when the Target user is done processing the data and is ready for MCU to consume or pass data to Requestor. \|
1084		-
1085		-
1086		-The following interrup(s) are available for SOC consumption:
1087		-
1088		-\| Interrupt \| Description \|
1089		-\| :--------- \| :--------- \|
1090		-\| Mailbox data available from MCU \| Asserted when MCU gets lock and assert the EXECUTE register, indicating data is available for SOC consumption. \|
	1498	+\| Interrupt \| Signal \| Description \|
	1499	+\| :--------- \| :--------- \| :--------- \|
	1500	+\| SOC request MBOX \| `notif_mbox*_soc_req_lock` \| Asserted when MCU has MBOX lock and an SOC agent tries to obtain the lock. MCU can decide to release the mailbox if this happens. \|
	1501	+\| Mailbox data available from SOC \| `notif_mbox*_cmd_avail` \| Asserted when a SOC agent gets lock and asserts the EXECUTE register, indicating data is available for MCU. \|
	1502	+\| Target complete \| `notif_mbox*_target_done` \| Asserted when the Target user writes a terminal TARGET_STATUS. \|
	1503	+
	1504	+
	1505	+Each interrupt has a corresponding enable, status, trigger, and count register
	1506	+field in the MCI register block, named with the `_en`, `_sts`, `_trig`, and
	1507	+`_intr_count_r` suffixes.
	1508	+
	1509	+The following signal is available for SOC consumption.
	1510	+
	1511	+\| Interrupt \| Signal \| Description \|
	1512	+\| :--------- \| :--------- \| :--------- \|
	1513	+\| Mailbox data available from MCU \| `cptra_ss_soc_mcu_mbox*_data_avail` \| Asserted while MCU holds the mailbox lock and EXECUTE is 1. \|
	1514	+
	1515	+
1091	1516
1092	1517	#### MCU Mailbox Errors
1093	1518
@@ -1096,18 +1521,49 @@
1096	1521	\| Error Type \| Response \| Description \|
1097	1522	\| :--------- \| :--------- \| :--------- \|
1098	1523	\| Untrusted User Access \| Read:<br> - Data return 0 <br> - AXI Error<br>Write:<br> - Data dropped<br> - AXI Error \| When an [Untrusted user](#mcu-mailbox-limited-trusted-axi-users) tries to access any address within the MBOX. \|
1099		-\| Trusted User Illegal Access \| Read:<br> - Data return 0 <br>Write:<br> - Data dropped \| When a [Trusted user](#mcu-mailbox-limited-trusted-axi-users) tries to:<br>- Access the mailbox when it doesn't have a lock<br>- Tries to write to a register it doesn't have access to.<br>- Tries to access an illegal SRAM address within the mailbox. \|
	1524	+\| Trusted User Illegal Access \| Read:<br> - Data return 0 <br>Write:<br> - Data dropped \| When a [Trusted user](#mcu-mailbox-limited-trusted-axi-users) tries to:<br>- Access mailbox SRAM when it is not the current owner<br>- Write a register it does not have access to<br>- Access an illegal SRAM address within the mailbox \|
1100	1525	\| Single Bit ECC Error \| - Interrupt to MCU<br>- Mailbox ECC SB status set<br>- Data corrected \| Single bit ECC error while reading Mailbox. \|
1101	1526	\| Double Bit ECC Error \| - Error interrupt to MCU<br> - HW_NON_FATAL error set for SOC consumption<br>- Mailbox ECC DB status set<br>- Invalid data returned \| Double bit ECC error while reading Mailbox. \|
1102	1527
1103	1528
1104		-Whenever an agent reads data from the SRAM they either need to consume the Double Bit ECC interrupt wire or check the MCU Mailbox status registers to know if the data they received is valid.
	1529	+Whenever an agent reads data from the SRAM they either need to consume the Double Bit ECC interrupt wire or check the MCU Mailbox status registers to know if the data they received is valid.
1105	1530
1106	1531	#### MCU Mailbox MCU Access
1107	1532
1108		-When there is a mailbox lock the MCU has full access to the mailbox CSRs and SRAM in order to facilitage interactions and help with any lockup.
1109		-
1110		-It is the only agent allowed to set TARGET_USER and update the final CMD_STATUS.
	1533	+MCU has read access to the mailbox CSRs at all times. MCU write access is
	1534	+determined by its role in the current transaction, and follows the
	1535	+[status register](#mcu-mailbox-status-registers) writer rules.
	1536	+
	1537	+Root is the only agent that may write `TARGET_USER` and
	1538	+`TARGET_USER_VALID`. Both registers are writable only while
	1539	+`TARGET_USER_VALID=0`. See
	1540	+[MCU Mailbox Target User](#mcu-mailbox-target-user).
	1541	+
	1542	+When an external Requester holds the lock, MCU is the only agent that may write
	1543	+`CMD_STATUS`. The Requester owns `CMD` and `EXECUTE` in this transaction, so
	1544	+those registers are read-only to MCU.
	1545	+
	1546	+When MCU holds the lock it is the Requester and has Requester write access to
	1547	+`CMD` and `EXECUTE`.
	1548	+
	1549	+`DLEN` follows [SRAM ownership](#mcu-mailbox-sram-ownership). MCU has write
	1550	+access to `DLEN` while it is the current SRAM owner, so it can report the length
	1551	+of a response it produced.
	1552	+
	1553	+\| CSR \| MCU holds the lock \| An external Requester holds the lock \|
	1554	+\| --- \| --- \| --- \|
	1555	+\| `CMD` \| RW \| RO \|
	1556	+\| `DLEN` \| RW while MCU owns the SRAM \| RW while MCU owns the SRAM \|
	1557	+\| `EXECUTE` \| RW \| RO \|
	1558	+\| `TARGET_USER` \| RW while `TARGET_USER_VALID=0` \| RW while `TARGET_USER_VALID=0` \|
	1559	+\| `TARGET_USER_VALID` \| RW while 0 \| RW while 0 \|
	1560	+\| `CMD_STATUS` \| Unused \| RW \|
	1561	+\| `TARGET_STATUS` \| RO \| RO \|
	1562	+\| `LOCK`, `USER` \| Per mailbox locking rules \| Per mailbox locking rules \|
	1563	+
	1564	+
	1565	+MCU can access mailbox SRAM only while MCU is the current
	1566	+[SRAM owner](#mcu-mailbox-sram-ownership).
1111	1567
1112	1568	#### MCU Mailbox Address Map
1113	1569
@@ -1117,11 +1573,12 @@
1117	1573	\| 0x0020_0000 \| 0x020_003F \| MBOX CSR \| Mailbox Control Status Registers \|
1118	1574
1119	1575
1120		- *NOTE: MBOX SRAM size is configurable, but MBOX always reserves 2MB address space. See [MCU Mailbox Errors](#mcu-mailbox-errors) for how access to and invalid SRAM address are handled.
	1576	+ *NOTE: MBOX SRAM size is configurable, but MBOX always reserves 2MB address space. See [MCU Mailbox Errors](#mcu-mailbox-errors) for how access to and invalid SRAM address are handled.
1121	1577
1122	1578	[MCU MBOX Register Spec](https://chipsalliance.github.io/caliptra-ss/main/regs/?p=soc.mci_top.mcu_mbox0_csr)
1123	1579
1124	1580	### MCU SRAM
	1581	+
1125	1582	![](../images/caliptra-ss/docs/images/MCI-MCU-SRAM-Diagram.png)
1126	1583
1127	1584	The MCU SRAM provides essential data and instruction memory for the Manufacturer Control Unit. This SRAM bank is utilized by the MCU to load firmware images, store application data structures, and create a runtime stack. The SRAM is accessible via the AXI interface and is mapped into the MCI's memory space for easy access and management. Exposing this SRAM via a restricted API through the SoC AXI interconnect enables seamless and secured Firmware Updates to be managed by Caliptra.
@@ -1133,18 +1590,20 @@
1133	1590	AXI USER filtering is used to restrict access within the MCU SRAM based on system state and accessor. Access permissions are based on the AXI USER input straps (either the MCU SRAM Config AXI_USER, or the MCU IFU/LSU AXI USERS). Any write attempt by an invalid AXI_USER is discarded and returns an error status. Any read attempt returns 0 data and an error status.
1134	1591	The MCU SRAM contains two regions, a Protected Data Region and an Updatable Execution Region, each with a different set of access rules.
1135	1592
1136		-After each MCU reset the Updateable Execution Region may only be read/written by MCU SRAM Config User (typically Caliptra) prior to mcu_sram_fw_exec_region_lock input signal is set. Once fw_exec_region_lock is set it can be read/written by the MCU IFU or MCU LSU until MCU reset is asserted.
	1593	+After each MCU reset the Updateable Execution Region may only be read/written by MCU SRAM Config User (typically Caliptra) prior to mcu_sram_fw_exec_region_lock input signal is set. Once fw_exec_region_lock is set it can be read/written by the MCU IFU or MCU LSU until MCU reset is asserted.
1137	1594
1138	1595	The Protected Data Region is only ever read/write accessible by MCU LSU.
1139		-The span of each region is dynamically defined by the MCU ROM during boot up. Once MCU has switched to running Runtime Firmware, the RAM sizing shall be locked until any SoC-level reset. ROM uses the register FW_SRAM_EXEC_REGION_SIZE to configure the SRAM allocation in 4KB increments. FW_SRAM_EXEC_REGION_SIZE counts in base 0 meaning the smallest the Updateable Execution Region size can be is 4KB. It is possible for the entire SRAM to be allocated to the Updatable Execution Region and there be no Protected Data Region.
1140		-
1141		-The entire MCU SRAM has ECC protection with no ability to disable. Single bit errors are detected and corrected. Double bit errors are detected and error.
	1596	+The span of each region is dynamically defined by the MCU ROM during boot up. Once MCU has switched to running Runtime Firmware, the RAM sizing shall be locked until any SoC-level reset. ROM uses the register FW_SRAM_EXEC_REGION_SIZE to configure the SRAM allocation in 4KB increments. FW_SRAM_EXEC_REGION_SIZE counts in base 0 meaning the smallest the Updateable Execution Region size can be is 4KB. It is possible for the entire SRAM to be allocated to the Updatable Execution Region and there be no Protected Data Region.
	1597	+
	1598	+The entire MCU SRAM has ECC protection with no ability to disable. Single bit errors are detected and corrected. Double bit errors are detected and error.
1142	1599
1143	1600	MCI actions for single bit errors:
	1601	+
1144	1602	- Correct data and pass corrected data back to the initiator.
1145	1603	- Send maskable interrupt notification to MCU.
1146	1604
1147	1605	MCI actions for double bit errors:
	1606	+
1148	1607	- AXI SLVERR response to the initiator
1149	1608	- HW_ERROR_FATAL asserted and sent to SOC
1150	1609
@@ -1152,7 +1611,7 @@
1152	1611
1153	1612	#### MCU Hitless Update Handshake
1154	1613
1155		-The hitless flow is described in full in [Caliptra Top Spec](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#subsystem-support-for-hitless-updates). The [Caliptra SS Integration Spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSIntegrationSpecification.md#mci) contains all MCI warm reset and hitless update flows and restrictions. This section is focused on the HW registers both Caliptra and MCU will used to complete the flow.
	1614	+The hitless flow is described in full in [Caliptra Top Spec](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#subsystem-support-for-hitless-updates). The [Caliptra SS Integration Spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSIntegrationSpecification.md#mci) contains all MCI warm reset and hitless update flows and restrictions. This section is focused on the HW registers both Caliptra and MCU will used to complete the flow.
1156	1615
1157	1616	MCI tracks three different ```RESET_REASON``` in its register bank:
1158	1617
@@ -1169,9 +1628,26 @@
1169	1628
1170	1629	```FW_EXEC_CTLR[2]``` is an input signal to the MCI and is sent as an interrupt (```notif_cptra_mcu_reset_req_sts```) to the MCU. This interrupt should be cleared by the MCU before it requests a reset with ```RESET_REQUEST.req```. After a warm reset, setting ```FW_EXEC_CTRL[2]``` will trigger an interrupt to the MCU, indicating that the MCU should reset itself with ```RESET_REQUEST.req```. After the first MCU reset request, when this input signal is cleared, it triggers the interrupt. The MCU is held in reset until ```FW_EXEC_CTRL[2]``` is set, with a minimum reset time determined by the ```MIN_MCU_RST_COUNTER``` MCI parameter.
1171	1630
	1631	+### MCU ROM Patch SRAM
	1632	+
	1633	+MCI hosts a dedicated MCU ROM patch SRAM so integrators can fix MCU ROM bugs on pre-production parts. MCU ROM loads the patch (for example from the vendor non-secret fuse partition) and fetches patch instructions from it.
	1634	+
	1635	+A patched device must never run in production or provision device identity, so hardware enforces:
	1636	+
	1637	+- Write window: MCU LSU only, and only while the LC state is TEST_LOCKED0-6, TEST_UNLOCKED0-7 or DEV, and Caliptra core has not yet left reset in the current power cycle (checked both at the MCI boot sequencer and at the Caliptra core reset input). The window closes when Caliptra core is first released and stays closed until the next cold reset.
	1638	+- Patch flag: the first accepted write sets a flag that is only cleared by cold reset. The flag is stable before Caliptra core boots and is readable in `HW_FLOW_STATUS.mcu_rom_patch_active`.
	1639	+- Sequential load: patch words must be written in order from offset 0. A hardware write pointer counts them and is only cleared by cold reset.
	1640	+- Fetch: MCU IFU/LSU reads (MCU ROM and MCU RT FW) are allowed only below the write pointer and while the LC condition still holds. The patch survives warm resets, so MCU ROM does not reload it and MCU RT FW can call patched ROM functions. Only words MCU ROM wrote in the current power cycle can execute, so stale or preloaded SRAM content can never be fetched, and a stale patch cannot run after an LC transition to PROD.
	1641	+- Identity: while the flag is set, the UDS and Field Entropy delivered to Caliptra core are zeroized, and the fuse controller filter discards DAI write and digest commands to the UDS and Field Entropy fuses.
	1642	+- Release: if no patch was loaded, the SRAM is released as data memory to any AXI user once MCU RT FW is running (MCU released from reset with the FW exec region locked). It is never fetchable while released, and a warm reset closes it again until MCU RT FW is running. A loaded patch is never released, because MCU ROM needs it again after a warm reset.
	1643	+
	1644	+The patch SRAM is optional: setting `MCU_ROM_PATCH_SRAM_SIZE_KB` to 0 removes it, leaving its address window unmapped.
	1645	+
	1646	+See the Integration Specification for the address map and interface details.
	1647	+
1172	1648	### MCI AXI Subordinate
1173	1649
1174		-MCI AXI Subordinate decodes the incoming AXI transaction and passes it onto the appropriate submodule within MCI.
	1650	+MCI AXI Subordinate decodes the incoming AXI transaction and passes it onto the appropriate submodule within MCI.
1175	1651
1176	1652	The MCI AXI Sub will respond with an AXI error if one of the following conditions is met:
1177	1653
@@ -1182,24 +1658,25 @@
1182	1658	1. Writes dropped
1183	1659	2. Reads return 0
1184	1660
1185		-
1186	1661	### MCI Interrupts
1187	1662
1188	1663	![](../images/caliptra-ss/docs/images/MCI-Interrupts.png)
1189	1664
1190	1665	All interrupt status and control registers live in the CSR block. Each interrupt has the following properties:
	1666	+
1191	1667	- Status: W1C for SW to clear
1192	1668	- Enable: Prevents status from propagating. It does not block the status from being set.
1193	1669	- SW Trigger: Ability for SW to manually trigger the interrupt. Typically used for debug.
1194		-- Counter: Counts number of times the interrupt event was detected (SW or HW).
	1670	+- Counter: Counts number of times the interrupt event was detected (SW or HW).
1195	1671
1196	1672	There are two different groups of interrupts
	1673	+
1197	1674	- Error
1198		-- Notification
1199		-
1200		-Each group of interrupts has its own global status and enable registers that are an aggregate of all interrupts in the group. These status and enable registers have the same properties as the individual interrupt status and enable registers.
1201		-
1202		-All interrupt groups are ORed and sent out on a signal mci_intr pin.
	1675	+- Notification
	1676	+
	1677	+Each group of interrupts has its own global status and enable registers that are an aggregate of all interrupts in the group. These status and enable registers have the same properties as the individual interrupt status and enable registers.
	1678	+
	1679	+All interrupt groups are ORed and sent out on a signal mci_intr pin.
1203	1680
1204	1681	SW access to all interrupt registers are restricted to MCU.
1205	1682
@@ -1219,11 +1696,15 @@
1219	1696
1220	1697	![](../images/caliptra-ss/docs/images/MCI-error-agg.png)
1221	1698
	1699	+MCI internal hardware fatal errors are reported in HW\_ERROR\_FATAL and can be masked through internal\_hw\_error\_fatal\_mask, except for fsm\_error (bit 3). Its mask field, mask\_fsm\_error, is read-only 0. This boot-FSM error does not generate an MCU interrupt; the SOC handles it while MCU and Caliptra are held in reset.
	1700	+
	1701	+Clearing a fatal status bit does not deassert `all_error_fatal`; reset is required. For fsm\_error, follow the reset-then-W1C steps in [CSS-BootFSM Glitch Protection](#css-bootfsm-glitch-protection).
	1702	+
1222	1703	Aggregate error register assignments are documented in the register specification: TODO: Add a link to rdl -> html file
1223	1704
1224	1705	Regions of 6 bits in the aggregate error registers are reserved for each component.
1225	1706	MCU and Caliptra errors are connected to appropriate severity levels.
1226		-Lifecycle controller, fuse controller and I3C are connected to both severities.
	1707	+Lifecycle controller, fuse controller and I3C are connected to both severities.
1227	1708	Masks are used to set the severity of each error for these components. These can be configured by integrators, ROM, or runtime firmware.
1228	1709
1229	1710	\| Error Register Bits \| Component \| Default Error Severity \| Description \|
@@ -1239,20 +1720,29 @@
1239	1720
1240	1721	![](../images/caliptra-ss/docs/images/MCI-internal-error.png)
1241	1722
	1723	+Masking exception: HW\_ERROR\_FATAL.fsm\_error bypasses the programmable hardware-fatal masking shown in this diagram and cannot be masked.
1242	1724
1243	1725	### MCI Fuse Storage Support
	1726	+
1244	1727	MCI also provides capability to store fuses required for Caliptra subsystem for Caliptra core's usage for production debug unlock feature. MCU will read the fuse controller for the production debug unlock hashes , write to the corresponding registers in the MCI block and lock the registers from being changed by MCU RT FW. Lock is done by writing to do a FUSE_WR_DONE (FIXME: Add specific register & bit names).
1245	1728
1246	1729	### MCU Timer
	1730	+
1247	1731	Standard RISC-V timer interrupts for MCU are implemented using the mtime and mtimecmp registers defined in the RISC-V Privileged Architecture Specification. Both mtime and mtimecmp are included in the MCI register bank, and are accessible by the MCU to facilitate precise timing tasks. Frequency for the timers is configured by the SoC using the dedicated timer configuration register, which satisfies the requirement prescribed in the RISC-V specification for such a mechanism. These timer registers drive the timer_int pin into the MCU.
1248	1732
1249	1733	### MCU Trace Buffer
1250	1734
1251	1735	![](../images/caliptra-ss/docs/images/MCI-MCU-Trace-Buffer-Diagram.png)
1252	1736
1253		-MCI hosts the MCU trace buffer. It can hold up to 64 trace packets from the MCU, see [MCU Trace Buffer Packet](#mcu-trace-buffer-packet) for the data format. Read access to the trace buffer is controlled by the LCC state Translator. When Debug Locked all AXI and DMI accesses to the trace buffer are rejected. See [MCU Trace Buffer Error Handling](#mcu-trace-buffer-error-handling) for expected response while Debug Locked.
1254		-
1255		-MCU RISC-V processor can enable/disable tracing with an internal CSR, by default it is enabled. Within MCI there is no way to disable traces.
	1737	+MCI hosts the MCU trace buffer. It can hold up to 64 trace packets, see [MCU Trace Buffer Packet](#mcu-trace-buffer-packet) for the data format. Read access to the trace buffer is controlled by the LCC state Translator. When Debug Locked all AXI and DMI accesses to the trace buffer are rejected. See [MCU Trace Buffer Error Handling](#mcu-trace-buffer-error-handling) for expected response while Debug Locked.
	1738	+
	1739	+Note: trace is collected continuously whenever the selected trace source is valid, independent of the security state; the debug-unlock gate applies only to read access (AXI/DMI), not to collection.
	1740	+
	1741	+##### Trace Source Select (MCU vs Caliptra core)
	1742	+
	1743	+The trace buffer can capture the instruction-retire trace of either the MCU (VeeR) core or the Caliptra core. The source is selected by the `CTRL.cptra_core_sel` field in the trace buffer CSR (0 = MCU core trace, the default; 1 = Caliptra core trace).
	1744	+
	1745	+MCU RISC-V processor can enable/disable its own tracing with an internal CSR, by default it is enabled. Within MCI there is no way to disable traces; only the read-access debug gating and the source select above apply.
1256	1746
1257	1747	The trace buffer is a circular buffer where the oldest data is overwritten by new traces when the buffer is full. When a trace packet is stored the write pointer increments by [MCU Trace Buffer Packet Size](#mcu-trace-buffer-packet)/DWORD
1258	1748
@@ -1261,12 +1751,13 @@
1261	1751	![](../images/caliptra-ss/docs/images/MCI-MCU-Trace-Buffer-Circular-Diagram.png)
1262	1752
1263	1753	#### MCU Trace Buffer SW Interface
	1754	+
1264	1755	Below is the SW interface to extract trace data:
1265	1756
1266		-\| Register Name \| Access Type \| Description \|
1267		-\| :--------- \| :--------- \| :---------\|
	1757	+\| Register Name \| Access Type \| Description \|
	1758	+\| :--------- \| :--------- \| :---------\|
1268	1759	\| DATA \| RO \| Trace data at READ_PTR location\|
1269		-\| READ_PTR \| RW \| Read pointer in trace buffer for DATA. NOTE: this is not an address, meaning increment by 1 to get the next entry. \|
	1760	+\| READ_PTR \| RW \| Read pointer in trace buffer for DATA. NOTE: this is not an address, meaning increment by 1 to get the next entry. \|
1270	1761	\| WRITE_PTR \| RO \| Offset to store next trace entry in trace buffer. If VALID_DATA is set, WRITE_PTR - 1 is the newest trace entry. \|
1271	1762	\| STATUS.VALID_DATA \| RO \| Indicates at least one entry is valid in the trace buffer. \|
1272	1763	\| STATUS.WRAPPED \| RO \| Indicates the trace buffer has wrapped at least once. Meaning all entries in the trace buffer are valid. If 0, then the oldest entry in the buffer is at ptr=0. If 1, the oldest entry is at WRITE_PTR\|
@@ -1280,7 +1771,7 @@
1280	1771
1281	1772	![](../images/caliptra-ss/docs/images/MCI-MCU-Trace-Buffer-Data.png)
1282	1773
1283		-Assuming there is only one trace stored in the trace buffer the WRITE_PTR would read as 0x4. To get the entire trace packet the user would need to read offsets 0x0, 0x1, 0x2, and 0x3.
	1774	+Assuming there is only one trace stored in the trace buffer the WRITE_PTR would read as 0x4. To get the entire trace packet the user would need to read offsets 0x0, 0x1, 0x2, and 0x3.
1284	1775
1285	1776	#### MCU Trace Buffer Extraction
1286	1777
@@ -1289,7 +1780,7 @@
1289	1780	1. Write READ_PTR
1290	1781	2. Read DATA
1291	1782
1292		-Repeat these steps until all data required has been extracted.
	1783	+Repeat these steps until all data required has been extracted.
1293	1784
1294	1785	The user should use the combination of WRITE_PTR, VALID_DATA, WRAPPED, and TRACE_BUFFER_DEPTH to know where valid data lives in the trace buffer.
1295	1786
@@ -1297,21 +1788,20 @@
1297	1788
1298	1789	AXI access to the MCU Trace Buffer while not in debug mode will result in an AXI error.
1299	1790
1300		-DMI access to the MCU Trace Buffer while not in debug mode will result in writes being dropped and reads returning 0.
1301		-
1302		-If the user sets the READ_PTR > (TRACE_BUFFER_DEPTH - 1) and tries to read the DATA register, the behavior is undefined.
	1791	+DMI access to the MCU Trace Buffer while not in debug mode will result in writes being dropped and reads returning 0.
	1792	+
	1793	+If the user sets the READ_PTR > (TRACE_BUFFER_DEPTH - 1) and tries to read the DATA register, the behavior is undefined.
1303	1794
1304	1795	## MCI Debug
1305	1796
1306	1797	### MCI Debug Access
1307	1798
1308		-MCI provides DMI access via MCU TAP and a DEBUG AXI USER address for debug access to MCI.
	1799	+MCI provides DMI access via MCU TAP and a DEBUG AXI USER address for debug access to MCI.
1309	1800
1310	1801	#### MCI DMI
1311	1802
1312	1803	NOTE: DMI access to MBOX0/1 is not enabled in Caliptra 2.0. This will be enabled in future Caliptra versions
1313	1804	![](../images/caliptra-ss/docs/images/MCI-DMI-Interface.png)
1314		-
1315	1805
1316	1806	The DMI port on MCU is a dedicated interface that is controlled via the MCU TAP interface. MCI provides two services when it comes to DMI:
1317	1807
@@ -1328,15 +1818,13 @@
1328	1818	2. Uncore
1329	1819	- Access to MCI registers
1330	1820
1331		-
1332	1821	MCI provides the logic for these enables. When the following condition(s) are met the enables are set:
1333	1822
1334	1823	MCU Core Enable: Debug Mode
1335	1824
1336		-MCU Uncore Enable: Debug Mode OR LCC Manufacturing Mode OR DEBUG_INTENT strap set
1337		-
1338		-Note: These are the exact same controls Calipitra Core uses for DMI enable
1339		-
	1825	+MCU Uncore Enable: Debug Mode OR LCC Manufacturing Mode OR debug intent asserted (effective debug intent — physical strap OR `SS_DEBUG_INTENT_MCU`)
	1826	+
	1827	+Note: These are the exact same controls Calipitra Core uses for DMI enable
1340	1828
1341	1829	##### MCI DMI Interface
1342	1830
@@ -1397,32 +1885,31 @@
1397	1885	\| CPTRA\_BOOT\_GO \| 0x75 \| RW \| \| Yes \|
1398	1886	\| FW\_SRAM\_EXEC\_REGION\_SIZE \| 0x76 \| RW \| \| Yes \|
1399	1887	\| MCU\_RESET\_VECTOR \| 0x77 \| RW \| \| Yes \|
1400		-\| SS\_DEBUG\_INTENT \| 0x78 \| RW \| \| Yes \|
	1888	+\| SS\_DEBUG\_INTENT \| 0x78 \| RO \| \| Yes \|
1401	1889	\| SS\_CONFIG\_DONE \| 0x79 \| RW \| \| Yes \|
1402	1890	\| SS\_CONFIG\_DONE\_STICKY \| 0x7A \| RW \| \| Yes \|
1403	1891	\| MCU\_NMI\_VECTOR \| 0x7B \| RW \| \| Yes \|
1404	1892	\| MCI\_DMI\_MCI\_HW\_OVERRIDE ([DMI ONLY Reg](#dmi-only-registers)) \| 0x7C \| RW \| \| Yes \|
1405	1893
1406		-###### DMI Only Registers
	1894	+###### DMI Only Registers
1407	1895
1408	1896	MCI\_DMI\_MCU\_HW\_OVERRIDE
1409	1897
1410		-\| Field Name \| Bits \| Access Type \| Description \|
1411		-\| :---- \| :---- \| :---- \| :---- \|
	1898	+\| Field Name \| Bits \| Access Type \| Description \|
	1899	+\| :---- \| :---- \| :---- \| :---- \|
1412	1900	\| `mcu_sram_fw_exec_region_lock` \| [0] \| RW \| mcu_sram_fw_exec_region_lock control. ORed with input signal giving debugger control if Caliptra Core in reset while attempting MCU reset flow. \|
1413	1901	\| `reserved` \| [31:1] \| RW \| Reserved \|
1414	1902
1415		-
1416	1903	##### DMI MCU SRAM Access
1417	1904
1418	1905	MCU SRAM is only accessable via DMI while in Debug Unlock. While in Debug Unlock DMI has RW permission to the entire MCU SRAM.
1419	1906
1420	1907	Due to limited DMI address space the MCU SRAM is accessable via a two register mailbox.
1421	1908
1422		-* `MCU_SRAM_ADDR`
1423		-* `MCU_SRAM_DATA`
1424		-
1425		-The first MCU SRAM address is at address 0x0. The address is byte addressable, but all accesses must be DWORD aligned. Failure to align the address will result in undefined behavior. Access to addresses beyond the MCU SRAM size will result in address wrapping.
	1909	+- `MCU_SRAM_ADDR`
	1910	+- `MCU_SRAM_DATA`
	1911	+
	1912	+The first MCU SRAM address is at address 0x0. The address is byte addressable, but all accesses must be DWORD aligned. Failure to align the address will result in undefined behavior. Access to addresses beyond the MCU SRAM size will result in address wrapping.
1426	1913
1427	1914	To write content to the MCU SRAM the flow is:
1428	1915
@@ -1434,20 +1921,19 @@
1434	1921	1. Write `MCU_SRAM_ADDR`
1435	1922	2. Read `MCU_SRAM_DATA`
1436	1923
1437		-There is no error response on the DMI port, so any ECC error must be checked via the ECC registers in the MCI Register Bank.
	1924	+There is no error response on the DMI port, so any ECC error must be checked via the ECC registers in the MCI Register Bank.
1438	1925
1439	1926	Important: MCU core must be halted to access MCU SRAM via DMI. Failure to do so will result in collisions between the two interfaces and an error will be reported.
1440	1927
1441		-
1442	1928	##### DMI MCU Trace Buffer Access
1443	1929
1444	1930	Access to the MCU Trace buffer via DMI is the same SW interface as specified in [MCU Trace Buffer](#mcu-trace-buffer).
1445	1931
1446		-Access is limited to Debug Unlock mode only. Access to this space while not in Debug Unlock will result in writes being dropped and reads return 0x0.
	1932	+Access is limited to Debug Unlock mode only. Access to this space while not in Debug Unlock will result in writes being dropped and reads return 0x0.
1447	1933
1448	1934	### MCI Boot FSM Breakpoint
1449	1935
1450		-The MCI Breakpoint is used as a stopping point for debugging Caliptra SS. At this breakpoint the user can either use one of the [MCI Debug Access](#MCI-Debug-Access) mechanisms to configure MCI before bringing MCU or Caliptra out of reset.
	1936	+The MCI Breakpoint is used as a stopping point for debugging Caliptra SS. At this breakpoint the user can either use one of the [MCI Debug Access](#mci-debug-access) mechanisms to configure MCI before bringing MCU or Caliptra out of reset.
1451	1937
1452	1938	#### MCI Boot FSM Breakpoint Flow
1453	1939
@@ -1455,7 +1941,7 @@
1455	1941	2. Deassert MCI Reset
1456	1942	3. DEBUG ACCESS TO MCI
1457	1943	4. Set MCI's BRKPOINT_GO register to 1
1458		- - Through one of the [MCI Debug Access](#MCI-Debug-Access) methods.
	1944	+ - Through one of the [MCI Debug Access](#mci-debug-access) methods.
1459	1945	5. FSM will continue
1460	1946
1461	1947	## MCI Design for Test (DFT)
@@ -1463,3 +1949,64 @@
1463	1949	### Reset Controls
1464	1950
1465	1951	MCI controls various resets for other IPs like MCU and Caliptra Core. When the `scan_mode` input port is set these resets are directly controlled by the mcu_rst_b input intead of the internal MCI logic.
	1952	+
	1953	+# Caliptra SS USB2
	1954	+
	1955	+- Caliptra Subsystem 2.2 provides USB2 support
	1956	+- USB2 supports two USB devices - one for Caliptra MCU usage and one for SOC usage. Both the USB devices are independent of each other. Each device has a separate AXI interfaces with a dedicated DMA SRAM.
	1957	+- Caliptra SS MCU uses USB Device 0 for streaming boot and MCU supported MCTP scenarios (eg. SPDM, PLDM)
	1958	+- Note: USB Device 1 is dedicated to SOC usage model. SOC usage has all 30 EPs for its usage.
	1959	+- Please refer to USB2 specification in the [USB2 repo](https://github.com/chipsalliance/USB2) for more details such as
	1960	+ - USB2 architecture and microarchitecture
	1961	+ - Virtual hub programming (Caliptra MCU responsibility)
	1962	+ - USB device programming
	1963	+ - OCP streaming boot microarchitecture implemented in USB device 0
	1964	+ - Multi-Device support microarchitecture
	1965	+
	1966	+## Combo AXI memory map
	1967	+
	1968	+The Combo (COMB) AXI interface routes accesses to DEV0 control/status registers, the OCP Recovery interface, and the Hub. The following map uses the default `USB_C_HUB_FIFO_SIZE = 172` words. Offsets are byte offsets from the SoC-assigned Combo base address.
	1969	+
	1970	+\| Internal block \| Start offset \| End offset \|
	1971	+\|:---------------\|:-------------\|:-----------\|
	1972	+\| DEV0 CSRs \| `0x0000` \| `0x003F` \|
	1973	+\| Unmapped (fixed) \| `0x0040` \| `0x07FF` \|
	1974	+\| OCP Recovery interface \| `0x0800` \| `0x0FFF` \|
	1975	+\| Hub control and descriptor store (parameter-dependent end) \| `0x1000` \| `0x13FF` \|
	1976	+\| Unmapped after Hub (parameter-dependent) \| `0x1400` \| `0x1FFF` \|
	1977	+
	1978	+`USB_C_HUB_FIFO_SIZE` changes the Hub end offset and the trailing unmapped range; the earlier ranges stay fixed. Calculate the boundaries as follows (`ceil` rounds up):
	1979	+
	1980	+```text
	1981	+N = USB_C_HUB_FIFO_SIZE (172 to 4096 DWORDs inclusive; default 172)
	1982	+H = 4 * 2^ceil(log2(N)) (Hub aperture in bytes)
	1983	+U = 0x1000 + H (first byte offset after Hub)
	1984	+C = 2^ceil(log2(U)) (Combo window size in bytes)
	1985	+```
	1986	+
	1987	+The Hub ends at `U - 1`. The trailing unmapped range is `U` through `C - 1`; if `U == C`, no trailing unmapped region exists.
	1988	+
	1989	+## Ownership and access
	1990	+
	1991	+\| Policy group \| Protected resources \| Ownership / usage \|
	1992	+\|:-------------\|:--------------------\|:------------------\|
	1993	+\| Combo \| Combo AXI interface: DEV0 CSRs, Hub control/descriptor storage, and Recovery registers; DEV0 memory AXI interface \| MCU owns DEV0 and Hub; Caliptra DMA accesses Recovery registers and drains the recovery FIFO \|
	1994	+\| DEV1 \| DEV1 CSR and DEV1 memory AXI interfaces \| A designated SoC firmware agent owns DEV1; MCU access is optional \|
	1995	+
	1996	+All identities in an allowlist receive the same filter-level read/write authorization across that group. The [integration requirements](CaliptraSSIntegrationSpecification.md#axi-user-filtering) specify which identities the SoC must authorize.
	1997	+
	1998	+## AXI USER filtering
	1999	+
	2000	+The Combo and DEV1 policies have independent allowlists and active-high filtering enables. With filtering enabled, a read's `ARUSER` or a write's `AWUSER` must exactly match an entry in the corresponding allowlist. Disabling a filter permits all identities through that filter; see [USB and I3C AXI Access Control](CaliptraSSIntegrationSpecification.md#usb-and-i3c-axi-access-control).
	2001	+
	2002	+The decision is captured when the read or write address is accepted and retained for the entire request. Later policy changes do not revoke already accepted requests. A denied request never accesses the target: a denied read returns zero data and `SLVERR` on every requested beat; a denied write discards all requested data beats and returns one `SLVERR` response.
	2003	+
	2004	+Every allowlist entry participates; there are no per-entry enable bits.
	2005	+
	2006	+Enables and allowlists are live inputs, not internally sampled straps. The USB block supplies no policy configuration registers, lock, implicit policy defaults, or automatic MCU/Caliptra authorization. SoC provisioning, locking, and reset obligations are defined in [USB and I3C AXI Access Control](CaliptraSSIntegrationSpecification.md#usb-and-i3c-axi-access-control).
	2007	+
	2008	+## DWORD-only accesses
	2009	+
	2010	+All four USB AXI interfaces support only aligned 32-bit DWORD accesses, including Hub descriptor, packet SRAM, and Recovery register/FIFO accesses. USB does not honor `WSTRB` masking, so deasserted strobes do not suppress writes.
	2011	+
	2012	+These are AXI-bus restrictions, not USB packet-length restrictions. The [AXI Access Restrictions](CaliptraSSIntegrationSpecification.md#axi-access-restrictions) specify the required transfer format and software restrictions.

Changes to Subsystem Hardware Specification

Image Changes

v2.0: AXI-Recovery-Handler-Bypass.png

v2.1: AXI-Recovery-Handler-Bypass.png

v2.0: AXI-Recovery-Handler.png

v2.1: AXI-Recovery-Handler.png

v2.0: CSS2p2.png

v2.1: CSS2p2.png

v2.0: Caliptra-AXI-DMA-AES.png

v2.1: Caliptra-AXI-DMA-AES.png

v2.0: Caliptra-AXI-DMA-RD-WR.png

v2.1: Caliptra-AXI-DMA-RD-WR.png

v2.0: Caliptra-AXI-DMA-RD.png

v2.1: Caliptra-AXI-DMA-RD.png

v2.0: Caliptra-AXI-DMA-WR.png

v2.1: Caliptra-AXI-DMA-WR.png

v2.0: Caliptra-AXI-DMA.png

v2.1: Caliptra-AXI-DMA.png

v2.0: Caliptra-SS-BootFSM.png

v2.1: Caliptra-SS-BootFSM.png

v2.0: LCC-Summary.png

v2.1: LCC-Summary.png

v2.0: MCI-Integ-Block-Diagram.png

v2.1: MCI-Integ-Block-Diagram.png