Altera Cyclone V User manual

HPS SoC Boot Guide - Cyclone V SoC Development Kit
2016.01.27
AN-709 Subscribe Send Feedback
Introduction
is document describes:
• An overview of the boot options available on the Cyclone®V
• Recommendations to help reduce the boot duration, including measurements of the boot process on
the Cyclone V Development Kit
• Recommendations to help with debugging the boot process
• Bare-metal boot examples that can be run on the Cyclone V SoC Development Kit
Note: Although the document targets Cyclone V, it also applies to Arria®V, since the HPS portion is
identical between the two families.
Prerequisite
In order to run the examples presented in this Boot Guide the following are required:
• Altera®Cyclone V Development Kit, Rev D
• Host PC running Windows 7 or newer(1)
• Altera SoC Embedded Design Suite (SoC EDS), v14.1 installed
• Altera Complete Design Suite (ACDS) v14.1(2)
Note: is document assumes a basic knowledge of Altera SoC EDS, ACDS, Preloader Support Package
Generator (part of SoC EDS) and ARM DS-5 AE.
Related Information
•Cyclone V Development Kit and SoC Embedded Design Suite
For more information about the Cyclone V SoC Development board.
•SoC EDS Download
For more information about and where to obtain the latest SoC EDS downloads.
•ACDS Download
For more information about and where to obtain the latest ACDS downloads.
•Altera SoC Embedded Design Suite User Guide
(1) Linux can also be used, with similar commands.
(2) Required only for the boot from FPGA example.
Intel Corporation. All rights reserved. Intel, the Intel logo, Altera, Arria, Cyclone, Enpirion, MAX, Nios, Quartus and Stratix words and logos are trademarks of
Intel Corporation or its subsidiaries in the U.S. and/or other countries. Intel warrants performance of its FPGA and semiconductor products to current
specications in accordance with Intel's standard warranty, but reserves the right to make changes to any products and services at any time without notice.
Intel assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly
agreed to in writing by Intel. Intel customers are advised to obtain the latest version of device specications before relying on any published information
and before placing orders for products or services.
*Other names and brands may be claimed as the property of others.
ISO
9001:2008
Registered
www.altera.com
101 Innovation Drive, San Jose, CA 95134

Boot Overview
is chapter presents an overview of the dierent boot options and capabilities available for the Cyclone V.
Boot Flow
e following gure depicts the typical boot ow:
Figure 1: Typical Boot Flow
Additional boot ows are possible, as shown in the following diagram:
Figure 2: Additional Boot Flows
As it can be seen in the above diagram, we always have the Boot ROM, but then we may have more or less
stages, depending on the system design.
Boot ROM
e 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
e behavior of the Boot ROM is inuenced by the BSEL and CSEL options, and also by the registers in
System Manger (for RAM boot) as shown later in the document.
2Boot Overview AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

For the scenarios where the next boot stage is located in Flash, the Boot ROM can use up to four dierent
images:
• On Cold reset, the Boot ROM always starts with the rst 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 will
advance to the next image and increment sysmgr.romcodegrp.initswlastld.
• If all images are exhausted, the Boot ROM will try to fallback on the FPGA image. It will continue to be
reset by the Watchdog, but will never try to boot from Flash until the next Cold reset.
Note: e BootROM requires a special header to be placed at the beginning of the images that need to be
loaded from ash. e header also contains a checksum that is used for validating the image. e
header can be attached to the image by using the mkpimage tool that is included with the SoC
EDS.
Preloader
Typically, the main responsibilities of the Preloader are:
• Perform additional HPS initialization
• Bring up SDRAM
• Load the next boot stage from Flash to SDRAM and jump to it
Currently, two dierent Preloader options are available:
• SPL – part of U-Boot. Provided with SoC EDS under GPL (Open Source) License
• MPL – provided with SoC EDS as an example using the HWLibs (Altera bare-metal libraries). Uses
BSD license.
Note: e Preloader requires a special header to be placed at the beginning of the next stage boot image.
Also, the header contains a CRC value used to validate the image. e header can be attached to an
image by using the mkimage utility that is included with the SoC EDS.
Bootloader
e Bootloader has typical responsibilities that are similar with the Preloader, except it does not need to
bring up SDRAM.
Because the Bootloader is already residing in SDRAM, it is not limited by the size of the OCRAM.
erefore, it can provide a lot of features, such as network stack support.
Boot Sources
e HPS can boot from one of the following sources, as selected by the BSEL pins:
• SD/MMC
• QSPI
• NAND
• FPGA
AN-709
2016.01.27 Preloader 3
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

