Timesys Getting Started Guide for Boundary Devices BD-SL-i.MX6 Built to Freescale SABRE Lite Design


Contents

Introduction

Important Note: The Demo images are designed to run from an SD card, and will not work with this guide without some modification. Please use /docs/nitrogen6x_demo_installation_instructions instead.

This document will describe in detail the procedures for booting a Linux kernel image and mounting a root file system over NFS on the Boundary Devices BD-SL-i.MX6 Built to Freescale SABRE Lite Design.

Prerequisites

Host Requirements

To properly boot a board using software from Timesys, your host machine must meet the following requirements:

  • Modern GNU/Linux Distribution. While you can use nearly any modern Linux distribution released in the last 24 months, Timesys recommends one of the following:
    • Ubuntu (Most recent release or LTS)
    • Fedora (Most recent release)
  • An internet connection on the Development Host.
  • Root or sudo permission on the Development Host.
  • A copy of the Linux Kernel (uImage) and Root File System (rootfs.tar.gz) for the Target Board downloaded from Factory. These are found in the output directory of your online build, or in the directory build_armv7l-timesys-linux-<libc>/images/ on the command line.
  • If you are booting your root file system over the network, you will need two network cards installed and configured in the Development Host. One to communicate normally with your LAN/WAN while installing host packages, the other to communicate solely with the target board.
  • An available serial port on your Development Host.

Target Requirements

To boot the Boundary Devices BD-SL-i.MX6 Built to Freescale SABRE Lite Designusing NFS (network filesystem), you will need the following items:

  • Boundary Devices BD-SL-i.MX6 Built to Freescale SABRE Lite Design
  • 5V Power Supply
  • RS232 Serial Cable
  • Ethernet Crossover Cable or Ethernet hub/switch and Ethernet Patch Cables

Once you have all of the necessary components, you should perform the following steps:

  1. Connect the UART port of the BD-SL-i.MX6 board to the serial port of your workstation using the RS232 serial cable.
  2. If you are using a cross-over cable, connect the Ethernet port of the BD-SL-i.MX6 board to the second Ethernet port of your workstation.
  3. If you are using an Ethernet hub or switch, connect the debug board to the hub with a straight-through Ethernet cable, then connect the hub to the second Ethernet port of your workstation.
  4. Connect the power supply to your board.

Preparing the Target

Configuring Serial Communication

The BD-SL-i.MX6 uses a serial debug port to communicate with the host machine. The commands discussed in this section are meant to be performed by a privileged user account. This requires the root login or prepending each command with sudo.

Using Minicom

  1. Start minicom on your host machine in configuration mode. As root:

    # minicom -o -s -w

  2. A menu of configuration should appear. Use the Down-arrow key to scroll down and select the Serial port setup option, and press Enter.
  3. Verify that the listed serial port is the same one that is connected to the target board. If it is not, press A, and enter the correct device. This is /dev/ttyS0 on most Linux distributions.
  4. Set the Bps/Par/Bits option by pressing the letter E and using the next menu to set the appropriate values. You press the key that corresponds to the value 115200, then press Enter.
  5. Set Hardware flow control to No using the F key.
  6. Set Software flow control to No using the G key.
  7. Press Enter to return to the main configuration menu, and then press Esc to exit this menu.
  8. Reset the board, and wait for a moment. If you do not see output from the board, press Enter several times until you see the prompt. If you do not see any output from the board, and have verified that the serial terminal connection is setup correctly, contact your board vendor.

TIP: If you experience an error similar to Device /dev/ttyS0 is locked when starting minicom, it usually means that another process is using the serial port (which is usually another instance of minicom). You can find the process that is currently using the serial port by executing the following:

# fuser /dev/ttyS0
/dev/ttyS0:         28358

# ps 28358
  PID TTY      STAT  TIME COMMAND
  28923 pts/0    S+    0:00 minicom

This process can also be killed directly with fuser as root. Please use this command with caution:

# fuser -k /dev/ttyS0

Using GNU Screen

To quickly connect to a board using Gnu Screen, execute the following:

# screen /dev/ttyS0 115200

For more information about using screen, please consult the man page, or view the manual online at http://www.gnu.org/software/screen/manual/screen.html

Configuring the Network Interface

Finding the MAC Address

The MAC Address can be found by viewing the U-Boot's initial console output:

Example

U-Boot 2009.08-dirty (Mar 19 2012 - 10:04:33)

CPU:   Freescale i.MX 6 family 0.0V at 792 MHz
Temperature:   can't get valid data!
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 29333333Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 200000000Hz
usdhc2 clock  : 200000000Hz
usdhc3 clock  : 200000000Hz
usdhc4 clock  : 200000000Hz
nfc clock     : 24000000Hz
Board: MX6Q-SABRELITE:[ WDOG]
Boot Device: I2C
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1
JEDEC ID: 0xbf:0x25:0x41
Reading SPI NOR flash 0xc0000 [0x2000 bytes] -> ram 0x276009b8
SUCCESS

In:    serial
Out:   serial
Err:   serial
Net:   got MAC address from IIM: 12:34:56:78:9a:bc
FEC0 [PRIME]
Hit any key to stop autoboot:  0
MX6Q SABRELITE U-Boot >

Pay special attention to the line that begins "Net: got MAC address from IIM:". The twelve-digit colon-separated hexademical code at the end of this line, in this case the fictional 12:34:56:78:9a:bc, is your MAC Address.

Changing the IP Address

The IP address can be set manually by modifying the ipaddr environment variable, or automatically using the dhcp or bootp commands.

Preparing the Host

Setting up the network

The commands discussed in this section are meant to be performed by a privileged user account. This requires the root login or prepending each command with sudo.

Identify the network adapter connecting the Host to the Target

Timesys only supports direct Ethernet connections from the development Host to the Target board. Ideally, the development Host would have two network adapters; one adapter to connect to your LAN, and one Ethernet card to connect directly to the Target board with a crossover cable or Ethernet hub. If your development Host only has one network interface it must be directly connected to the Target board. The Ethernet adapter connected directly to the target board must be:
  • Configured with a proper static IP address and Subnet Mask.
  • Connected directly to the target board with either a crossover cable or its own Ethernet hub.
From a command prompt issue the command:
# /sbin/ifconfig
Each interface will report its IP address, Subnet Mask, and Default Gateway information:
eth0 Link encap:Ethernet HWaddr 00:19:bb:49:ff:0e      
        inet addr:192.168.3.244 Bcast:192.168.3.255 Mask:255.255.254.0
        inet6 addr: fe80::219:bbff:fe49:ff0e/64 Scope:Link      
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1      
        RX packets:57214 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:47272 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000      
        RX bytes:43109083 (41.1 MB) TX bytes:6308206 (6.0 MB)
        Interrupt:16
eth1 Link encap:Ethernet HWaddr 00:10:b5:4a:c1:a9      
        inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.0.0.0      
        UP BROADCAST MULTICAST MTU:1500 Metric:1      
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0     
        collisions:0 txqueuelen:1000      
        RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)      
        Interrupt:21 Base address:0x1100
lo  Link encap:Local Loopback      
        inet addr:127.0.0.1 Mask:255.0.0.0      
        inet6 addr: ::1/128 Scope:Host      
        UP LOOPBACK RUNNING MTU:16436 Metric:1      
        RX packets:1974 errors:0 dropped:0 overruns:0 frame:0      
        TX packets:1974 errors:0 dropped:0 overruns:0 carrier:0     
        collisions:0 txqueuelen:0      
        RX bytes:226637 (221.3 KB) TX bytes:226637 (221.3 KB)
Note the IP address and Subnet Mask of the appropriate network connection. You will use this to configure the DHCP server.

Installing the server daemons on the development host

  • On Ubuntu 11.04 and newer:
    # apt-get install xinetd tftp tftpd isc-dhcp-server \
                      nfs-kernel-server portmap
  • On Ubuntu 10.11 and older:
    # apt-get install xinetd tftp tftpd dhcp3-server \
                      nfs-kernel-server portmap
    NOTE: Older versions of Ubuntu use nfs-common and nfs-user-server in place of nfs-kernel-server
  • On Fedora Core:
    # yum install xinetd tftp tftp-server dhcp nfs-utils
