This Quickstart provides you with the tools and know-how to install and work with the Linux Board Support Package (BSP) for the phyFLEX-i.MX6 Rapid Development Kit (RDK). This Quickstart shows you how to do everything from installing the appropriate tools and source, to building custom kernels, to deploying the OS, to exercising the software and hardware. Please refer to the phyFLEX-i.MX6 Hardware Manual for specific information on board-level features such as jumper configuration, memory mapping and pin layout for the phyFLEX-i.MX6 System on Module (SOM) and baseboard. Additionally, gain access to the SOM, mapper board, and baseboard schematics for the phyFLEX-i.MX6 RDK by registering at the following: http://phytec.com/support/registration/

Requirements


The following system requirements are necessary to successfully complete this Quickstart. Deviations from these requirements may suffice, or may have other workarounds.

Hardware

Software

Getting Started With Binary Images


This section is designed to get the board up-and-running with pre-built images.

Connector Interfaces

Use the following as a reference for the connector interfaces on the phyFLEX-i.MX6 RDK that will be used in this Quickstart.

Booting the Pre-Built Images

The section was designed to show you how to boot the phyFLEX-i.MX6 RDK with the pre-built demo images.

  1. Insert a bootable SD card into the SD0 (X57) slot on the baseboard. Since the default boot mode for the imx6-3.14-PL15.1.0 release loads the kernel and root filesystem from SD card, a bootable SD card with barebox.bin, zImagezImage-imx6q-phytec-pbab01.dtb, and core-image-directfb-imx6q-pbab01.tar.bz2 extracted on the SD card is required. Instructions for creating an SD card are provided in the Creating a Bootable SD Card section of the Quickstart.
  2. If you ordered a PHYTEC Display such as the LCD-018-070-KAP, plug this into the LCD power and data connectors at X65.
  3. 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.
  4. 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.
  5. 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.
  6. 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 root@imx6q-pbab01 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?

  • Check that you have setup the terminal software correctly per step 5.
  • Flash the release images from the PHYTEC FTP by creating a bootable SD/MMC card (Creating a Bootable SD Card), then configure the board to boot from SD/MMC (Selecting Boot Modes).

When finished with the kit demo, from the Linux command line use the reboot command to restart, or the poweroff command to shutdown the system. It is safe to remove power from the kit when reboot: System halted is printed on the console.

About the Yocto BSP


The Yocto Project is a Linux embedded development environment which provides layers of meta data and tools. PHYTEC's Yocto BSPs are based on the Poky meta layer, which consists of the bitbake build tool, Linux base recipes, and various scripts to define a rudimentary linux system. The openEmbedded meta layer is also included in this BSP and is made up of a collection of meta layers which provide recipes for many software packages. The meta-fsl-arm layer is part of the FSL Community BSP, a community-driven project to provide support for Freescale ARM reference boards. The meta-phytec layer leverages the meta-fsl-arm layer as a base and contains recipes and classes developed by PHYTEC. This layer defines configurations for barebox, the kernel, and software specific to the phyFLEX-i.MX6.

In order to help get started with PHYTEC's Yocto BSP structure, the repo tool can be used to obtain all the BSP sources relevant to your hardware configuration without interfacing with git. Detailed information on building this BSP from source is provided following the Development Host Setup section.

Development Host Setup


Host Debian Packages

Yocto development requires certain packages to be installed. Run the following commands to ensure you have the packages installed:

sudo apt-get install gawk wget git-core diffstat unzip texinfo \
	gcc-multilib build-essential chrpath socat \
	libsdl1.2-dev xterm

The above is the recommended package installation for development on a Ubuntu 14.04 LTS Linux distribution. For a breakdown of the packages as well as a list of packages required for other Linux distributions, see the "Required Packages for the Host Development System" section in the Yocto Project Reference Manual: http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#required-packages-for-the-host-development-system

Verify that the preferred shell for your Host PC is ''bash'' and not ''dash'':

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

Repo Tool

Download and install the repo tool. This tool is used to obtain Yocto source from Git.

cd /opt
sudo mkdir bin

# /opt/ directory has root permission, change the permissions so your user account can access this folder. In the following replace <user> with your specific username
sudo chown -R <user>: bin

cd bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ./repo
#add directory that contains repo to your path
chmod a+x repo

Add the repo directory in your PATH, using export from the command line or permanently by including it in .bashrc:

PATH=/opt/bin/:$PATH

Git Setup

If you have not yet configured your Git environment on this machine, please execute the following commands to set your user name and email address. See here for more information on getting started with Git.

git config --global user.email "your@email.com"
git config --global user.name "Your Name"

Server Setup (Optional)

Building the BSP from Source


