AN 709: HPS SoC Boot Guide - Cyclone V SoC Development Kit

Download PDF
ID 683265
Date 1/27/2016
Public
Document Table of Contents
Document Table of Contents x
1. AN 709: HPS SoC Boot Guide - Cyclone V SoC Development Kit
1. AN 709: HPS SoC Boot Guide - Cyclone V SoC Development Kit x
1.1. Introduction 1.2. Boot Overview 1.3. Boot Duration 1.4. Boot Debugging 1.5. Boot Examples 1.6. Document Revision History
1.1. Introduction x
1.1.1. Prerequisite
1.2. Boot Overview x
1.2.1. Boot Flow 1.2.2. Boot Sources 1.2.3. Boot Clocks
1.2.1. Boot Flow x
1.2.1.1. Boot ROM 1.2.1.2. Preloader 1.2.1.3. Bootloader
1.2.2. Boot Sources x
1.2.2.1. Boot from SD/MMC 1.2.2.2. Boot from QSPI 1.2.2.3. Boot from NAND 1.2.2.4. Boot from FPGA 1.2.2.5. FPGA Fallback Boot 1.2.2.6. Boot from RAM on Warm Reset
1.3. Boot Duration x
1.3.1. Optimizing Boot Duration 1.3.2. Boot Duration Measurements
1.3.1. Optimizing Boot Duration x
1.3.1.1. Hardware Powerup Sequence 1.3.1.2. Boot ROM 1.3.1.3. Preloader 1.3.1.4. Bootloader 1.3.1.5. Linux Kernel 1.3.1.6. Init Scripts
1.4. Boot Debugging x
1.4.1. Boot ROM 1.4.2. Preloader 1.4.3. U-Boot
1.4.2. Preloader x
1.4.2.1. Debugging the Preloader from ARM DS-5 AE
1.5. Boot Examples x
1.5.1. Bare-Metal Application 1.5.2. Booting from SD/MMC – Custom Partition 1.5.3. Booting from SD/MMC – FAT Partition 1.5.4. Booting from QSPI Flash 1.5.5. Booting from FPGA
1.5.5. Booting from FPGA x
1.5.5.1. Overview 1.5.5.2. Hardware Design 1.5.5.3. Building and Running the Example
1. AN 709: HPS SoC Boot Guide - Cyclone V SoC Development Kit

1.2.1.1. Boot ROM

The HPS boot process starts when the processor is released from reset, and jumps to the reset vector address, located in the Boot ROM address space.

Typically, the main responsibilities of the Boot ROM are:

  • Detect the selected boot source
  • Perform minimal HPS initialization
  • Load the next boot stage (typically the Preloader) from Flash to OCRAM and jump to it

The behavior of the Boot ROM is influenced by the BSEL and CSEL options, and also by the registers in System Manger (for RAM boot) as shown later in the document.

For the scenarios where the next boot stage is located in Flash, the Boot ROM can use up to four different images:

  • On Cold reset, the Boot ROM always starts with the first image, and checks the CRC. If the CRC is OK, then it passes control to it. If the CRC is not OK, then it tries the next image and so on. Before an image is passed control, the Boot ROM updates the register sysmgr.romcodegrp.initswlastld with the image index.
  • On a Warm reset, the Boot ROM looks at the register sysmgr.romcodegrp.initswstate for the magic value 0x49535756. If it is there, it means last Preloader executed OK, so it loads it again and executes it. If the magic value is not found, it means the previous Preloader was not OK, and the Boot ROM advances to the next image and increment sysmgr.romcodegrp.initswlastld.
  • If all images are exhausted, the Boot ROM tries to fallback on the FPGA image. It continues to be reset by the Watchdog, but never tries to boot from Flash until the next Cold reset.
Note: The BootROM requires a special header to be placed at the beginning of the images that need to be loaded from flash. The header also contains a checksum that is used for validating the image. The header can be attached to the image by using the mkpimage tool that is included with the SoC EDS.
Level Two Title