e following table presents the possible BSEL options, together with the actual jumper settings on the
Cyclone V Development kit, rev D:
BSEL Description Cyclone V Dev Kit Switches
J28:BSEL0 J28:BSEL0 J28:BSEL0
0 Reserved Right Right Right
1 FPGA Le Right Right
2 1.8 V NAND - - -
3 3.3 V NAND - - -
4 1.8 V SD/MMC - - -
5 3.3 V SD/MMC Le Right Le
6 1.8 V SPI or quad SPI - - -
7 3.3 V SPI or quad SPI Le Le Le
ere are four boot options:
• Indirect execution - When booting from ash (SD/MMC/QSPI/NAND):
1. e code is loaded by the Boot ROM from the ash to the OCRAM.
2. Run the code from this location
• Direct execution - When booting from FPGA, the Boot ROM simply jumps to an address in the FPGA
address space.
• FPGA fallback boot - If the selected boot mode fails, the Boot ROM will try to jump to a fallback image
in the FPGA, if it exists.
• RAM boot - If an Warm Boot, the System Manager can be congured so that the Boot ROM directly
jumps to a location in OCRAM.
Boot from SD/MMC
When booting from SD/MMC, two dierent options are available:
• Raw mode - Preloader images are located at address0 on the card.
• Partition mode - Preloader images are located at oset 0 on a custom partition with ID=A2 on the
card.
4Boot from SD/MMC AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

Figure 3: Raw Mode and Partition Mode Options
e MBR is a 512 byte data structure, located at address 0, describing the partitions existing on the
SD/MMC card.
e Raw mode does not allow the card to be partitioned, since the Preloaders are located at address 0,
where the MBR data structure needs to be placed.
When using the Partition mode, the Preloader is located on a custom partition that does not interfere with
the other partitions on the SD/MMC card. e other partitions could, for example, contain Windows FAT,
or Linux EXT2 or EXT3 le systems, providing more exibility for the overall system design.
Related Information
Booting and Conguration
For more information about the SD/MMC clocking options selected by Boot ROM based on CSEL pins,
refer to the Booting and Conguration chapter of the Cyclone V Technical Reference Manual.
Boot from QSPI
When booting from QSPI, the four Preloader images are always located at the beginning of the QSPI
address space, occupying a total of 256 KB.
AN-709
2016.01.27 Boot from QSPI 5
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

Figure 4: QSPI Address Space
Related Information
Booting and Conguration
For more information about the QSPI commands and clocking options selected by Boot ROM based on
CSEL pins, refer to the Booting and Conguration chapter of the Cyclone V Technical Reference Manual.
Boot from NAND
When booting from NAND, the Preloader images are located at the beginning of the ash. Each image has
to start at NAND ash block boundary.
Figure 5: NAND Flash Block
Note: Booting from NAND is not available on the Cyclone V Development kit.
6Boot from NAND AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