Create a directory which will house your BSP development. In this example the BSP directory is /opt/PHYTEC_BSPs/. This is not a requirement and if another location is preferred (ex. ~/PHYTEC_BSPs) feel free to modify. We recommend using /opt over your HOME directory to avoid errors attributed to ~ syntax as well as the sudo requirement for the root filesystem and automation package building. We also recommend creating a package download directory (yocto_dl) separate from the yocto tree (yocto_fsl), as it makes resetting the build environment easier and subsequent build times much faster.

sudo mkdir /opt/PHYTEC_BSPs
cd /opt/

# /opt/ directory has root permission, change the permissions so your user account can access this folder. In the following replace <user> with your specific username
sudo chown -R <user>: PHYTEC_BSPs

cd PHYTEC_BSPs
mkdir yocto_fsl
mkdir yocto_dl
cd yocto_fsl
export YOCTO_DIR=`pwd`

At this point you will now be able to navigate to the Yocto directory using the $YOCTO_DIR environment variable.

Download the BSP Meta Layers

Download the manifest file for the imx6-3.14-PL15.1.0 BSP:

repo init -u git://git.phytec.com/phytec-manifests.git -b imx6 -m imx6-3.14-PL15.1.0.xml

Download the Yocto meta layers specified in the manifest file:

repo sync

Setup the Local Build Configuration

Run the Yocto build directory setup script. The TEMPLATECONF variable is used to set the source of the local configuration files(conf/bblayers.conf and conf/local.conf), which are located in the meta-phytec layer:

TEMPLATECONF=$YOCTO_DIR/sources/meta-phytec/conf source sources/poky/oe-init-build-env build

Add the new download directory to build/conf/local.conf:

DL_DIR ?= "/opt/PHYTEC_BSPs/yocto_dl"

Maximize build efficiency by modifying the BB_NUMBER_THREADS variable to suit your host development system. This sets the maximum number of tasks that BitBake should run in parallel. Also set the variable PARALLEL_MAKE to specify the number of threads that make can run. By default, these are set to 3 in build/conf/local.conf:

 # Parallelism options - based on cpu count
BB_NUMBER_THREADS ?= "3"
PARALLEL_MAKE ?= "-j 3"

To use Vivante GPU binaries in package 'gpu-viv-bin-mx6q' you need to accept the Freescale EULA at '/opt/yocto/yocto_fsl/sources/meta-fsl-arm/EULA'. Please read it and if you accept it, write the following in build/conf/local.conf:

ACCEPT_FSL_EULA = "1"

Start the Build

