Repository navigation
Conversation
The eRoT serves the OCP Recovery interface as the device and the BMC drives it as the Recovery Agent. This crate holds the half that does not depend on the transport: the command codes 0x22 to 0x2f, the byte layouts, the field encodings and the rules for which accesses the device refuses. The SMBus framing, the PEC and the register file the server-runtime owns come later, so the crate stays host-testable and free of kernel dependencies. The AST1030 has no OCP recovery silicon, so firmware has to keep the access semantics the agent expects from hardware. "Write 1, Device Clears" means the agent writes the command value and the device zeroes the field once it has acted, not a bitwise clear of the written bits: each of the three fields that work that way has an apply_agent_write and a clear_*, and writing 0x1 to the activate field is refused rather than leaving 0xe behind. The writes take a fixed-size array so the length is settled by the type, and RecoveryCommand::check_write resolves it where the bytes arrive off the wire. Signed-off-by: Christina Quast <christina.quast@9elements.com>
This was referenced Oct 28, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Q4 task 4c, first piece. The eRoT serves the OCP Recovery interface as the Device and the BMC drives it as the Recovery Agent. This crate holds the half that does not depend on the transport: the command codes 0x22 to 0x2f with their access rule, length and availability scope, the byte layouts, the field encodings, and the rules for which accesses the Device refuses.
Scope stops at the AMD design gate: no SMBus framing, no PEC, no staging or verify path, no state machine. Those answers (I2C vs I3C, forced recovery, whether the i2c read path is in scope) change the transport and the entry path, not the byte layouts.
The AST1030 has no OCP recovery silicon, so firmware keeps the access semantics the agent expects from hardware.
Write 1, Device Clearson RECOVERY_CTRL byte 2, DEVICE_RESET byte 0 and INDIRECT_FIFO_CTRL byte 1 means the agent writes the command value and the Device zeroes the field once it has acted, not a bitwise clear of the written bits. Each of the three has anapply_agent_writeand aclear_*, and writing 0x1 to the activate field is refused rather than leaving 0xe behind.Writes take a fixed-size array so the length is settled by the type, and
from_wireresolves it once where the bytes arrive.ImageIndexandVendorStatusLenbound the two fields the Device fills, so a Device-side mistake cannot be reported to the agent as a protocol error.Follows the
services/<proto>/apipattern:rust_libraryplusrust_test(crate = ...), zerocopy only, no kernel tags, host-testable.Checked with
bazel test //services/ocp-recovery/api:ocp_recovery_api_test, the clippy aspect, and./pw format --all --check.Stacked PR with the device dispatch follows.