Guidance Note Version # 0.5 (Cross GCC)

Zynq: Using a Custom BareMetal GCC Toolchain in XSDK

This document is intended to provide comprehensive guidance on how to use a custom GCC toolchain within Xilinx’s Software Development Kit (XSDK) for standalone software application development, targeting the Zynq®-7000 All Programmable SoC. Substituting the 'included/native' CodeSourcery Lite GCC compiler from Mentor and by example using the Linaro Bare Metal GCC toolchain - However, the principles are directly applicable to any alternative GCC release.

There are a variety of reasons this may be desired, by example through observation that the included compiler uses the 'Soft Floating Point' (softfp) ARM Procedure Call Standard (APCS): Whilst such brings flexibility to the compiler when sharing object code across platforms with different pipeline topologies it is not optimal for singular hardware platforms such as the Zynq-7000 family which ALL include 'hardware' Vector Floating Point (vfpv3) and NEON SIMD subsystems per CPU core. By explanation the “softfp” APCS specifically passes floating point values through the integer register file and stack when traversing functions, whilst the ‘hard’ APCS retains in and passes through the NEON floating point register file – this can lead to an improvement in performance for floating point intensive applications.

Custom Compilers

Numerous commercially packaged GCC toolchains are available for purchase or such could be built from source with suitable guidance, experience and knowledge. However, here we focus on the offerings from Linaro. Linaro - is a not-for-profit engineering organization that works on free and open-source software such as the Linux kernel, the GNU Compiler Collection (GCC), graphics and multimedia interfaces for the ARM family of instruction sets and implementations thereof: thus a good source for an alternative compiler for the Zynq-7000 platform, especially as they support the "hard" float APCS. The following guidelines include use of this alternative APCS:

Root Directory Prebuilt Images Status

GCC 4.8 Release Windows Maintenance Mode

GCC 4.9 Release Windows Active Development

Once downloaded simply follow the corresponding installation instructions, ensuring any PATH adjustments are applied to ensure the executable can be invoked from the XSDK command console.

Note: At the time of writing this flow has solely been tested on Windows hosts.

XILINX INTERNAL

Xilinx SDK - Using the Substitute Compiler

Eclipse Plug-In: GCC Cross Compiler The eclipse plugins that create the Xilinx aware persona of XSDK were developed with the Xilinx distributed CodeSourcery Lite compiler in mind - thus knowing the default options used by Mentor and similarly where the appropriate include libraries reside. HOWEVER, these obviously don't apply when using a custom compiler. Therefore to use other compilers you need to avoid this implicit association, this necessitates the selection of an alternative tool chain - as detailed below. Eclipse.org offer a generic solution for the use of GCC compilers, such is available as a plug-in, namely: "C/C++ GCC Cross Compiler Support". Which is available @ http://download.eclipse.org/tools/cdt/releases/kepler

To install, follow the standard plug-in installation process. Accessed through: Help -> Install New Software

XSDK Workspace - Customisation Create an XSDK Workspace - Import a Hardware Platform, derive a Bare-Metal BSP and create an Application project exactly as you would for the natively compiled software flow. In Summary, once created you need to do the following

Board Support Package Changes Substitute the toolchain and add build switches

Remove default build switches for Standalone sources

Software Application Changes Substitute the toolchain

Set appropriate build switches

Modify C Run-Time (CRT) Configuration

Define Build libraries

Extract Build image Size Information Automatically

XILINX INTERNAL

Now for the details.

Board Support Package Changes Open "Board Support Package Settings" and modify to the following as shown.

archiver arm-none-eabi-ar

compiler arm-none-eabi-gcc

extra_compiler_flags -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles

The default Makefile for the Standalone source within the BSP sets compiler switches which MAY not be required or worse still conflict with those you wish to use with the custom compiler, thus its necessary to conditionally comment them out. Additionally there is a mistake in the compiler invoked so a second change is required.

File location: <Workspace Location>\<BSP Project Name>\ps7_cortexa9_?\libsrc\standalone_v5_0\src

The required changes are captured below - the left visual is the original Makefile and needs to be modified to match that on the right. For ease of use we propose to modify the installation @ C:\Xilinx\SDK\2015.1\data\embeddedsw\lib\bsp\standalone_v5_0\src\cortexa9\gcc IF you plan to use this flow regularly. (Xilinx shall publish the official change in 2015.2/3)

Now you should be able to Build the BSP project to success using the selected toolchain.

XILINX INTERNAL

Software Application Changes

Cross Compiler Selection Modify the "Build Settings" for your Application Project as follows Change the toolchain from "Xilinx ARM GNU Toolchain" to "Cross GCC", if such is not listed check the plugin installation covered earlier.

Now define where the substitute toolchain was installed and its prefix (default shown below for Linaro)

XILINX INTERNAL

Apply Build Switches

Define a NEW Build Variables

Xlnx_BuildOptions -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard

Next, append the appropriate build options as Compiler, Linker and Assembler flags. Those detailed would be the minimum required.

COMPILERFor the Compiler, add the following under ‘Miscellaneous – Other flags’

${Xlnx_BuildOptions}

XILINX INTERNAL

LINKERThree modification areas are required for the linker, namely: Build Flags, C- RunTime association and library definition. These changes are detailed in the following three subsections.

Build Flags

In addition to “Xlnx_BuildOptions” the following switches are also required:

-Wl,--build-id=none -Wl,-T -Wl,../src/lscript.ld -Wl,--start-group,-lxil,-lgcc,-lc,--end-group

In summary these remove the build.id tag which is a “default” in many GCC toolchain builds and overrides any default linker script by pointing to that at location “../src/lscript.ld” (relative to the project being built).

The library archive grouping (start-group/end-group) is required because of function/symbol overriding in the Xilinx code – thus enabling recursive searching/resolution.

Adapt C-RunTime Start files As mentioned the native compiler was built with a customised CRT file configuration, this needs to be recreated explicitly for any generic substitute compiler by specifically excluding the ‘included/default’ crt0.o file. In brief overview, the “C RunTime” library fundamentally comprises five files, namely;

XILINX INTERNAL

Filename Descriptioncrt0.o(xil-crt0.S)

This object is expected to contain the _start symbol which takes care of bootstrapping the initial execution of the program. What exactly that entails is highly libc dependent and as such, the object is provided by the C library and cannot be mixed with other ones. On uClibc/glibc systems, this object initializes very early ABI requirements (like the stack or frame pointer), setting up the argc/argv/env values, and then passing pointers to the init/fini/main funcs to the internal libc main which in turn does more general bootstrapping before finally calling the real main function.

crti.o Defines the function prologs for the .init and .fini sections (with the _init and _fini symbols respectively). Which in turn define constructor/destructor .init_array/.fini_array sections and DT_INIT_ARRAY/DT_FINI_ARRAY ELF tags.

crtbegin.o GCC uses this to find the start of the constructors.crtend.o GCC uses this to find the start of the destructors.crtn.o Defines the function epilogs for the .init/.fini sections. See crti.o.

For custom GCC toolchains the crt0.o needs to be replaced with Xilinx’s customised version, namely xil-crt0.S : part of the processors standalone library and which is archived into libxil.a as part of the BSP build process:

Such is achieved by creating a custom build spec and passing to gcc on invocation using the switch

-specs=Xilinx.spec

This contrasts with the default for many generic GCC toolchains which would be as shown here.

You can find your toolchains default startfile spec using the command

arm-none-eabi-gcc -dumpspecs | grep -A1 *startfile:

For convenience this will be created dynamically using the eclipse pre-build feature, specifics detailed shortly.

Combined, the build flags and start file overrides should be set as “Miscellaneous -> Linker flags” as shown.

${Xlnx_BuildOptions} -specs=Xilinx.spec -Wl,--build-id=none -Wl,-T -Wl,../src/lscript.ld -Wl,--start-group,-lxil,-lgcc,-lc,--end-group

Define Build libraries Add libraries as (might not need gcc and c)

XILINX INTERNAL

ASSEMBLER Now add the build options as: “General -> Assembler flags”

${Xlnx_BuildOptions}

XILINX INTERNAL

Miscellaneous / Extract Build Image size and Create Build spec

To dynamically create the linker build spec detailed earlier add the following Pre-Build Step

(echo *startfile: & echo crti%%O%%s crtbegin%%O%%s) > Xilinx.spec To extract and display the size of the compiled program add the follow Post Build Step

arm-none-eabi-size ${BuildArtifactFileName}

XILINX INTERNAL

Conclusion With the above changes applied the user should be able to successfully build, debug and run compiled code using the selected third party compiler on the All Programmable Zynq -7000 SoC platform.

Revision History

Version Date Author Description0.1 5th May 2015 Simon George

EMEA&I - Tech SalesDraft Release

0.2 10/5/15 Simon GeorgeEMEA&I - Tech Sales

Adapted to focus on alternative GCC toolchains, not just Linaro. Focused on “Cross GCC”

0.3 11/05/15 Kester AernoudtEMEA&I – Tech Sales

Corrected PATH settings + simplified and streamlined build flags

0.4 12/5/15 Simon GeorgeEMEA&I - Tech Sales

Restructured based on Kester and Aniket’s feedback and elaborated on CRT section/details.

0.5 12/5/15 ….. Migrated to use gcc spec file to adapt CRT configuration, thus avoiding need to remove everything and explicitly add majority back.

XILINX INTERNAL

Error Avoidance Due to a problem with the discovery options ‘default’ for the GCC Cross Compiler plugin a workspace configuration option needs to be changed. Select Window -> Preferences to access the configuration page

Select Display “Discovery Options” page

Then disable “Automate discovery of paths and symbols”

XILINX INTERNAL

XILINX INTERNAL