Revocation of the SPK is very different than the PPK since the SPK, and its associated ID, are delivered to the Zynq UltraScale+ MPSoC as part of the programming image and authenticated with the PPK. To revoke an SPK, change the SPK ID implemented as eFUSEs inside of the device. If a device boots with an old SPK and SPK ID, the CSU recognizes that the IDs do not match and keeps the device from booting. This Figure shows a notional and proposed method to perform a remote update forced by the revocation of the SPK. There are two very important steps that are performed to avoid any complications in the revocation process.
Once the new design, DesignSPK1, is loaded into external memory, DesignSPK0 verifies the integrity of DesignSPK1. The method to verify the integrity of DesignSPK1 is a user decision. One recommendation is to send a hash of DesignSPK1 with the remote update. DesignSPK0 could then read back DesignSPK1 from external memory, calculate its hash, and then compare it to what was delivered. DesignSPK0 now revokes the SPK by changing the programming of a new SPK ID into the SPK ID eFUSEs. DesignSPK0 reads back the SPK ID to confirm it was programmed correctly. Once these verification steps have been performed, DesignSPK0 can now update the multi-boot register and initiate a software reset for the system to boot using DesignSPK1.