Introduction

The Altera SoC Development board Rev C successfully boots from QSPI after a POR (power on reset) but in most situations it cannot re-boot from QSPI after either a COLD or WARM reset.

The problem arises from the fact that the BootROM needs the QSPI Flash part to be in the default 3-byte addressing mode, but the QSPI part is configured by the software (Preloader, U-boot, Linux) to work in 4-byte addressing mode.

This document presents the problem in detail and explains the possible solutions. It also highlights the solution that will be used by the Altera SoC Development board Rev D, which involves resetting the QSPI flash part at each reboot.

HPS QSPI Support

The Cyclone V SoC and Arria V SoC devices offer the user the ability to boot the Cortex A9 cluster from a serial NOR flash device using the Quad SPI Flash Controller IP that is built into the HPS core.

The QSPI Flash Controller supports operation with industry standard SPI flash devices as well as higher performance dual and quad SPI flash devices.

The HPS boot ROM that is executed by the Cortex A9 cluster following a cold or warm reset event is configured in such a way that it could support booting from any SPI flash device that can operate with the Quad SPI Flash Controller, SPI, Dual SPI or Quad SPI.

The HPS boot ROM accomplishes this by using a very common configuration setup that all of these devices share regardless of single, dual or quad signaling capability or device density.

Challenges can arise when using more advanced and high density serial flash devices that can operate in modes more capable than the common configuration that is assumed by the HPS boot ROM.

HPS Boot ROM Requirements

When booting from QSPI, the HPS accesses the Flash in a read-only mode. It loads the Preloader image from Flash to OCRAM (On Chip RAM), validates it and then passes control to it.

To accomplish this goal, the HPS Boot ROM is implemented with the following requirements for the QSPI Flash part:

• Single Bit I/O mode (for both commands and data) must be enabled
• 3 byte address mode must be enabled
• Normal read command (0x03) must be available
• The baud rate of the SPI clock is compatible with the serial flash device.

These requirements are fundamentally supported by most serial flash devices from most vendors, as the default setting after powering up or resetting the QSPI Flash part. They represent the minimal requirements that allow the HPS Boot ROM to successfully read out the Preloader that it is looking for.

Serial Flash Challenges

There are many vendors of serial flash devices on the market today. These vendors offer a broad selection of devices with various capabilities and densities.

A large number of the basic operations performed by these serial flash devices use common and compatible instructions and signaling characteristics. However, some vendors implement proprietary instructions and signaling requirements for their devices. There is no formal standardization of the communication protocols used by the serial flash vendors.

By necessity the Boot ROM has to use the common denominator of all the flash devices and use only features that are supported by all devices. Also, the Boot ROM has to make some assumptions about the state of the QSPI Flash part.

Some of the areas that can cause problems for the HPS boot ROM are these:

• 4-byte Addressing Mode. For serial flash devices that are larger than 16MB, 4-byte addressing mode is required to address the entire contents of the flash. Each vendor offers ways in which the extra span may be addressed, some of these methods are compatible across serial flash vendors, and some of them are not. Some vendors support paging or segment registers, some vendors offer volatile and non-volatile address mode configuration bits, some vendors offer specific instructions for each address mode, and some vendors offer multiple variations of all of these options.
• Multi-bit Command Signaling. Serial flash devices with more than single channel communication capability can offer multi-bit command signaling which can be setup with volatile and non-volatile configuration bits.
• Persistent Segment or Page Register. Many serial flash devices offer a segment or page register that can be used to hold the upper 4th byte of addressing information such that the normal 3 byte addressing mode is still used over the serial channel, but setting this type of register would again leave the serial flash device in an incompatible mode that the HPS boot ROM cannot communicate with.
• Non-volatile Settings - for any of the above. Many serial flash devices contain non-volatile configuration bits that can alter the default power-on reset state of the device as well as the run time default reset state of the device such that the address mode, segment or page register and even multi-bit command modes can be enabled as the default state for the device. Enabling any of these non-volatile capabilities would create a situation that the HPS boot ROM would never be able to recover from and a hardware reset or even a power cycle of the serial flash device would not create a compatible state for the HPS boot ROM to deal with.
• Serial Flash Reset. When a serial flash device is placed into 4 byte addressing mode or multi-bit command signaling mode it becomes necessary to reset these devices to get into a known mode of operation. Some flash devices carry reset pins, some do not, some flash devices have reset commands, some do not, reset commands tend to be incompatible across serial flash vendors. Because of these issues, the Boot ROM cannot reset the QSPI part by itself.

HPS Reset Considerations

This section describes some aspects of the HPS reset that are relevant for the QSPI booting.

HPS supports two types of resets: COLD resets and WARM resets.

COLD resets ca be generated from the following main sources:

• nPOR pin input being pulled low
• Software writing rstmgr.ctrl.swcoldrstreq
• FPGA sending a COLD reset request

