HPS SoC Boot Guide - Cyclone V SoC Development Kit

Transcription

1 AN-709 Subscribe Introduction This document describes the available boot stages and source modes for both the HPS and FPGA fabric. The boot sequence is a multi-stage process, where each stage is responsible for loading the next stage. Also this document will present examples for the Boot Mode scenarios where both the boot stages and applications are configured. All examples use the Bare Metal Hello World application. Prerequisite In order to run the examples presented in this Boot Guide the following are required: Altera Cyclone V Development Kit Windows or Linux PC (1) Altera SoC Embedded Design Suite installed (2) Boot Process Overview The HPS boot process begins when processor reset occurs, which is when control is transferred to the internal Boot ROM. The Boot ROM is the first boot stage and when completed, transfers control to the next Preloader stage. Depending on the user s configuration, subsequent boot stages are loaded. A typical Boot Process Flow is shown in the figure below, where all the possible boot stages are used. The different available boot flows the user can configure are described in the sections that follow. (1) All examples are presented on Windows PC. (2) Requires Windows version of the Altera SoC Embedded Design Suite All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of and registered in the U.S. Patent and Trademark Office and in other countries. All other words and logos identified as trademarks or service marks are the property of their respective holders as described at Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera 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 Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. ISO 9001:2008 Registered Innovation Drive, San Jose, CA 95134

2 2 OS Boot Flow Figure 1: Typlical Boot Flow AN OS Boot Flow The OS Boot Flow is also referred to as a Typical Boot Flow, as shown in this figure, that includes all boot stages. The last stage, Application, is loaded by the OS. The OS used must support the SoC architecture, and is typically in Linux or an RTOS. RTOS Boot Flow The RTOS boot flow is similar to the OS typical scenario; except the Application code resides in the task code being managed by the RTOS. Figure 2: RTOS Boot Flow Bare Metal Boot Flow In the case where an OS stage is not used, the user develops an Bare Metal Application that is executed once the Preloader stage completes. Figure 3: Preloader and Bare Metal Boot Flow Customized Preloader Boot Flow (Bare Metal) The minimal Boot Flow scenario consists of Boot ROM; and next stage boot a custom Preloader. The Preloader incorporates Bare Metal Application, code and be contained in the form of a customized Preloader.

3 AN Boot Stages 3 Figure 4: Custom Preloader Boot Flow Note: This scenario is not recommend as the IOCSRs are not documented externally. Boot Stages Boot ROM This section describes the different boot stages used in the Boot Flow Scenarios in the preceding sections. The user configures the boot stage flow through the SoC Embedded Design Suite tools. The boot source of the Preloader Boot Stage is determined by BOOTSEL value. Preloader The Boot ROM is the first boot stage after power on reset, residing at the reset exception address. It s primary function is to detect and execute the secondary stage, the Preloader and also initializing the HPS. The BootROM is responsible for loading the Preloader image into the On Chip RAM and executing. Before transferring to the Preloader stage, the Boot ROM checks for a valid Preloader image by verifying it s header and performing a CRC on the image. For further reference see the Altera Technical reference Guide Booting and Configuration. Bootloader The function of the Preloader is user defined. However, typical functions include initializing the SDRAM interface and configuring the HPS I/O pins. Initializing the SDRAM allows the Preloader to load the next stage of the boot process, that may not fit in the 60 KB available in the on-chip RAM. The next software stage is Bootloader, such as U-Boot, or OS such as Linux or RTOS, or it can be a stand alone, Bare Metal, application. OS The Bootloader stage may also perform initializing the HPS and continue to load a application or an OS such at Linux or RTOS Typically the BootLoader is built from open source U-Boot. This stage consists of a user selected OS or RTOS. Once this stage completes it can be configured to load or incorporate an Application.