Important: After installing these packages the DHCP server software may start automatically. Having the DHCP server running while you are connected to a LAN can interfere with the operation of other computers. After the DHCP service installs and starts issue these commands to stop the DHCP service and prevent it from starting automatically at boot:

  • To stop the dhcp service:

    • On Ubuntu 11.04 and newer:

      # service isc-dhcp-server stop

    • On Ubuntu 10.11 and older:

      # service dhcp3-server stop

    • On Fedora Core:

      # /etc/init.d/dhcp stop

  • To prevent the service from starting automatically:

    • On Ubuntu 11.04 and newer:

      # chmod 644 /etc/init.d/isc-dhcp-server

    • On Ubuntu 10.11 and older:

      # chmod 644 /etc/init.d/dhcp3-server

    • On Fedora Core:

      1. Click the System Menu
      2. Select Administration
      3. Select Services
      4. Select dhcpd
      5. Click the Customize button
      6. Uncheck Runlevel 2, 3, 4 and 5

Disable SELinux and Firewall on Fedora Core

On Fedora Core, SELinux and the firewall will interfere with many of the services that are needed to work with the target board. These should be disabled before continuing.

Generally Ubuntu does not have these services running by default.

  1. Disable SELinux:

    1. Click the System Menu
    2. Select Administration
    3. Select SELinux Management
    4. Change System Default Enforcing Mode to Disabled

  2. Disable Firewall:

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select iptables
    5. Click the Customize button
    6. uncheck Runlevel 2, 3, 4 and 5

Setting up DHCP

  1. Edit the dhcpd configuration file:

    • On Ubuntu, edit /etc/dhcp/dhcpd.conf and include the following lines (note: on older versions of Ubuntu this file is at either /etc/dhcp3/dhcpd.conf or /etc/dhcpd.conf):

      subnet 10.0.0.0 netmask 255.0.0.0 {
       host targetboard {
        fixed-address 10.0.0.10;
        hardware ethernet 12:34:56:78:9a:bc;
        option root-path "/full/path/to/rfs";
        filename "uImage";
       }
      }

    • On Fedora Core, edit /etc/dhcpd.conf and include the following lines:

      ddns-update-style ad-hoc;
      subnet 10.0.0.0 netmask 255.0.0.0 {
       host targetboard {
        fixed-address 10.0.0.10;
        hardware ethernet 12:34:56:78:9a:bc;
        option root-path "/full/path/to/rfs";
        next-server 10.0.0.1;
        filename "uImage";
       }
      }

  2. Test the DHCP server on the network card that is connected to your development board. For this example assume eth1. This command will start the DHCP server in the foreground and output any status or error messages to the screen.

    • On Ubuntu up to 12.04 LTS:

      # service dhcp3-server restart

    • On Ubuntu 12.04 LTS and later:

      # service isc-dhcp-server restart

    • On Fedora Core:

      # /usr/sbin/dhcpd -d eth1

    • It is recommended to start the DHCP server in this manner each time you need to boot your Target board.

