PhyCORE-Vybrid Linux Quickstart-PD13.0.0alpha

From PHYTEC Wiki

1 About this Quickstart

This document describes how to install and work with the Linux Board Support Package (BSP) for the phyCORE-Vybrid platform. This BSP provides a fundamental software platform for development, deployment and execution on the phyCORE-Vybrid.

The Quickstart contains instructions for:

• Host Setup
• Board Setup
• Building a BSP (Platform, Kernel, Root Filesystem)

1.1 phyCORE-Vybrid Support

Use the PHYTEC Support Forum to connect with PHYTEC for phyCORE-Vybrid product announcements and to ask questions, share knowledge, and help solve problems. Sign in at http://forum.phytec.com, for additional information on becoming a member or general forum use see the PHYTEC Support Forum Guide.

It is highly recommended to subscribe to phyCORE-Vybrid announcements for notifications of BSP releases/patches, hardware/software known issues with applicable workarounds, and other important product related information. Announcement subscription is easy to setup and manage:

1. Sign into the PHYTEC Support Forum, http://forum.phytec.com
2. Go to the <user> tab from the navigation menu
3. Select E-mail Subscriptions from the preference list on the left
   
4. Check the box next to Subscribe to category Vybrid Announcements in the E-mail Subscription Settings window
   
5. Click Save to apply selections

2 Host Setup

The phyCORE-Vybrid (PCM-052) has been developed and tested with Ubuntu 10.04 LTS Lucid Lynx [Installation Guide]. Although it is possible to use a different OS, some setup information will contain OS-specific commands and paths for settings.

Update repositories and upgrade installed packages:

sudo apt-get update
sudo apt-get upgrade

2.1 Server Setup

Support for installing and setting up TFTP, NFS, and Samba server settings to enable communication between multiple systems and the target.

2.1.1 TFTP

TFTP allows files to be downloaded from one machine to another. With most embedded Linux devices, TFTP is an efficient way to boot the kernel during development so that the user does not have to flash a new kernel every time it is modified. It is also helpful when updating images in flash from U-Boot.

First, start by installing the TFTP server.

sudo apt-get install tftpd-hpa

Next, files can be accessed from another machine on the same network by simply using the IP address of the host. Specify a folder where the files will reside on the host by replacing the folder path for TFTP_DIRECTORY with whatever folder you wish to use as your TFTP file storage location, or leave the folder as the default.

sudo gedit /etc/default/tftpd-hpa

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

If you made any changes to the settings of the TFTP server, you need to restart it for them to take effect.

sudo restart tftpd-hpa

Lastly, if you would like to grant every user on the system permission to place files in the TFTP directory, use the following command, replacing <TFTP_DIRECTORY> with your chosen location.

sudo chmod ugo+rwx <TFTP_DIRECTORY>

2.1.2 NFS

A network file-system (NFS) server gives other systems the ability to mount a file-system stored on the host and exported over the network. In embedded development, this is essential for quickly testing applications and evaluating different file-system setups.

To begin the installation process use the following command:

sudo apt-get install nfs-kernel-server

Exported filesystems are designated in the "/etc/exports" file and allow you to choose both the directory to be exported and many settings for accessing the exports. Below is an example for exporting a folder called "nfs_export-ex" located in a user's home directory.

sudo gedit /etc/exports

# /etc/exports

/home/<user>/nfs_export-ex  *(rw,sync,no_root_squash,no_subtree_check)

The options (rw, sync, no_root_squash, no_subtree_check) for this folder are essential in setting up the NFS export correctly. For more information on additional options, refer to the man page for 'exports'.

• rw enables

read and write access when the directory is mounted

• sync

tells the file-system to handle local access calls before remote access

• no_root_squash

allows root access when mounting the file-system

• no_subtree_check

reduces the number of checks the server must make to ensure that an exported sub-directory is within an exported tree and also enables access to root files in conjunction with no_root_squash

