ATCA board bsp
Preloader and U-Boot Customization - v13.1 Overview This page introduces the reader to the Preloader and U-Boot source code and how to customize them for a new board. An overview of HPS boot flow and Preloader generation flow are also included. HPS Boot Flow The typical HPS boot flow includes the following stages:
- BootROM
- Preloader
- U-Boot
- Linux
The BootROM and the Preloader stages are needed for all the applications in which the Cyclone V or Arria V SoCs are used. They are shown in blue in the above figure. The U-Boot and Linux are used by the GSRD, but they are not required for all applications. The next stage boot image loaded and executed by the Preloader does not necessarily needs to be an U-boot image. For example the Preloader can : ● Load bare-metal applications directly, ● Load RTOS-es or OS-es directly, ● Load another bootloader that can subsequently load the applications. The only requirement is that the next stage image has the proper mkimage header, that is required for U-boot to recognize the image. The following table presents a short description of the different boot stages: Stage Description BootROM Performs minimal configuration and loads Preloader into 64KB OCRAM Preloader Configures clocking, IOCSR, pinmuxing, DDRAM and loads U-boot into DDRAM U-boot Configures FPGA, loads Linux kernel Linux Runs the end application For more information about SoC FPGA booting please refer to the following documents: ● Cyclone V Booting and Configuration ● Arria V Booting and Configuration ● Golden System Reference Design Boot Flow Preloader Generation Flow The Preloader is based on the SPL (Secondary Program Loader), which is a component of U-Boot, the open source bootloader. The following figure presents an overview of how the Preloader is generated, by using the tools provided with SoC EDS.
See Generating and Compiling the Preloader for detailed steps on how to generate and compile the Preloader. Note that the make command above first extracts the full U-Boot source code, then it copies the generated Preloader configuration files to the U-Boot source code, and finally compiles the Preloader. For applications where only the Preloader is needed, the above is sufficient. But for applications where U-Boot is needed too, the command make uboot can be used to also compile the U-Boot image.
Note that the main repository for the U-Boot source code is the git tree at http://rocketboards.org/gitweb/. U-Boot is also included with the Yocto Source Package. The U-Boot source code generated by SoC EDS tools is provided for reference only, but it can be useful in understanding the interactions between Preloader and U-Boot, especially when tweaking parameters like clocking.
For the remainder of this document we will use the U-Boot source code created by the Preloader Generator.
Preloader & U-Boot Source Code
The Preloader is based on the SPL (Secondary Program Loader), which is a component of U-Boot, the open source bootloader.
Common Source Code
The Preloader and U-Boot share most of the source code. This allows the Preloader access to the extensive set of available U-Boot drivers. U-Boot supports a lot of drivers mainly because it leverages the existing Linux kernel drivers.
While compiling the Preloader, the CONFIG_SPL_BUILD variable is automatically defined, both in the make environment and in the C compilation flags. Therefore the source code and the makefiles can discern whether they are compiled for U-Boot or the Preloader and perform the necessary customizations.
For example the file board/altera/socfpga/Makefilehas the following statement that adds the pinmuxing and iocsr configuration files to the Preloader build only:
COBJS-$(CONFIG_SPL_BUILD) += pinmux_config_cyclone5.o iocsr_config_cyclone5.o
Another example is the file arch/arm/cpu/armv7/socfpga/s_init.c:
#ifdef CONFIG_SPL_BUILD
/* re-setup watchdog /
DEBUG_MEMORY
if (!(is_wdt_in_reset())) {
/
* only disabled if wdt not in reset state
* disable the watchdog prior PLL reconfiguration
*/
DEBUG_MEMORY
watchdog_disable();
}
...
Top Level Files & Folders
The following table presents an overview of the U-Boot source code, at the top level.
File/Folder Description
api/ Architecture independent API for external applications
arch/ Architecture specific folder
board/ Board related files
common/ Different common files, such as SPL and U-Boot commands
disk/ Disk related files
doc/ Documentation folder, in text format
drivers/ Drivers folder
dts/ Device Tree related files
examples/ Example source code
fs/ Filesystem source code
include/ Include files
lib/ Various libraries, such as compression, random number generation etc.
nand_spl/ Files use when booting from NAND
net/ Network stack source code
post/ Power-on Self Test files
spl/ Preloader Files
test/ Test code
tools/ Host tools folder. The most important is mkimage
boards.cfg Describes all the supported platforms in a tabular text format
MAINTAINERS List of maintainers for all the supported platforms, including names and email addresses
MAKEALL Utility for building
Makefile Makefile
mkconfig Utility for configuring
README Readme file
rules.mk Makefile include file
Relevant Folders
The following table highlights a few of the most relevant folders, related to the Altera Cyclone V and Arria V SoCs.
Folder Description
arch/arm/cpu/armv7/socfpga/ Architecture specific files, like clock manager, interrupt controller etc
arch/arm/include/asm/arch-socfpga/ Include files for the architecture specific source code
board/altera/socfpga/ Board specific files - some generated by the Preloader Generator
board/altera/socfpga/sdram Board specific DDRAM files - some generated by the Preloader Generator
Board Files
The following table presents the Altera board specific files. The Generated column designates which files are generated by the Preloader Generator.
Folder File Generated Description
board/altera/socfpga/ build.h yes Preloader Build Parameters
iocsr_config_arria5.c yes I/O Pin Configuration Blob (Arria V)
iocsr_config_arria5.h yes
iocsr_config_cyclone5.c yes I/O Pin Configuration Blob (Cyclone V)
iocsr_config_cyclone5.h yes
pinmux_config.h yes Pin Muxing Parameters Header
pinmux_config_arria5.c yes Pin Muxing Parameters (Arria V)
pinmux_config_cyclone5.c yes Pin Muxing Parameters (Cyclone V)
pll_config.h yes Clocking Configuration
reset_config.h yes Reset Configuration
Makefile Makefile
socfpga_common.c Common Functions
socfpga_arria5.c Displays Board Name (Arria V)
socfpga_cyclone5.c Displays Board Name (Cyclone V)
timestamp_config.h Timestamp File
board/altera/socfpga/sdram/ sdram_config.h yes SDRAM Configuration Parameters
Makefile SDRAM Configuration Makefile
alt_types.h SDRAM Configuration Source Code
sdram.h
sdram_io.h
sequencer.c
sequencer.h
sequencer_auto.h
sequencer_auto_ac_init.c
sequencer_auto_inst_init.c
sequencer_defines.h
system.h
tclrpt.c
tclrpt.h
Various Files
The following table presents a few more files that are relevant for the Altera SoCs:
File Description
doc/README.SOCFPGA SoC specific readme file
doc/README.SPL SPL specific readme file
include/configs/socfpga_arria5.h Arria V configuration file
include/configs/socfpga_cyclone5.h Cyclone V configuration file
include/configs/socfpga_common.h Common configuration file for Cyclone V and Arria V
boards.cfg File defining all the supported targets
Target Parameters
The parameters for each supported U-Boot board, the configuration parameters are stored in a C include file named include/configs/<board_name>.h. These parameters are shared between Preloader and U-Boot.
For the Cyclone V and Arria V SoCs, the following files are used:
● include/configs/socfpga_arria5.h - Arria V parameters
● include/configs/socfpga_cyclone5.h - Cyclone V parameters
● include/configs/socfpga_common.h - Shared parameters
The following table details some of the board parameters:
Parameter Description
CONFIG_SYS_PROMPT U-Boot command prompt string
CONFIG_EMAC_BASE Base address of EMAC peripheral control registers
CONFIG_EPHY_PHY_ADDR Address of EMAC PHY
CONFIG_PHY_INTERFACE_MODE EMAC mode of operation
CONFIG_BOOTDELAY U-Boot boot delay
CONFIG_BAUDRATE Baudrate to be used for serial commnication
CONFIG_EXTRA_ENV_SETTINGS Default environment variables for U-Boot
CONFIG_MMC SD Card related parameters
CONFIG_SDMMC_BASE
CONFIG_SDMMC_HOST_HS
CONFIG_GENERIC_MMC
CONFIG_DWMMC
CONFIG_ALTERA_DWMMC
CONFIG_DWMMC_FIFO_DEPTH
CONFIG_SYS_MMC_MAX_BLK_COUNT
CONFIG_DWMMC_BUS_WIDTH
CONFIG_DWMMC_BUS_HZ
CONFIG_DWMMC_BUS_WIDTH
CONFIG_DWMMC_BUS_HZ
CONFIG_CADENCE_QSPI QSPI flash related parameters
CONFIG_CQSPI_BASE
CONFIG_CQSPI_AHB_BASE
CONFIG_SPI_FLASH
CONFIG_SPI_FLASH_STMICRO
CONFIG_SF_DEFAULT_SPEED
CONFIG_SF_DEFAULT_MODE
CONFIG_SPI_FLASH_QUAD
CONFIG_CQSPI_REF_CLK
CONFIG_CQSPI_PAGE_SIZE
CONFIG_CQSPI_BLOCK_SIZE
CONFIG_CQSPI_TSHSL_NS
CONFIG_CQSPI_TSD2D_NS
CONFIG_CQSPI_TCHSH_NS
CONFIG_CQSPI_TSLCH_NS
CONFIG_CQSPI_DECODER
CONFIG_CQSPI_4BYTE_ADDR
CONFIG_DESIGNWARE_ETH EMAC related parameters
CONFIG_EMAC0_BASE
CONFIG_EMAC1_BASE
CONFIG_NET_MULTI
CONFIG_DW_ALTDESCRIPTOR
CONFIG_DW_SEARCH_PHY
CONFIG_MII
CONFIG_PHY_GIGE
CONFIG_DW_AUTONEG
CONFIG_AUTONEG_TIMEOUT
CONFIG_PHYLIB
CONFIG_PHY_MICREL
CONFIG_PHY_MICREL_KSZ9021
CONFIG_EPHY0_PHY_ADDR
CONFIG_EPHY1_PHY_ADDR
CONFIG_KSZ9021_CLK_SKEW_ENV
CONFIG_KSZ9021_CLK_SKEW_VAL
CONFIG_KSZ9021_DATA_SKEW_ENV
CONFIG_KSZ9021_DATA_SKEW_VAL
CONFIG_SYS_SDRAM_BASE Physical SDRAM base address
PHYS_SDRAM_1_SIZE Physical SDRAM size
The U-Boot command line interface allows execution of different commands. These commands can also be executed from U-Boot scripts. The commands' source code is located in the folder common and are named cmd_
The target configuration file can enable various commands by defining the macro CONFIG_CMD_. Here are some of the commands enabled by the socfpga_common.h:
Macro Description
CONFIG_CMD_FAT Enable FAT filesystem support
CONFIG_CMD_EXT2 Enable EXT2 filesystem support
CONFIG_CMD_MMC Enable SD/MMC support
CONFIG_CMD_USB Enable USB support
CONFIG_CMD_DHCP Enable DHCP support
CONFIG_CMD_MII Enable MII commands
CONFIG_CMD_NET Enable networking commands
CONFIG_CMD_PING Enable ping command
CONFIG_CMD_MTDPARTS Enable MTD partition support
CONFIG_CMD_SF Enable serial flash support
CONFIG_CMD_FPGA Enable FPGA commands
Preloader Parameters
The following sections will present some of the settings that are included in the files generated by the Preloader Generator.
Preloader Build Parameters
The following Preloader parameters are passed in the generated file build.h. They are usually edited in the Preloader Generator GUI but can also be edited manually after they are generated.
Parameter Description
CONFIG_PRELOADER_BOOT_FROM_QSPI Preloader boot source, mutually exclusive.Also used by U-Boot to decide where to store the environment variables
CONFIG_PRELOADER_BOOT_FROM_SDMMC
CONFIG_PRELOADER_BOOT_FROM_RAM
CONFIG_PRELOADER_QSPI_NEXT_BOOT_IMAGE Location of boot image on QSPI Flash
CONFIG_PRELOADER_SDMMC_NEXT_BOOT_IMAGE Location of boot image on SD card
CONFIG_PRELOADER_WATCHDOG_ENABLE Enable watchdog operation
CONFIG_PRELOADER_DEBUG_MEMORY_WRITE Write debug info in memory
CONFIG_PRELOADER_SEMIHOSTING Use semihosting for printing messages - requies debugger
CONFIG_PRELOADER_CHECKSUM_NEXT_IMAGE Use checksum on the next image
CONFIG_PRELOADER_SERIAL_SUPPORT Enable serial port for debug messages
CONFIG_PRELOADER_HARDWARE_DIAGNOSTIC Enable hardware diagnostic support
CONFIG_PRELOADER_EXE_ON_FPGA Run Preloader from FPGA memory
CONFIG_FPGA_MAX_SIZE FPGA memory parameters, used when running Preloader from FPGA memory
CONFIG_FPGA_DATA_BASE
CONFIG_FPGA_DATA_MAX_SIZE
CONFIG_PRELOADER_STATE_REG_ENABLE Pass information to BootROM that Preloader executed OK
CONFIG_PRELOADER_BOOTROM_HANDSHAKE_CFGIO Pass information to BootROM that Preloader completed configuration of IOCSR and pin muxing
CONFIG_PRELOADER_WARMRST_SKIP_CFGIO Preloader to skip IOCSR configuration on warm resets
CONFIG_PRELOADER_SKIP_SDRAM Skip SDRAM initialization and calibration
Preloader Reset Parameters
The following parameters are passed in the file reset_config.h, which is generated by the Preloader Generator. The Editable column identifies the parameters that can be edited in the Preloader Generator GUI. If a parameter is not marked as editable, it means it is passed from the Qsys design and should not be manually edited. Each parameter instructs the Preloader whether to keep a module in reset or not.
Parameter Editable
CONFIG_HPS_RESET_ASSERT_EMAC0
CONFIG_HPS_RESET_ASSERT_EMAC1
CONFIG_HPS_RESET_ASSERT_USB0
CONFIG_HPS_RESET_ASSERT_USB1
CONFIG_HPS_RESET_ASSERT_NAND
CONFIG_HPS_RESET_ASSERT_SDMMC
CONFIG_HPS_RESET_ASSERT_QSPI
CONFIG_HPS_RESET_ASSERT_UART0
CONFIG_HPS_RESET_ASSERT_UART1
CONFIG_HPS_RESET_ASSERT_I2C0
CONFIG_HPS_RESET_ASSERT_I2C1
CONFIG_HPS_RESET_ASSERT_I2C2
CONFIG_HPS_RESET_ASSERT_I2C3
CONFIG_HPS_RESET_ASSERT_SPIM0
CONFIG_HPS_RESET_ASSERT_SPIM1
CONFIG_HPS_RESET_ASSERT_SPIS0
CONFIG_HPS_RESET_ASSERT_SPIS1
CONFIG_HPS_RESET_ASSERT_CAN0
CONFIG_HPS_RESET_ASSERT_CAN1
CONFIG_HPS_RESET_ASSERT_L4WD1 yes
CONFIG_HPS_RESET_ASSERT_OSC1TIMER1 yes
CONFIG_HPS_RESET_ASSERT_SPTIMER0 yes
CONFIG_HPS_RESET_ASSERT_SPTIMER1 yes
CONFIG_HPS_RESET_ASSERT_GPIO0 yes
CONFIG_HPS_RESET_ASSERT_GPIO1 yes
CONFIG_HPS_RESET_ASSERT_GPIO2 yes
CONFIG_HPS_RESET_ASSERT_DMA yes
CONFIG_HPS_RESET_ASSERT_SDR yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA0 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA1 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA2 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA3 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA4 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA5 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA6 yes
CONFIG_HPS_RESET_ASSERT_FPGA_DMA7 yes
CONFIG_HPS_RESET_ASSERT_HPS2FPGA
CONFIG_HPS_RESET_ASSERT_LWHPS2FPGA
CONFIG_HPS_RESET_ASSERT_FPGA2HPS
CONFIG_HPS_RESET_WARMRST_HANDSHAKE_FPGA yes
CONFIG_HPS_RESET_WARMRST_HANDSHAKE_ETR yes
CONFIG_HPS_RESET_WARMRST_HANDSHAKE_SDRAM yes
Preloader Clocking Parameters
The clocking parameters are created by the Preloader Generator and stored in the file pll_config.h. See Preloader Clocking Customizationfor more details about the file and a calculator to facilitate editing it.
Preloader IOCSR & Pinmuxing Parameters
The IOCSR parameters define the HPS pin behavior: input or output, drive strength, logic levels etc. The file is called iocsr_config_<cyclone/arria>5.h and .c and is generated automatically by the Preloader Generator based on the handoff information from Qsys. These files cannot be manually edited, since the IOCSR interface is not publicly documented.
The pin muxing parameters are stored in the file pinmux_config.h and are generated by the Preloader Generator based on Qsys settings. They should not be generally edited by hand.
Preloader SDRAM Parameters
The SDRAM parameters are stored in the file sdram_config.h that is generated by the Preloader Generator based on the handoff information from Qsys. Do not edit this file manually.
Compiling the Preloader & U-Boot
This section presents some details about compilation of Preloader and U-Boot.
Compiling the Preloader
The Preloader is compiled from an embedded command shell by using the following commands:
$ /altera/13.1/embedded/embedded_command_shell.sh
$ cd <hardware_folder>/software/spl_bsp
$ make
See Generating and Compiling the Preloader for more details about compiling the Preloader.
Compiling U-Boot
U-Boot can be compiled either standalone, or from the source code generated by the Preloader Generator. When compiled in standalone mode, the following commands can be used:
$ export CROSS_COMPILE=<gnu_tools_path_and_prefix>
$ make mrproper
$ make socfpga_cyclone5_config or socfpga_arria5_config
$ make
See Using Git Trees for more details about compiling U-Boot.
When using the source code generated by the SoC EDS Preloader Generator, the following commands can be used to compile U-Boot:
$ ~/altera/13.1/embedded/embedded_command_shell.sh
$ cd <hardware_folder>/software/spl_bsp
$ make uboot
Adding a New Board to Preloader & U-Boot
This section demonstrates how to add a new board to the Preloader and U-Boot source code, by cloning the socfpga_cyclone5 board. This is needed in case the user does not want to directly modify the Altera files, and it is mandatory if the user wants to eventually upmerge the U-Boot changes.
The following prerequisites are needed:
● Host PC running Windows or Linux (Linux is preferred)
● SoC EDS - can be downloaded from https://www.altera.com/download/software/soc-eds
● Hardware Design - can be based on the GHRD. This section assumes the hardware design is stored in a folder named ~/acme_hwdesign
For the purpose of this example, the new board will be called acme_dynamite, provided by the vendor acme and be based on the SoC socfpga.
- Create the hardware design and compile it in Quartus, to obtain the handoff information folder. You can use the GHRD (Golden Hardware Reference Design) as a starting point. For more information on how to compile the hardware design see Compiling the GHRD.
- Generate the Preloader based on the handoff information folder from Quartus. See Generating and Compiling the Preloader for more information on how to generate the Preloader.
- Compile the Preloader once, to make sure all the source code is available. This is needed because the first time the Preloader is compiled, it will extract the Preloader and U-Boot source code from an archive that is part of the SoC EDS. Then clean the code, to remove intermediate files. $ ~/altera/13.1/embedded/embedded_command_shell.sh $ cd ~/acme_hwdesign/software/spl_bsp $ make $ make clean
- Change the current folder to be the generated Preloader and U-boot source code: $ cd ~/acme_hwdesign/software/spl_bsp/uboot-socfpga
- Make a copy of the board folder board/altera/socfpgato the folder board/acme/dynamite $ mkdir -p board/acme/dynamite $ cp -r board/altera/socfpga/* board/acme/dynamite
- Make a copy of the configuration files socfpga_cyclone5.h and socfpga_common.h to match the acme_dynamitename: $ cp include/configs/socfpga_cyclone5.h include/configs/acme_dynamite.h $ cp include/configs/socfpga_common.h include/configs/acme_dynamite_common.h
- Edit the new configuration file acme_dynamite.h to: ● add the CONFIG_ACME_DYNAMITE in addition to the CONFIG_SOCFPGA_CYCLONE5: ● replace reference to socfpga_common.h to acme_dynamite_common.h ● replace path board/altera/socfpga with path board/acme/dynamite ● change the U-Boot prompt from SOCFPGA_CYCLONE5 to ACME_DYNAMITE $ sed -i 's/#define CONFIG_SOCFPGA_CYCLONE5/&\n#define CONFIG_ACME_DYNAMITE/g' include/configs/acme_dynamite.h $ sed -i 's/socfpga_common.h/acme_dynamite_common.h/g' include/configs/acme_dynamite.h $ sed -i 's/board/altera/socfpga/board/acme/dynamite/g' include/configs/acme_dynamite.h $ sed -i 's/SOCFPGA_CYCLONE5 #/ACME_DYNAMITE #/g' include/configs/acme_dynamite.h
- Edit the file acme_dynamite_common.h to replace the path board/altera/socfpgawith path board/acme/dynamite $ sed -i 's/board/altera/socfpga/board/acme/dynamite/g' include/configs/acme_dynamite_common.h
- Edit the file that displays the board name to use the new name: $ sed -i 's/Altera SOCFPGA Cyclone V Board/Acme Dynamite Board/g' board/acme/dynamite/socfpga_cyclone5.c
- Edit the file boards.cfg to add the new acme_dynamite board, as shown in the table below: Target ARCH CPU Board Name Vendor SoC options acme_dynamite arm armv7 dynamite acme socfpga socfpga_cyclone5 arm armv7 socfpga altera socfpga socfpga_arria5 arm armv7 socfpga altera socfpga $ sed -i 's/socfpga_cyclone5/acme_dynamite arm armv7 dynamite acme socfpga\n&/' boards.cfg
- Update the Makefilecreated by the Preloader Generator to use the new target board: $ cd ~/acme_hwdesign/software/spl_bsp/ $ sed -i 's/board/altera/socfpga/board/acme/dynamite/g' Makefile $ sed -i 's/socfpga_$(DEVICE_FAMILY)_config/acme_dynamite_config/g' Makefile
- Build Preloader and U-boot for the new acme_dynamiteboard $ ~/altera/13.1/embedded/embedded_command_shell.sh $ cd ~/acme_hwdesign/software/spl_bsp $ make $ make uboot
- Create a bootable SD card or use the one provided with the GSRD, and replace the Preloader and U-boot images with the new ones. Fore more details, please refer to: ● Booting Linux Using Prebuilt SD Card Image ● Creating and Updating SD Card
- Boot the board, pressing any key to stop at U-Boot console. The messages displayed on the console will look similar to the following listing. Highlighted in red are the board name for Preloader and U-Boot and also the U-Boot console prompt. U-Boot SPL 2013.01.01 (Oct 21 2013 - 13:44:30) BOARD : Acme Dynamite Board SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: ECC Enabled ALTERA DWMMC: 0
U-Boot 2013.01.01 (Oct 21 2013 - 13:44:44) CPU : Altera SOCFPGA Platform BOARD : Acme Dynamite Board DRAM: 1 GiB MMC: ALTERA DWMMC: 0 *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: mii0 Warning: failed to set MAC address
Hit any key to stop autoboot: 0 ACME_DYNAMITE #
Common Customization Recipes This section presents a list of useful customizations recipes for Preloader and/or U-Boot. Loading U-Boot/Next Image From FAT Partition When booting from SD/MMC the Preloader loads the next image from the offset CONFIG_PRELOADER_SDMMC_NEXT_BOOT_IMAGE inside the custom partition with id=0xA2. The Preloader also offers the option of loading the next image from a FAT partition on the SD card instead. Here are the required steps in order to achieve this:
- Enable the FAT support in Preloader by editing the include/configs/socfpga_common.h #define CONFIG_SPL_FAT_SUPPORT
- Tell Preloader the U-Boot's filename to be loaded and partition which FAT located: #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img"
- Build the Preloader
- Copy the image file in the selected FAT partition. Changing SDRAM Memory Size The SDRAM memory is used by the Preloader to load U-Boot (or another image) and execute it.Changing the SDRAM memory size is achieved by editing the parameter PHYS_SDRAM_1_SIZE in the file include/configs/socfpga_common.h. The base address of the SDRAM memory can also be edited in the same file by changing the parameter CONFIG_SYS_SDRAM_BASE. Disabling SDRAM Initialization & Calibration The SDRAM initialization can be disabled from the Preloader Generator GUI or by editing the file build.h and setting the parameter CONFIG_PRELOADER_SKIP_SDRAM to 1. This can be useful for example if the user wants the Preloader to use the FPGA SDRAM memory instead of HPS SDRAM memory. In order to achieve that the user needs to disable SDRAM initalization, and define the=PHYS_SDRAM_1_SIZE= and CONFIG_SYS_SDRAM_BASE parameters to point to the FPGA SDRAM memory. Changing HPS Clocking The Preloader Generator sets up the HPS clock tree using default hardcoded values. See Customizing HPS Clocks in Preloader for details on how to modify the clock values. Using a Different SDRAM Memory Edit the HPS component in Qsys to enter the proper memory parameters, compile the hardware design, generate and compile the Preloader. All the parameters will be updated automatically. Disabling SDRAM ECC The SDRAM ECC can be enabled in Qsys, by editing the HPS component. If the ECC is enabled in Qsys, then the Preloader will also enable it. For systems where the ECC was enabled, it can be disabled in the Preloader by editing the file board/altera/socfpga_cyclone5/sdram/sdram_config.h and defining the following parameters to 0: #define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN (0) #define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCCORREN (0) Note that you cannot enable ECC using the above macros, for a design that does not have the ECC enabled in Qsys. You can only disable ECC for a system that was compiled with ECC enabled. Using a Different EMAC instance The GSRD uses EMAC1. In order to change that, you need to updated the board configuration file (include/condfigs/socfpga_cyclone5.h or similar) to change the following #define CONFIG_EMAC_BASE CONFIG_EMAC1_BASE #define CONFIG_EPHY_PHY_ADDR CONFIG_EPHY1_PHY_ADDR to #define CONFIG_EMAC_BASE CONFIG_EMAC0_BASE #define CONFIG_EPHY_PHY_ADDR CONFIG_EPHY0_PHY_ADDR Adding a New Driver in U-Boot The U-Boot has a lot of drivers that are used on its various supported platforms. It is relatively easy to enable one of the existing drivers for the target board. This section will show how to add the DesignWare I2C driver to the newly created acme_dynamite board.
- Edit the file include/configs/acme_dynamite.h to add the following definitions:
#define CONFIG_HARD_I2C
#define CONFIG_DW_I2C
#define CONFIG_SYS_I2C_BASE 0xffc04000 #define CONFIG_SYS_I2C_SPEED 100000 #define CONFIG_SYS_I2C_SLAVE 0x02 #define CONFIG_CMD_I2C
The following table presents a description of the above macros: Macro Description CONFIG_HARD_I2C Enable I2C hardware module driver CONFIG_DW_I2C Enable DesignWare I2C module driver CONFIG_SYS_I2C_BASE Base address for the DesignWare module CONFIG_SYS_I2C_SPEED I2C speed CONFIG_SYS_I2C_SLAVE Address of device when used as slave CONFIG_CMD_I2C Enable I2C commands - can be used from command line or scripts 2. Create empty file arch/arm/include/asm/arch-socfpga/hardware.h. The DesignWare I2C driver requires inclusion of this file, but the contents of the file is not actually used for our platform. $ touch arch/arm/include/asm/arch-socfpga/hardware.h 3. Compile U-Boot and put it on the boot medium (SD card or QSPI). 4. Boot Board. The log will display the I2C initialization and the I2C commands will be available at the U-Boot prompt and in the U-Boot scripts. U-Boot 2013.01.01 (Nov 01 2013 - 16:39:46) CPU : Altera SOCFPGA Platform BOARD : Acme Dynamite Board I2C: ready DRAM: 1 GiB MMC: ALTERA DWMMC: 0 *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: mii0 Warning: failed to set MAC address
Hit any key to stop autoboot: 0 ACME_DYNAMITE # Adding a New Driver in Preloader The U-Boot has a lot of drivers that are used on its various supported platforms. It is very easy to enable one of the existing drivers for the target board, to be used for the Preloader. This section will show how to add the DesignWare I2C driver to the newly created acme_dynamite board, for the Preloader.
- Edit the file include/configs/acme_dynamite.h to add the following definitions:
#define CONFIG_HARD_I2C
#define CONFIG_DW_I2C
#define CONFIG_SYS_I2C_BASE 0xffc04000 #define CONFIG_SYS_I2C_SPEED 100000 #define CONFIG_SYS_I2C_SLAVE 0x02 #define CONFIG_SPL_I2C_SUPPORT
The following table presents a description of the above macros: Macro Description CONFIG_HARD_I2C Enable I2C hardware module driver CONFIG_DW_I2C Enable DesignWare I2C module driver CONFIG_SYS_I2C_BASE Base address for the DesignWare module CONFIG_SYS_I2C_SPEED I2C speed CONFIG_SYS_I2C_SLAVE Address of device when used as slave CONFIG_SPL_I2C_SUPPORT Enable SPL/Preloader support for I2C 2. Create empty file arch/arm/include/asm/arch-socfpga/hardware.h. The DesignWare I2C driver requires inclusion of this file, but the contents of the file is not actually used for our platform. $ touch arch/arm/include/asm/arch-socfpga/hardware.h 3. Call the I2C initialization function at the end of the spl_board_init() function in the file arch\arm\cpu\armv7\socfpga\spl.c: ... #include <i2c.h> … void spl_board_init(void) { … #ifdef CONFIG_SPL_I2C_SUPPORT i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); puts("I2C : Initialized\n"); #endif } 4. Compile Preloader and put it on the boot medium (SD card or QSPI). 5. Boot Board. The log will display the I2C initialization message. U-Boot SPL 2013.01.01 (Nov 01 2013 - 16:53:52) BOARD : Acme Dynamite Board SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: ECC Enabled I2C : Initialized ALTERA DWMMC: 0 Detailed Preloader Execution Flow This section presents a detailed Preloader execution flow, to enable the user to better understand and debug the Preloader.
Changing Linux command line arguments to isolate an HPS core via U-Boot U-Boot can pass boot arguments to the Linux kernel to achieve different goals. It is sometimes necessary to keep Linux from scheduling processes in a given CPU so that that CPU could be dedicated to a given application. This is achieved by first telling Linux to isolate the CPU core we wish to dedicate to our application, and then having our application indicate that it wishes to run on the CPU that has been isolated. To isolate the CPU in a multi core system, we change the boot arguments U-Boot passes to Linux and recompile U-Boot. In the Altera Cyclone V board this is accomplished by modifying the file: include/configs/socfpga_common.h by changing the line: #define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE)
to #define CONFIG_BOOTARGS "isolcpus=1 console=ttyS0," __stringify(CONFIG_BAUDRATE)
In this example the second CPU of the processor is being isolated. (CPU numbering is zero based) Now, just compile and install U-Boot into your board. When Linux boots, you could verify the command line arguments passed to it by typing: cat /proc/cmdline
You can also run htop to view the CPU assigned to each running process. They should all say 1. (htop uses one based CPU numbering). Note: If the command line arguments are not what's expected, try rebooting and defaulting the board's U-Boot environment by doing the following: Interrupt the boot sequence and at the U-Boot command prompt enter the following two commands and reboot: env default -a saveenv
The second part of the process involves changing your application to run in the CPU core that has been isolated. Somewhere in your application initialization code do this: unsigned int cpu = 1 // zero based index of the CPU being targeted cpu_set_t mask; CPU_ZERO(&mask); CPU_SET(cpu, &mask); assert(sched_setaffinity(0, sizeof(mask), &mask) == 0);
Now run your application and run htop again. You should see that only your application is running on the second CPU.