The setup is complete and you now have everything to complete a build. This BSP has been tested with and supports the image core-image-directfb. It is suggested that you start with this image. Alternate images are located in various meta layers at meta*/recipes*/images/*.bb. They can be found using the command bitbake-layers show-recipes "*-image*" in $YOCTO_DIR/build/.

The following will start a build from scratch including installation of the toolchain as well as barebox, Linux kernel, and root filesystem images.

cd $YOCTO_DIR/build
bitbake core-image-directfb

If the package fetch fails, you will need to manually download the linuxptp IEEE 1588 stack to $DL_DIR (http://sourceforge.net/projects/linuxptp/files/). Once you've downloaded the archive (e.g. linuxptp-1.3.tgz), you will need to create a "done" file so fetch doesn't delete the file and try to refetch it:

cd yocto_dl
touch linuxptp-1.3.tgz.done


Another issue that may happen is ncurses5.9 won't be built in time for a different package in the build (says libpanelw.so is missing). Forcing the reinstall of the base ncurses package unsticks this:

bitbake ncurses -f -c install

Built Images

All images generated by bitbake are deployed to $YOCTO_DIR/build/deploy/images/imx6q-pbab01:

The phyFLEX-i.MX6 SOMs can be populated with various sizes of DDR3 SDRAM. Since the DDR3 initialization is performed by the bootloader, different versions of barebox may be required if using a custom SOM. The available versions of barebox are:

  • barebox-phytec-pbab01-1gib.img
  • barebox-phytec-pbab01-1gib-1bank.img (tested)
  • barebox-phytec-pbab01-2gib.img
  • barebox-phytec-pbab01-4gib.img (tested)
  • barebox-phytec-pbab01dl-1gib.img
  • barebox-phytec-pbab01s-512mb.img

All of these images are built with the BSP, and are located in the barebox source directory: $YOCTO_DIR/build/tmp/work/imx6q_pbab01-poky-linux-gnueabi/barebox/2014.11.0-r0/git/images/

To change which of these barebox images is deployed to the image directory, edit the machine file located at: $YOCTO_DIR/sources/meta-phytec/conf/machine/imx6q-pbab01.conf and modify the variable "BAREBOX_IMAGE_IMX " to the appropriate barebox image above.

Source Locations:

Build Time Optimizations

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:

bitbake barebox -f -c compile && bitbake barebox

To rebuild the Linux kernel:

bitbake linux-fslc -f -c compile ; bitbake linux-fslc

The Yocto project's Bitbake User Manual provides useful information regarding build options: http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html

Customizing the BSP


We recommend you create your own layer and make changes to the existing BSP there. This will make it easier to update the BSP. Instructions and tips on creating your own layer are available here: http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#creating-your-own-layer

Appending Recipes

To modify an existing recipe in your own layer, use a bbappend file. The following is an example of modifying the barebox_2014.11 recipe, barebox_2014.11.0.bb, located at $YOCTO_DIR/sources/meta-phytec/recipes-bsp/barebox/barebox_2014.11.0.bb.

Create a recipes-bsp/barebox/ directory in your own meta-layer to place the bbappend file in. Make sure that the new file matches the .bb file name exactly. Alternatively, you may use % after the underscore in place of the specific version for portability with future versions of the recipe.

mkdir $YOCTO_DIR/sources/<YOUR_META_LAYER>/recipes-bsp/barebox/
vim $YOCTO_DIR/sources/<YOUR_META_LAYER>/recipes-bsp/barebox/barebox_%.bbappend

For information on how to write a recipe, see chapter 5.3 of the Yocto Development Manual: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-recipe-syntax

Adding Packages to the build

There are various ways to add a package to the BSP. For example, packages and package groups can be added to image recipes. See the Yocto Development manual for how to customize an image: http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#usingpoky-extend-customimage-imagefeatures

The following instructions demonstrate how to add a package to the local build of the BSP. First, search for the corresponding recipe and which layer the recipe is in. This link is a useful tool for doing so: http://layers.openembedded.org/layerindex/branch/daisy/layers/.

If the package is in the meta-openembedded layer, the recipe is already available in your build tree. Add the following line to $YOCTO_DIR/build/conf/local.conf:

IMAGE_INSTALL_append = " <package>"

The leading whitespace between the " and the package name is necessary for the append command.

 

If you need to add a layer to the BSP, clone or extract it to the $YOCTO_DIR/sources/ directory. Then, modify $YOCTO_DIR/build/conf/bblayers.conf to include this new layer in BBLAYERS:

BBLAYERS += "${BSPDIR}/sources/<new_layer>"

Configuring the Kernel

The kernel configuration menu allows the user to adjust drivers and support included in a Linux Kernel build. run the following command from the build directory:

cd $YOCTO_DIR/build
bitbake linux-fslc -c menuconfig

Then rebuild the kernel:

bitbake linux-fslc -f -c compile ; bitbake linux-fslc

To rebuild the root filesystem:

bitbake -f core-image-directfb

Customizing the Device Tree

The device tree is a data structure for describing hardware, and is a way of separating machine specific information from the kernel. For information on the device tree concept, devicetree.org is a good source: http://devicetree.org/Device_Tree_Usage

Device trees for PHYTEC products consist of a board DTS file, a SOM dtsi and a carrier board dtsi. The SOM dtsi includes the processor dtsi and contains definitions for all devices that are located on the SOM, such as NAND flash. Peripherals whose signals are routed through the SOM but whose hardware is located on the carrier board are defined in the carrier board dtsi, such as MMC. The board file then enables optional nodes that were defined in the dtsi files that pertain to this specific board configuration.

To disable a peripheral such as UART3, change the status of the uart3 node in tmp/work/imx6q_pbab01-poky-linux-gnueabi/linux-fslc/3.14+gitAUTOINC+e6c7ae7613-r0/git/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi

from "okay" to "disabled":

&uart3 {
        status = "disabled";
};

The kernel source directory has very good documentation and examples on what bindings are supported for specific peripherals: Documentation/devicetree/bindings/.

Creating a Bootable SD Card


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 sections below – here if updating the kernel, or here if updating the Root filesystem, 

  1. Determine the SD card device name
    1. The SD card device name is of the form /dev/sd[b|c|d|e]. Run the following without and with the SD card connected:

      ls /dev/sd*
    2. The device that appeared on the call to ls with the SD card but not the call without is the SD card device.

  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.

     

    1. Create a new primary partition (n command) with partition id C, leaving 8 MB of free space at the beginning of the card:

      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))
    2. Create a new Linux partition (n command) with partition id 83

      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
    3. Write the partition table to the card (w command) which will destroy all data on the SD card

      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.
    4. Create a filesystem on the partitions from the Linux command line:

      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
    1. Remove and reinsert the SD card, automount will mount /media/boot and /media/rootfs

Kernel

  1. If modifying the kernel, remove the existing linuximage and device tree binary files:

    rm /media/boot/zImage
    rm /media/boot/zImage-imx6q-phytec-pbab01.dtb
  2.  Load the new Linux kernel and device tree binary to the SD Card. Note that the default bootloader environment is configured to recognize "zImage" and "zImage-imx6q-phytec-pbab01.dtb" as the kernel and dts respectively:
     

    cp zImage /media/boot/zImage; sync
    cp zImage-imx6q-phytec-pbab01.dtb /media/boot/; sync

Root Filesystem

  1. If modifying the root filesystem, remove the existing:
     

    sudo rm -rf /media/rootfs/*
  2. Load the new filesystem to the SD Card:

    sudo tar -jxf core-image-directfb-imx6q-pbab01.tar.bz2 -C /media/rootfs/; sync
  3. Extract the kernel modules to the root partition of the SD card:

    sudo tar -zxf modules-imx6q-pbab01.tgz -C /media/rootfs/; sync
  4. If you intend to flash images to NAND, also copy the UBIFS filesystem image to the boot partition of the SD card:

    cp core-image-directfb-imx6q-pbab01.ubifs /media/boot/; sync

Bootloader

  1. Umount each partition before copying the bootloader:

    umount /media/boot /media/rootfs


  2. Use the dd command to copy the barebox image to the SD card:

    sudo dd if= barebox-imx6q-pbab01.imx  of=/dev/sd[b|c|d|e] bs=512 skip=2 seek=2

Boot Configurations


The default boot mode for the imx6-3.14-PL15.1.0 Yocto BSP is the following:

Selecting Boot Modes

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 dipswitch on the Carrier Board, determines the location of the primary bootloader. Set the dipswitch correspondingly:

SPI NOR (Default)

S3-1 ON

S3-2, S3-3, S3-4 OFF

SD Card

S3-1, S3-2 ON

S3-3, S3-4 OFF

Basic Settings

After application of power, approximately three seconds are allotted for the user to hit any key which will halt autoboot and enter Barebox.

help is a useful tool in Barebox to show available commands and usage.

Network Settings

You can check the target's 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=###.###.###.###

Saving Configurations

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

Boot Options

Note modify the default boot configuration for this BSP if different from below. 

The target can be booted from on-board media or from a development host via network. In our standard configuration, this BSP release loads the kernel and root filesystem from SD cardThis 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.

For booting via network, the development host is connected to the phyFLEX-i.MX6 RDK 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. This method is especially useful for development purposes as it provides a quick turnaround while testing the kernel and root filesystem.

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 device. This is done by default in the kit, however if the kernel and root filesystem are not available in the on-board media or you would like to update them, refer to the Flashing Images section for information on flashing images.

The nand boot entry can 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 to go into the Barebox shell. Run the command:

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 Creating a Bootable SD Card section of the Quickstart) SD/MMC card.

Restart the board and stop autoboot to go into the Barebox shell. Run the command:

boot mmc

Custom Boot

You may have custom boot requirements that are not covered by the four available boot files (nand, net, mmc, spi). If this is the case you can create your own custom boot entry specifying the kernel and root filesystem location.

 

Once complete with file modifications exit the editor using CTRL+D. Save the environment:

saveenv

To run your custom boot entry from the Barebox shell:

boot custom

 Specifiend the Default Boot Mode

The device is configured by default to boot the kernel and mount the root filesystem from the bootsource set for Barebox in the dipswitch (Selecting Boot Modes). This default setting can be changed by adding or modifying the global.boot.default environment variable.

edit /env/config-board

Comment out the if else statements which set the boot sequence depending on the Barebox bootsource, and add the global.boot.default variable to 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

 

Flashing Images


The phyFLEX-i.MX6 Rapid Development Kit is delivered with a pre-flashed bootloader. The following instructions for flashing images from TFTP or SD card will be useful if you want to:

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 Creating a Bootable SD Card section of the Quickstart.

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 in /env/network/eth0.

If you need to change you network configuration, type:

edit /env/network/eth0

Edit the settings as described in the Network Settings section of the Quickstart. Save the environment and reboot the board, this will automount your tftp server at boot to /mnt/tftp.

Barebox

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: 

barebox.bin should be copied to your TFTP exported directory or the /boot partition of the SD card depending on your chosen flashing procedure.

Be sure that the barebox-imx6q-pbab01.imx file has the correct RAM size for your version of the phyFLEX-i.MX6 SOM. This is configured as part of the build settings.

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 the DIP-switch as stated in Boot Configurations) and then do the flashing. See the Creating a Bootable SD Card section of this Quickstart for a description of how to create a bootable SD card.

Kernel

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 zImage is available on the exported TFTP directory or /boot partition of the SD card depending on your chosen flashing procedure.

Root Filesystem

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 core-image-directfb-imx6q-pbab01.ubifs is 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.

If you experience issues flashing the root filesystem, erase the entire NAND partition before reflashing the images:

 erase /dev/nand0.bb