Initial draft of OCP Global Demo Proposal. - #456
CourtneyDrant wants to merge 1 commit into
Conversation
Looking at the diagram, how can the BMC be informed about an invalid image when it is not booted yet?
|
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
|
How does the BMC signal to the eRoT a successfull boot? How do we distinguish it from a hung BMC? What happens on failure? |
|
Maybe do 12 (Mark B as active) first, then 11 (Erase staging area). Otherwise, in case there is a power outage between 11 and 12, we would need to retransfer the firmware over PLDM. Or maybe even better: Erase staging area after successful boot? |
|
Small issues:
CAD: Will fix. ActivatePendingComponentImage is a T5 Command used while FSM is "IDLE" for FW activation without Component Image Transfer. |
|
Why do we do this "Update inactive slot A to match slot B"? Don't we want to keep a "previously known-good firmware" for rollback? What if the BMC turns out to have a broken daemon or service or so? ("requires mastership and ANOTHER BMC power cycle") |
|
It looks like in case of image bad, we still end up in good update completed after the BMC boot completes. |
|
Maybe the diagram should start by the BMC writing the new firmware image into the SPI? |
|
Should we also add Timeouts into this sequence diagram, e.g. boot timeout? |
| participant OpenProt as OpenProt | ||
| participant fwspi as BMC SPI bus (fwspi) | ||
|
|
||
| BMC->>OpenProt: GetFirmwareParameters |
There was a problem hiding this comment.
Add the trigger event to the flow - The flow diagram never shows the event triggering the flow - an external agent writing the flash image to the staging area - The first documented event is GetFirmwareParameters, and by the time OpenPRoT does "Verify BMC image in staging area," the diagram just assumes the image is already sitting there.
There was a problem hiding this comment.
actually, it would be the update agent on BMC that needs to know how to update the staging area and coordinate the PLDM flow alongside that. Some external agent would provide the image to the OpenBMC update image, but we don't care about that part.
So yes, we need to show the update agent performing these steps either before or during the PLDM steps.
|
@CourtneyDrant , I have proposed some changes to the flow as a PR to your fork. |
| participant OpenProt as OpenProt | ||
| participant fwspi as BMC SPI bus (fwspi) | ||
|
|
||
| BMC->>OpenProt: GetFirmwareParameters |
There was a problem hiding this comment.
We need to add an explicit causal link between the staging firmware and the GetFirmwareParameters command.
| Note over OpenProt,BMC: OpenProt disables access by BMC (notify BMC to shutdown, then pull power) | ||
|
|
||
| OpenProt->>fwspi: Claim mastership | ||
| OpenProt->>OpenProt: Verify BMC image in staging area |
There was a problem hiding this comment.
OpenPRoT must persist the outcome of the verification process across the power cycle. UA will poll for it later when it comes back up.
There was a problem hiding this comment.
some breadcrumbs should be put in place to help the system recover properly in the event of a power failure, but in the normal case, the external PRoT itself would not be power cycled here, just the BMC being updated.
There was a problem hiding this comment.
@FerralCoder Maybe @rusty1968 is referring to the self-update case?
|
ActivatePendingComponentImage should be sent only when FD or FDP is in the IDLE state. From your proposal, do you think FD (PRoT) is in the IDLE state when ActivatePendingComponentImage command is issued from BMC? |
Yes, the FD is in Idle until it receives a RequestUpdate. In this flow, there are no RequestUpdates. If in the future we want to support RequestUpdate and ActivatePendingComponentImage, we would deny the ActivatePending if already in an RequestUpdate flow. The UA would then need to retry. |
6 participants
No description provided.