Setting up TFTP

  1. Edit the xinetd.conf file

    • On Ubuntu, edit /etc/xinetd.conf and add the following lines just above the line that reads includedir /etc/xinetd.d.

      service tftp
      {
       socket_type = dgram
       protocol = udp
       wait = yes
       user = root
       server = /usr/sbin/in.tftpd
       server_args = -s /tftpboot
       disable = no
      }

    • On Fedora Core, the tftp-server package creates a /etc/xinetd.d/tftp file. Edit this file and change the disable line from yes to no. The contents of the file are:

      service tftp
      {
       socket_type     = dgram
       protocol      = udp
       wait       = yes
       user       = root
       server       = /usr/sbin/in.tftpd
       server_args     = -s /tftpboot
       disable      = no
       per_source      = 11
       cps       = 100 2
       flags       = IPv4
      }

  2. Create the /tftpboot folder if it does not exist:

    # mkdir /tftpboot

  3. Copy the kernel image to the /tftpboot directory:

    # cp /path/to/kernel/image/uImage \
                      /tftpboot/uImage

    NOTE Also copy other files that are required for booting, such as a device tree blob, to /tftpboot.

  4. Restart the xinetd server with the following command:

    # /etc/init.d/xinetd restart

  5. Test the TFTP server with the following commands

    # tftp localhost
    tftp> get uImage
    Received 1456898 bytes in 0.4 seconds
    tftp> quit

  6. Set xinetd to start automatically on Fedora Core.

    Ubuntu users will skip this step.

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select xinetd
    5. Click the Customize button
    6. Check Runlevel 2, 3, 4 and 5

Setting up NFS

  1. As root, extract rootfs.tar.gz to a directory and note the path. This path will be referred to as /full/path/to/rfs in this document.

    # mkdir /full/path/to/rfs
    # cd /full/path/to/rfs
    # sudo tar xvf rootfs.tar.gz

  2. Export this path by editing /etc/exports to include a line similar to the following:

    /full/path/to/rfs 10.0.0.10(rw,no_root_squash)

  3. Restart the NFS services

    • On Ubuntu issue the following commands in order:

      # service portmap stop
      # service nfs-kernel-server stop
      # service portmap start
      # service nfs-kernel-server start
      NOTE: Older versions of Ubuntu use nfs-common and nfs-user-server in place of nfs-kernel-server

    • On Fedora Core:

      # /etc/init.d/nfs restart

  4. Set nfsd to start automatically on Fedora Core. Ubuntu users will skip this step.

    1. Click the System Menu
    2. Select Administration
    3. Select Services
    4. Select NFS
    5. Click the Customize button
    6. Check Runlevel 2, 3, 4 and 5

i.MX USB Programming Utility

The BD-SL-i.MX6 loads U-boot from SPI-NOR by default.

The Timesys Factory can build a utility which loads a custom U-boot binary over USB OTG onto the BD-SL-i.MX6. This is useful for testing iterations of U-Boot before performing a destructive update to the board's SPI-NOR.

In order to build this utility, you will first need to install libusb-1.0 development software to your host.

  • On Ubuntu:

    # apt-get install libusb-1.0-0-dev

  • On Fedora Core:

    # yum install libusb1-devel

Select the i.MX USB utility in the Timesys Factory under Toolchain Configuration -> i.MX USB programming utility. After this configuration, rebuild your factory with a simple 'make' to build the software.

To load your U-boot onto the BD-SL-i.MX6, follow these steps:

The method in which U-boot is loaded is determined by the SW1 switch and are listed below. 0 = off, 1 = on, and the configurations are listed in the order of 'switch1, switch2'. The cardinal numbers for these switches can be found by markings surrounding SW1 on your board:

  • Fuses: 0,0
  • USB OTG: 0,1
  • Internal: 1,0

Image sabrelite_bootusb_scaled

Fuses causes the board to load U-boot from SPI-NOR, USB OTG allows the board to load U-boot over OTG, and Internal enters Serial download mode for the MFG Tool.

The orientation of the SW1 switch may vary based on your board revision. Try and find the '1' and '2' marks on the black plastic surrounding the switch in order to determine the ordering of the switches, as well as the 'down' or '0' side of each switch.

Connect the BD-SL-i.MX6 to your host via the USB OTG cable included with the hardware. You will see the hardware enumerate as (refer to host dmesg output):

new high speed USB device using ehci_hcd and address 111
New USB device found, idVendor=15a2, idProduct=0054
New USB device strings: Mfr=1, Product=2, SerialNumber=0
Product: SE Blank ARIK
Manufacturer: Freescale SemiConductor Inc
configuration #1 chosen from 1 choice

Once your Timesys Factory build has completed successfully, perform the following steps:

$ cd factory/build_armv7l-timesys-linux-gnueabi/toolchain/bin/
$ sudo ./imx_usb /path/to/bootloader/u-boot.imx

