PPK Revocation

Versal Adaptive SoC Technical Reference Manual (AM011)

Document ID
Release Date
1.6 English

Each PPK has a set of revocation bits implemented with eFUSEs. Programming these fuses invalidates (revokes) that PPK permanently preventing its use. The following figure demonstrates the OTA use case with the revocation of a PPK (PPK0 in this instance).

Figure 1. Configuration Update with PPK Revocation

In the notional system, it is assumed that a revision of the design (DesignPPK0) and a golden image (GoldenDesignPPK0) are both stored in external memory and both are signed by PSK0 (authenticated by PPK0).

Note: The subtext of the design/image name represents the public version of the key used to sign the image.

Again, this is a representative system used to describe the process of updating a system when it is necessary to revoke a PPK. It is not a requirement.

The initial design, DesignPPK0, is notified when an update is desired. In many cases, the design itself is responsible for supporting the remote update. DesignPPK0 increments the MultiBoot register ( PMC_MULTI_BOOT ) and then initiates a reset. DesignPPK1 is then booted, and if successful, begins operation. DesignPPK1 should then update, if necessary, the golden image and then program the eFUSEs to revoke PPK0. In the event of a failed boot, the RCU increments the MultiBoot register and initiates a reset. As the golden image is stored at a higher address in external memory, it is ultimately loaded, and communication can be re-established (again, assuming this is an OTA case).