element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
FPGA
  • Technologies
  • More
FPGA
Blog Using Avnet Build Scripts to Build a PetaLinux BSP (2019.2 and earlier)
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join FPGA to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: narrucmot
  • Date Created: 1 May 2020 2:52 AM Date Created
  • Views 5342 views
  • Likes 8 likes
  • Comments 12 comments
  • ultra96-v2
  • ultrazed-ev
  • tcl
  • ultrazed
  • microzed
  • avnet
  • petalinux
  • ultrazed-eg
  • picozed
  • vivado
  • ultra96
  • designed by avnet
  • vivado tcl
  • bash script
  • minized
Related
Recommended

Using Avnet Build Scripts to Build a PetaLinux BSP (2019.2 and earlier)

narrucmot
narrucmot
1 May 2020

This blog post is a long overdue continuation of the "Avnet HDL git HOWTO" blog post I wrote last year.  Like the Avnet HDL github repository of build scripts, IP, etc. for building the Vivado projects that are the hardware foundation for customers to use and customize, Avnet's PetaLinux github repository is also full of build scripts, bitbake recipes, etc. for creating BSPs that customers are able to use as the basis for their own Linux development on Avnet Zynq and Zynq UltraScale+ SOMs and development boards.  This blog will focus on building a PetaLinux BSP for the Avnet Ultra96-V2 board using a Linux bash build script from the Avnet "petalinux" github repository.

 

Before we Begin

Bold assumptions:

User is familiar with:

  • git commands
  • Linux command line
  • Xilinx PetaLinux tools

Software requirements:

  • Ubuntu v16.04 LTS or v18.04 LTS 64-bit host OS
  • PetaLinux tools installed
  • At least 100GB of free disk space

 

Repository Setup

Make the Repositories Folder

The git repositories must be installed into the same parent folder because the build scripts use relative paths to reference their required input files.  Choose a folder where you wish to clone the git repositories and run the scripts.  You will need at least 100GB of free disk space in this folder.  For example, you may wish to clone the repositories into a /home/<user>/git/avnet folder.

$ cd ~

$ mkdir -p git/avnet

$ cd git/avnet

 

Clone the Repositories

Clone the Avnet "petalinux", "hdl", and "bdf" git repositories.  Though we are building a PetaLinux BSP the underlying Vivado hardware platform is required and the PetaLinux build script will take care of launching the Vivado tools in the background to build this, hence the requirement now for the "hdl" and "bdf" repositories.

 

The "bdf" repository stores the Vivado Board Definition Files (BDFs) that are required to build or open any designs that target a known SOM or development board.  Xilinx provides BDFs for their boards (ZC702, ZCU102, etc.) and includes them in the Vivado installation.  Avnet provides this repository for the BDFs that target their SOMs and dev boards.

$ git clone https://github.com/avnet/bdf.git

 

The "hdl" git repository stores all of the TCL build scripts and design input files (constraints files, IP sources, etc.).

$ git clone https://github.com/avnet/hdl.git

 

The "petalinux" git repository stores all of the Linux bash build scripts and input files (Yocto recipes, patches, etc.).

$ git clone https://github.com/avnet/petalinux.git

 

Checkout the Correct git Branch

As you may know, git uses the concept of branches to separate revision controlled versions of source files.  For a stable repository with not many changes, like the bdf store, all changes can be tracked on the master branch.  For a more dynamic repository, like the hdl and petalinux stores, it makes sense to create branches tied to the version of Vivado and PetaLinux tools the build scripts, etc. are meant to work with

$ cd bdf

$ git checkout master

$ cd ../hdl

$ git checkout 2019.2

$ cd ../petalinux

$ git checkout 2019.2

 

Repository File Structure

The Avnet git repository for PetaLinux projects contains the following subdirectories:

 

DirectoryDescription
configsContains the files needed to create specific configurations for the Linux device tree, kernel, rootfs, and u-boot.
projectsEmpty when the repository is cloned.  This is where the PetaLinux project will be created when the build script is run.
scriptsContains the scripts for each for each of the scripted build projects.

 

