RocketBoards- Home
- Documentation
- Community
- Projects
- Boards
- Agilex 5 SoC
- Agilex 7 SoC
- Arria 10 SoC
- Nallatech 385A - Arria 10 FPGA Network Accelerator Card
- Nallatech 385A-SoC Accelerator Card with Arria 10 FPGA
- ALARIC Instant DevKit ARRIA 10 SoC FMC IDK by REFLEX CES
- Altera Arria 10 SoC Virtual Platform
- Altera Arria 10 SoC Board
- Nallatech 510T compute acceleration card with Intel Arria 10 FPGA
- REFLEX CES Achilles Arria 10 SoC SOM
- Terasic Arria10 SoC Board : HAN Pilot Platform
- Arria V SoC
- Cyclone V SoC
- Altera Cyclone V SoC Board
- Arrow SoCKit User Manual - July 2017 Edition
- Arrow SoCKit User Manual - November 2019 Edition
- Arrow SoCKit Evaluation Board
- Atlas-SoC Development Platform
- Critical Link MitySOM-5CSx Development Kit
- Cyclone V Ethernet driver problems
- DE10-Nano Development Board
- Terasic DE10-Standard Development Kit
- Devboards DBM-SoC1 module
- Devboards DBM-SoC2 module
- EBV SoCrates Evaluation Board
- Enclustra Mercury SA1 SoC Module
- Enterpoint Drigmorn 5
- Enterpoint Larg 2
- Altera Cyclone V SoC Development Platform
- Mpression Helio SoC Evaluation Kit by Macnica
- Mpression Sodia Evaluation Board by Macnica
- ARIES Embedded - MCV System on Module
- Mpression Borax SOM Module and Development Kit by Macnica
- Enterpoint Mulldonoch 3
- Networked Pro-Audio FPGA SoC Development Kit by Coveloz
- NOVPEK™CVLite
- NOVSOM®CV
- NOVSOM®CVLite
- NovTech IoT Octopus™
- NovTech NetLeap™
- Enterpoint Raggedstone 4
- Solectrix SMARC compliant System-on-Module
- Terasic DE1-SoC Development and Education Board
- Stratix 10 SoC
- Find a Board
- News
Documentation
Similar topics
-
GSRD v13.1 - Programming QSPI Flash
-
Arria 10 Flash Programming Alternative
Conveniently flash QSPI, NAND, SDMMC using DS 5, JTAG and optional TFTP -
GSRD QSPI Boot
List of pages presenting GSRD QSPI boot
-
GSRDQ spi Boot - Arrow SoCKit Edition
-
BootTheArrowSoCKitFromQSPI
Recent Changes
-
Macnica Sulfur ~ Development Kit for Agilex™ 5 FPGA E-Series ~
-
Docker Yocto Build
Using Docker to Build Yocto Recipes
-
Building Bootloader for Agilex 5
Building latest bootloaders for Agilex 5 SoC Devices -
GSRD for Agilex 7 I-Series Transceiver-SoC DevKit (4x F-Tile)
Golden System Reference Design for DK SI AGI027FB and DK SI AGI027FA -
Building Bootloader for Cyclone V and Arria 10
Information abut latest bootloaders for Cortex A9 based SoC FPGA devices
Table of Contents
Considerations about connecting QSPI Flash Devices to CV SoC and AV SoC
Considerations about connecting QSPI Flash Devices to CV SoC and AV SoC
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.
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
- nRST pin input being pulled low
- Software writing rstmgr.ctrl.swwarmrstreq
- FPGA sending a WARM reset request
- Watchdogs
- 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)
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.
- 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.
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
- 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
© 1999-2024 RocketBoards.org by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
This website is using cookies. More info.
That's Fine