Intel Agilex® 7 Hard Processor System Remote System Update User Guide

ID 683184
Date 6/09/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

8.5.2. Using Multiple SSBLs with QSPI

This section presents the recommended approach to support multiple SSBLs when they are stored in the SDM QSPI flash.

Changes required in the Programming File Generator, at initial image creation time:
  • Use the default naming scheme for the bitstream partitions:
    • FACTORY_IMAGE for factory image
    • P1, P2, and so on for application images
  • Make copies of the U-Boot image files (u-boot-socfpga/u-boot-dtb.img) to have the .bin extension, as that is what the Programming File Generator requires for binary files. For example name them u-boot-socfpga/u-boot-dtb.img.bin
    Attention: Intel® Quartus® Prime Programming File Generator version 21.2 has an issue which causes block partitions (specified by entering the start and end address of the partition) containing raw data files (.hex, .bin, .puf or .wkey) to have incorrect content. Intel® Quartus® Prime Pro Edition software version 21.2 Patch 0.14 fixes this issue.
  • In the Input Files tab, click the Add Raw button, then select the .bin file filter at the bottom and browse for the renamed U-Boot image file. Once added, click the file to select it, then click Properties on the right. Make sure to change the “Bit-swap” option from “off” to “on”. This is telling the PFG that it is a regular binary file.
  • Create new partitions to contain SSBLs, one for each bitstream:
    • SSBL partitions are large enough for the U-Boot image (1 MB suffices for most applications)
    • Name the partition with a name that is derived from the bitstream partition name, and is less than 15 characters long (limit for SPT partition name excluding null terminator). For example “FACTORY_IM.SSBL”, “P1.SSBL”, etc.
    • For the initially loaded SSBL partitions, select the corresponding U-Boot binary image files as Input file so that they are loaded with the SSBLs.
  • Generate the initial image.
Changes required in FSBL:
  • Query SDM and read flash to determine all the partition information, and the currently running bitstream location in flash.
  • Look up the currently running bitstream location in the list of the SPT partitions to determine the partition containing the currently running bitstream.
  • Add the “.SSBL” to the name of the currently running partition and find the SSBL partition using that name. Treat “FACTORY_IMAGE” differently as adding “.SSBL” to it can make it longer than the maximum allowable of 15 characters.
  • Instead of loading the SSBL for a hardcoded address, load it from the partition found at the previous step.
If the SSBL is configured with read-only environment, then no changes are needed. If the SSBL is configured with a modifiable environment, then the following changes are recommended:
  • Make the SSBL partitions larger than the maximum anticipated U-Boot image, to accommodate the environment. 1 MB can still suffice, as typical U-Boot image is smaller, and typical environment size is 4 KB.
  • Change the hardcoded value for the SSBL environment address to query SDM for partitioning information and currently running image to determine the name of the current SSBL partition, and use its top portion as environment.
The recommended application image update procedure also changes:
  • Use LIBRSU to erase the application image partition. This also disables it, removing it from the CPB.
  • Use MTD to erase SSBL partition instead of LIBRSU because it does not support erasing raw partitions yet, just bitstreams.
  • Use MTD to write the new contents of the SSBL partition instead of LIBRSU because it does not support writing raw partitions, just bitstreams.
  • Use LIBRSU to write the new application image. This also enables it, putting it as highest priority in the CPB.