After modifying this file, in order to mount the directories as an NFS, you must force the NFS server to export all of the directories listed in "/etc/exports".

sudo /usr/sbin/exportfs -va

2.1.3 Samba

Samba servers are an excellent way to access a Linux file-system on a Windows machine via a network connection. Using a Samba server, it is quick and easy to transfer files between systems. To install a Samba server, use the following command:

sudo apt-get install samba

Before the Samba share can be mounted on another machine it's necessary to modify the configuration file to allow write access and access to home directories. Start by editing the "/etc/samba/smb.conf" file.

sudo gedit /etc/samba/smb.conf

Inside this file there are four specific things that need to be uncommented (remove the ';' at the beginning of the line) to enable the sharing of home folders and write access. Below is the section that must be modified:

#======================= Share Definitions =======================

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares. This will share each
# user's home directory as \\server\username
;[homes]
;   comment = Home Directories
;   browseable = yes

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
;   read only = no

The outcomes after the changes are made follow:

#======================= Share Definitions =======================

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares. This will share each
# user's home directory as \\server\username
[homes]
   comment = Home Directories
   browseable = yes

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
   read only = no

NOTE: It might also be necessary to change the "workgroup = " line to match the workgroup for your machine.

To apply the changes, the next step is to restart all Samba-related processes.

sudo restart smbd
sudo restart nmbd

Lastly, each user needs to have a password enabled to be able to use the Samba server. There are no rules for this password. The simplest method for choosing this password is to make it the same as the UNIX user's password, but it is not a requirement. After typing in the command below, you will be prompted to enter the password for the specified user.

sudo smbpasswd -a <user>

As mentioned in the configuration file, the samba share can be connected by accessing "\\<host machine ip>\\<user>" by either mounting a network share or using Windows explorer to navigate to it.

2.2 LinuxLink Tools Setup

LinuxLink, created by Timesys, provides web and desktop factory tools for embedded Linux development to manage toolchains, build environments, and software sources. After registering your kit, access to the BSP as well as to additional resources for Vybrid development will be provided.

2.2.1 LinuxLink Registration

Create a Timesys LinuxLink account for the PHYTEC Vybrid processor:

1. Go to https://linuxlink.timesys.com/register/phytec/
2. Complete all required sections on the registration form
3. Enter the serial number on the SOM for the Vybrid Board Serial Number
   The serial number will be a 12 digit MAC ID printed on a sticker on the SOM. Enter the 12 hexadecimal digits with no separation.

   Example: MAC ID = 01:23:45:67:89:AB, Enter 0123456789AB
   

   
   

4. Click the Get Access Now! button to submit the registration form

Once the registration form is submitted, expect a welcome email containing login information including user name and password as well as helpful links to get started.

After logging into LinuxLink [Here], the custom personal dashboard will be brought up which acts as a hub of information for embedded Linux development including relevant software, tools, educational documentation, and links to custom builds.

2.2.2 Desktop Factory Build System

The Timesys Factory Build System allows full access to the target preconfigured build system for customization and development on a host Desktop. If you plan to modify the phyCORE-Vybrid Linux kernel, use the following instructions to download and install the Desktop Factory Build System.

LinuxLink pre-built starting points for the PHYTEC phyCORE-Vybrid include a download for a preconfigured Desktop Factory. Download the installer from the Build Output page under Build the SDK on your host -> Download the Desktop Factory Installer -> pcm052-factory-installer.sh.

Note: See the Linux BSP release notes page for a link to the most recent pre-built Build Output page or view all in LinuxLink from the Download BSP/SDK tab under Pre Built Starting Points -> PHYTEC phyCORE Vybrid Development Kit.

chmod +x pcm052-factory-installer.sh
./pcm052-factory-installer.sh

After successfully installing the Desktop Factory, the tools will be available from the /timesys/pcm052/Factory-<version> directory.