WARM resets ca be generated from the following main sources:

• nRST pin input being pulled low
• Software writing rstmgr.ctrl.swwarmrstreq
• FPGA sending a WARM reset request
• Watchdogs

The following two signals are available as HPS pins:

• nPOR - COLD reset signal, input only. It is used to issue a COLD reset signal to HPS.
• nRST - WARM reset signal, bidirectional. It can be used to instruct HPS to perform a WARM reset. It is also driven by HPS when a WARM reset is produced internally (issued by software, watchdogs or from FPGA)

Note that all the WARM resets are visible outside the chip because the nRST signal is bidirectional. On the other hand, the internally generated COLD resets are not visible outside the chip, because the nPOR signal is input only.

When a WARM reset is generated from internal sources (software, watchdog or FPGA) the nRST signal is asserted for a software controlled amount of time. This is accomplished by writing to the rstmgr.counts.nrstcnt.

Possible Solutions

This section presents the different possible approaches that can be used to be able to re-boot successfully from a QSPI Flash device.

Solution #1: Use QSPI Flash Part < 16MB

When using a QSPI Flash device with a size less than 16MB, there is no need to switch to the 4-byte addressing mode. Therefore the re-boot after both COLD and WARM resets would be successful.

Please note that even in this situation the software must still make sure that it does not use the rest of the potentially problematic issues listed in the "Serial Flash Challenges" section. For example if persistent multi bit command modes or other conflicts arise in these smaller flash devices, then reset synchronization may be required.

Solution #2: Reset QSPI Flash Part before Reboot

This solution involves making sure that the QSPI Flash part is reset each time the HPS is re-booted. It involves the following:

• Use QSPI Part with RESET pin
• Combine HPS WARM and COLD reset signals and drive QSPI Flash reset each time an HPS reset happens. AND gate shown because REST signals have negative logic.

In addition to the above change, since the internally generated COLD resets are not visible outside, the following requirement must also be met:

• Internally generated COLD resets (from software or FPGA) must be preceded by manually resetting the QSPI flash part either by using manufacturer specific QSPI commands, or by using a GPIO connected to the QSPI flash part reset pin.

Alternatively the internally generated COLD resets can be avoided by design, since they are always intentionally issued, as opposed to WARM resets that can happen out of software or FPGA control, for example because of a watchdog timeout.

Solution #3: Use QSPI Flash With Extended 4-byte Addressing Commands

Some QSPI flash manufacturers, like Spansion, offer an extended command set, that allows 4-byte addressing to be used without switching the chip to 4-byte addressing mode.

Important Note: Current software implementation of Preloader, U-boot and Linux do not support the extended 4-byte addressing commands available on some QSPI flash parts.

Please note that even in this situation the software must still make sure that it does not use the rest of the potentially problematic issues listed in the "Serial Flash Challenges" section. For example if persistent multi bit command modes or other conflicts arise in these smaller flash devices, then reset synchronization may be required.

Solution #4: Promote WARM Resets to COLD Resets

This solution is similar with the solution implemented on the Altera SoC Development board Rev D with the exception that the external reset monitor and generator detects the WARM resets and converts them to COLD resets.

Whenever the reset generator and monitor detects a WARM reset, it will assert the COLD reset pin to HPS. When this happens, the WARM reset sequence will be aborted, and a COLD reset sequence will be initiated by HPS.

The advantages of this solution are:

• Internally generated COLD resets will eventually result in successful booting, even if software does not explicitly reset the QSPI flash part before issuing the COLD reset. This is because first the boot will fail, then after 1-2s (depending on external clock) the watchdog will generate a WARM reset, that will be observed by the reset monitor and converted to a COLD reset that will be successful. The boot will succeed because in this case the QSPI flash part is also reset by the monitor.
• There is no need for two reset generators, just one, potentially reducing the amount of circuitry

A few more observations about this solution:

• FPGA generated COLD reset events can occur, however a recovery delay of the watchdog timeout period may result.
• This configuration essentially removes the unique features provided by WARM reset events, since any WARM reset event will create a COLD reset event.

Solution That Will be Implemented by Altera SoC Development board Rev D

The Altera SoC Development board Rev D implements Solution #2: Reset QSPI Flash Part before Reboot.

Specific implementation details:

• Use QSPI Flash part with a RESET pin. QSPI Flash part N25Q00AA13GSF40F is replaced by N25Q512A83GSF40F
• The HPS WARM and COLD reset pins are connected to the onboard MAX V CPLD device
• QSPI Flash RESET pin is driven by the onboard MAX V CPLD that ANDs together the WARM and COLD reset signals.

References

• Altera Cyclone V SoC Board
• Cyclone V Quad SPI Flash Controller
• Cyclone V Booting and Configuration
• Cyclone V Reset Manager
• N25Q00AA13GSF40F Datasheet
• N25Q512A83GSF40F Datasheet