There are two PPKs in Zynq UltraScale+ MPSoC. Each PPK has a set of invalid bits, (PPK0_INVLD and PPK1_INVLD) implemented as eFUSEs, that can be programmed to permanently revoke the PPK from use. If either of these eFUSEs is programmed, the PPK is revoked. This Figure shows a notional and proposed method to perform a remote update forced by the revocation of the PPK.
In the notional system, it is assumed that resident in external memory is the design authenticated with PPK0 (DesignPPK0) and a golden image, also signed with PPK0 (Golden DesignPPK0). Some applications choose to use a golden image as a backup. The golden image is not full-featured, but provides basic diagnostic and communication in the event of a failed boot of the primary image. Again, this is a representative system used to describe the process of updating a system in the event of a primary key revocation, and not a requirement.
The initial design, DesignPPK0, is notified when a remote update is being performed (in many cases the design itself is responsible for supporting the remote update). DesignPPK0 writes to the multi-boot register and then initiates a reset. DesignPPK1 is booted, and if successful, begins operation. DesignPPK1 should update the golden image (if necessary) and then program the eFUSEs to revoke PPK0. In the event of a failed boot, the CSU updates the multi-boot register and initiates a reset. As the golden image is stored at a higher address in external memory, it is ultimately loaded and communication is established. For more information on the golden image, see Golden Image Search.