Note: Throughout the Quickstart any reference to <factory_install_dir> refers to /timesys/pcm052/Factory-<version>.

Alternatively, a manual install of the Factory Build Engine can be performed. In the case of an upgrade, it is recommended to back up the existing factory directory and then extract the new release, which allows preservation of the unchanged platform definition. Download and extract factory.tar.gz from View All Files on the Build Output page.

tar –zxf factory.tar.gz
cd factory

The Factory Build system requires distribution specific packages on the host that should match the specifications summarized by Timesys [Here].

If using Ubuntu, complete the following:

sudo  apt-get install build-essential libc6-dev libtool sharutils libncurses5-dev libgmp3-dev libmpfr-dev gawk gettext bison flex gperf indent texinfo libgtk2.0-dev libgtk2.0-bin libsdl1.2-dev swig python-dev texlive-latex3 texlive-extra-utils binutils-dev automake guile-1.8 icon-naming-utils libdbus-glib-1-dev wget gtk-doc-tools libxml-parser-perl zip unzip ecj fastjar x11-xkb-utils libglade2-dev libperl-dev python-libxml2 libexpat1-dev gconf2 groff libc6-dev-amd64

sudo dpkg-reconfigure dash
# Respond “No” to the prompt asking “Install dash as /bin/sh?”

# For 64-bit host machines only
sudo apt-get install ia32-libs libc6-dev-i386

To check that the host system has all required software run a checksystem within the factory directory, and follow the instructions for resolving missing requirements if applicable:

make checksystem

3 Board Setup-phyCORE-Vybrid

The phyCORE-Vybrid PD13.0.0alpha supports booting from a SD/MMC Card. After the device is out of the box and setup, the SD/MMC Card containing U-Boot, Linux kernel image, and root filesystem can be used to boot the device.

3.1 Connections

Power and host-PC connections must be made to the target device. The hardware manual, included with the Rapid Development Kit, may be referred to for specific connection information.

3.1.1 Power

The primary input power for the phyCORE-Vybrid Carrier Board comes from the wall adapter jack, X2 (+5 V). Upon application of power, LED D3 (red) and D14 (green) should light up and initial serial data will be sent to the console. The Carrier Board provides options for a system reset through push button S2 (RST).

3.1.2 Serial

A serial connection is used as system communication for boot-up interaction throughout start-up and as a monitoring/debugging interface. This RS-232 connection is made between the Host and SCI_1, top connector of X10 on the phyCORE-Vybrid Carrier Board.

The following provides a summary of the serial settings required to allow console access over the serial port in a communications program on the host such as Minicom:

3.1.2.1 Minicom

Minicom is the recommended communications program on the host for serial communication to the device.

To install Minicom, execute the following in a terminal on the host:

/* if Minicom is not installed */
sudo apt-get install minicom

Start minicom from the terminal in the following way:

minicom -c on -s

Minicom will be executed and the main menu will be displayed in the terminal:

Navigate to "Serial port setup" in the Minicom main menu and modify line A - Serial Device : to read /dev/ttyS0 and line E - Bps/Par/Bits : to have a speed of 115200 and 8-N-1 (8N1) for the stop bits:

Note: The serial device is dependent on what COM port you are connected to on your system, so /dev/ttyS0 is merely an example.

Return to the main menu of minicom and select Save setup as dfl to make this the default setup anytime Minicom is loaded, meaning minicom -c on is all that needs to be done in the future for this machine to be able to communicate with the kit. Be sure that permissions allow writing to minirc.dfl by:

sudo chmod ugo+rwx /etc/minicom

3.1.3 Ethernet

The Ethernet connection is used for flashing, downloading, and debugging images and applications. Connect the cross-over Ethernet cable to the Ethernet connector on the target, X7, and appropriate network card on the host. LEDs on the RJ-45 connector verify the connection.

3.1.4 SD/MMC Card