This structure has been setup for maximum flexibility in design creation as well as maximum reuse of designs . Avnet has made a commitment to using this structure to implement our designs in order to give our customers a consistent look and feel to our reference designs. This will allow anyone to be able to edit a project to fit their needs. Typically we will release a TAG (snapshot) of a project guaranteeing it’s validity for a specific configuration. This provides great flexibility for users to start with a known-good project and edit the scripts as needed to create a project that has been purpose built for the configuration they want.

The Configs Folder

Here you will see the subfolders of the numerous components of a PetaLinux project that can be configured and customized.

image

The files in device-tree, kernel, and rootfs generally follow naming convention of filename.BOARD_NAME or filename.PROJECT_NAME. These BOARD_NAME and PROJECT_NAME variables are defined in the build scripts that fetch these files and incorporate them into the PetaLinux build. The u-boot configurations files generally follow a naming convention of platform-top.h.<board architecture>_<boot media method>. The meta-user/ROOTFS_NAME folders contain the custom applications, scripts, bitbake build recipes, etc. to be integrated into the rootfs of the PetaLinux build.

 

The Scripts Folder

The scripts folder contains the PetaLinux project build and cleanup scripts for all the available projects. The scripts in this folder generally follow the naming convention of <make| clean>_<board architecture>_<target application>.sh. Scripts that are used to build the generic PetaLinux BSPs for Avnet SOMs and development boards are named <make| clean>_<board architecture>_petalinux_bsp.sh.

 

Anatomy of a Project Script

It is important to note that the PetaLinux projects scripts will also first run the associated Vivado build script to build the underlying hardware platform that PetaLinux will run on. This is why it is a requirement that the git HDL repository also be cloned AND that it is cloned into the same parent folder as the PetaLinux git repository. There are three key portions of the PetaLinux Build Script:

  • Script Variables
  • Main Make Function
  • Build Hardware Platform
  • Create PetaLinux BSP

To get an understanding of what happens when we launch a scripted PetaLinux build, let's take a look at a sample build script and follow the chain of events that occur.  For this example we will examine the make_ultra96v2_oob_bsp.sh build script.

 

Script Variables

This section is where build options like boot method(s) for the build are set, path locations of where the Vivado and PetaLinux tools are installed, core names of the input and output build files, and relative path locations of where the input files can be found. The script specifies the Xilinx default install folders, and may need to be edited to match your environment. Different boot methods can be selected, and this in turn fetches the specific u-boot bootloader configuration that is needed for the selected boot media. Boot options include SD card, QSPI Flash, and eMMC.  Not all SOMs and dev boards support all boot methods.  The Ultra96-V2 board, for example, does not support QSPI or eMMC boot.  The default for the Ultra96-V2 is SD card boot with a ext4 partition for the root file system (rootfs).  The BUILD_BOOT_SD_OPTION is always set to yes (for the Ultra96-V2 this is always SD_EXT4 boot).

image

Main Make Function

This is the part of the script where the build target(s) are specified. In some cases like the MicroZed, PicoZed, and UltraZed SOMs there are different variants for the Xilinx device and Avnet carrier card that such that each has their own build configuration. The HDL_BOARD_NAME script variable defines the Avnet board target as input to the Vivado build script that is run during the build_hw_platform step.

image

 

Build Hardware Platform

The build script will first check to see if the Vivado hardware project has already been built. If it has then the script will move on to the next step to build the PetaLinux BSP. This is helpful to reduce run times when this PetaLinux script is run many times during development and debug.

image

 

Create PetaLinux BSP

This part of the script is where most of the work happens. It starts with the PetaLinux project is created:

The hardware definition file and PL bitstream from the Vivado project are copied to the PetaLinux project folder and imported into the PetaLinux project:image

image

The project config file is patched with customized settings:

image

The root filesystem (rootfs), device tree, and kernel are all configured with their particular settings imported from the configs folders:

image

Because the script may build a u-boot image for many different boot methods, the current boot configuration must be saved:

image

Do a full project clean before building the first image:

image