Related Information
Booting and Conguration
For more information about the NAND clocking options selected by Boot ROM based on CSEL pins, refer
to the Booting and Conguration chapter of the Cyclone V Technical Reference Manual.
Boot from FPGA
When booting from FPGA, the Boot ROM performs the following operations:
• Waits for FPGA to be congured and in user mode
•Veries that the Boot from FPGA was enabled in the FPGA fabric
• Jumps to address 0xC0000000, corresponding to oset 0 on the HPS-2-FPGA bridge
Note: e conguration on the FPGA side needs to enable the signal notifying the HPS that a boot image
is available (f2h_boot_from_fpga_ready).
Note: No other checking, such as CRC of the image, is performed. No clocking conguration is
performed either, and the CSEL value is ignored.
FPGA Fallback Boot
When the Boot ROM did not successfully load any image, it tries to boot from an FPGA fallback image:
• Checks if the FPGA is congured and in user mode
•Veries that the fallback image was enabled in the FPGA fabric
• Jumps to address 0xC0000000, corresponding to oset 0 on the HPS-2-FPGA bridge
Note: e conguration on the FPGA side needs to enable the signal notifying the HPS that an FPGA
fallback image is available (f2h_boot_from_fpga_on_failure).
Boot from RAM on Warm Reset
is scenario applies only for Warm resets. e Boot ROM can be instructed to directly jump to an image
already loaded in OCRAM with an optional CRC check for that image.
e following registers located in sysmgr (romcodegrp and warmramgrp) are used to set up the Boot from
RAM on Warm Reset:
•enable - Set bit 0 to enable Boot from RAM on Warm reset.
•datastart - Byte oset in OCRAM for the region to be CRC-validated. Needs to be 4 byte aligned.
•length - Size of OCRAM area to be CRC-validated, in 4 byte words. Set to 0 to disable the CRC
validation.
•execution - Byte oset in OCRAM where to jump to.
•crc - CRC value for the OCRAM area that is CRC-validated.
Note: When booting from RAM, the Boot ROM does not do any initialization, including clocking and it
therefore ignores the CSEL pins.
Boot Clocks
e board on which the Cyclone V resides can have dierent clocking needs:
• OSC1 input clock can have dierent values
• Flash memories can have dierent clocking requirements
• Board layout may also impact the maximum ash speeds
AN-709
2016.01.27 Boot from FPGA 7
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

In order to accommodate the above, the Boot ROM can be instructed to use dierent clocking options,
through the CSEL pins. e following table presents the CSEL options available on Cyclone V, together
with the actual jumper settings on the Cyclone V Development Kit, rev D:
Table 1: CSEL Options Available
CSEL Cyclone V Dev Kit Switches
J26:CSEL0 J26:CSEL1
0 Right Right
1Le Right
2 Right Le
3Le Le
Note: In the following cases the Boot ROM does not touch the clocking at all:
• CSEL = 0
• Boot from FPGA
• Fallback boot from FPGA
• RAM boot on Warm reset
Related Information
Booting and Conguration
For more information about what each of the CSEL values mean for each of the BSEL options, refer to the
Booting and Conguration chapter of the Cyclone V Technical Reference Manual.
Boot Duration
In some applications, the duration of the boot process is very critical, and it needs to meet a certain
constraint.
is section presents some considerations on optimizing the boot time, together with some measurements
taken with various options on the Cyclone V Development Kit.
e elements that compose the boot time for a typical Linux system are depicted in the gure below:
Figure 6: Boot Time Stages for Linux Systems
8Boot Duration AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

