This document describes how to install and work with the Linux Board Support Package (BSP) for the phyFLEX-i.MX6 platform. This BSP provides a fundamental software platform for development, deployment and execution on the phyFLEX-i.MX6.
The Quickstart contains instructions for:
To successfully build a customized Linux distribution using PTXdist, your host machine must be running a modern GNU/Linux Operating System either natively or via a virtual machine. This Quickstart was authored and tested with Ubuntu 12.04 LTS 32-bit Virtual Machine on a Windows 7 Host PC.
This section is designed to get the board up-and-running with the demo images included in the kit.
Use the following as a reference for the connector interfaces on the phyFLEX-i.MX6 that will be used in this Quickstart
The section was designed to show you how to boot the phyFLEX-i.MX6 with the pre-flashed demo images.
1. If you ordered a PHYTEC Display such as the LCD-018-070KAP, plug this into the LCD power and data connectors at X65. Alternatively for a display option you can connect a DVI cable from a monitor to the connector X40 on the carrier board. Additional setup is required to use DVI as the main display, see Display Settings section of the Quickstart for additional instructions.
2. Connect the kit supplied serial cable from a free serial port on your host PC to the DB9 connector X51 on the carrier board. This is the UART0 communication channel with the i.MX6 at RS-232 levels.
3. Connect the kit supplied Ethernet cable from the Ethernet connector X28 on the carrier board to your network hub, router, or switch. If you do not have an Ethernet connection you can postpone this step, Linux will boot without the need for Ethernet connectivity but having the connection will significantly reduce your boot time.
4. Start your favorite terminal software (such as Minicom or TeraTerm) on your host PC and configure it for 115200 baud, 8 data bits, no parity, and 1 stop bit (8n1) with no handshake.
5. Plug the kit supplied 12 V power adapter into the power connector X12 on the carrier board. You will instantly see power LEDs VCC12IN, VCC12, VCC5_X, VCC5, and VCC3V3 on the carrier board as well as D1 on the SOM light up solid green. You will also start to see console output on your terminal window. If everything was done correctly the board should boot completely into Linux, arriving at a phyFLEX-i login: prompt. The default login account is root with an empty password. Note that the first time the board is booted it will takes a little while for the SSH server to generate new keys. Subsequent boots should be faster.
Not seeing any output on the console?
If you connected a PHYTEC Display as per step 1 the system will run fluid launcher. Interact with the fluid launcher on the display by touching the screen to browse through applications. More information regarding fluid launcher is provided in the Additional Demos section of the Quickstart.
Not seeing anything on your display?
The phyFLEX-i.MX6 (PFL-A-02) has been developed and tested with Ubuntu 12.04 LTS Precise Pangolin [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
Support for installing and setting up TFTP, NFS, and Samba server settings to enable communication between multiple systems and the target.
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 Barebox.
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>
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
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.
PTXdist is a set of tools created by Pengutronix to help manage all of the BSP sources, from x-loader to the filesystem and its applications. It makes it easier for a user to manage everything for specific platforms and toolchains without manually repeating relatively complex commands every time it is necessary to build a new image. It is important to note the PTXdist version because more than one may be necessary for building the toolchain and BSP.
Visit the phyFLEX-i.MX6's BSP page for information on the current versions of BSP tools.
Potentially, two versions of PTXdist will need to be downloaded:
The following instructions correspond to downloading PTXdist for building the BSP, ptxdist-2012.03.0. Therefore, to download the PTXdist software for building the toolchain, ptxdist-2011.11.0, repeat the instructions replacing 2012.03.0 with 2011.11.0. In order to be built, extract the archive containing the PTXdist software:
tar -jxvf ptxdist-2012.03.0.tar.bz2 cd ptxdist-2012.03.0
Now that the source has been extracted, the next step is to configure it for building.
PTXdist checks for specific packages that must be installed before it can be successfully built. From the PTXdist source directory, ptxdist-2012.03.0, execute the command to begin a script that uses GNU autotools to help set up the environment for building the distribution.
./configure
This command automatically stops if it is missing a package and states why and what package to install to continue with the initial setup. After successfully running the configure script, build and install PTXdist.
From the PTXdist source directory, ptxdist-2012.03.0:
make sudo make install
The install location is "/usr/local" by default, which is why the make install command must be run with root privileges. If another directory is preferred for the install, use the --prefix option when installing, but be sure to add the "bin/" directory of the installed tools in this new folder to $PATH by modifying and sourcing ~/.bashrc.
source ~/.bashrc
Now that the install is complete, the PTXdist folder can be removed, as well as the original archive.
Optional:
cd .. rm -rf ptxdist-2012.03.0*
PTXdist is a console command tool and different functions are run by extending parameters to the ptxdist base command.
ptxdist <parameter>
To generate a full list of parameters and a description of the function, use the help command:
ptxdist help
Since PTXdist versions can be installed in parallel it may be useful to view the version number corresponding to the ptxdist command:
ptxdist --version
If the output of this command does not correlate to the desired version of PTXdist, affix the ptxdist command with the version number. For example, for the phyFLEX-i.MX6 BSP, affix all ptxdist commands with 2012.03.0 resulting in ptxdist-2012.03.0:
ptxdist-2012.03.0 <parameter>
Alternatively, to correlate the ptxdist command with a specific version create a symbolic link. For example, for ptxdist to correlate to ptxdist-2012.03.0:
sudo ln -fs /usr/local/lib/ptxdist-2012.03.0/bin/ptxdist /usr/local/bin/ptxdist
It is important to use the correct version of PTXdist when building the Toolchain or BSP. If the incorrect version is used, the following will result:
error: The ptxconfig file version and ptxdist version do not match:configfile version: 2012.03.0ptxdist version: 2011.11.0
You can either migrate from an older ptxdist release with:'ptxdist migrate'
or, to ignore this error, add '--force'to ptxdist's parameters, e.g.:'ptxdist --force go'
The version of PTXdist used is noted as ptxdist version where the one required is specified as configfile version. Therefore, rerun the command with the correct version either appended to ptxdist or create a symbolic link. If the merge or force options were used on the Toolchain or BSP they will need to be removed and reinstalled to be built with the correct PTXdist version. Please note that the above is a generic example and may not apply directly to your BSP.
The first time PTXdist is used, there are some setup properties that have to be configured. To run PTXdist's setup, use the following command:
ptxdist setup
Once in the ptxdist setup, the only settings that should be modified are the User->Name and User->eMail. This is mainly for general logging purposes. If you wish to modify any other settings, please refer to the Getting Help section for a link to PTXdist documentation.
Since PTXdist works with sources only, it needs to grab source archives from the web using wget as it advances through its setup if they do not exist already. Therefore, an internet connection is required.
In order to build images or applications for an embedded device, it is necessary to have a cross toolchain that will perform the necessary operations to compile code for a specified processor and system setup.
Each toolchain will have a modified GNU Compiler Collection (gcc) designed for the desired setup. The phyFLEX-i.MX6 PD13.1.1 uses the arm-cortexa9 toolchain which can be built from the OSELAS.Toolchain-2011.11.1 and ptxdist-2011.11.0 sources.
If a working toolchain is already installed for a given architecture, it is possible to use this instead of building an OSELAS Toolchain. Do note that since external toolchains have not been tested it is possible that they may not work properly across all environments.
An extra step needs to be taken if the plan is to use an external toolchain. By default, the software package will be set to check for the vendor toolchain that it was compiled with. In order to change this, use the following command inside the root directory of the BSP:
ptxdist platformconfig architecture ---> toolchain ---> () check for specific toolchain vendor
An OSELAS toolchain, managed by PTXdist, can be easily built for a target architecture.
For the phyFLEX-i.MX6, the arm-cortexa9 architecture based toolchain is built from OSELAS.Toolchain-2011.11.1 [Here] and PTXdist 2011.11.0 [Here]. See Section 2.2 for information regarding the installation of PTXdist sources.
tar -jxvf OSELAS.Toolchain-2011.11.1.tar.bz2 cd OSELAS.Toolchain-2011.11.1
Be sure to use the correct ptxdist version for the toolchain by affixing all ptxdist commands with 2011.11.0 resulting in ptxdist-2011.11.0 or see Section 2.2.4 for information on creating a symbolic link between ptxdist and ptxdist-2011.11.0.
ptxdist select ptxconfigs/arm-cortexa9-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig ptxdist go
The toolchain is now built and installed in /opt/OSELAS.Toolchain-2011.11.1/arm-cortexa9-linux-gnueabi and ready to be used for building the BSP.
If you wish to build applications outside of the BSP directory, add the toolchain location to your PATH. Use the following from the command line or permanently add to your PATH by including it in .bashrc:
PATH=/opt/OSELAS.Toolchain-<toolchain version>/arm-<processor>-linux-gnueabi_gcc-linaro-<version>_glibc-<version>_binutils-<version>_kernel-<version>-sanitized/bin/:$PATH
Following a successful build, the OSELAS.Toolchain-2011.11.1 folder can be removed, as well as the original archive.
Optional:
cd .. rm -rf OSELAS.Toolchain-2011.11.1*
It is recommended, although optional, to set the /opt/OSELAS.Toolchain-2011.11.1/arm-cortexa9-linux-gnueabi directory and its contents as read-only to prevent accidental modifications to the toolchain.
Eclipse is a software development environment that offers extended functionality by plug-in integration. Install Eclipse and the C/C++ Development Toolkit (CDT) plug-in to write, build, and debug C/C++ code.
sudo apt-get install eclipse
Open Eclipse from the command line and specify a workspace for storing Eclipse settings and projects, ex. /home/<user>/workspace.
eclipse &
Eclipse is now started and the CDT plug-in can be integrated.
The CDT plug-in is now installed and programming in C/C++ is supported in the Eclipse environment.
Qt Integration
Setup of the Qt plug-in in Eclipse requires files located in <bsp_install_dir>/platform-phyFLEX-i.MX6/. These files are not generated until after a successful build of the BSP -- see Section 6 for additional information.
Download and extract the Qt Eclipse plug-in Here to /usr/lib.
tar -xvzf qt-eclipse-integration-linux.x86-1.6.1.tar.gz -C /usr/lib
Install the Qt plug-in in Eclipse:
eclipse --clean &
Version Name: QT_phyFLEX-i.MX6Bin Path: /platform-phyFLEX-i.MX6/sysroot-cross/binInclude Path: /platform-phyFLEX-i.MX6/sysroot-host/include
This section provides an example of using Eclipse to debug a HelloWorld Linux application, downloadable from the PHYTEC FTP, using aGNU debugger GDB via a TCP/IP network connection.
Kit Setup: Make the following connections
From the Linux command line on the target: Setup the remote settings
ifconfig eth0
The network settings can be modified. Set the IP address and, if the device is outside the network, the gateway IP address.
ifconfig eth0 ###.###.###.### route add default gw ###.###.###.###
From Eclipse on the host: Open the HelloWorld demo
From Eclipse on the host: Build the application
GCC C Compiler -> Command: arm-cortexa9-linux-gnueabi-gccGCC C Linker -> Command: arm-cortexa9-linux-gnueabi-gccGCC Assembler -> Command: arm-cortexa9-linux-gnueabi-as
scp ./HelloWorld root@###.###.###.###:/home/. ;ssh root@###.###.###.### ./HelloWorld
The Linux application, HelloWorld, will be copied to the /home/ directory of the root filesystem on the target.
From the Linux command line on the target: Start the GDB server
gdbserver ###.###.###.###:10000 HelloWorld
The GDB server has been started on the target, it is now waiting for connections on the TCP port 10000.
From Eclipse on the host: Setup the debug configuration
Automatically, Eclipse is switched into the debug perspective and the debugger stops automatically at the first line and the host's GDB is now connected to the GDB server on the target. The debug configuration, HelloWorld [C/C++ Application], in the Debug control window displays the current state of the application. Continue using the Eclipse debugger to set breakpoints, step through a project, watch and change content of variables, and use the memory monitor to view the content at a memory address.
Management of the phyFLEX-i.MX6 BSPs is provided by PTXdist version 2012.03.0. If a symbolic link was not created between ptxdist and ptxdist-2012.03.0 affix all ptxdist commands with 2012.03.0 resulting in ptxdist-2012.03.0, see Section 2.2 for additional information on using PTXdist.
Download and extract the BSP, BSP-Phytec-phyFLEX-i.MX6-<release-version>.tar.gz, available on the PHYTEC FTP.
Note: Replace <release-version> with the BSP release version downloaded, ex. for phyFLEX-PD13.2.1 BSP release, replace BSP-Phytec-phyFLEX-i.MX6-<release-version> with BSP-Phytec-phyFLEX-i.MX6-PD13.2.1.
tar -xvzf BSP-Phytec-phyFLEX-i.MX6-<release-version>.tar.gz cd BSP-Phytec-phyFLEX-i.MX6-<release-version>
Some of the important components of the BSP that you will find are:
Before we can build the BSP, we need to select the target to build for. To do that use the pre-defined ptxconfig to select a software platform and select phyCORE-i.MX6 for the hardware platform.
ptxdist-2012.03.0 select configs/ptxconfig ptxdist-2012.03.0 platform configs/phyFLEX-i.MX6/platformconfig
PTXdist should automatically detect the toolchain:
found and using toolchain: '/opt/OSELAS.Toolchain-2011.11.1/arm-cortexa9-linux-gnueabi/gcc-4.6.2-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin'
If the toolchain was not installed in the OSELAS.Toolchain() default location, PTXdist will not automatically detect it. The toolchain will need to be selected manually, see PTXdist User Manual Section 3.2.4 for additional information.
Building and creating images with PTXdist is very simple. All the required steps to download sources and build packages in the correct order are done using the ptxdist go command.
ptxdist-2012.03.0 go
The build process relies on obtaining source information from the web, therefore in some cases the content to be downloaded may no longer exist and ptxdist go will fail. If this occurs, check the PHYTEC ftp-server via ftp://ftp.phytec.de/pub/BSP_PACKAGES/EXTERNALS for an alternative download link for the file as it appears in the build output. Download the file and place it in BSP-Phytec-phyFLEX-i.MX6-<release-version>/src directory in its compressed form. After that, restart the build process by calling ptxdist go again. If the package is not available on the FTP, please contact support@phytec.de. We will then take it from our buildserver and upload it onto our ftp-server for you.
It is also possible that ptxdist will download a file that is claimed to be an archive but then is unable to decompress it. This is because the link didn’t deliver the requested archive, but rather HTML containing a message like: “Error - This file has been moved to ...”. Please treat this case in the same way as stated above.
Following a successful build, the ptxdist images command will create images to deploy on the target.
ptxdist-2012.03.0 images
PTXdist will then extract the content of priorly created *.ipk packages to a temporary directory and generate an image output of it. Therefore, files that are put manually into platform-phyFLEX-i.MX6/root will not be enclosed in the image.
All images are stored in BSP-Phytec-phyFLEX-i.MX6-<release-version>/platform-mx6/images:
Primary bootloader used to boot the Linux kernel. It is feature rich supporting environment variables, NAND Flash, and Ethernet (TFTP) to name a few. Barebox is responsible for loading the Linux kernel into RAM and transferring execution to it. Barebox is relatively stable and does not require frequent modifications or rebuilds, it is unlikely that the version of Barebox built is different than the default image on the PHYTEC FTP. Several barebox-*.img files are generated, dedicated for different RAM sizes populated on the module:barebox-phytec-pbab01-1gib_1bank.imgbarebox-phytec-pbab01-1gib.img - Matches the phyFLEX-i.MX6 default configurationbarebox-phytec-pbab01-2gib.imgbarebox-phytec-pbab01-4gib.imgbarebox-phytec-pbab01dl-1gib.imgbarebox-phytec-pbab01s-512mb.img
The monolithic kernel that is the Linux Operating Systemlinuximage
This software component contains all of the data associated with particular software components installed on the system, configuration files, device nodes, etc... that are available to a user when the operating system is running.root.tgz - Root files inside a plain gzip compressed tar ball. Typically extracted on an SD/MMC card or NFS directory.root.ubifs - Root files inside an UBI filesystem. Flashed to NAND to make the root filesystem persistent on the SOM.
The build time will vary depending on the package selection and Host performance. Beyond the initial build, after making modifications to the BSP, a full build is not required. Use the following as a reference to take advantage of optimized build options and reduce the build time.
To rebuild Barebox:
ptxdist-2012.03.0 drop barebox compile ptxdist-2012.03.0 targetinstall barebox
To rebuild the Linux kernel:
ptxdist-2012.03.0 drop kernel compile ptxdist-2012.03.0 targetinstall kernel
To rebuild the entire root filesystem:
ptxdist-2012.03.0 clean rootfs ptxdist-2012.03.0 go
To rebuild a single package in the root filesystem:
ptxdist-2012.03.0 clean <package name> ptxdist-2012.03.0 go
All source code is located in the BSP-Phytec-phyFLEX-i.MX6-<release-version>/platform-phyFLEX-i.MX6/build-target directory. To help 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 files summarized by the following:
Board File: linux-3.0.35/arch/arm/mach-mx6/board-mx6q_phyflex.c
Board File: barebox-2013.08.0/arch/arm/boards/phytec-pfla02/board.cBarebox Script Files: barebox-2013.08.0/arch/arm/boards/phytec-pfla02/env/
The files located in <bsp_install_dir>/platform-phyFLEX-i.MX6/ and are not generated until after the first successful build of the BSP.
PTXdist uses the kernel configuration, KConfig, files present throughout the BSP for straightforward user configuration of individual settings and drivers. The platform, kernel, and project’s root filesystem configuration menus will be the most beneficial.
The platform configuration menu contains the default settings for each platform including what bootloaders, kernel, and filesystem images are to be built and located.
ptxdist-2012.03.0 platformconfig
The kernel configuration menu allows the user to adjust the drivers and support included in a Linux kernel build.
ptxdist-2012.03.0 kernelconfig
Configuration of the project’s filesystem can be done in the overall menuconfig. By toggling the options in the base configuration, the applications and content built into the filesystem can be modified directly. This allows both minimal and more complete filesystem builds to be created easily.
ptxdist-2012.03.0 menuconfig
A bootable SD/MMC card is a necessity especially if something has happened where the board cannot be booted from Flash. Also, an SD/MMC card is one possible solution for stand-alone applications. The process requires an SD card reader operational under Linux to format and access the Linux partition of the card. If you do not have SD card access under Linux then copying the bootloader and mounting the root filesystem on SD/MMC card will not be possible.
If using a SD/MMC card that has already been formatted skip to the appropriate steps below -- Step 5 if the Linux kernel is changing or Step 7 if the root filesystem is the only change and continue the steps from there.
1. Determine the SD card device name
ls /dev/sd*
2. Unmount all partitions of the SD card, using the SD card device name from Step 1:
umount /dev/sd[b|c|d|e]*
3. Make two partitions on the SD card using fdisk from the Linux kernel, specifying the SD card device name from Step 1:
sudo fdisk /dev/[b|c|d|e] Command (m for help): o Building a new DOS disklabel with disk identifier 0x2fe3ef94. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable.
Command (m for help): n Partition type: p primary (0 primary, 0 extended, 4 free) e extended Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-7626751, default 2048): 17432 Last sector, +sectors or +size{K,M,G} (17432-7626751, default 7626751): 1267432 Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): C Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): n Partition type: p primary (1 primary, 0 extended, 3 free) e extended Select (default p): p Partition number (1-4, default 2): 2 First sector (2048-7626751, default 2048): 1267433 Last sector, +sectors or +size{K,M,G} (1267433-7626751, default 7626751): Using default value 7626751 Command (m for help): t Partition number (1-4): 2 Hex code (type L to list codes): 83
Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks.
sudo mkfs.vfat /dev/sd[b|c|d|e]1 -F 32 -n boot sudo mkfs.ext3 /dev/sd[b|c|d|e]2 -L rootfs
4. Mount all partitions
Remove and reinsert the SD card, automount will mount /media/kernel and /media/rootfs
Kernel
5. If modifying the Linux kernel, remove the existing uImage-pfla02 file:
rm -rf /media/boot/*
6. Load the new Linux kernel to the SD Card:
cp <path to uImage-pfla02>/uImage-pfla02 /media/boot; sync
Root Filesystem
7. If modifying the root filesystem, remove the existing:
sudo rm -rf /media/rootfs/*
8. Load the new filesystem to the SD Card:
sudo tar -zxvf <path to rootfs.tgz> -C /media/rootfs/; sync
9. Unmount each partition before copying the bootloader or removing the SD Card:
umount /media/boot /media/rootfs
Bootloader
10. Use the dd command to copy barebox-image to the SD Card:
dd if=barebox-image of=/dev/sd[b|c|d|e] bs=512 skip=2 seek=2
11. Use the dd command to copy the barebox default environment to the SD Card:
dd if=barebox_default_env of=/dev/sd[b|c|d|e] bs=512 seek=4096
Additionally, if you plan on using the SD/MMC card to flash images (Section 9), copy the files to the /boot partition. Since the /boot partition is FAT32 file copying can be handled using a Windows machine and a Linux machine is not required.
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 S3 dipswitch on the Carrier Board, determines the location of the primary bootloader. Set the S3 switches correspondingly:
SPI NOR
S3-1 ONS3-2, S3-3, S3-4 OFF
SD Card
S3-1, S3-2 ONS3-3, S3-4 OFF
After application of power, approximately three seconds are allotted for the user to hit any key which will halt autoboot and enter Barebox.
Note: help is a useful tool in Barebox to show available commands and usage.
Use the Barebox configuration files to modify environment variables, select boot settings, and setup networking parameters.
You can check the targets network settings by running the following:
devinfo eth0
The ethaddr variable is the MAC id of the target. This is a pre-programmed value which is read from the EEPROM and matches the sticker on the SOM. To modify any of the network settings, type:
edit /env/network/eth0
You should see something similar to the following, modify the variables to specify your network configuration for ETH0:
ipaddr=###.###.###.### netmask=###.###.###.### gateway=###.###.###.### serverip=###.###.###.###
A dedicated IP address for the SOM. This is crucial if TFTP will be used for updating the device's images at any point.
Netmask for the network: typically 255.255.255.0. This is only necessary if the TFTP directory is located on another network.
Gateway IP for the network. This is only necessary if the TFTP directory is located on another network.
IP address of the host or another machine. serverip corresponds to where the TFTP directory, if it exists, is located.
Display either via LCD or DVI/HDMI is supported in the Barebox display script.
edit /env/video/display
The primary display output (/dev/fb0) is selected by prim_out. To use the PHYTEC display connector as your primary output, set prim_out to lbd. Additionally, in the "Displays" section, be sure to uncomment the LCD selected out of the five supported and place a '#' at the beginning of the line for the remaining to comment them out. For example, the file should resemble the following if the 7" EDT display with capacitive touch and adapter board, ETM0700G0DH6 (LCD-018-070KAP) screen is to be used on the target device:
# Set prim out put (hdmi/ldb) prim_out=ldb #Displays #display=Primeview-PD050VL1 #display=Primeview-PD035VL1 #display=Primeview-PD104SLF #display=Primeview-PM070WL4 display=ETM0700G0DH6
Display | PHYTEC Display Part Number | Description | Resolution |
---|---|---|---|
Primeview-PD050VL1 | LCD-017-050V | 5" VGA LCD with resistive touch | 640x480 |
Primeview-PD035VL1 | KLCD-011 | 3.5" QVGA LCD with resistive touch | 640x480 |
Primeview-PD104SLF | LCD-017-104S | 10.4" SVGA LCD with resistive touch | 800x600 |
Primeview-PM070WL4 | LCD-017-070W | 7" WVGA LCD with resistive touch | 800x480 |
ETM0700G0DH6 | LCD-018-070KAP | 7" WVGA LCD with capacitive touch | 800x480 |
To use HDMI/DVI as your primary output, set prim_out to hdmi.
# Set prim out put (hdmi/ldb) prim_out=hdmi
Additionally, to set the HDMI resolution edit the display bootargs:
edit env/display/bootargs-display
Replace the HDMI specific line global.linux.bootargs.dyn.display="video=mxcfb1:$display prim_hdmi=yes" with the following replacing <xres>x<yres>@<frequency> with your custom resolution. For example, global.linux.bootargs.dyn.display="video=mxcfb0:1600x900M@60 video=mxcfb1:$display fbmem=25M,5M prim_hdmi=yes" successfully worked to display on a 16:10 monitor at a resolution of 1680x1050 (VESA resolution).
global.linux.bootargs.dyn.display="video=mxcfb0:<xres>x<yres>@<frequency> video=mxcfb1:$display fbmem=25M,5M prim_hdmi=yes"
From any of the Barebox scripts, return to the Barebox prompt by pressing CTL+D to apply changes or CTL+C to cancel. To retain changes, at the Barebox prompt save the environment.
saveenv
The target can be booted from on-board media or from a development host via network. By default the Rapid Development Kit is prepared with all required components available on the target itself with all images persistent in flash. This means the only connection needed is a serial cable to see what is happening on the target. This method is called stand-alone.
Another possible solution for stand-alone applications is to use an SD/MMC card. This process requires a properly formatted SD card which can be prepared using the instructions in the Creating a Bootable SD card section of the Quickstart.
The other method is to provide needed components via network. In this case the development host is connected to the phyFLEX-i.MX6 with a serial cable and via Ethernet; the embedded board boots into the bootloader, then issues a TFTP request on the network and boots the kernel from the TFTP server on the host. Then, after decompressing the kernel into RAM and starting it, the kernel mounts its root filesystem via the NFS server on the host.
The BSP supports all methods. The latter is especially useful for development purposes as it provides a quick turnaround while testing the kernel and root filesystem.
The "boot" command known from the former BSP version has changed. Options, such as -k to select the location of the Linux kernel, are no longer available. Instead the boot command uses a boot file, there are three entries available in "/env/boot" including nand, net, and sd-ext3.
Stand-Alone NAND Boot
To use the target stand-alone, the kernel and root filesystem have to be made persistent in the on-board media of the phyFLEX-i.MX6. This is done by default in the RDK, however if the kernel and root filesystem are not available in the on-board media or you would like to update them, refer toSection 9 for information on flashing images.
The phyFLEX-i.MX6 is configured by default to boot the kernel and mount the root filesystem from flash. By simply resetting or power cycling the board the target will boot into Linux.
The nand boot entry can also be run from the Barebox shell:
boot nand
Remote Boot
The network-remote boot variant is intended to be used during development because of the frequent need to rebuild the Linux kernel and root filesystem. TFTP and NFS accelerate the development process. Reflashing the newest kernel and root file system to the SOM after every new build would be very cumbersome and time consuming. All that is needed is an Ethernet connection and a network aware bootloader which can fetch the kernel from a TFTP server.
Restart the board and stop autoboot by pressing m. You'll get a menu:
Welcome to Barebox 1: Boot: Kernel:nand;rootfs:nand 2: Boot: network (Kernel:tftp;rootf:nfs) 3: Boot: MMC (ext3) 4: Settings 5: Shell 6: Reset
From this menu you can select the interface in which to boot from. Press 2 and then the enter key.
The net boot entry can also be run from the Barebox shell:
boot net
Stand-Alone SD/MMC card Boot
The SD/MMC card boot variant is an alternative stand-alone boot option. All that is needed is a properly formatted (see the Create a Bootable SD/MMC card section of the Quickstart) SD/MMC card
Restart the board and stop autoboot by pressing m. You'll get a menu:
Welcome to Barebox 1: Boot: Kernel:nand;rootfs:nand 2: Boot: network (Kernel:tftp;rootf:nfs) 3: Boot: MMC (ext3) 4: Settings 5: Shell 6: Reset
From this menu you can select the interface in which to boot from. Press 3 and then the enter key.
The SD/MMC card boot entry can also be run from the Barebox shell:
boot sd-ext3
Custom Boot
You may have custom boot requirements that are not covered by the three available boot files (nand, net, sd-ext3). If this is the case you can create your own custom boot entry specifying the kernel and root filesystem location.
edit /env/boot/custom
#!/bin/sh if [ "$1" = menu ]; then boot-menu-add-entry "$0" "Kernel:<kernel_loc>;rootfs:<rootfs_loc>" exit fi global.bootm.image="<kernel_loc_bootm.image>" #global.bootm.oftree="/env/oftree" global.bootm.oftree="none" <div style="color:red"><nfs_root_path></div> bootargs-ip bootargs-cam bootargs-display global.linux.bootargs.dyn.root="<rootfs_loc_dyn.root>"
Specifies the location of the Linux kernel to be printed in the Barebox menu. Replace this with one of the following:nand - To boot the Linux kernel from NANDtftp - To boot the Linux kernel via TFTPext3 - To boot the Linux kernel from the SD/MMC card
Specifies the location of the root filesystem to be printed in the Barebox menu. Replace this with one of the following:nand - To mount the root filesystem from NAND Flashtftp - To mount the root filesystem via NFSext3 - To mount the root filesystem from the SD/MCC card
Specifies the location of the Linux kernel image/dev/nand0.kernel.bb - To boot the Linux kernel from NAND${path}/linuximage - To boot the Linux kernel via TFTP/mnt/mmc/linuximage - To boot the Linux kernel from SD/MMC card
Specifies the location of the root filesystemroot=ubi0:root ubi.mtd=5 rootfstype=ubifs - To mount the root filesystem from NANDroot=/dev/nfs nfsroot=$nfsroot,v3,tcp - To mount the root filesystem via NFSroot=/dev/mmcblk0p2 rootfstype=ext3 rootwait - To mount the root filesystem from SD/MMC card
Only required if mounting the root filesystem from NFS. Replace with the following:nfsroot="/home/${global.user}/nfsroot/${global.hostname}"
Once complete with file modifications exit the editor using CTRL+D. Save the environment:
saveenv
Restart the board and stop autoboot by pressing m. You'll see the original menu but with an additional boot entry. The following example shows an added boot entry that boots the kernel from TFTP and mounts the root filesystem from NAND Flash.
Welcome to Barebox 1: Boot: Kernel:nand;rootfs:nand 2: Boot: Kernel:tftp;rootfs:nand 3: Boot: network (Kernel:tftp;rootf:nfs) 4: Boot: MMC (ext3) 5: Settings 6: Shell 7: Reset
To run your custom boot entry, press the corresponding number and then the enter key. In the example above, to boot the kernel from TFTP and mount the root filesystem from NAND Flash press 3 and then the enter key.
The custom boot entry can also be run from the Barebox shell:
boot custom
Default Boot
The phyFLEX-i.MX6 is configured by default to boot the kernel and mount the root filesystem from flash. This default setting can be changed by modifying the global.boot.default environment variable.
edit /env/config
Find the boot entries section, uncomment the global.boot.default variable and set to the desired boot source. This variable can be set to any of the entries in /env/boot. For example to set the default boot configuration to net, global.boot.default should be set in the following way:
global.boot.default=net
Exit the editor by CTRL+D and save the environment (saveenv). On a reset or power cycle the new default boot source will take affect. Similarly it will be used in the Barebox shell when executing the following:
boot
The phyFLEX-i.MX6 Rapid Development Kit comes pre-flashed with the bootloader, Linux kernel, and root filesystem. Use the following instructions to flash images via TFTP or SD card if the images are not pre-flashed, you want to upgrade to a new release, or you want to flash your own custom built images. The images to be flashed will need to be copied to the exported TFTP directory or the /boot partition of a properly formatted SD card as described in the Create a Bootable SD card section.
After making all required connections, power on the board and enter Barebox:
If flashing from TFTP, additional setup to configure the Barebox environment variables to meet your network environment and development host settings is required. The current network settings can be checked by executing the following:
devinfo
If you need to change you network configuration, type:
edit /env/network/eth0
Edit the settings as described in the Network Configuration section of the Quickstart. Save the environment and reboot the board, this will automount your tftp server at boot to /mnt/tftp.
If you would like to upgrade, have custom Barebox requirements, or are interested in seeing the version you built in action, follow the steps below:
The barebox-phytec-pba01-1gib.img file has the correct RAM size for this version of the kit. It should be copied to your TFTP exported directory or the /boot partition of the SD card depending on your chosen flashing procedure.
Method: TFTP
cp /mnt/tftp/barebox-phytec-pbab01-1gib.img .
Method: SD/MMC
cp /mnt/mmc/barebox-phytec-pbab01-1gib.img .
erase /dev/m25p0.barebox cp barebox-phytec-pba01-1gib.img /dev/m25p0.barebox
If something goes wrong and you don’t have a bootloader anymore on your module you need to boot from an SD card into Barebox (set DIP-switch S3 to ON-ON-OFF-OFF) and then do the flashing. See the previous section for a description of how to create a bootable SD card.
Placing the kernel into NAND Flash allows booting the system without the need for the TFTP hosted kernel image. This is the most common place to put the kernel in a stand-alone application. Normally development is done using a TFTP hosted kernel image until the configuration has become more stable and is unlikely to change frequently. Once stable, the kernel image can be moved to NAND Flash. This section assumes a Linux kernel with file name linuximage is available on the exported TFTP directory or /boot partition of the SD card depending on your chosen flashing procedure.
erase /dev/nand0.kernel.bb
Method: TFTP
cp /mnt/tftp/linuximage /dev/nand0.kernel.bb
Method: SD/MMC
cp /mnt/mmc/linuximage /dev/nand0.kernel.bb
Similar to the Linux kernel, placing the root filesystem into NAND Flash allows booting the system without the need for a remote connection to the NFS server. This section assumes a root filesystem of the form root.ubifs available on the exported TFTP directory or /boot partition of the SD card depending on your chosen flashing procedure. Note that you should not flash Linux’s root filesystem into NAND the same way as you did with Linux kernel.
ubiformat /dev/nand0.root ubiattach /dev/nand0.root ubimkvol /dev/ubi0 root 0
Method: TFTP
cp /mnt/tftp/root.ubifs /dev/ubi0.root
Method: SD/MMC
cp /mnt/mmc/root.ubifs /dev/ubi0.root
This demo requires one of the following displays:
Refer to the Getting Started section for connection information and Display Settings for information regarding display configuration.
The default images boot directly into the fluid launcher. If the filesystem has been modified/rewritten, the system will run ts_calibrate before loading fluid launcher. Press the boxes on the screen as they appear to calibrate the touchscreen controller.
When an application is highlighted, positioned in the center of the main screen and name displayed above the icon, simply clicking on it will open the application. Fluid launcher contains the following applications:
Use the calculator application to perform basic arithmetic. Enter operations by touching the screen or using a USB mouse or keyboard.
By month calendar display. Customize the view with formatting options.
View an image of choice and adjust the viewing perspective once it is loaded.
The Scribble Paint application allows a user to draw an image in real time as well as to open and edit an existing image. Use the Options menu to select the pen width and color and begin drawing by touching the screen or clicking on the open area using a USB mouse. The following file types are supported: bmp, ico, jpeg, png, ppm, xbm, and xpm.
Customized table that supports dynamic content in cells. Supports addition of two cells, subtraction of one cell from another, multiplication of two cells, dividing one cell from another, and summing contents from an arbitrary number of cells.
Qt version of the classic Tetrix game. The goal of the game is to fill every square in a row to clear a line. As blocks are dropped from the top of the playing area, move, rotate, and stack the blocks to fill entire rows at the bottom of the playing area. To control the blocks, connect a USB keyboard:Left cursor - move the piece one space to the leftRight cursor - move the piece one space to the rightUp cursor - rotates the piece 90 degrees counter-clockwiseDown cursor - rotates the piece 90 degrees clockwiseD - immediately move the piece down by one rowSpace - drop a piece as close to the bottom of the board as possibleUse the buttons to control the game flow, press Start to begin; Quit to end; and Pause to freeze the game but retain its state.
The Text Edit demonstration shows Qt's rich text editing facilities in action, providing an example document to experiment with. Connect a USB keyboard and mouse to insert and format text.
This example demonstrates how to animate text. Use a USB keyboard to dynamically modify the text displayed.
Exit fluid launcher. The demo can be relaunched by running the following from the Linux command line:
fluidlauncher &
Note: Some applications display a Help menu in the toolbar, click on this to learn more about what Qt classes were used.
If necessary, recalibrate the touchscreen from the Linux command line:
ts_calibrate
When finished with the kit demo, use the reboot command to restart, or the poweroff command to shutdown the system. Please note that failure to use these commands to end a session could result in a corrupted file system.
Use the following instructions to setup your WiFi module to operate in Station mode, allowing you to be able to connect as a client to an Access Point, or to operate as an Access Point. Wireless support is single role limited meaning that the WLAN interface can only operate in Station or Access Point mode, not both simultaneously.
This demo requires the following:
Software Configuration
Configure the BSP to support WiFi and rebuild the kernel and root filesystem.
Completing the following in the BSP base directory will enable:
To add support for hostapd in the BSP, download the files available here: ftp://ftp.phytec.com/products/PFL-A-02_phyFLEX-iMX6/Linux/PD13.2.2_EA2/wifi/hostapd/
ptxdist-2012.03.0 kernelconfig [*] Networking support ---> Networking options ---> <M> 802.1d Ethernet Bridging [*] IGMP/MLD snooping -*- Wireless ---> --- Wireless <*> cfg80211 - wireless configuration API [*] nl80211 testmode command [ ] enable developer warnings [ ] cfg80211 regulatory debugging [*] enable powersave by default [ ] cfg80211 DebugFS entries [ ] use statically compiled regulatory rules database [*] cfg80211 wireless extensions compatibility [*] Wireless extensions sysfs files -*- Common routines for IEEE802.11 drivers [ ] lib80211 debugging messages <*> Generic IEEE 802.11 Networking Stack (mac80211) [ ] PID controller based rate control algorithm [*] Minstrel [*] Minstrel 802.11n support Default rate control algorithm (Minstrel) ---> [ ] Enable mac80211 mesh networking (pre-802.11s) support [ ] Enable LED triggers [ ] Export mac80211 internals in DebugFS [ ] Select mac80211 debugging features ---> Device Drivers ---> [*] Network device support ---> [*] Wireless LAN ---> <*> TI wl12xx driver support ---> --- TI wl12xx driver support <*> TI wl12xx support [*] TI wl12xx 802.11 HT support (EXPERIMENTAL) < > TI wl12xx SPI support <M> TI wl12xx SDIO support <M> TI wl12xx SDIO testing support
ptxdist-2012.03.0 menuconfig Networking Tools ---> <*> bridge utils <*> wpa_supplicant ---> <*> hostapd ---> --- hostapd [*] nl80211
Re-build the kernel and root filesystem as described in Section 6.
Usage and Verification
Complete the following hardware setup:
Use NAND or network methods to boot the WiFi enabled images as described in previous sections of this Quickstart. Please note that SD0 becomes inactive when WiFi is enabled with JP13 and SD boot is not an option. Once Linux has booted, the wireless interface can be tested in either client or Access Point.
Wireless Client
The client connects to a wireless network based on the information provided in the /etc/wpa_supplicant.conf file. Specify your network configuration by editing this file:
vim /env/wpa_supplicant.conf
Replace my_network_ssid and my_network_password with the networks SSID and password.
ctrl_interface=/var/run/wpa_supplicant eapol_version=2 network={ ssid="my_network_ssid" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk="my_network_password" }
Save the changes (:wq).
Configure the IP address for WLAN0:
ifconfig wlan0 <ip_addr>
Run the WPA supplicant:
wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf
Test the interface by pinging www.phytec.com:
ping 72.32.209.9
Access Point
So that the wireless interface can provide Internet access to multiple clients, a bridge between the Gigabit Ethernet interface (ETH0) and WLAN0 must be created.
Setup the ETH0 interface:
ifconfig eth0 <ip_addr>
If you are on a subnet be sure to setup a routing gateway:
route add default gw <gateway_ip>
Use the baseline hostapd.conf provided to customize your Access Point wireless interface, environment, and authentication / encryption.
vim /etc/hostapd.conf
The following is an example of a hostapd.conf file with WPA2 security that will be recognized by wireless clients as phyFLEX-i.MX6 and can be connected to using the password passphrase:
interface=wlan0 bridge=br0 driver=nl80211 ssid=phyFLEX-i.MX6 channel=11 country_code=US hw_mode=g wpa=2 wpa_passphrase=password wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP #rsn_pairwise=CCMP
Run the following command to start hostapd:
hostapd /etc/hostapd.conf –B
Setup the bridge between ETH0 and WLAN0:
brctl addif br0 eth0
Assign an IP address to the bridge (br0) interface:
ifconfig br0 <ip_addr>
Test your interface by using a wireless client to view and connect to the phyFLEX-i.MX6 Access Point created.