The script will build a PetaLinux image for each boot method that has been specified in the script variables. The script will loop here until the PetaLinux image is built successfully and the boot method-specific product files will be saved and copied to new filenames so they won't be overwritten later.  Once the builds are complete for each of the boot methods, the binary product files are copied to a project folder and the BSP file is created.

 

Launch the PetaLinux Build Script

Open a command terminal and navigate to the build scripts folder.

$ cd ~/git/avnet/petalinux/scripts

$ ./make_ultra96v2_oob_bsp.sh

 

The build will begin and the terminal window will display the progress as the hardware platform is built in Vivado and the the Linux OS image is created.

image
Prepare the SD Card and Boot the New Linux OS Image

Once the BSP build is complete you can boot the new OS image on the Ultra96-V2 board.  If you haven't already followed the Getting Started Guide you will need to first partition the SD card with - for example - a 1GB FAT32 boot partition and (assuming you are using the provided 16GB Delkin micro SD card) and a 15GB ext4 partition.  Navigate to the 'images/linux' folder of the PetaLinux project and extract the rootfs.tar.gz file to the ext4 partition and copy the BOOT.BIN and Linux kernel image.ub files to the FAT32 partition.  Remember that you will need to have 'root' or 'su' permissions to extract the rootfs to the ext4 partition.  It is a good idea to delete anything that is already in that partition, so be careful that you don't delete anything you need to keep.  For example, on an Ubuntu host:

$ cd ~/git/avnet/petalinux/projects/ultra96v2_oob_2019_2

$ cp ./images/linux/BOOT.BIN /media/training/<UUID of FAT32 partition>/.

$ cp ./images/linux/image.ub /media/training/<UUID of FAT32 partition>/.

