Changes

Jump to: navigation, search

Introduction to development environment (BELK/BXELK)

661 bytes added, 10:08, 14 July 2017
no edit summary
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0]]
|First release
|-
|2.0.0
|July 2017
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0 / 4.0.0]]
|Updates for BELK-4.0.0 / BXELK-2.0.0
|-
|}
==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.
[[File:Belk-development-flow.png|thumb|center|600px|BORA/BORAX development environment(BELK <= 3.0.2 and BXELK <= 1.0.1)]][[File:BELK-4.0.0 belk-development-flow.png|thumb|center|600px|BORA/BORAX development environment (BELK 4.0.0 or newer and BXELK 2.0.0 or newer)]]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). Starting from BELK-4.0.0 and BXELK-2.0.0 U-boot SPL bootloader is used instead of FSBL allowing SW only development flow avoiding the use of Vivado® Design Suite.
==Software components==
===Xilinx Zynq-7000 development tools===
====Zynq application development flow====
The following diagram describes the development flow for Zynq-based Linux applications:
[[File:Belk-vivado-sdk-development-flow.png|thumb|center|600px|BELK development flow(BELK <= 3.0.2 and BXELK <= 1.0.1)]] [[File:BELK-4.0.0 belk-vivado-sdk-development-flow.png|thumb|center|600px|BELK development flow (BELK 4.0.0 or newer and BXELK 2.0.0 or newer)]]
===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.
136
edits

Navigation menu