Hard Processor System Technical Reference Manual: Agilex™ 3 SoCs

ID 848530
Date 6/23/2025
Public

Visible to Intel only — GUID: pmh1677546544751

Ixiasoft

Document Table of Contents

A.2.2. HPS Use of SDM QSPI Controller Use Cases

On power up, the SDM owns the QSPI controller. In order for the HPS to use the QSPI controller, the HPS must request ownership from the SDM.

Once the HPS obtains ownership of the QSPI controller, it retains ownership until the next power cycle, HPS reset, or an HPS reboot generated from an RSU event.

Note:

Quartus® Prime Pro Edition software allows you to select the QSPI controller ownership for either SDM or QSPI. In any case, the SDM still gets the ownership of the QSPI controller at power up and after this, the following two scenarios can occur:

  1. If QSPI ownership is assigned to SDM from the Quartus® Prime Pro Edition software, SDM keeps the ownership and will reject the QSPI_DIRECT command from the HPS (through the HPS-to-SDM mailbox) to request the ownership. This means that the HPS cannot perform direct access to the QSPI controller.
  2. If QSPI ownership is assigned to HPS from the Quartus® Prime Pro Edition software, HPS is granted with the ownership once it requests it with the QSPI_DIRECT command (through the HPS-to-SDM mailbox). This means that the HPS can perform direct access to QSPI controller.

This feature was implemented to enhance security in features that requires the SDM owns the QSPI like attestation, BKPS or any other that requires to keep an encryption key in the QSPI flash device.

Refer to the Device and Pin Options in the Hard Processor System Booting User Guide: Agilex™ 3 and Agilex™ 5 SoCs for more information about the QSPI controller ownership selection.

The following details the typical flow for the HPS to use the QSPI controller:

  1. The bootloader passes the value of the QSPI controller reference clock to the end application or operating system.
  2. The end application uses the QSPI controller.

For the Linux use case, the U-Boot passes the value of the QSPI reference clock into the Linux device tree. In the Remote System Update (RSU) flow, the U-Boot also patches the Linux device tree to create the first mtd partition in the flash device, starting at the location of the SPT0. This approach is done to minimize the risk of corruption of DCMF, DCIO, and factory image, which are located outside of this partition (below the SPT0).