A typical bare-metal application boot time is depicted in the following gure:
Figure 7: Boot Time Stages for a Bare-Metal Application
Note: e above gures are not drawn to scale - each stage is depicted with the same size.
Optimizing Boot Duration
e recommended approach for optimizing boot time consists of:
• Measure the duration of the total boot time. For example, monitor the reset signal and a custom signal
toggled at the beginning of the application by using a scope or a logical analyzer.
• Measure the duration of as many individual steps as possible, to understand where most of the time is
spent.
• If possible, optimize the steps that take most of the time. Usually the upper levels take longer than the
lower ones.
e following sections describe some of the factors that inuence the duration of the Boot ROM.
Hardware Powerup Sequence
is is the smallest contributor to boot time and it does not need to be optimized. It is actually inuenced
by the OSC1 input clock frequency, but it is so small that its duration does not warrant changing the OSC1
value.
Boot ROM
e duration of the Boot ROM is inuenced by the following factors:
•OSC1 Clock Frequency (for the portion before setting the PLLs or when using CSEL=00)
• Clocking option (selected by CSEL pins)
• Boot Source (SD/MMC, QSPI, NAND or FPGA – selected by BSEL pins)
• Performance of external ash device
• Size of Preloader image
e above parameters can be tweaked in order to optimize the Boot ROM duration. For example, the OSC1
and CSEL should be selected such that the maximum possible clock values are used for both the MPU and
the external ash.
Another example - Tweaking the Preloader so that it is made smaller. e smaller the Preloader, the less
time the Boot ROM spends loading it from ash.
AN-709
2016.01.27 Optimizing Boot Duration 9
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

For the boot from FPGA option, the Preloader loading time is reduced to zero. But the FPGA has to be
already congured for this to be possible, and this takes time, as well.
Related Information
Booting and Conguration
Preloader
e Preloader duration is inuenced by the following elements:
• Location of next boot stage
• Size of next boot stage image
• Speed of SDRAM (since Preloader loads the image from Flash to SDRAM)
• Speed of Flash
• Various Preloader options:
• SDRAM scrubbing
• Hardware diagnostic
• Checking the CRC of the next boot stage image
• Serial logging
• Program FPGA
In order to reduce the Preloader duration, the above parameters may be tweaked. For example:
• Reduce the size of the next boot stage (for example remove networking support from U-Boot if not
needed)
• Use a faster ash (it will require changing Preloader source code – option is not available in Preloader
Generator)
• Disable hardware diagnostic if enabled (uncheck HARDWARE_DIAGNOSTIC in Preloader Generator)
• Disable serial console output - (uncheck SERIAL_SUPPORT in Preloader Generator)
• Disable CRC of the next boot stage image (uncheck CHECKSUM_NEXT_IMAGE in Preloader Generator)
If the FPGA programming is selected in the Preloader, then the following also impacts the duration:
• Location of FPGA Image (QSPI or SD Card FAT partition)
• Size of the FPGA Image (compression may reduce it signicantly)
Bootloader
e duration of the Bootloader is inuenced by the following:
• Size of the next stage to be loaded (Linux kernel for example)
• Location of the next stage (ash, network, etc)
• Whether networking is enabled, and is statically or dynamically (DHCP) congured
• Whether FPGA programming is also performed
• Speed of SDRAM
• Countdown counter(3) (default 5s in U-Boot – can be disabled for production systems)
Linux Kernel
e Linux kernel can be made to start faster, and there is a lot of material in the Linux community on how
to achieve this. For example, removing debugging capabilities and various unneeded drivers and features.
(3) Can be tweaked to achieve faster boot time.
10 Preloader AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

Init Scripts
e boot time can be optimized by reducing the amount of work done in the init scripts. Either remove
unneeded functionality, or defer it for later, if possible.
Boot Duration Measurements
is section presents various Boot time measurements taken on the Cyclone V Development Kit. Only
Boot ROM and Preloader are measured.
e measurements are done with the following setup:
• SoC EDS 14.1b182: for GHRD & Preloader
• Cyclone V Development Kit rev D
• Kingston 4GB Class 10 SD card
• 512 MB Micron QSPI
• Preloader size = 38,548 bytes
• U-boot size = 238,316 bytes
Note: All durations are in milliseconds.
Table 2: Boot ROM Duration for CSEL Options
is table presents the Boot ROM duration for dierent CSEL options, for both SD/MMC and QSPI.
Source CSEL=00 CSEL=01 CSEL=10 CSEL=11
SD/MMC 168.86 N/A 72.43 103.06
QSPI 110.44 28.09 24.56 13.9
Table 3: SD/MMC and QSPI Preloader Duration
is table presents the standard Preloader duration, for both SD/MMC and QSPI.
Source CSEL=00 CSEL=01 CSEL=10 CSEL=11
SD/MMC 142.88 N/A 136.67 137.17
QSPI 136.4 130.94 130.84 130.27
Note: e CSEL also inuences the Preloader duration, but less than Boot ROM.
Table 4: Preloader Duration after Removing Serial Support
is table presents the Preloader duration aer the serial support was removed:
Source CSEL=00 CSEL=01 CSEL=10 CSEL=11
SD/MMC 93.58 N/A 87.26 87.81
QSPI 79.08 73.27 73.08 72.53
Table 5: Preloader Duration after Removing Serial Support and the CRC
is table presents the Preloader durations aer removing both the serial support and the CRC of the next
boot stage.
AN-709
2016.01.27 Init Scripts 11
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