You will see output to console as follows:

parse mx6_usb_work.conf
15a2:0054(mx6_qsb) bConfigurationValue =1
Interface 0 claimed
report 1, wrote 16 bytes, err=0
report 3, read 5 bytes, err=0
read=56 78 78 56
../../images/bootloader/u-boot.bin
main dcd length 2f0
sub dcd length 2ec
dcd_ptr=0x2780042c

loading binary file(../../images/bootloader/u-boot.bin) to 27800000, skip=0, fsize=2b028 type=aa

«<176168, 176168 bytes»>
jumping to 0x27800400
j3 in err=0, last_trans=5  56 78 78 56
j4 in err=-7, last_trans=0  00 00 00 00

At the same time, you will see the BD-SL-i.MX6 loading the U-boot binary:

U-Boot 2013.01 (Apr 05 2013 - 08:15:54)

CPU:   Freescale i.MX 6 family 0.0V at 792 MHz
Temperature:   can't get valid data!
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 29333333Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 200000000Hz
usdhc2 clock  : 200000000Hz
usdhc3 clock  : 200000000Hz
usdhc4 clock  : 200000000Hz
nfc clock     : 24000000Hz
Board: MX6Q-SABRELITE:[ WDOG]
Boot Device: I2C
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1
JEDEC ID: 0xbf:0x25:0x41
Reading SPI NOR flash 0xc0000 [0x2000 bytes] -> ram 0x276009b8
SUCCESS

In:    serial
Out:   serial
Err:   serial
Net:   got MAC address from IIM: 00:19:b8:80:e5:3f
FEC0 [PRIME]
Hit any key to stop autoboot:  0
MX6Q SABRELITE U-Boot >

If you do not see a successful transfer of U-boot, confirm that switch SW1 is in the correct position.

Booting the Board

3.0 Kernel

Set Environment Variables

You must set a few environment variables in order to boot the board over TFTP and DHCP. This is done with the setenv and saveenv commands in U-Boot. On the target, set the following environment variables:
Variable Value
bootargs console=ttymxc1,115200 ip=dhcp root=/dev/nfs rw
bootcmd bootp\;bootm
loadaddr 10800000
If you are not using bootp to load the kernel, you must also specify the following values:
Variable Value
serverip 10.0.0.1
ipaddr 10.0.0.10
bootfile uImage
bootargs console=ttymxc1,115200 ip=${ipaddr} root=/dev/nfs rw nfsroot=${serverip}:/full/path/to/rfs
bootcmd tftp\;bootm 10800000
Example
> setenv bootargs console=ttymxc1,115200 ip=dhcp root=/dev/nfs rw
> setenv bootcmd bootp\;bootm
> setenv loadaddr 10800000
> saveenv

Load The Kernel

You can use bootp or tftp to load the kernel. Note that the DHCP server needs to be set up for bootp, and tftp is necessary for both. Example

> bootp
Speed: 100, full duplex
BOOTP broadcast 1
Using eTSEC1 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.10
Filename 'uImage'.
Load address: 10800000
Loading: #################################################################
         #################################################################
         ##################################################
done
Bytes transferred = 2632869 (282ca5 hex)

Boot the Kernel

The bootm command is used to boot the kernel. It loads the file that was previously uploaded using the bootp, dhcp, or tftp commands.

Example

> bootm
## Booting kernel from Legacy Image at 010800000 ...
   Image Name:   Linux-3.0-ts-armv7l
   Image Type:   Linux Kernel Image (gzip compressed)
   Data Size:    2632805 Bytes =  2.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

3.10 Kernel

Set Environment Variables

You must set a few environment variables in order to boot the board over TFTP and DHCP. This is done with the setenv and saveenv commands in U-Boot.

On the target, set the following environment variables:

Variable Value
bootargs console=ttymxc1,115200 ip=dhcp root=/dev/nfs rw
bootcmd bootp\;tftp 11000000 BD-SL-i.MX6.dtb\;bootm 10800000 - 11000000
loadaddr 10800000