4 4 Application Application AN This stage consists of a user written Application that is a self-contained executable image, having no OS dependencies or interfaces. From the perspective of being a User Application it will be loaded by the OS. If a BareMetal Application, it is executed by the previous Boot Stage or incorporated into it (e.g. Custom Preloader ). Boot Sources After Boot Rom stage completes the next stage is the Preloader. The Preloader can be customized and is typically stored external to the HPS in a nonvolatile flash based memory and if present, executes the next software stage. The processor can boot from the following sources: SD/MMC Flash Device memory QSPI Flash memory FPGA fabric Boot from RAM (Warm Boot) Figure 5: HPS Boot Sources The HPS boot supports indirect or direct execution of the Preloader depending on the Boot Source device.,with indirect execution, the Boot ROM code copies the Preloader from the boot device into the on-chip RAM and jumps to it. Indirect execution is used for flash memory boot sources. With direct execution, the boot ROM code jumps to the Preloader located in the FPGA fabric. If running on CPU0, the Boot ROM code reads the BOOTSEL and CLKSEL values from the bsel and csel fields of the boot information register (boot info) in the system manager. See the following table for further details on the BOOTSEL values/settings.

5 AN Boot from SD/MMC Flash Device 5 Table 1: Boot Selections 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 BOOTSEL Field Value Reserved Flash Device FPGA (HPS-to-FPGA bridge) 1.8 V NAND flash memory 3.3 V NAND flash memory 1.8 V SD/MMC flash memory with external transceiver 3.3 V SD/MMC flash memory with internal transceiver 1.8 V SPI or quad SPI flash memory 3.3 V SPI or quad SPI flash memory Boot from SD/MMC Flash Device MBR Mode Using MBR mode the Preloader image is always stored in the partition type with ID 0xA2. This is a custom raw partition with no file system. Up To four Preloader Images can be stored in the Partition. The MBR is located at the first 512 bytes of the device (SD/MMC). If the MBR is not detected then BootROM will switch to Raw mode. Note: If the user wishes to include more images the Start Address of each image is based on the following formula:start Address = Partition start address + ( n * 64 K), where n is the image number

6 6 Raw Mode Figure 6: Preloader Image MBR AN Raw Mode When using Raw mode boot scenario, the Preloader image will be stored at the start address of the SD Card, where the MBR would typically reside.. The Boot ROM will detect Raw mode due to the absence of the MBR signature. The Preloader looks for a valid next stage boot image in the next stage boot device by checking the boot image validation data and checksum in the mirror image. The Preloader image will load the application, next stage, image at the address following the reserved Preloader Image Block. Figure 7: Preloader Raw Image Block Boot from QSPI For booting from a QSPI Flashing device, the Preloader image is always located at offsets which are multiples of a subsector size. If the image is less than 64 KB (3), only one subsector is used.

7 AN Boot from FPGA 7 Since a subsector is the smallest area used for erase operation, any update to a particular image does not affect other images. Figure 8: QSPI Flash Image Layout Boot from FPGA This section will cover comfiguring the GHRD to boot and run the Bare Metal example, Hello World, after booting from the FPGA. Boot from FPGA memory using the following requirements: 1. BSEL needs to be set to 0x1 - Boot from FPGA 2. FPGA image needs to have an on-chip memory instantiated, mapped at offset 0x0 behind the HPS2FPGA bridge. The memory needs to be loaded with Preloader executable binary. 3. FPGA image needs to drive the value of the flollowing two signals to HPS, since they are required by BootROM: f2h_boot_from_fpga_ready - indicates that the BootROM can boot from FPGA if BSEL = 0x1 f2h_boot_from_fpga_on_failure - indicates that the BootROM can boot from FPGA as a fallback, if it failed booting from the selected BSEL. 4. Preloader executable.text section needs to be linked to address 0xC000_0000 (equivalent of offset 0x0 behind the HPS2FPGA bridge) 5. Preloader executable.data sections need to be linked to address 0xFFF_0000 (the HPS OCRAM). 6. HPS Configuration. The HPS Component needs to be configured to enable the Boot from FPGA signals: (3) The SoC Dev Kit QSPI Flash Device has a sector size of 64KB.