The Carrier Board supports a slot at X9 for SD/MMC Cards which can be used as a booting device by applying the S5 dipswitch settings accordingly, described in Section 3.2.2.

3.2 BSP Image Format

Support is provided for loading the bootloader, kernel, and root filesystem to the target from the SD/MMC Card. Additionally, U-Boot can be configured to load and execute the kernel from the TFTP server and mount the root filesystem from the NFS server.

3.2.1 Original Images

If for any reason it is necessary to obtain the original example images, they are available from the PHYTEC FTP [Here] or located on LinuxLink [Here], see Section 2.2.1 for more information, by going to Download BSP/SDK -> Pre Built Starting Points -> PHYTEC phyCORE Vybrid Development Kit -> PD13.0.0alpha and on the Build Output page click View All Files.

3.2.2 SD Card

It is recommended to make a script to correctly create and format a phyCORE-Vybrid SD/MMC Card. The following is the contents of a personal script, vybrid_sd_card.sh, that uses the dd command in order to place u-boot.imx on the SD/MMC Card. Note that because this is a personal script, if executed, a user is at their own risk:

#!/bin/bash
if [ $# -ne 2 ]
then
  echo "$0 usage: designate the SD card block device to format (e.g /dev/sdb)
$0 usage: supply the location of u-boot.imx file to flash (e.g. ~/images/u-boot.imx)" 1>&2
  exit 1
elif [ ! "$1" = "/dev/sda" ] ; then
  unset LANG
  DRIVE=$1
  BOOTIMG=$2
  if [ -b "$DRIVE" ] ; then
    dd if=/dev/zero of=$DRIVE bs=1024 count=1024
    parted --script ${DRIVE} mklabel msdos
    dd if=$BOOTIMG of=$DRIVE seek=2 bs=512
    parted --script ${DRIVE} mkpart primary ext2 2 52
    parted --script ${DRIVE} mkpart primary fat32 53 100
    parted --script -- ${DRIVE} mkpart primary ext2 101 "-1"
    mkfs.ext2 ${DRIVE}1 -L boot
    mkfs.vfat ${DRIVE}2 -F 32 -n kernel
    mkfs.ext2 ${DRIVE}3 -L rootfs
  fi
fi

On an unmounted SD Card, run the script in the following way by specifying the two parameters for the device file and location of the bootloader, u-boot.imx:

sudo ./vybrid_sd_create.sh /dev/sd[a|b|c|d|e] <path to u-boot.imx>/u-boot.imx

Mount all partitions of the SD Card to copy uImage-3.0-ts-armv7l to the kernel partition and extract rootfs.tar.gz to the rootfs partition:

cp <path to uImage-3.0-ts-armv7l>/uImage-3.0-ts-armv7l /media/kernel
sudo tar -zxvf <path to rootfs.tar.gz -C /media/rootfs/
sync

Unmount each partition before removing the SD Card:

umount /media/boot /media/kernel /media/rootfs

3.2.3 TFTP Server

Images are available over the TFTP server, setup in Section 2.1.1.

The following files are present in a directory, such as /var/lib/tftpboot/PHYTEC/Vybrid/PD13.0.0alpha, on the server:

3.2.4 NFS Server

An entire root filesystem can be made accessible over the NFS Server, setup in Section 2.1.2.

To have the ability to mount the file system, root.tgz can be extracted to a NFS server directory such as /home/<user>/phyCORE-Vybrid/NFS:

sudo tar -zxf root.tgz -C /home/<user>/phyCORE-Vybrid/NFS/

3.3 Booting Configurations

The bootloader, one of the key software components included in the BSP, completes the required hardware initializations to download and run operating system images. The boot mode, selected from the S5 dipswitch on the Carrier Board, determines the location of the primary bootloader, u-boot.imx. In this release, SD Card is the only supported boot mode, therefore the S5 switch settings on the Carrier Board should match those corresponding to SD Card.

3.3.1 SD Card

To boot from SD Card, use the following switch settings:

S5-1 to S5-4 ON

S5-5 to S5-8 OFF

3.4 Working with U-Boot

The phyCORE-Vybrid uses the Universal Bootloader, U-Boot, as its bootloader, it can be customized with environment variables and scripts to support any boot constellation. The PD13.0.0alpha release supports the booting configurations of Linux kernel and file system located on the SD/MMC Card as well as Linux kernel on TFTP and root filesystem mounted from NFS.

After connecting the board to a terminal emulator, application of power will initiate booting the target. Approximately three seconds are allotted for the user to hit any key which will halt autoboot and enter U-Boot’s simple command line interface:

The U-Boot shell offers a set of commands; a full list along with their usage is available by the help command:

help

3.4.1 Environment Configuration

U-Boot can be configured through environment variables, which affect the behavior of the different commands.

The printenv command will display a list of all variables and their current value to the console:

printenv

If the U-Boot environment variables need to be restored for any reason, set them individually to their original value as referenced by the following:

baudrate=115200
bootargs_base=setenv bootargs rw mem=256M console=ttymxc1,115200n8 init=/sbin/init
bootargs_net=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfs_root},v3,tcp
bootargs_sd=setenv bootargs ${bootargs} root=/dev/mmcblk0p3 rootwait rootfstype=ext2
bootcmd=run bootcmd_sd
bootcmd_net=run bootargs_base bootargs_net; tftpboot ${loadaddr} ${tftploc}${bootfile};bootm
bootcmd_sd=run bootargs_base bootargs_sd; mmc rescan; fatload mmc 0:2 ${loadaddr} ${bootfile}; bootm ${loadaddr}
bootdelay=3
bootfile=uImage-3.0-ts-armv7l
eth1addr=00:e0:0c:bc:e5:61
ethact=FEC0
ethaddr=00:e0:0c:bc:e5:60
gatewayip=192.168.3.1
ipaddr=192.168.3.10
loadaddr=0x80010000
mem=260096k
netmask=255.255.255.0
nfs_root=/path/to/nfs/root
serverip=192.168.3.11
stderr=serial
stdin=serial
stdout=serial
tftploc=/path/to/tftp/directory

Save to apply changes made to environment variables:

saveenv

3.4.1.1 General Settings

U-Boot’s environment variables specific to remote settings must be configured to load the kernel over TFTP or mount the root filesystem from NFS. Set the IP address, Server IP, Gateway IP, and Netmask variables to match those of the networking parameters and development host settings:

set ipaddr ###.###.###.###
set serverip ###.###.###.###
set gatewayip ###.###.###.###
set netmask ###.###.###.###

Additionally, the environment variables corresponding to the file locations on each of the servers must be specified in U-Boot:

3.4.1.1.1 TFTP Path Location

For the TFTP server setup in Section 2.1.1 and with images present as described in Section 3.2.3, set the tftploc environment variable accordingly by referencing the following examples:

 setenv tftploc PHYTEC/Vybrid/PD13.0.0alpha 

 setenv tftploc 

3.4.1.1.2 NFS Path Location

For the NFS server setup in Section 2.1.2 and root filesystem available as described in Section 3.2.4, set the nfs_root environment variable to the path of the NFS server:

setenv nfs_root /home/<user>/phyCORE-Vybrid/NFS/ 

These remote settings can be applied by default by saving the environment:

saveenv

3.4.2 SD/MMC Boot Configuration

U-Boot can be configured to boot from SD/MMC Card. This boot configuration is customized by the ‘bootargs’ and ‘bootcmd’ environment variables. A predefined configuration and script is available by the environment variables bootargs_sd and bootcmd_sd, for further details on the default values see Section 3.4.1. Therefore, configuring SD/MMC Card booting in U-Boot can be done with a simple command:

setenv bootcmd 'run bootcmd_sd'

Save these changes to retain this boot configuration:

saveenv

3.4.2.1 Remote Booting

U-Boot can be configured to perform a net boot, which will load the Linux kernel from TFTP and mount the root filesystem from NFS. As a prerequisite, the remote settings described in Section 3.4.1.1 must be setup and the paths to the file locations on each of the servers must be specified, Sections 3.4.1.1.1 and 3.4.1.1.2, in U-Boot. This boot configuration is customized by the ‘bootargs’ and ‘bootcmd’ environment variables. A predefined configuration and script is available by the environment variables bootargs_net and bootcmd_net, for further details on the default values see Section 3.4.1. Therefore, configuring net booting in U-Boot can be done with a simple command:

setenv bootcmd 'run bootcmd_net'

Save these changes to retain the file location on the servers and boot configuration:

saveenv

3.4.3 Booting the Target

Assuming a valid kernel image and a target filesystem, images can be downloaded from either SD/MMC Card or remotely from U-Boot:

boot

The target enters Linux after the system successfully boots, hit enter to begin using the command prompt:

When powering off or restarting the device it is recommended to use the poweroff and reboot commands, respectfully to allow a complete close out of the filesystem and shut down for maintaining system integrity.

4 Building a BSP

4.1 Build with Web Factory

The BSP can be built from a workorder using the Timesys servers via the Web Factory. The workorder, see Section 2.2.2, can be customized in terms of platform configuration options and built.

4.1.1 Managing Configurations

A workorder process can be customized in terms of the Linux component versions, package selection, and root filesystem options. The PHYTEC pre-built starting point BUILD-OUTPUT.txt file Here, see Section 4.1.3.2, acts as a reference for a default configuration with a minimal set of packages to select to be run on the target application.

The Web Factory user interface provides simple navigation through sub categories available in the top menu for configuring the BSP/SDK.

The Kernel Configuration allows selection of a Linux kernel from the Timesys provided options. By clicking on the kernel version link more information will be displayed about the kernel including the version, revision, estimated build time, license, and device drivers enabled. Additionally, the kernel .config file is available for download for inspection of the options as configured in the Linux kernel.

The Toolchain Configuration menu provides options for toolchain selection. It is recommended to select glibc Recommended because it provides a complete set of toolchain components and versioning. If a different version of toolchain components such as glic, gcc, binutils, and gdb is preferred, the custom toolchain option can be selected. More information including the version, revision, license, and an estimated build time for a toolchain component is available by clicking the component link.

A table format that details the package names, version, license, and size information is available in the Packages Configuration menu. Browse through the Desktop, Development, Graphics, Multimedia, Networking, Runtimes, System, and Utilities categories or use the Smart Search feature to choose packages required for the target application. By clicking on the package, details including version, estimated build time, and license are provided. Additionally, some packages have modifiable build options which are accessed by liking the associated icon in the package listing. Checking the box next to the package name will select the package and automatically any package dependencies. Similarly, unchecking the box next to a package name will deselect the package and automatically any package dependencies. View the left panel for a summary of the both all the packages selected and dependencies as well as the total packages size.

The Build Output Options menu allows the user to tailor the application and root filesystem output by providing options to select the specific file formats. Additionally, optimizations for along with the choice to include the native toolchain and kernel in the root filesystem are provided.

The Advice menu or Timesys Recommendations can be used to detect any build and run or logic dependencies based on Timesys Recommendations. A user can Accept which will apply the recommendations or continue with the selections made with risk to having conflicts, incompatibilities, and deficiencies.

Use the Summary menu to review the workorder and use the Edit buttons as quick links to modify configurations. Based on the custom workorder, an estimated build time is generated and can be viewed at the bottom of the summary. It is important to note that this estimate does not take into account the number of builds currently being processed on the Timesys servers, therefore, a build will generally take longer than the estimated time.

After completing modifications to the workorder, click on the Save button at the bottom of the page to apply changes.

4.1.2 Building Images

A build is initiated on the Summary page of a workorder. To open the Summary from LinuxLink click Build BSP/SDK, select the project and click on the name of the workorder that is to be built. Alternatively, from an open workorder click Summary in the top menu. This menu provides a review of the workorder configuration and an estimated build time, see Section 4.1.2 for more information. Click the Build button to start the build.

The workorder will be queued for a short amount of time before being built on the Timesys servers. The status of the build can be viewed on the personal LinuxLink dashboard or the Download BSP/SDK page. Additionally, when the build is complete, these pages will display if the build was successful and provide a link to the download. Similarly, a user will receive notification via email when a build is complete with a link to the download, see Section 4.1.3 for more information.

4.1.3 Downloading Images

After notification of a successful build, links to the download for the BSP are provided via the Build Download Page or the Build Output Page.

4.1.3.1 Download Page

The BSP Download page can be opened after a successful build via the link provided by email notification or in LinuxLink from the personal dashboard or Download BSP/SDK page.

The BSP Download page highlights relevant files from the Build output along with instructions to support different user intentions including setting up application development on the host, building the SDK on the host, and booting the board.

Click the View All Files button at the bottom of the page for the complete Build output.

4.1.3.2 Build Output Page

The Build Output Page is a resource for all information relating to the build of a BSP/SDK. The page includes a build summary; package sources; individual binary files for the kernel, toolchain, bootloader, and root filesystem; and the desktop factory download.

The build summary, BUILD-SUMMARY.txt, provides a list of configuration and build instructions associated with the platform including the system specifications, kernel and bootloader versions, toolchain components, host build tools, package selections, and root filesystem options. By inspecting the pre-built starting points, phyCORE-Vybrid PD13.0.0alpha, build summary the default/suggested configuration settings can be determined.

4.2 Build with Desktop Services

The BSP can be built from using the Desktop Factory, setup in Section 2.2.3.

4.2.1 Board Files

All source code is located in the /build-armv7l-timesys-linux-gnueabi/ directory. To integrate and modify features on the system for both driver development and general settings or Carrier Board design, it is necessary to know about the board files summarized by the following:

4.2.2 Make Rules

The Desktop Factory uses the kernel configuration (KConfig) system to include the packages, kernel, and toolchain versions and configurations. Make rules, performed on configuration symbols defined in KConfig, are defined to execute commands for the standard configuration, build, and install processes for the kernel, packages, and toolchain components. Therefore, target commands can be used with make directly on the command line.

For more information see the Make documentation provided by Timesys or use the help make target to view a list describing the common target commands:

make help

Timesys Factory (Released: 20130107)
Host targets:
* checksystem            - Check that the system meets build requirements
* checkupdates           - Check for updates from Timesys
  update                 - Update work order with new defaults from Timesys
  menuupdate             - Menu based update tool
  update-noprompt        - Update work order without prompting for each change
  checktool-oprofile, checktool-ltp, 
  checktool-mpatrol, checktool-gdb
                         - Check current configuration for compatibility with
                           tool (oprofile, ltp, etc)
  advice                 - Upload current configuration to the TimeSys server
                           and receive advice about selections

  timestorm-register-toolchain - Register the toolchain with Timestorm

Cleaning targets:
  clean                  - Purge build directories
  download-clean         - Purge source files
  distclean              - Purge build directories, source files and .config
  rfs-distclean          - Reset RFS working directory
  packages-distclean     - Reset package state for selected applications
  software-distclean     - Distclean all selected applications
  reset-toolchain        - Resets the build environment to a pristine toolchain

Per application targets:
  [application]-clean        - Purge build directory
  [application]-distclean    - Purge build and source directories
  [application]-fetch        - Fetch source, patches, and files
  [application]-unpack       - Unpack into working directory
  [application]-patch        - Apply patches to working directory
  [application]-configure    - Configure
  [application]-restage      - reset build status to unbuilt
  [application]-reconfigure  - reset build status to unconfigured
  [application]-build        - Build
  [application]-package      - Generate package
  [application]-rfs-install  - Install to RFS working directory
  [application]-host-install - Install to Host Toolchain
  [application]-show         - display application information
  [application]-select       - add application to current configuration