If you are not using bootp to load the kernel, you must also specify the following values:

Variable Value
serverip 10.0.0.1
ipaddr 10.0.0.10
bootfile uImage
bootargs console=ttymxc1,115200 ip=${ipaddr} root=/dev/nfs rw nfsroot=${serverip}:/full/path/to/rfs
bootcmd tftp\;tftp 11000000 BD-SL-i.MX6.dtb\;bootm 10800000 - 11000000

Example

> setenv bootargs console=ttymxc1,115200 ip=dhcp root=/dev/nfs rw
> setenv bootcmd  bootp\;tftp 11000000 BD-SL-i.MX6.dtb\;bootm 10800000 - 11000000
> setenv loadaddr 10800000
> saveenv

Load The Kernel

You can use bootp or tftp to load the kernel. Note that the DHCP server needs to be set up for bootp, and tftp is necessary for both.

Example

> bootp
Speed: 100, full duplex
BOOTP broadcast 1
Using eTSEC1 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.10
Filename 'uImage'.
Load address: 10800000
Loading: #################################################################
         #################################################################
         ##################################################
done
Bytes transferred = 2632869 (282ca5 hex)

Load The Device Tree Blob

You can use tftp to load the device tree. The previous bootp command will have set up the interface for you.

Example

> tftp 11000000 BD-SL-i.MX6.dtb
Speed: 100, full duplex
Using eTSEC1 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.10
Filename 'BD-SL-i.MX6.dtb'.
Load address: 11000000
Loading: #
done
Bytes transferred = 13395 (3453 hex)

Boot the Kernel

The bootm command is used to boot the kernel. It loads the file that was previously uploaded using the bootp, dhcp, or tftp commands.

Example

> bootm 10800000 - 11000000
## Booting kernel from Legacy Image at 010800000 ...
   Image Name:   Linux-3.10-ts-armv7l
   Image Type:   Linux Kernel Image (gzip compressed)
   Data Size:    2632805 Bytes =  2.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0011000000
   Booting using the fdt blob at 0x11000000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007f9000, end 007ff452 ... OK

Booting via SD card for BD-SL-i.MX6 and flashing a new U-boot

Externally built U-boot and the BD-SL-i.MX6

Note: As explained in the "Preparing the Host" section "i.MX USB Programming Utility" currently, the BD-SL-i.MX6 is not capable of loading U-boot from SD-card without hardware modification or blowing fuses, and by default boots from SPI-NOR. As such, until you are prepared to flash SPI-NOR with a new U-boot, use the Factory built imx_usb tool to transfer your U-boot to the board and boot. You may select this in Desktop Factory under: Toolchain Configuration -> i.MX usb programming utility.

Preparing the SD Card

To install a new Timesys build of the bootloader onto the SD card, follow these directions:

Note: The following instructions will overwrite data on your SD card. Make sure to back up any valuable data before performing this operation.

  1. From the host, run:

    $ ls /dev/sd*

    Note which memory devices are currently connected to your computer. We will use this information to determine the SD Card device name.

  2. Connect your SD Card card to your host, via a SD Card slot, an SD card adapter, or a USB adapter.

  3. Determine the device name of the SD Card. This can be done using dmesg. In the following example, the device is /dev/sdb, which contains one partition sdb1.

    $ dmesg | tail
    [88050.184080] sd 4:0:0:0:[sdb] 1990656 512-byte hardware sectors:(1.01 GB/972 MiB)
    [88050.184821] sd 4:0:0:0:[sdb] Write Protect is off
    [88050.184824] sd 4:0:0:0:[sdb] Mode Sense: 03 00 00 00
    [88050.184827] sd 4:0:0:0:[sdb] Assuming drive cache: write through
    [88050.185575] sd 4:0:0:0:[sdb] 1990656 512-byte hardware sectors:(1.01 GB/972 MiB)
    [88050.186323] sd 4:0:0:0:[sdb] Write Protect is off
    [88050.186325] sd 4:0:0:0:[sdb] Mode Sense: 03 00 00 00
    [88050.186327] sd 4:0:0:0:[sdb] Assuming drive cache: write through
    [88050.186330]  sdb: sdb1

  4. Unmount all partitions on the SD Card. With root permissions, run:

    $ umount /dev/sdX*

    where /dev/sdX is the device name found in the previous step.

  5. Make a single parition SD card:

    $ sudo fdisk /dev/sdb

    Command (m for help): o
    Building a new DOS disklabel with disk identifier 0xa15334d2.
    Changes will remain in memory only, until you decide to write them.
    After that, of course, the previous content won't be recoverable.

    Create a new primary partition using the n command.

    Command (m for help): n
    Command action
       e   extended
       p   primary partition (1-4)
    p
    Partition number (1-4): 1
    First cylinder (1-1022, default 1):
    Using default value 1
    Last cylinder, +cylinders or +sizeK,M,G (1-1022, default 1022):
    Using default value 1022

    Verify that the partition table is correct by using the p command. It should look similar to the following:

    Command (m for help): p

    Disk /dev/sdb: 4023 MB, 4023386112 bytes
    124 heads, 62 sectors/track, 1022 cylinders
    Units = cylinders of 7688 * 512 = 3936256 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0xa15334d2

       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1               1        1022     3928537   83  Linux

    This step will destroy all data on the SD Card - Write the partition table to the card using the w command.

    Command (m for help): w
    The partition table has been altered!

    Calling ioctl() to re-read partition table.
    Syncing disks.

  6. Format the partition:

    $ sudo mkfs.ext4 -L RFS /dev/sdX1

  7. Explode the RFS tarball onto the SD card:

    $ cd /media/RFS/
    $ sudo tar -xf \
         /path/to/factory/factory/build_armv7l-timesys-linux-<libc>/images/rfs/rootfs.tar.gz

  8. Unmount the partition:

    $ sync
    $ cd /media/
    $ sudo umount RFS/

Remove the SD Card from your host, and slide it into the slot of your BD-SL-i.MX6. You should hear the card 'click' into place.

Booting from SD

Note:The following instructions require the kernel image to be included in your rootfs under /boot and named uImage. This is the default configuration for a Timesys Factory built rootfs.

The default U-boot environment includes two commands to boot a kernel and rootfs from SD, and update U-boot. This requires that the rootfs you are booting includes two pre-built scripts named 6x_bootscript and 6x_upgrade; Factory includes these by default as well.

To boot the board via script:

MX6Q SABRELITE U-Boot > printenv bootcmd_mmc
bootcmd=for dtype in sata mmc ; do for disk in 0 1 ; do $dtype dev $disk ;for fs in fat ext2 ; do $fsload $dtype $disk:1 10008000 /6x_bootscript&& source 10008000 ; done ; done ; done; setenv stdout serial,vga ; echo ; echo 6x_bootscript not found ; echo ; echo serial console at 115200, 8N1 ; echo ; echo details at http://boundarydevices.com/ 6q_bootscript ; setenv stdout serial
MX6Q SABRELITE U-Boot > run bootcmd_mmc

The above command looks for a functional MMC device, sets it, loads the 6x_bootscript and runs it, loading the kernel from the /boot directory of your SD card, and setting the appropriate bootargs to boot from SD.

If you prefer to do so manually, please follow the steps below:

In U-Boot, load the kernel from an ext2/ext3/ext4 formatted partition on your microSD card; this assumes mmc 1 as your microSD.

In the below example, dev corresponds to the mmc device, while part corresponds to the ext2/3 partition containing your rootfs. When setting the root= parameter, specify mmcblk0pY with Y referring to the partition of the microSD to which your root filesystem is loaded. Below, for example, we assume the RFS is loaded to partition 2 by using a root value of mmcblk0p2.

U-Boot > mmc dev 1
U-Boot > ext2load mmc dev:part 10800000 /boot/uImage
U-Boot > setenv bootargs console=ttymxc1,115200 root=/dev/mmcblk0p2 rootwait video=mxcfb0:dev=hdmi,1280x800M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-SVGA,if=RGB666
U-Boot > bootm