Source CSEL=00 CSEL=01 CSEL=10 CSEL=11
SD/MMC 71.25 N/A 65.04 65.48
QSPI 56.44 50.61 50.82 50.25
Table 6: Boot ROM and Preloader Durations when Using SD/MMC with a FAT Partition
is table presents the durations of Boot ROM and Preloader when using SD/MMC with a FAT partition
for the next boot stage.
Note: e new Preloader size is 42,268 bytes.
Source CSEL=00 CSEL=01 CSEL=10 CSEL=11
BootROM 183.85 N/A 78.23 113.80
Preloader: SD +
FAT
78.56 N/A 75.65 75.93
Note: e serial support and the CRC for the next image area also removed.
Table 7: Duration of FPGA Programming
is table presents the duration of FPGA programming, when performed from Preloader. e
uncompressed FPGA image size is 7,007,248 bytes, while the compressed FPGA image size is 2,335,334
bytes.
FPGA Image Source Uncompressed Image Compressed Image
QSPI 1,374 473
SD-FAT 563 223
Table 8: Duration of Two of the Optional Preloader Operations
Activity Duration
Hardware Diagnostic (Memory Test) 2,640
SDRAM Scrubbing (16 MB) 25
Boot Debugging
is section presents some techniques that can help with the debug of the booting process. Considerations
are included for Boot ROM and Preloader. e rest of the boot ow is generic and can be debugged with
general purpose techniques.
Boot ROM
Since the Boot ROM is the rst 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).
12 Boot Debugging AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

e rst thing to try when having boot problems is to check the Cold boot. e Warm boot is a little more
versatile, but depending on how the soware congures the chip, it may fail in dierent ways. Cold boot is
initiated by either pressing the Cold reset button (if available) or by power-cycling the board or the device.
e following may cause the Warm boot to fail, but not the Cold boot:
• Application soware enabled Warm RAM Boot incorrectly
• Application soware 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. is 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
ne.
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. e
registers are available in sysmgr.romcodegrp and consist of:
•initswstate - e Preloader writes the magic value ‘0x49535756’ to it just before it jumps to a valid
next boot stage. e absence of that value means that Preloader did not jump to the next boot stage.
•initswlastld - Contains the index of the last Preloader soware image loaded by the Preloader from
the boot device. ere 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 ash boot source was used:
• NAND: 0
• SD/MMC: 1
• QSPI: 2
Note: e 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 ash signals could be
monitored for activity, if available for observation on the board. If there is some activity on the ash 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 veried.
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 conrm 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 ash, but communication with the Flash fails.
• Preloader is loaded correctly, but it does not do what we expected it, or crashes because of a soware
bug.
In order to reduce the likelihood of Flash communication issues, CSEL can be set to 00, if congurable on
the board. is prevents Boot ROM from reprogramming the PLLs and also forces it to use the lowest
possible speed when communicating with the Flash device.
AN-709
2016.01.27 Boot ROM 13
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