$ sudo rm -rf /media/training/<UUID of ext4 partition>/*

$ sudo tar xvf ./images/linux/rootfs.tar.gz -C /media/training/<UUID of ext4 partition>/

$ sync; sync (VERY IMPORTANT to sync the filesystem BEFORE ejecting the SD card!  If you don't the filesystem may be corrupted.)

 

The Value of a Known-Good Design and Starting Point

The key idea behind these PetaLinux build scripts and the "bdf", "hdl", and "petalinux" github repositories is to easily create a known-good BSP targeting an Avnet SOM or dev board quickly, easily, and repeatably.  Being able to start a Xilinx design from a known-good starting point is critical when designing with complex devices like Zynq and Zynq MPSoC.  There are many Linux kernel, u-boot, and root filesystem configuration details, from devicetree settings and software packages, etc., that can cause hours and days of anguish to debug if they aren't done correctly.  For the engineers at Avnet these build scripts have the added benefit of providing a starting point when it is time to update a published reference design.  Public users are also welcome to use these repositories and contribute.

 

Buy Ultra96-V2Buy Ultra96-V2

 

Buy Ultra96-V2 I-gradeBuy Ultra96-V2 I-grade

 

Buy 96Boards 4A Power SupplyBuy 96Boards 4A Power Supply

 

Buy Ultra96-V2 JTAG/UART AdapterBuy Ultra96-V2 JTAG/UART Adapter

  • Sign in to reply

Top Comments

  • drozwood90
    drozwood90 over 4 years ago in reply to cmelement14 +1
    Hi there, With the appropriate substitutions, yes. It might be helpful to take a look at how Vitis is calling into the PetaLinux and HDL repos. From there, follow that through the code. The same things…
  • drozwood90
    drozwood90 over 4 years ago in reply to cmelement14 +1
    HI there, Take a look through projectMakefile.mk https://github.com/Avnet/vitis/blob/2020.1/projectMakefile.mk This is the backbone of everything. The variables are set by each product MakeFile (called…
  • ece7498
    ece7498 over 4 years ago +1
    Hello again! I achieved to run your instructions and produce a bsp and a linux-folder, import it on Vitis and run a vadd example. Great work by the way! Now I want to modify the petalinux-configuration…
  • narrucmot
    narrucmot over 4 years ago in reply to cthomas43

    Hi Chris,

     

    This script error is a result of the BUILD_FROM_TAG script variable is set to "true" in the scripts/common.sh file:

    image

    Change this to "false" and re-run the script and it should complete successfully.

     

    During our BSP release process we set this script variable to "true" because we create git tags for each BSP.  This allows us to verify and supply users a known-good set of script and PetaLinux build source files that match the BSP contents exactly.  We simply forgot to set this variable to "false" when we were done creating the tagged BSPs for posting online.  I apologize for this inconvenience.  I have fixed this now in the petalinux git repository.

     

    --Tom

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • cthomas43
    cthomas43 over 4 years ago

    I have been trying to run a script from /petalinux/scripts for one of the boards, but it fails with git tag saying that the reported hdl tag is blank and thus doesnt match the the requested tag. I am confident that it on the latest branch for both hdl and petalinux. Do you possibly know where I am going wrong?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • ece7498
    ece7498 over 4 years ago in reply to ece7498

    To be more specific with my question, why I can't see in "petalinux-config -c rootfs" the ZOCL and OPENCL and XRT ?
    As they are included in the final export.

    Thanks
    AE

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • lcaseiro
    lcaseiro over 4 years ago in reply to drozwood90

    Hi Dan,

     

    Thanks for your reply.

    The modules in question are kernel modules, to be included in the petalinux build. The problem is that the modules were developed for the specific kernel version (4.9 - the one used in the 2017.4 tools), so they recommend using that petalinux version. I have been in contact with the company providing those modules and they say they will not be upgrading the code for newer kernel versions any time soon.. They basically told me to use the older kernel.

     

    When using more recent kernel versions I cannot build the modules successfully, the build gives me lots of errors due to conflicting declarations and types... I suppose newer kernels have some fundamental differences that make the code unusable.. Since I have no experience developing kernel modules and the company did not give me any assistance in upgrading their code, I gave up on upgrading the modules themselves..

     

    I then tried using the 2017.4 version of the linux-xlnx kernel in more recent petalinux versions, but I had no success... After disabling the kernel version sanity check, changing the md5 values expected by petalinux and performing several other tweaks to the project, I was able to build a petalinux project successfully (with the 2017.4 linux-xlnx kernel on the 2019.1 petalinux tool). However, the board does not boot... I only get the first 2 lines of code from the fsbl (something similar to the code below) and the board shuts down...

    "Xilinx Zynq MP First Stage Boot Loader

    Release 2017.4   Feb  8 2021  -  19:21:34"

     

    The board fails to boot even without any changes to the petalinux project (just the inclusion of the older kernel). However, I tried including the kernel modules and they build successfully when the older kernel is used, which leads me to believe that the problem really is some incompatibility with newer kernels.

     

    I figured it could be due to the fact that I was using a more recent u-boot with an older kernel, so I tried to downgrade the u-boot to the 2017.4 version supplied by xilinx as well.. However, I could never get this to build...

     

    So, since I was having no luck in using recent tools with older kernel versions, I decided to revert to the older tools themselves... Which brought me to these build scripts (after long tries to get a simple petalinux project working without a bsp), in an attempt to get a BSP that could provide me with a working petalinux project for the 2017.4 tools.. However, I am still having no luck.. The project built directly from the BSP generated with these scripts (with no changes) is also not booting..

     

    Do your have any suggestion on how I should go about fixing this?

     

    Thank your very much!

     

    Luis

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • drozwood90
    drozwood90 over 4 years ago in reply to lcaseiro

    Hi Luis,

     

    How did the  third-party provide you with module recipes?  It is undoubtedly going to be MUCH MUCH MUCH simpler to upgrade/adapt/work with the third-party to change the modules rather than try to recreate the OS for older tools.  While possible, I personally think that is the hardest path forward - especially knowing the drivers and all the host of other issues you are going to run into.

     

    Assuming this is just a Vivado module, if it is provided as a netlist, version should not really matter.  If it is provided as a TCL usually there is a version check, you can change that and then update whatever breaks when you execute.  If it is a precompiled module, you can use that as a locked piece of logic, or you can attempt to "right click" it and update it.

     

    Overall, I really suggest you NOT try to create a whole new OS that was never intended to be, vs. upgrading if at all possible.

     

    --Dan

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube