![]() While compiling the Preloader, the CONFIG_SPL_BUILD variable is automatically defined, both in the make environment and in the C compilation flags. U-Boot supports a lot of drivers mainly because it leverages the existing Linux kernel drivers. This allows the Preloader access to the extensive set of available U-Boot drivers. The Preloader and U-Boot share most of the source code. 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.įor the remainder of this document we will use the U-Boot source code created by the Preloader Generator. U-Boot is also included with the Yocto Source Package. Note that the main repository for the U-Boot source code is the git tree at. 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 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.įor applications where only the Preloader is needed, the above is sufficient. ![]() See Generating and Compiling the Preloader for detailed steps on how to generate and compile the Preloader. The following figure presents an overview of how the Preloader is generated, by using the tools provided with SoC EDS. The Preloader is based on the SPL (Secondary Program Loader), which is a component of U-Boot, the open source bootloader. Golden System Reference Design Boot Flow.Performs minimal configuration and loads Preloader into 64KB OCRAMĬonfigures clocking, IOCSR, pinmuxing, DDRAM and loads U-boot into DDRAMįor more information about SoC FPGA booting please refer to the following documents: The following table presents a short description of the different boot stages: Stage The only requirement is that the next stage image has the proper mkimage header, that is required for U-boot to recognize the image. Load another bootloader that can subsequently load the applications.The next stage boot image loaded and executed by the Preloader does not necessarily needs to be an U-boot image. The U-Boot and Linux are used by the GSRD, but they are not required for all applications. They are shown in blue in the above figure. The BootROM and the Preloader stages are needed for all the applications in which the Cyclone V or Arria V SoCs are used. The typical HPS boot flow includes the following stages: ![]() An overview of HPS boot flow and Preloader generation flow are also included. This page introduces the reader to the Preloader and U-Boot source code and how to customize them for a new board. Changing Linux command line arguments to isolate an HPS core via U-Boot.Disabling SDRAM Initialization & Calibration.Loading U-Boot/Next Image From FAT Partition.Adding a New Board to Preloader & U-Boot.Terasic Stratix 10 SoC Board : DE10-Pro.Terasic Stratix 10 SoC Board : Apollo S10 SoM.REFLEX CES COMXpressSX Stratix 10 Module.Terasic DE1-SoC Development and Education Board.Solectrix SMARC compliant System-on-Module.Networked Pro-Audio FPGA SoC Development Kit by Coveloz.Mpression Borax SOM Module and Development Kit by Macnica.Mpression Sodia Evaluation Board by Macnica.Mpression Helio SoC Evaluation Kit by Macnica.Altera Cyclone V SoC Development Platform.Critical Link MitySOM-5CSx Development Kit. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |