BORA SOM/BELK-L/Development/Introduction to the development environment

Introduction to development environment

The following pictures show a simplified scheme of the the development environment for an Embedded Linux system based on BORA or BORAX. The two main blocks are a host machine and a target machine.

BORA/BORAX development environment (BELK 4.0.0 or newer, BXELK 2.0.0 or newer)

BORA/BORAX development environment (BELK version up to 3.0.2, BXELK version up to 1.0.1)

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 (for recent kits, this is the MVM).

The bootloader running on the target can download the Linux kernel image through the network (TFTP), as well as the bootloader 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 (aka PS, Processing System) and an integrated FPGA (aka PL, Programmable Logic). This means that additional tools are required to manage this complexity.

In particular

• The Vivado® Design Suite is required for the generation of the PL bitstream
• The Xilinx Software Development Kit (SDK) is required for building the first stage boot loader (FSBL) (BELK version up to 3.0.2, BXELK version up to 1.0.1)

Starting from BELK 4.0.0 and BXELK 2.0.0 U-boot SPL bootloader is used instead of FSBL, therefore Xilinx SDK is no longer required.

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.

For any version of BELK/BXELK, Vivado is required to generate the PL bitstream.

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 multiprocessor and hardware/software debug capabilities, integrating editor, compilers, build tools, flash memory management, JTAG/GDB debug, custom libraries and device drivers.

As described here, in the context of BELK/BXELK, the SDK is no longer required for the version of BELK starting from 4.0.0 and for the version of BXELK starting from 2.0.0.

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

Two different first-stage bootloaders are used, depending on the version of the kit.

U-Boot SPL (BELK 4.0.0 or newer, BXELK 2.0.0 or newer)

These kits use U-Boot SPL as first-stage bootloader. It is loaded by the internal bootrom during the boot process. U-Boot SPL is run to set up the PS and load the second stage bootloader (U-Boot).

U-Boot SPL is built with the same tool chain used to build the the other software modules, such as the Linux kernel and the applications.

Please note that U-Boot SPL is based on one file (ps7_init.c) that is generated by Vivado. In turn, this file contains some initialization parameters that are set according to Zynq configuration. The U-Boot sources provided by the BELK/BXELK include such file. Unless you need to modify the initial Zynq configuration, you don't need to generate a new ps7_init.c file. Therefore, from the standpoint of the software running on PS, Vivado is genrally not required.

FSBL (BELK version up to 3.0.2, BXELK version up to 1.0.1)

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 the mainline 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 makes 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.