e ash lines (if available) could be monitored with an oscilloscope and/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 ash 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. is 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.
Preloader
e Preloader can be debugged much easier than the Boot ROM, since all the source code is available.
e following general purpose debugging techniques can be used:
• On systems where a JTAG connection is available, a debugger can be used to debug the Preloader.
• Alternatively, the code can be modied to output more debug information either through serial
connection, if available, or by toggling LEDs or various other signals.
When the Preloader is generated by the Preloader Support Package Generator, the le preloader.ds is
also automatically created. is le enables the developer to debug the Preloader by using the ARM DS-5
AE over a JTAG connection.
Note: Since the executable is an ELF format, any other compatible debugger may be used too.
Debugging the Preloader from ARM DS-5 AE
e following steps are required in order to debug the Preloader from ARM DS-5 AE:
1. Compile Hardware Design to obtain the hando les.
2. Generate the Preloader from the Preloader Support Package Generator. is will create the les
preloader.ds and uboot.ds in the Preloader folder.
3. Compile the Preloader to obtain the executable.
4. Connect the board to the host PC by using the USB serial connection (in order to see the Preloader
serial output).
5. Connect the board to the PC by using either USB Blaster or ARM DSTREAM.
6. Start ARM DS-5 AE and select your workspace if asked.
7. In DS-5 AE, go to Run > Debug Congurations to open the Debug Congurations window.
8. Create a new debug conguration by right-clicking DS-5 Debugger on the le panel and selecting New.
9. Rename the new debug conguration to Debug Preloader by editing the Name eld.
10.In the "Connection" tab of the Debug Conguration window, select the target to be Altera > Cyclone
V SoC (Dual Core) > Bare Metal Debug > Debug Cortex A9_0.
11.Select Target Connection to be either USB-Blaster or DSTREAM.
12.Click the Browse button in the "Connections" group, select the desired connection, and click Select.
14 Preloader AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

13.In the "Debugger" tab of the Debug Congurations window, select the option Connect Only under
"Run Control".
14.In the same tab, check the option Run debug initialization debugger script, then click File System …
button and browse to the preloader.ds le that was created by the Preloader Generator .
15.Click the Debug button. is will close the Debug Congurations window, and start a debugging
session. e usual debugging techniques can then be applied.
Related Information
ARM DS-5 Altera Edition
For more information about the ARM DS-5 AE including how to import and build projects, refer to the
SoC EDS User Guide.
U-Boot
Debugging U-boot is very similar to debugging the Preloader. e same techniques are available.
e Preloader Support Package Generator creates the le uboot.ds in the Preloader folder, that can be
used to debug the U-Boot from the ARM DS-5 AE. Since the executable is an ELF format, any other
compatible debugger may be used, as well.
Boot Examples
is chapter presents several boot examples that can be run on the Cyclone V Development Kit:
• Boot from SD/MMC - using raw and FAT partitions
• Boot from QSPI
• Boot from FPGA
In all the examples, the Preloader is used to load and run a simple bare-metal application. e boot ow is
depicted in the following gure:
Figure 8: Boot Flow
Archive File Contents
is document has an accompanying archive le with all the source code required to reproduce the
examples from this chapter, and also all the binaries required to run the examples without building them.
AN-709
2016.01.27 U-Boot 15
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

e archive is called cv_boot_guide.zip and contains the following:
• prebuilt
• application
•hello-mkimage.bin
• fpga
•soc_system.sof
• preloaders
• sd_custom_partition
•preloader-mkpimage.bin
• sd_fat_partition
•preloader-mkpimage.bin
• qspi
•preloader-mkpimage.bin
• fpga
•preloader-mkpimage.bin
• sources
•cv_soc_devkit_boot_fpga_rd
• Altera-SoCFPGA-HardwareLib-Unhosted-CV-GNU.tar.gz
Related Information
cv_boot_guide.zip
Bare-Metal Application
e bare-metal application used in all the examples simply displays the Hello World message over UART.
e application is included as an importable project called Altera-SoCFPGA-HardwareLib-Unhosted-CV-
GNU.tar.gz. It can also be downloaded from the SoC Example Designs webpage.
Import the project archive in ARM DS-5 AE and build it. is will create the le hello-mkimage.bin,
which is the image that will be loaded by the Preloader.
Related Information
•ARM DS-5 Altera Edition
For more information about the ARM DS-5 AE including how to import and build projects, refer to
the SoC EDS User Guide.
•SoC Example Designs webpage
For more information, refer to the SoC Example Designs webpage.
Booting from SD/MMC – Custom Partition
is example demonstrates how to boot from the SD card, with the bare-metal image stored on the same
SD card custom partition as the Preloader.
16 Bare-Metal Application AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

Before you begin
To prevent the "Device Open Failed!" error message, ensure that you are operating in the following user
modes:
• Windows — "Administrator mode user"
• Linux — "sudo mode"
e steps required to run this scenario are:
1. Build the sample bare-metal application or simply use the provided le hello-mkimage.bin directly.
2. Generate a Preloader based on the GHRD provided with SoC EDS.
Make sure to select the following options:
• Check the option spl.boot.BOOT_FROM_SDMMC
• Uncheck the other boot options (spl.boot.BOOT_FROM_RAM, spl.boot.BOOT_FROM_QSPI,
spl.boot.BOOT_FROM_NAND)
Note: spl.boot.SDMMC_NEXT_BOOT_IMAGE = 0x40000. is is the location where the bare-metal
application image will need to be stored.
• Check the option spl.boot.SDRAM_SCRUBBING and spl.boot.SDRAM_SCRUB_REMAIN_REGION. is
will zero out the SDRAM, preventing any ECC errors to occur during bare-metal program
execution.
• Uncheck the option spl.boot.WATCHDOG_ENABLE. is is because we are not kicking the watchdog
in our bare-metal application.
3. Compile the Preloader. is will create the le preloader-mkpimage.bin.
4. Manually create an SD card with a custom partition with id=A2 using fdisk, or use the example SD
card image that comes with SoC EDS:
• Unzip the SD Card Image provided in the <SoCEDS installation folder>:\embedded\
embeddedsw\socfpga\prebuilt_images\sd_card_linux_boot_image.tar.gz by using
the command ‘tar -xzf <filename>’ from the Embedded Command Shell. is will create
the le sd_card_linux_boot_image.img.
• Use the free Win32DiskImager tool to write the le sd_card_linux_boot_image.img to an SD
card.
5. Write only the Preloader image to the SD card custom partition, using the SD card boot utility that is
part of SoC EDS:
• Start an Embedded Command Shell.
•Run the command “alt-boot-disk-util -a write -p preloader-mkpimage.bin
-b hello-mkimage.bin -d <sd_card_drive_letter>”
6. Set the board to boot from SD card by conguring the BOOTSEL jumpers like this:
• BOOTSEL0 (J28): le
• BOOTSEL1 (J29): right
• BOOTSEL2 (J30): le
7. Connect the board to the PC using the USB serial connection, and start a serial terminal on the PC,
using 115,200-8-N-1.
8. Insert the SD card on the board socket and power-cycle the board or reset the HPS by pressing the
COLD reset button (S7).
AN-709
2016.01.27 Booting from SD/MMC – Custom Partition 17
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

e board will boot, Preloader messages will be displayed, then “Hello World” will be displayed by the
bare-metal application.
Figure 9: Custom Partition
Related Information
•Altera SoC Embedded Design Suite User Guide
For more information about SoC EDS, ARM DS-5, Preloader Generator and SD Card Boot Utility,
refer to the SoC EDS User Guide.
•Win32 Disk Imager
Booting from SD/MMC – FAT Partition
is example demonstrates how to boot from the SD card, with the bare-metal image stored on the FAT
partition on the SD card.
Note: e Preloader is still stored on the custom partition.
Before you begin
To prevent the "Device Open Failed!" error message, ensure that you are operating in the following user
modes:
• Windows — "Administrator mode user"
• Linux — "sudo mode"
18 Booting from SD/MMC – FAT Partition AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback

e steps required to run this scenario are:
1. Build the sample bare-metal application or simply use the provided le hello-mkimage.bin directly.
2. Generate a Preloader based on the GHRD provided with SoC EDS. Make sure to select the following
options:
• Check the option spl.boot.BOOT_FROM_SDMMC
• Uncheck the other boot options (spl.boot.BOOT_FROM_RAM, spl.boot.BOOT_FROM_QSPI,
spl.boot.BOOT_FROM_NAND)
• Check the option spl.boot.FAT_SUPPORT. is will tell the Preloader to load the bare-metal
application from the FAT partition.
• Edit the eld spl.boot.FAT_LOAD_PAYLOAD_NAME to contain the name of the bare-metal image:
hello-mkimage.bin
• Check the option spl.boot.SDRAM_SCRUBBING and spl.boot.SDRAM_SCRUB_REMAIN_REGION. is
will zero out the SDRAM, preventing any ECC errors to occur during bare-metal program
execution.
• Uncheck the option spl.boot.WATCHDOG_ENABLE. is is because we are not kicking the watchdog
in our bare-metal application.
3. Compile the Preloader. is will create the le preloader-mkpimage.bin.
4. Manually create an SD card with a custom partition with id=A2 using fdisk, or use the example SD
card image that comes with SoC EDS:
• Unzip the SD Card Image provided in the <SoCEDS installation folder>:\embedded\
embeddedsw\socfpga\prebuilt_images\sd_card_linux_boot_image.tar.gz by using
the command ‘tar -xzf <filename>’ from the Embedded Command Shell. is will create
the le sd_card_linux_boot_image.img.
• Use the free Win32DiskImager tool to write the le sd_card_linux_boot_image.img to an SD
card.
5. Write both the Preloader image and the Bare-metal application images to the SD card custom partition,
using the SD card boot utility that is part of SoC EDS:
• Start an Embedded Command Shell.
•Run the command “alt-boot-disk-util -a write -p preloader-mkpimage.bin
-d <sd_card_drive_letter”
6. Write the bare-metal application image to the SD card FAT partition, using for example drag and drop
in Windows Explorer.
7. Set the board to boot from SD card by conguring the BOOTSEL jumpers like this:
• BOOTSEL0 (J28): le
• BOOTSEL1 (J29): right
• BOOTSEL2 (J30): le
8. Connect the board to the PC using the USB serial connection, and start a serial terminal on the PC,
using 115,200-8-N-1.
9. Insert the SD card on the board socket and power-cycle the board or reset the HPS by pressing the
COLD reset button (S7).
e board will boot, Preloader messages will be displayed, then “Hello World” will be displayed by the
bare-metal application.
AN-709
2016.01.27 Booting from SD/MMC – FAT Partition 19
HPS SoC Boot Guide - Cyclone V SoC Development Kit Altera Corporation
Send Feedback

Figure 10: FAT Partition
Related Information
•Altera SoC Embedded Design Suite User Guide
For more information about SoC EDS, ARM DS-5, Preloader Generator and SD Card Boot Utility,
refer to the SoC EDS User Guide.
•Win32 Disk Imager
Booting from QSPI Flash
is example demonstrates how to boot from the QSPI Flash. Both the Preloader and the Bare-metal
application are stored in QSPI Flash.
e steps required to run this scenario are:
1. Build the sample bare-metal application or simply use the provided le hello-mkimage.bin directly.
2. Generate a Preloader based on the GHRD provided with SoC EDS. Make sure to select the following
options:
20 Booting from QSPI Flash AN-709
2016.01.27
Altera Corporation HPS SoC Boot Guide - Cyclone V SoC Development Kit
Send Feedback