8 8 Boot from FPGA Figure 9: HPS FPGA Boot Interface AN HPS Boot Memory The HPS Boot Memory needs to be set to 8bit witdh, and be initialized with a hex file containing the Preloader image.the following screenshot shows the memory settings that were used for this example. Note the Preloader image is stored in the file named software/spl_bsp/preloader.hex.

9 AN Boot from FPGA 9 Figure 10: HPS Boot Memory 8. QSys SoC The following figure shows the Qsys system, and how components are integrated in the design. Note: The HPS's f2h_boot_from_fpga bus was exported by double-clicking the corresponding cell in the Export column. The HPS Boot Memory was connected to the h2f AXI bus The HPS Boot Memory was set to a base address of 0x000_0000

10 10 Boot from FPGA Figure 11: QSys SoC AN Preloader The Preloader needs to be instructed that it will reside in the FPGA memory. In order to achieve this, the option EXE_ON_FPGA needs to be checked in the Preloader Generator GUI before clicking the Generate button.

11 AN Boot from RAM (Warm Boot) 11 Figure 12: Preloader Configuration Boot from RAM (Warm Boot) Warm boot from on-chip RAM has the highest priority to execute if the warmramgrp registers in the romcodegrp group in the system manager has been configured to support booting from on-chip RAM on a warm reset. When warmramgrp is enabled, and length is set to 0x0, Boot ROM will not perform CRC on the Preloader image and immediately jump to the address. If the length is not 0x0, the Boot ROM will ensure the Preloader image passes the CRC check before the Preloader image is executed. If a valid Preloader image cannot be found in the on-chip RAM, or the Preloader in the on-chip RAM fails the CRC check the, Boot ROM will attempt to load the last valid Preloader image loaded from the Flash. Getting Started This section covers the prerequisites in order to run the examples in the following examples. Before continuing, make sure you have read the Prerequisite section.

12 12 Preloader Generation Note: All paths are in reference to the SoCEDS installation folder as noted by <*>.. AN Preloader Generation This section describes how to generate and build the Preloader for the Cyclone V SoC Golden Hardware Reference Design (GHRD) that is provided with SoCEDS. The Preloader is delivered as part of the GSRD is found in the SoCEDS installation folder:<*>embedded/examples/hardware/cv_soc_devkit_ghrd / software/preloader In this example, we will generate a new Preloader in the folder:<*>/ examples/ hardware/ cv_soc_devkit_ghrd/software/spl_bsp To generate the required Preloader: 1. Launch an Embedded Command Shell from the SoC EDS Start Menu: Figure 13: SoC EDS Command Shell Note: You can also launch an Embedded Command Shell by running the command:<*>/ embedded/ embedded_command_shell.sh 2. Next launch the BSP Editor from the Embedded Command Shell:$ bsp-editor 3. Create a new BSP by selecting File > New BSP.

13 AN Preloader Generation 13 Figure 14: BSP Editor 4. Use the browse button to set the Preloader Settings Directory to the following path:<*>/ embedded/ examples/hardware/cv_soc_devkit_ghrd/hps_isw_handoff/soc_system_hps_0 Figure 15: New BSP (Default) The Preloader Image Layout is displayed in the following diagram:

14 14 Preloader Generation Figure 16: Preloader Image Layout AN Note: If the user wishes to have multiple Preloader Images, then use the following guide and see the following figure for reference: Uncheck/De-Select the Use Default Locations checkbox Specify the target folders accordingly

15 AN Preloader Generation 15 Figure 17: New BSP (Alternate Location) 5. Click OK to close the New BSP dialog box. This will populate the BSP Editor with the default settings. 6. Before proceeding, verify all Preloader settings as shown in the following figure, then Click Generate to continue.

16 16 Preloader Generation Figure 18: Generate BSP AN Exit the BSP Editor and verify the files generated as shown in the following table: Table 2: BSP Files Generated settings.bsp Makefile preloader.ds Project File Description Folder containing source code that was generated based on the information from the handoff folder. Preloader settings file, that contains the settings from the Preloader Generator. Makefile used to build the Preloader ARM DS-5 AE that can be used to load the Preloader. 8. From the Embedded Command Shell, change to the BSP Target Directory Note: Specified by the Preloader Settings from the BSP Editor. 9. Build the generated Preloader image using the make command from the shell. Note: Note: The Makefile (created by the Preloader Generator) performs the following steps:

