Introduction to development environment (BELK/BXELK)

Info Box Applies to Bora Applies to BORA Xpress

History

Version	Date	BELK version	Notes
1.0.0	November 2015	3.0.0	First release

Overview

The following figure shows the developing environment for an Embedded Linux system based on BORA or BORAX: it is composed of a host machine and a target machine.

BORA/BORAX development environment

In a typical environment, the host is used by the developer to (cross-)compile the code that is to run on the target. In our case the target is a SOM, while the host is assumed to be a PC running the Linux operating system, either in a physical installation or as a virtual machine. The bootloader running on the target can download the Linux kernel image through the network (TFTP), as well as the u-boot binary images (useful when an update of the bootloader is required). Moreover, the Linux kernel running on the target is able to mount the root file system from different physical media, for example from a directory exported via Network File System (NFS) by the host. This strategy (kernel image and RFS retrieved from the network) saves time during the development phase, since no flash reprogramming or removable storage (SD, usb pen drives, external disks) is required to test new versions or updates of the software components. In contrast with a typical embedded system, BORA/BORAX adds some complexity, due to the nature of the Zynq processor, which provides both a CPU core (PS, processing system) and a integrated FPGA (PL, programmable logic). This means that additional tools are required to manage this complexity. In particular, the Vivado® Design Suite and the Xilinx Software Development Kit are required for the hardware level configuration and for building the first stage boot loader (FSBL).

Software components

Xilinx Zynq-7000 development tools

Vivado® Design Suite

Xilinx provides the Vivado® Design Suite, a SoC-strength, IP-centric and system-centric, next generation comprehensive development environment for All Programmable SoCs. The Vivado® Design Suite is used to configure the PS for embedded processor hardware system development. Specification of the microprocessor, memory parameters, boot peripherals, MIO settings and the interconnection of these components, along with their respective detailed configuration, takes place in Vivado IP Integrator.

Xilinx Software Development Kit

The Software Development Kit (SDK) is the Xilinx Integrated Design Environment for creating embedded applications on Zynq™-7000 All Programmable SoCs. SDK is the first application IDE to deliver true homogeneous and heterogeneous multi-processor design and debug, it is optionally included with the Vivado Design Suite or ISE Design Suite, or available as a separate free download for application developers. It is based on Eclipse and CDT and it directly interfaces to the Vivado embedded hardware design environment. The SDK offers support for complete software design and debug flows including multi-processor and hardware/software debug capabilities, integrating editor, compilers, build tools, flash memory management, JTAG/GDB debug, custom libraries and device drivers.

Zynq application development flow

The following diagram describes the development flow for Zynq-based Linux applications:

BELK development flow

Toolchain

With the term toolchain we refer to the set of programs that allow the building of a generic application. For applications built to run on the same platform as the tool chain, we use a native toolchain. On the contrary, for applications built to run on a target architecture different from the host architecture, we use a cross-toolchain. In this case all the tools involved in this process are lead by the “cross-” prefix. So we talk about cross-compiler, cross-toolchain and so on. The cross-toolchain used to build U-Boot, the Linux kernel and the applications is the GNU toolchain for the ARM architecture built for x86 hosts. In other words, the toolchain runs on x86 machines but generates binaries for ARM processors. As for all the software compliant to the GPL license, it is released in source code. Thus the first thing to do to set up the developing environment should be building the cross-toolchain. This is not a trivial task, it takes a lot of time and hard disk space. To avoid this tedious task, we suggest using a pre-built toolchain as explained in the following sections.

First stage bootloader (FSBL)

The first stage bootloader is loaded by the internal bootrom during the boot process. FSBL is run to set up the PS and load the second stage bootloader (U-Boot). The FSBL must be created using the Xilinx development tools and must be stored into the boot memory.

Second stage bootloader: U-Boot

U-Boot is a very powerful boot loader and it became the "de facto" standard on non-x86 embedded platforms. The main tasks performed by U-Boot are:

• hardware initialization
• starting a shell on the serial port allowing the user to interact with the system through the provided commands
• automatic execution of the boot script (if any)

After system power-up, U-Boot prints some information about itself and about the system it is running on. Once the bootstrap sequence is completed, the prompt is printed and U-Boot is ready to accept user's commands. U-Boot manages an environment space where several variables can be stored. These variables are extremely useful to permanently save system settings (such as ethernet MAC address) and to automate boot procedures. This environment is redundantly stored in two physical sectors of boot flash memory; the default variables set is hard-coded in the source code itself. User can modify these variables and add new ones in order to create his/her own custom set of configurations. The commands used to do that are setenv and saveenv. This process allows the user to easily set up the required configuration. Once U-Boot prompt is available, it is possible to print the whole environment by issuing the command printenv. For further information on the use of U-Boot, please refer to http://www.denx.de/wiki/view/DULG/UBoot.

Kernel

Linux kernel for Zynq processors is maintained primarily by Xilinx, that constantly works in close cooperation with Linux community in order to push all the released drivers into mainstream kernel. Kernels released within BELK derive directly from Xilinx Zynq kernels, with patches added by DAVE Embedded Systems to support the BORA and BORAX hardware platforms.

Target root file system

The Linux kernel running on the target needs to mount a root file system. Building a root file system from scratch is definitively a complex task because several well known directories must be created and populated with a lot of files that must follow some standard rules. Again we will use pre-packaged root file systems that make this task much easier. Please note that using a pre-packaged root file system can lead to conflicts with the application binaries obtained using the pre-built cross-toolchain: as a general rule, dynamically linking an application against libraries built with a different toolchain can cause malfunctioning.