# AMR Build Scripts

The AMR Git repository contains a shell script which can be used to build any of the AMR example designs. `build.sh` is the main build script, which calls other build scripts for each step of the build.


Example Build Command

The following command demonstrates how to build a V80 design. For RAVE set the appropriate -profile option

    $ cd <amr>
    $ ./build.sh -profile v80

<span id="amrbuildscripts-buildsteps"></span>

## Build Steps

The build script divides the build flow into a number of separate steps.

  - hw - Builds the hardware design and exports an XSA file

  - fw - using the XSA file, compiles the AMC firmware into an elf file

  - pdi - uses the outputs of previous steps to generate the device programming files

<span id="amrbuildscripts-hwstep"></span>

### hw step

The hw step of the build flow operates on the AMR hardware design described here. A /build_v80 directory is created, where the implemented hardware design and Vivado log are generated. The xpr file for this project is located here **amr/build_v80/amr_vivado_designs/alveo_v80/v80_base/project**. Similarly for RAVE it will be located under build_rave.

This Vivado project is used to generate the BD design, run Synthesis & Implementation, and create the initial PDI. The write\_hw\_platform command is run on the implemented design to create an XSA (named v80_base.xsa), which is used as a hardware handoff file to the AMC build in the fw build step.

<span id="amrbuildscripts-fwstep"></span>

### fw step

The fw step of the build flow operates on the AMR AMC firmware design described here: [Firmware Design - AMR](../firmware/index.md). The fw step builds the AMC firmware and generates final PDIs.

The AMC build is run in the AMC source code directory (i.e., **\<amr\>/fw/AMC**) using the AMC’s own build script **(\<amr\>/fw/AMC/scripts/build.sh).**

The AMC’s build.sh can take a number of different build options (which are detailed in the AMC’s [Profiles and CMake build process](../firmware/profiles-cmake.md) page), but the AMR build flow executes it with these specific options.

    ```bash
      ./scripts/build.sh -help
      =================================== AMC Build script ====================================

      -profile <profile_name> : set the board profile to build (rave|v80)
      -xsa <abs_path_to_xsa>  : Path to the XSA file to generate BSP from
      -sdt                    : Path to SDT folder
      -amc                    : only builds the AMC application (BSP untouched)
      -analysis               : triggers a static analysis check on AMC files

      Any additional arguments are passed directly into CMAKE
      Note:
        Either the XSA or the SDT must be provided
        if both XSA and SDT are provided, then the SDT will be used to generate the BSP

      E.g.: To build from scratch:
      ./scripts/build.sh -xsa /path/to/example.xsa -profile <v80|rave>

    ```

The **profile** is the v80 or rave and the **xsa** is the xsa generated in the hw step.

The resultant ELF file from the AMC build is then stored in the fw directory (**\<amr\>/fw/AMC/build_amc/amc.elf**)

**Tip:** If the firmware has changed and the hardware design has not, the hardware XSA does not need to be re-built when compiling the firmware. Following command can be used to build amc only
  ./scripts/build.sh -xsa /path/to/example.xsa -profile <v80|rave> -amc

<span id="amrbuildscripts-pdistep"></span>

### pdi step

The pdi step is responsible for combining outputs from previous steps in order to create two different bin files. The two generated PDIs are known as the amr\_ospi.bin and the amr\_ospi\_fpt.bin.

First, the amr\_ospi.bin is created when bootgen is called to combine the PDI generated in the hw step with the AMC ELF which was generated in the fw step. This PDI contains the complete AMR design and is intended to be written to a flash partition over PCIe using AMI.

[![image2](../images/1107374131.png)](../images/1107374131.png)

The amr\_ospi\_fpt.bin is intended to be written to flash over JTAG using HW Manager. This PDI sets up the flash so that it can be used by AMC/AMI.

This basically means that it contains the FPT at the beginning of the OSPI flash memory, which AMI/AMC can then process to determine where in flash it can write different PDIs. Padding is added between the amr\_ospi\_fpt.bin and the amr\_ospi.bin to ensure that the amr\_ospi.bin is aligned to a 32KB boundary (this is a requirement of the PMC boot search).

Effectively, the amr\_ospi\_fpt.bin configures the flash to contain the FPT along with amr\_ospi.bin in the 1st PDI Partition.

Writing amr\_ospi\_fpt.bin to flash is only required if the FPT has been modified. Otherwise, if the FPT in flash is still valid, then the amr\_ospi.bin can be written to one of the PDI partitions over PCIe using AMI.