17 AN Bare Metal Application 17 Extract the fixed part of the Preloader source code Build the Preloader executable using the fixed and the generated parts of the Preloader source code Convert the executable to binary, then add the bootrom required header on top of it 10.Verify the post build files are present in the BSP target directory shown in the following table: Table 3: Preloader Files Project File uboot-socfpga/spl/u-boot-sp.binl uboot-socfpga/spl/u-boot-spl preloader-mkpimage.bin Description Preloader binary file. Preloader ELF file. Preloader image w/ BootROM required header. Bare Metal Application In the Boot Flow examples, the Bare Metal Hello World application is used as the Application Stage in the Boot Flow scenario. Note: Before continuing, you must unzip the Hello World application project into a target folder. The following table lists the files that must be included in the project. Table 4: Project Files test.c io.c Makefile Debug-unhosted.ds File Description Main entry source code file. Source file containing IO specific code. GNU build Makefile Debugger launch script. Building the Application There are two ways you can build the Hello World application: From DS-5 Eclipse, Import and build the SoCEDS project By running make from the Embedded Command Shell If you choose to run make from the Embedded Command Shell, you must do the following: 1. Launch an Embedded Command Shell from the SoCEDS Launch Menu. 2. Navigate to the folder containing the Hello World project files. 3. Navigate to the Sample folder and run the make command to build the project. When the build completes, verify the following result executables:

18 18 Boot Examples Table 5: Post Build AN test-img.bin test.axf File Executable Image File DS-5 Project executable Description Boot Examples This section contains select examples for the Boot Modes supported as described in the Boot Source section. The examples demonstrate configuring the board to boot from the source device chosen and having the Preloader run the Bare Metal application from the Bare Metal Hello World section. Note: All examples require generating the Preloader image and building the Bare Metal example application sources. These are both covered in the following sections: Preloader Generation and Bare Metal Application. For reference on the Boot Flow scenario for all examples shown in the figure beow. The application is the next stage image verifiesd and loaded from the Preloader. The type of application is Bare Metal. The Boot flow is shown below: Figure 19: Preloader and Application Boot Stage Note: The Preloader image tool always places the output image at the start of the output binary file, regardless of the target flash memory type. The flash programming tool is responsible for placing the image at the desired location on the flash memory device. Booting from SD/MMC MBR Mode This section will cover configuring the GHRD to boot and run the Bare Metal example, Hello World, from a SD/MMC device. This section will cover the MBR and boot mode. Follow the steps below to generate the Preloader and configure the board for this boot scenario: 1. Generate the Preloader as defined in the Generating the Preloader section and verify:

19 AN MBR Mode 19 Select BOOT_FROM_SDDMC Figure 20: Boot From SD/MMC Select FAT_SUPPORT Figure 21: SD/MMC Boot Image with FAT_SUPPORT

20 20 MBR Mode Note: These settings configure the Preloader to boot from the SDMMC card that has been properly imaged with the SD Card Image file provided in the SoC EDS. After Preloader has completed its boot stage, it will then load the application from the FAT partition. 2. From the shell, navigate to the generated Preloader folder and perform the build using the make command. 3. Build the example: Bare Metal Application, as described in the Bare Metal Application. 4. Prepare the SD card for the Preloader Boot. a. Unzip the SD Card Image provided in the SoCEDS installation folder:\embedded\embeddedswsoc\ socfpga\prebuilt_images b. Download Win32 Disk Imager tool and write the image to the SD Card. Figure 22: Win32 Disk Image Tool AN Use the Disk Update Tool provided in the SoC EDS to update the SD Card partition with the built Preloader image: $ alt-boot-disk-util -p preloader-mkpimage.bin -a write -d <sd card drive> 6. Copy the Bare Metal application, Hello World, on to the SD card FAT partition. $ cp hellomkimage.bin <sd_mmc drive>/<path> 7. Boot the board.