Kernel Configuration:
  kernel-menuconfig          - call kernel menuconfig (or other *config)

Configuring targets:
  config         - Update configuration file using command-line utility
  menuconfig     - Update configuration file using ncurses utility
  oldconfig      - Update configuration file using current .config as a base
* showpackages   - Show summary of packages selected in current .config
* showoutput     - Show summary of the build output

Fetching targets:
* sources        	- Download all sources and patches required to build selections

Building targets:
* packages       	- Generate packages for all selections
* toolchain      	- Build and package the cross toolchain
* rfs            	- Compile all selections and kernel and create RFS output
* rfs-images    	- Generate RFS images (Called by RFS)
* installer      	- Generate the installer for the custom target SDK

Execute "make" to build all targets marked with [*]

4.2.3 Managing Configurations

A set of make rules are defined specifically for configuring targets by updating the configuration file. From Config.in files throughout the Desktop Factory, KConfig keys and their values are listed together in a menu to allow straightforward user configuration and customization of the platform. Use the menuconfig make target on the command line in the BSP directory, ex. timesys/pcm052/factory-20130107/, to modify the settings for the platform:

make menuconfig

This menu can be used to customize and configure the platform:

When making modifications, it is recommended to begin with the Target Configuration because of the dependencies other platform configuration have based on the chosen target. The options available in this menu range from architecture and CPU choice to root filesystem image types and target build specifications.

Toolchain specific configuration is provided by the Toolchain Configuration menu including customization for each toolchain component and a selection to either build a toolchain, optionally a native toolchain for the target as well, or fetch an existing pre-built toolchain. To customize the target software that can be included in the platform use the Target Software menu which provides sub menus to the Kernel, Bootloader, and Software Packages. Refer to Configuration System Overview for additional documentation provided by Timesys.

To adjust the drivers and support included in a Linux kernel build, invoke the Linux kernel menuconfig interface:

make kernel-menuconfig

When using menuconfig, the location of a name or token can be searched by using the “/” key:

4.2.4 Building Images

The build system is invoked by executing make targets from the command line in the BSP directory, ex. timesys/pcm052/factory-20130107/. The files generated by a build are located in the BSP project directory under build_armv7l-timesys-linux-gnueabi/images. With no targets specified, executing make will build the entire BSP through implementing a set of core Factory targets:

make

Note: See Section 4.2.2 or execute make help, the list of included make targets when executing make will be designated by a ‘*’ mark.

The build time will vary depending on the package selection and Host performance. After the initial build when modifications to the same BSP are made, a full build is not required and taking advantage of optimized build options specific to modifications will reduce the build time. For example, from a built BSP, if modifications were made to the bootloader, u-boot could be rebuilt without having to invoke an entire rebuild on the system by performing target application specific commands to reset its build status to unbuilt, then simply build and install the application:

make u-boot-restage 
make u-boot-build
make u-boot-host-install

Alternatively, the make command can be run specifically on the u-boot application for the changes to take affect:

make u-boot-restage 
make u-boot

Each target application selection has a series of make targets for itself, as can be viewed by per application targets in make help. Alternatively, to view the available make targets for a given application, enter the name, such as u-boot in the command prompt of the BSP directory, ex. timesys/pcm052/factory-20130107/, and hit the TAB key:

make u-boot

u-boot			u-boot-check		u-boot-configure
u-boot-fetch		u-boot-package		u-boot-reconfigure
u-boot-rfs-install	u-boot-build         	u-boot-clean
u-boot-distclean	u-boot-host-install	u-boot-patch
u-boot-restage		u-boot-unpack