To save this as a bootcmd:

U-Boot > setenv mmc_init 'mmc dev 1'
U-Boot > setenv ext2_load 'ext2load mmc 1:${part} 10800000 /boot/uImage'
U-Boot > setenv bootargs_mmc 'setenv bootargs $bootargs root=/dev/mmcblk0p2 rw rootwait'
U-Boot > setenv bootcmd_mmc 'run mmc_init; run ext2_load; run bootargs_mmc; bootm'
U-Boot > setenv bootcmd 'run bootcmd_mmc'

Save your environment variables with saveenv and boot the board with boot.

Upgrading U-boot

The 6x_upgrade script allows you to easily upgrade U-boot; if you have customized your U-boot, please use the iMX USB Utility mentioned previously to test your U-boot before flashing.

The Factory build system includes the built u-boot.bin binary by default in the resulting rootfs. Provided you have deployed this rootfs to an ext2/ext3/ext4 formatted SD card, simply run the command detailed below:

U-Boot > printenv upgradeu
upgradeu=for dtype in sata mmc ; do for disk in 0 1 ; do $dtype dev $disk ;for fs in fat ext2 ; do $fsload $dtype $disk:1 10008000 /6x_upgrade && source 10008000 ; done ; done ; done

U-Boot > run upgradeu
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
No port device detected!
** Bad device size - sata 0 **
** Bad device size - sata 0 **

SATA device 1: unknown device
** Bad device sata 1 **
** Bad device sata 1 **
mmc0 is current device
** Unrecognized filesystem type **
1744 bytes read in 34 ms (49.8 KiB/s)
## Executing script at 10008000
check U-Boot
326956 bytes read in 112 ms (2.8 MiB/s)
read 0x4fd2c bytes from SD card
SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB
probed SPI ROM
byte at 0x12037754 (0x41) != byte at 0x12437754 (0x4d)
Total of 227156 byte(s) were the same
Need U-Boot upgrade
Program in 5 seconds
5
4
3
2
1
erasing
programming
verifying
Total of 326956 byte(s) were the same
-- U-Boot upgraded. reset

Reset the board, and your will boot the newly flashed U-boot.

Additional Information

Displays

The BD-SL-i.MX6 supports multiple display configurations. The displays are enabled on the kernel command line at boot time.

Configure each display with a video variable and a mxcfbx argument in your bootargs, replacing x is a 0 (primary) or 1 (secondary) to correspond to which display you wish to be primary:

  • 7" PRGB: video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB666
  • 7" LVDS: video=mxcfb0:dev=ldb,1024x600M@60,if=RGB666
  • HDMI: video=mxcfb0:dev=hdmi,1280x800M@60,if=RGB24
  • Hannstar: video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666

The BD-SL-i.MX6 sends a video signal to each output that has a video variable specified. Parameters following the mxcdfb argument specify the color and sizing of the attached display.

Typical values for dev= are:

  • LCD Interface: lcd
  • LVDS: ldb
  • HDMI on chip or sii902x: hdmi

Typical values for different display HW interface formats:

  • CLAA WVGA LCD: RGB565
  • HDMI: RGB24

For a full list of display formats, visit the build_armv7l-timesys-linux-<libc>/linux-3.0-ts-armv7l/drivers/video/mxc/ directory. Pay attention to these files:

  • tve.c: TV (Component) and VGA display formats. Do not reference vga.c for VGA.
  • ldb.c: LVDS display formats
  • mxcfb.c: generic display formats
  • Use grep in the directory for anything else

The following display(s) were tested by Timesys:

  • HDMI Display
  • 800x480 LCD panel

Multiple Displays

The board can support two display connections at a time. This is accomplished by providing a video variable for both mxcfb0 and mxcfb1 on the kernel command line. Typically, graphical applications will use the device marked as 'mxcfb0' as the primary display.

Example

HDMI (primary display), and LVDS Panel (secondary display)

video=mxcfb0:dev=hdmi,1280x800M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-SVGA,if=RGB666

Factory Documentation