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.4.1. Boot ROM

Since the Boot ROM is the first booting stage, the most common boot failure symptom is that not anything is happening. For example, the system does not boot, there is no activity on the UART from the Preloader (if enabled).

The first thing to try when having boot problems is to check the Cold boot. The Warm boot is a little more versatile, but depending on how the software configures the chip, it may fail in different ways. Cold boot is initiated by either pressing the Cold reset button (if available) or by power-cycling the board or the device.

The following may cause the Warm boot to fail, but not the Cold boot:

  • Application software enabled Warm RAM Boot incorrectly
  • Application software changed the Warm reset options inconsistently with the usage scenario
  • QSPI is used as a boot source, but the QSPI is not reset on a Warm reset, as required by Boot ROM for some QSPI devices with more than 16 MB of Flash

Another thing to check is whether the HPS works at all. This can be done by connecting a debugger (if the JTAG connection is available on the board). If the debugger can connect reliably, then probably the HPS is fine.

If a debugger connection is available, more information can be obtained by connecting a debugger to the board and looking at registers maintained by Boot ROM and Preloader to determine what happened. The registers are available in sysmgr.romcodegrp and consist of:

  • initswstate - The Preloader writes the magic value ‘0x49535756’ to it just before it jumps to a valid next boot stage. The absence of that value means that Preloader did not jump to the next boot stage.
  • initswlastld - Contains the index of the last Preloader software image loaded by the Preloader from the boot device. There are a total of 4 Preloader images.
  • bootromswstate - Information about the BootROM state, including:
    • Bit 0: if set, it means that the BootROM tried all four images and none of them worked
    • Bit 1: set if the Preloader was started (then it may have failed)
    • Bits 11:8: which flash boot source was used:
      • NAND: 0
      • SD/MMC: 1
      • QSPI: 2
Note: The contents of bootromswstate may change in future revisions of the BootROM.

If a debugger connection is not available, and boot from Flash is requested, then the flash signals could be monitored for activity, if available for observation on the board. If there is some activity on the flash lines, then probably HPS is OK.

If it is still not clear whether the HPS is OK, then the power, clock and reset signals could be verified. Check the power supplies for the correct voltages, absence of excessive noise and also power up sequencing. Use a scope to look at the input clocks, for amplitude, frequency and excessive jitter. Look at the reset signals to confirm they are correct.

If the HPS is OK but the Boot ROM does not seem to successfully load the Preloader, it may be because one of the following reasons:

  • Preloader images are corrupted in Flash, and the Boot ROM cannot load any of them.
  • Preloader images are correct in flash, but communication with the Flash fails.
  • Preloader is loaded correctly, but it does not do what we expected it, or crashes because of a software bug.

In order to reduce the likelihood of Flash communication issues, CSEL can be set to 00, if configurable on the board. This prevents Boot ROM from reprogramming the PLLs and also forces it to use the lowest possible speed when communicating with the Flash device.

The flash lines (if available) can be monitored with an oscilloscope or logical analyzer, looking for things like:

  • How long is the communication? Does the Boot ROM give up on communication quickly, or there is a lot of communication? If it gives up easily, it may be an indication that the problem is pretty obvious.
  • Do the signal levels look correct? Look for voltage levels, ringing, raise and fall times.
  • If using logical analyzer, and option is available, try to decode the communication between the HPS and the flash device and see if and how it is failing.

If the above steps are not enough to diagnose the issue, and a debugger connection is available, the contents of the upper 4 KB of OCRAM can be dumped from the debugger and it can be analyzed by Altera. This can lead to information such as “Boot ROM failed to initialize SD Card”. Most of the time, the same information can be obtained by looking at the external behavior and at the above mentioned registers.

Level Two Title