i.MX_Linux_User's_Guide
1About This Book
This document explains how to build and install the Freescale Linux ? OS BSP, where BSP stands for Board Support Package, on the i.MX platform. It also covers special Freescale features and how to use them.
This document provides the steps to run the i.MX platform,including board DIP switch settings, and instructions on configuring and using the U-Boot bootloader.
The later chapters describe how to use some Freescale special features when running the Linux OS kernel.
Features covered in this guide may be specific to particular boards or SOCs. For the capabilities of a particular board or SOC, see the i.MX Linux ? Release Notes (IMXLXRN).
1.1Audience
This document is intended for software, hardware, and system engineers who are planning to use the product, and for anyone who wants to understand more about the product.
1.2Conventions
This document uses the following conventions:
User's Guide
Rev. L3.14.38_6ul-ga, 09/2015
i.MX Linux? User's Guide
? 2015 Freescale Semiconductor, Inc.
Contents
1About This Book....................................................12Introduction.............................................................33Basic Terminal Setup..............................................34Booting Linux OS...................................................45Enabling Solo Emulation......................................296Power Management...............................................297Multimedia...........................................................318Graphics.................................................................439Security.. (4510)
Connectivity (46)
?Courier New font: This font is used to identify commands, explicit command parameters, code examples,expressions, data types, and directives.
1.3Supported hardware SoCs and boards
These are the systems covered in this guide:?i.MX 6Quad SABRE-SD Board and Platform ?i.MX 6DualLite SABRE-SD Platform ?i.MX 6Quad SABRE-AI Platform ?i.MX 6DualLite SABRE-AI Platform ?i.MX 6SoloLite EVK
?i.MX 6SoloX SABRE-SD Platform ?i.MX 6SoloX SABRE-AI Platform ?i.MX 6QuadPlus SABRE-AI platform ?
i.MX 6UltraLite EVK platform
Some abbreviations are used in places in this document.
?SABRE-SD refers to the i.MX 6Quad SABRE-SD, i.MX 6DualLite SABRE-SD, and i.MX 7Dual SABRE-SD boards.?SABRE-AI refers to the i.MX 6Quad SABRE-AI, i.MX 6DualLite SABRE-AI, and i.MX 6QuadPlus SABRE-AI boards.
?SoloLite refers to the i.MX 6SoloLite Board.
?SoloX or SX refer to the i.MX 6SoloX SABRE-SD and SABRE-AI boards.?UL refers to the i.MX 6UltraLite board
1.4References
This release includes the following references and additional information.
?i.MX Linux ? Release Notes (IMXLXRN) - Provides the release information.
?i.MX Linux ? User's Guide (IMXLUG) - Contains the information on installing U-Boot and Linux OS and using i.MX-specific features.
?Freescale Yocto Project User's Guide (IMXLXYOCTOUG) - Contains the instructions for setting up and building Linux OS in the Yocto Project.
?i.MX Linux ? Reference Manual (IMXLXRM) - Contains the information on Linux drivers for i.MX.?i.MX 6 Graphics User's Guide (IMX6GRAPHICUG) - Describes the graphics used.
?i.MX BSP Porting Guide (IMXXBSPPG) - Contains the instructions on porting the BSP to a new board.
?i.MX VPU Application Programming Interface Linux ? Reference Manual (IMXVPUAPI) - Provides the reference information on the VPU API.
The quick start guides contain basic information on the board and setting it up. They are on the Freescale website.?SABRE Platform Quick Start Guide (IMX6QSDPQSG)?SABRE Board Quick Start Guide (IMX6QSDBQSG)
?SABRE Automotive Infotainment Quick Start Guide (IMX6SABREINFOQSG)?
i.MX 6SoloLite Evaluation Kit Quick Start Guide (IMX6SLEVKQSG)
Documentation is available online at https://www.sodocs.net/doc/a012591672.html, .
?i.MX 6 information is at https://www.sodocs.net/doc/a012591672.html,/iMX6series
?i.MX 6 SABRE information is at https://www.sodocs.net/doc/a012591672.html,/imxSABRE ?i.MX 6SoloLite EVK information is at
https://www.sodocs.net/doc/a012591672.html,/6SLEVK
?i.MX 7Dual information is at https://www.sodocs.net/doc/a012591672.html,/webapp/sps/site/prod_summary.jsp?code=i.MX7D
?i.MX 6UltraLite information is at https://www.sodocs.net/doc/a012591672.html,/webapp/sps/site/prod_summary.jsp?code=i.MX6UL .
2Introduction
The i.MX Linux BSP is a collection of binary files, source code, and support files that can be used to create a U-Boot
bootloader, a Linux kernel image, and a root file system for i.MX development systems. The Yocto Project is the framework of choice to build the images described in this document, although other methods can be used.
All the information on how to set up the Linux host machine, how to run and configure a Yocto Project, generate an image,and generate a rootfs, are covered in the Freescale Yocto Project User's Guide (IMXLXYOCTOUG).
When Linux OS is running, this guide provides information on how to use some special features that Freescale SoCs provide.The release notes provides the features that are supported on a particular board.
3Basic Terminal Setup
The i.MX boards can communicate with a host server (Windows ? OS or Linux OS) using a serial cable. Common serial
communication programs such as HyperTerminal, Tera Term, or PuTTY can be used. The example below describes the serial terminal setup using HyperTerminal on a Windows host.
The i.MX 6Quad/QuadPlus/DualLite SABRE-AI boards connect to the host server using a serial cable.
The i.MX 6 SABRE-SD, i.MX 6SoloLite EVK, i.MX 6SoloX SABRE-AI, i.MX 7Dual SABRE-SD, and i.MX 6UltraLite EVK boards connect the host driver using the micro USB connector. The USB to serial driver can be found under https://www.sodocs.net/doc/a012591672.html,/Drivers/VCP.htm .
1.Connect the target and the PC running Windows OS using a serial cable on i.MX 6 SABRE-AI boards or a micro-B USB cable on i.MX 6 SABRE boards.
2.
Open HyperTerminal on the PC running Windows OS and select the settings as shown in the following figure.
Figure 1. HyperTerminal settings for terminal setup
4Booting Linux OS
Before the Linux OS kernel can boot on an i.MX board, the images (U-Boot, Linux kernel, device tree, and rootfs) need to be copied to a boot device and the boot switches need to be set to boot that device. There are various ways that this can be done for different boards, boot devices, and results desired. This section explains how to prepare a boot device, giving some understanding of where files need to be in the memory map section, specifies switch settings for booting, and describes how to boot Linux OS from U-Boot.
4.1Software overview
This section describes the software needed for the board to be able to boot and run Linux OS. To boot a Linux image, four elements are needed:
?Bootloader (U-Boot)
?Linux kernel image (zImage)
? A device tree file (.dtb) for the board being used
? A root file system (rootfs) for the particular Linux image
The system can be configured for a specific graphical backend. The graphical backends are X11, Wayland, frame buffer, or direct frame buffer.
4.1.1Bootloader
U-Boot is the tool recommended as the bootloader. U-Boot must be loaded onto a device to be able to boot from it. U-Boot images are board-specific and can be configured to support booting from different sources.
The pre-built or Yocto Project default bootloader names start with the name of the bootloader followed by the name of the platform and board and followed by the name of the device that this image is configured to boot from: u-boot-[platform] [board]_[machine configuration].imx. If no boot device is specified, it boots from SD/MMC.
The manufacturing tool can be used to load U-Boot onto all devices. U-Boot can be loaded directly onto an SD card using the Linux dd command. U-Boot can be used to load a U-Boot image onto some other devices.
4.1.2Linux kernel image and device tree
This Freescale i.MX BSP contains a pre-built kernel image based on the 3.14.38 version of the Linux kernel and the device tree files associated with each platform.
The same kernel image is used for all the i.MX boards. Device trees are kernel configuration files that allow a common kernel to boot with different pin settings for different boards or configurations. Device tree files use the .dtb extension. The configuration for a device tree can be found in the Linux source code under arch/arm/boot/dts in the *.dts files.
The i.MX Linux delivery package contains pre-built device tree files for the i.MX boards in various configurations. The prebuilt images are named zImage--[kernel]-[platform]-[board]-[configuration].dtb.
The *ldo.dtb device trees are used for LDO-enabled feature support. By default, the LDO bypass is enabled. If your board has the CPU set to 1.2 GHZ, you should use the *ldo.dtb device tree instead of the default, because LDO bypass mode is not supported on the CPU at 1.2 GHZ. The device tree *hdcp.dtb is used to enable the DHCP feature because of a pin conflict, which requires this to be configured at build time.
4.1.3Root file system
The root file system package (or rootfs) provides busybox, common libraries, and other fundamental elements.
The i.MX BSP package contains several root file systems. The file system includes Freescale-specific libraries and common Linux utilites. They are named with the following convention: [image recipe]-[backend]-[platform][board].[ext3|sdcard]. The ext3 extension indicates a standard file system. It can be mounted as NFS, or its contents can be stored on a boot media such as an SD/MMC card.
The graphical backend to be used is also defined by the rootfs.
4.2Manufacturing tool
The manufacturing tool, named MFGTool, is a tool that runs on a computer and is used to download images to different devices on an i.MX board. The tar.gz file can be found with the pre-built images.
4.2.1Configuring MFGTool
Unzip Mfgtools-Rel-[version]_UPDATER.tar.gz.
Instructions for MFGTool V2 can be found in the file Profiles/[SOC] Linux Update/OS Firmware/ucl2.xml . Read and update the ucl2.xml file to understand the operations before using MFGTool.
It is important to correctly configure the cfg.ini and UICfg.ini files. For example, if only one board is supported,PortMgrDlg=1 should be set in UICfg.ini . If four boards are supported, PortMgrDlg=4 should be set. Incorrect configuration causes MFGTool to malfunction.
NOTE
For i.MX 6SoloX, the default settings in the cfg.ini file need to be changed as follows.MFGTool looks for the settings in the ucl2.xml file.
[profiles]chip = Linux [platform]
board = SabreSD [LIST]
name = SDCard [variable]
board = sabresd mmc = 0
sxuboot=17x17arm2sxdtb=17x17-arm2ldo=
4.2.2Using MFGTool
Follow these instructions to use the MFGTool V2:
1.Connect a USB cable from a computer to the USB OTG port on the board.
2.
Connect a USB cable from the OTG-to-UART port to the computer for console output.
3.Open a Terminal emulator program. See Section "Basic Terminal Setup" in this guide.
4.Set the boot pin to Mfgtool mode. See Section "Serial download mode for the Manufacturing Tool" in this guide.
5.Choose the correct .vs file and double-click it to launch MFGTool host tool.
6.The default profile of the manufacturing tool assumes that your file system is packed and compressed using the bzip2
algorithm. An example can be found in the MFGTool release package in the folder Profiles\[SOC] Linux Update \OS Firmware\files. To create this file, run the following commands as a root user on Linux OS. You can also
modify the profile to support other formats.
Figure 2. Programming SD with the manufacturing tool – image downloading
NOTE
The manufacturing tool may sometimes report an error message when it is
downloading the file system to an SD card. This can be caused by insufficient
space on the SD card due to a small partition size. To fix this, unzip the file
Profiles\Linux\OS Firmware\mksdcard.sh.tar and modify the script to
increase the size of the partition and create more partitions according to your file
system requirements. After the modification is done, tar the script again.
4.3Preparing an SD/MMC card to boot
This section describes the steps to prepare an SD/MMC card to boot up an i.MX board using a Linux host machine. These instructions apply to SD and MMC cards although for brevity, often only SD card is listed.
For a Linux image to be able to run, four separate pieces are needed: the Linux kernel image (zImage), the device tree file (*.dtb), the U-Boot boot loader image, and the root file system (*.ext3 or *.ext4).
A .sdcard image contains all four images properly configured for an SD card. The release contains a pre-built .sdcard image that is built specifically for the i.MX 6QuadPlus SABRE-AI board. It runs the X11 graphical backend. It does not run on other boards unless U-Boot, the device tree, and rootfs are changed.
The Yocto Project build creates an SD card image that can be flashed directly. This is the simplest way to load everything needed onto the card with one command.
When more flexibility is desired, the individual components can be loaded separately, and those instructions are included
here as well. An SD card can be loaded with the individual components one-by-one or the .sdcard image can be loaded and
the individual parts can be overwritten with the specific components.
The rootfs on the default .sdcard image is limited to a bit less than 4 GB, but re-partitioning and re-loading the rootfs can increase that to the size of the card. The rootfs can also be changed to specify the graphical backend that is used.
The device tree file (.dtb) contains board and configuration-specific changes to the kernel. Change the device tree file to change the kernel for a different i.MX board or configuration.
By default, the release uses the following layout for the images on the SD card. The kernel image and DTB move to use the FAT partition without a fixed raw address on the SD card. The users have to change the U-Boot boot environment if the fixed raw address is required.
4.3.1Preparing the card
An SD/MMC card reader, such as a USB card reader, is required. It is used to transfer the bootloader and kernel images to initialize the partition table and copy the root file system. To simplify the instructions, it is assumed that a 4GB SD/MMC card is used.
Any Linux distribution can be used for the following procedure.
The Linux kernel running on the Linux host assigns a device node to the SD/MMC card reader. The kernel might decide the device node name or udev rules might be used. In the following instructions, it is assumed that udev is not used.
To identify the device node assigned to the SD/MMC card, carry out the following command:
$ cat /proc/partitions
major minor #blocks name
8 0 78125000 sda
8 1 75095811 sda1
8 2 1 sda2
8 5 3028221 sda5
8 32 488386584 sdc
8 33 488386552 sdc1
8 16 3921920 sdb
8 18 3905535 sdb1
In this example, the device node assigned is /dev/sdb (a block is 512 Bytes).
NOTE
Make sure that the device node is correct for the SD/MMC card. Otherwise, it may
damage your operating system or data on your computer.
4.3.2Copying the full SD card image
The SD card image (with the extension .sdcard) contains U-Boot, the Linux image and device trees, and the rootfs for a 4 GB SD card. The image can be installed on the SD card with one command if flexibility is not required.
Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card.
$ sudo dd if=<.sdcard image> of=/dev/sdx bs=1M conv=fsync
The entire contents of the SD card are replaced. If the SD card is larger than 4 GB, the additional space is not accessible.
4.3.3Partitioning the SD/MMC card
The full SD card image already contains partitions. This section describes how to set up the partitions manually. This needs to be done to individually load the bootloader, kernel, and rootfs.
There are various ways to partition an SD card. Essentially, the bootloader image needs to be at the beginning of the card. Followed by the Linux image and the device tree file. These can either be in a partition or not. The root file system does need to be in a partition that starts after the Linux section. Make sure that each section has enough space. The example below creates two partitions.
On most Linux host operating systems, the SD card is mounted automatically upon insertion. Therefore, before running fdisk, make sure that the SD card is unmounted if it was previously mounted (through sudo umount /dev/sdx).
Start by running fdisk with root permissions. Use the instructions above to determine the card ID. We are using sdx here as an example.
$ sudo fdisk /dev/sdx
Type the following parameters (each followed by
p [lists the current partitions]
d [to delet
e existing partitions. Repeat this until no unnecessary partitions
are reported by the 'p' command to start fresh.]
u [switch the unit to sectors instead of cylinders]
n [create a new partition]
p [create a primary partition - use for both partitions]
1 [the first partition]
20480 [starting at offset sector]
1024000 [size for the first partition to be used for the boot images]
p [to check the partitions]
n
p
2
1228800 [starting at offset sector, which leaves enough space for the kernel,
the bootloader and its configuration data]
the last sector of the media]
p [to check the partitions]
w [this writes the partition table to the media and fdisk exits]
4.3.4Copying a bootloader image
This section describes how to load only the boot loader image, when the full SD card image is not used. Carry out the following command to copy the U-Boot image to the SD/MMC card.
$ sudo dd if=
The first 1 KB of the SD/MMC card, which includes the partition table, is preserved.
4.3.5Copying the kernel image and DTB file
This section describes how to load the kernel image and DTB when the full SD card image is not used. The pre-built SD card image uses the VFAT partition for storing kernel image and DTB, which requires a VFAT partition that is mounted as a Linux drive and the files are simply copied into it. This is the preferred method.
Another method that can be used is for users to put the kernel image and DTB to the fixed raw address of the SD card by using the dd command. The later method needs to modify the U-Boot default environment variables for loading the kernel image and DTB.
Default: VFAT partition
1.Format partition 1 on the card as VFAT with this command:
$ sudo mkfs.vfat /dev/sdx1
2.Mount the formatted partition with this command:
$ mkdir mountpoint
$ sudo mount /dev/sdx1 mountpoint
3.Copy the zImage and *.dtb files to the mountpoint by using cp . The device tree names should match the mount point specified by U-Boot. Be sure to un-mount the partition with this command:
$ sudo umount mountpoint
Alternative: Fixed raw address
The following command can be used to copy the kernel image to the SD/MMC card:
$ sudo dd if=zImage_imx_v7_defconfig of=/dev/sdx bs=512 seek=2048 conv=fsync
This copies zImage to the media at offset 1 MB (bs x seek = 512 x 2048 = 1 MB).
The i.MX DTB image can be copied by using the copy command and copying the file to the 2nd partition or the following commands copy an i.MX DTB image to the SD/MMC card by using dd . Choose the command for your board:
$ sudo dd if=zImage-imx6qp-sabreauto.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync $ sudo dd if=zImage-imx6q-sabreauto.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync $ sudo dd if=zImage-imx6q-sabresd.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync $ sudo dd if=zImage-imx6sl-evk.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync $ sudo dd if=zImage-imx7d-sdb.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync
This copies the board-specific .dtb file to the media at offset 10 MB (bs x seek = 512 x 20480 = 10 MB).The following command can be used to copy the kernel image to the i.MX 6UltraLite EVK board:
$ sudo dd if=zImage-imx6ul-14x14-evk.dtb of=/dev/sdx bs=512 seek=20480 conv=fsync
4.3.6Copying the root file system (rootfs)
This section describes how to just load the rootfs image when the full SD card image is not used.
Copy the target file system to a partition that only contains the rootfs. This example uses partition 2 for the rootfs. First format the partition. The file system format ext3 or ext4 is a good option for the removable media due to the built-in journaling. Replace sdx with the partition in use in your configuration.
$ sudo mkfs.ext3 /dev/sdx2Or
$ sudo mkfs.ext4 /dev/sdx2
Copy the target file system to the partition:
$ mkdir /home/user/mountpoint
$ sudo mount /dev/sdx2 /home/user/mountpoint
Extract a rootfs package to a directory: extract fsl-image-gui-imx6qpsabreauto.ext3 to /home/user/rootfs for example:
$ sudo mount -o loop -t ext3 fsl-image-gui-imx6qpsabreauto.ext3/home/user/rootfs
The rootfs directory needs to be created manually.
Assume that the root file system files are located in /home/user/rootfs as in the previous step:
$ cd /home/user/rootfs
$ sudo cp -a * /home/user/mountpoint $ sudo umount /home/user/mountpoint $ sudo umount /home/user/rootfs $ sync
NOTE
Copying the file system takes several minutes depending on the size of your rootfs.
The file system content is now on the media.
4.4Downloading images
Images can be downloaded to a device using a U-Boot image that is already loaded on the boot device or by using the manufacturing tool, MFGTool. Use a terminal program to communicate with the i.MX boards.
4.4.1Downloading images using U-Boot
The following sections describe how to download images using the U-Boot bootloader.
The commands described below are generally useful when using U-Boot. Additional commands and information can be found by typing help at the U-Boot prompt.
The U-Boot print command can be used to check environment variable values.The setenv command can be used to set environment variable values.
4.4.1.1Downloading an image to MMC/SD
This section describes how to download U-Boot to an MMC/SD card that is not the one used to boot from.
Insert an MMC/SD card into the SD card slot. This is slot SD3 on i.MX 6 SABRE boards and SD1 on i.MX 6SoloLite boards, SD2 on i.MX 6UltraLite EVK board and SD1 on i.MX 7Dual SABRE-SD board.To flash the original U-Boot, see Preparing an SD/MMC card to boot .
The U-Boot bootloader is able to download images from a TFTP server into RAM and to write from RAM to an SD card. For this operation, the Ethernet interface is used and U-Boot environment variables are initialized for network communications.The boot media contains U-Boot, which is executed upon power-on. Press any key before the value of the U-Boot
environment variable, "bootdelay", decreases and before it times out. The default setting is 1 second to display the U-Boot prompt.
1.To clean up the environment variables stored on MMC/SD to their defaults, carry out the following command in the U-Boot console:
U-Boot > env default -f -a U-Boot > save
U-Boot > reset
2.Configure the U-Boot environment for network communications. The folllowing is an example. The lines preceded by the "#" character are comments and have no effect.
U-Boot > setenv serverip
U-Boot > setenv bootfile
The user can set a fake MAC address through ethaddr enviroment if the MAC address is not fused.
U-Boot > setenv ethaddr 00:01:02:03:04:05U-Boot > save
3.Copy zImage to the TFTP server. Then download it to RAM:
U-Boot > dhcp
4.Query the information about the MMC/SD card.
U-Boot > mmc dev U-Boot > mmcinfo
5.Check the usage of the "mmc" command. The "blk#" is equal to "
U-Boot > help mmc mmc - MMC sub system
Usage:
mmc read addr blk# cnt mmc write addr blk# cnt mmc erase blk# cnt mmc rescan
mmc part - lists available partition on current mmc device
mmc dev [dev] [part] - show or set current mmc device [partition]mmc list - lists available devices
6.Program the kernel zImage located in RAM at ${loadaddr} into the SD card. For example, the command to write the image with the size 0x800000 from ${loadaddr} to the offset of 0x100000 of the microSD card. See the following examples for the definition of the mmc parameters.
blk# = (microSD Offset)/(SD block length) = 0x100000/0x200 = 0x800cnt = (image Size)/(SD block length) = 0x800000/0x200 = 0x4000
This example assumes that the kernel image is equal to 0x800000. If the kernel image exceeds 0x800000, increase the image length. After issuing the TFTP command, filesize U-Boot environment variable is set with the number of bytes transferred. This can be checked to determine the correct size needed for the calculation. Use the U-Boot command printenv to see the value.
U-Boot > mmc dev 2 0
U-Boot > tftpboot ${loadaddr} ${bootfile}
### Suppose the kernel zImage is less than 8M.U-Boot > mmc write ${loadaddr} 0x800 0x4000
7.Program the dtb file located in RAM at ${fdt_addr} into the microSD.
U-Boot > tftpboot ${fdt_addr} ${fdt_file}U-Boot > mmc write ${fdt_addr} 0x5000 0x800
8.On i.MX 6 SABRE boards, you can boot the system through the rootfs in the SD card by the HannStar LVDS. The kernel MMC module now uses a fixed mmcblk index for the uSDHC slot. The SD3 slot uses mmcblk2 on i.MX 6SABRE boards, the SD1 slot uses mmcblk0 on the i.MX 7Dual SABRE-SD board, and the SD2 slot uses mmcblk1 on the i.MX 6UltraLite board.9.Boot the board.
U-Boot >setenv bootcmd_mmc 'run bootargs_base mmcargs;mmc dev;mmc
read ${loadaddr} 0x800 0x4000;mmc read ${fdt_addr} 0x5000 0x800;bootz ${loadaddr} - $
{fdt_addr}'
U-Boot > setenv bootcmd 'run bootcmd_mmc'
U-Boot > saveenv
4.4.1.2Using eMMC
There is an eMMC chip on i.MX SABRE boards. It is accessed through SDHC4 on i.MX 6 SABRE boards or SDHC3 on
i.MX 7Dual SABRE-SD board. The following steps describe how to use this memory device.
1.Carry out the following command on the U-Boot console to clean up the environments stored on eMMC:
U-Boot > env default -f -a
U-Boot > save
U-Boot > reset
2.Configure the boot pin. Power on the board and set the U-Boot environment variables as required. For example,
U-Boot > setenv serverip
U-Boot > setenv bootfile
U-Boot > setenv fdt_file
### The user can set fake MAC address via ethaddr enviroment if the MAC address is not fused
U-Boot > setenv ethaddr 00:01:02:03:04:05
U-Boot > save
3.Copy zImage to the TFTP server. Then download it to RAM:
U-Boot > dhcp
4.Query the information about the eMMC chip.
U-Boot > mmc dev
U-Boot > mmcinfo
5.Check the usage of the "mmc" command. "blk#" is equal to "
"cnt" is equal to "
mmc read addr blk# cnt
mmc write addr blk# cnt
mmc erase blk# cnt
mmc rescan
mmc part - lists available partition on current mmc device
mmc dev [dev] [part] - show or set current mmc device [partition]
mmc list - lists available devices
6.Program the kernel zImage into eMMC. For example, the command below writes the image with the size 0x800000
from ${loadaddr} to the offset 0x100000 of the eMMC chip. Here, the following equations are used: 0x800
=0x100000/0x200, 0x4000=0x800000/0x200. The block size of this card is 0x200. This example assumes that the kernel image is less than 0x800000 bytes. If the kernel image exceeds 0x800000, enlarge the image length.
### Select mmc dev 2 (USDHC4) on the i.MX 6 SABRESD board:
U-Boot > mmc dev 2 0
### Select mmc dev 1 (USDHC3) on the i.MX 7Dual SABRESD board:
U-Boot > mmc dev 1 0
### Select mmc dev 1 (USDHC2) on the i.MX 6UltraLite EVK board:
U-Boot > mmc dev 1 0
### Suppose kernel zImage is less than 8 MB:
U-Boot > tftpboot ${loadaddr} ${bootfile}
U-Boot > mmc write ${loadaddr} 0x800 0x4000
7.Program the dtb file located in RAM at ${fdt_addr} into the eMMC chip.
U-Boot > tftpboot ${fdt_addr} ${fdt_file}
U-Boot > mmc write ${fdt_addr} 0x5000 0x800
8.Boot up the system through RFS in eMMC by HannStar LVDS. The kernel MMC module now uses the fixed mmcblk
indices for the USDHC slots. The eMMC/SD4 slot in i.MX 6 SABRE boards is mmcblk3. The eMMC5.0/SD3 slot on
the i.MX 7Dual SABRE board is mmcblk2.
U-Boot > setenv mmcboot 'run bootargs_base mmcargs; mmc dev 2;
mmc read ${loadaddr} 0x800 0x4000; mmc read ${fdt_addr} 0x5000 0x800;bootz ${loadaddr} - ${fdt_addr} '
U-Boot > setenv bootcmd 'run mmcboot'U-Boot > saveenv
9.Boot up the system through RFS in eMMC by the CLAA WVGA panel:
?For i.MX 6 boards:
U-Boot > setenv mmcargs 'setenv bootargs ${bootargs}
root=/dev/mmcblk3p2 rootwait rw video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565 ip=dhcp'
?For i.MX 7Dual SABRE boards:
U-Boot > setenv mmcargs 'setenv bootargs ${bootargs}
root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565 ip=dhcp'
10.Boot up the system through RFS in eMMC by HDMI:
?For i.MX 6 boards:
U-Boot > setenv mmcargs 'setenv bootargs ${bootargs} root=/dev/mmcblk3p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24'
?For i.MX 7Dual SABRE boards:
U-Boot > setenv mmcargs 'setenv bootargs ${bootargs} root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24'
To program the rootfs to MMC/SD, see Using an i.MX board as the host server to create a rootfs or Preparing an SD/MMC card to boot .
4.4.1.3Flashing U-Boot on SPI-NOR from U-Boot
Flashing directly to SPI-NOR with TFTPBoot is limited to i.MX 6 SABRE-AI boards. To flash U-Boot on SPI-NOR,perform the following steps:
1.Boot from an SD card.
2.Set Jumper J3 to position: 2-
3.
3.Fetch the U-Boot image with built-in SPI-NOR support. This example uses u-boot.imx .
----------------tftpboot ${loadaddr} u-boot.imx -----------------
4.Flash the U-Boot image in SPI-NOR.
-----------------sf probe
sf erase 0 0x80000
sf write ${loadaddr} 0x400 0x7FC00----------------
5.Set boot switches to boot from SPI-NOR on SABRE-AI.
?S2-1 1?S2-2 1?S2-3 0?S2-4 0
?S1-[1:10] X
6.
Reboot the target board.
4.4.1.4Flashing U-Boot on Parallel NOR from U-Boot
Flashing directly to Parallel NOR with TFTPBoot is limited to i.MX 6 SABRE-AI boards. To flash U-Boot on Parallel NOR,perform the following steps:1.Boot from an SD card.2.TFTP the U-Boot image.
tftpboot ${loadaddr} u-boot.imx
3.Flash the U-Boot image.
cp.b ${loadaddr} 0x1000 ${filesize}
4.Change boot switches and reboot.
S2 all 0
S1-6 1 others 0
5.By default, rootfs is mounted on NFS.
4.4.1.5
Flashing an ARM ? Cortex ?-M4 image on QuadSPI
i.MX 6SoloX SABRE-SD and SABRE-AI boards have an ARM Cortex-M4 processor and QuadSPI memory that can be used to flash an image to it.
U-Boot has a default script to flash the ARM Cortex-M4 image from the SD card VFAT partition. To execute the script,perform the following steps:
1.Copy the ARM Cortex-M4 image to the first VFAT partition of the boot SD card. Name the file to “m4_qspi.bin”.
2.Boot from the SD card.
3.Flash the ARM Cortex-M4 image from the SD card to the NOR flash on QuadSPI2 PortB CS0 on the i.MX 6SoloX SABRE-SD board or QuadSPI1 PortB CS0 on the i.MX 6SoloX SABRE-AI board.
----------------run update_m4_from_sd -----------------
Alternatively, users can flash the ARM Cortex-M4 image from TFTP by performing the following steps:1.Boot from the SD card.
2.TFTP the ARM Cortex-M4 image.
-----------------tftp ${loadaddr} m4_qspi.bin ----------------
3.Select the NOR flash on QuadSPI2 PortB CS0 on the i.MX 6SoloX SABRE-SD board or QuadSPI1 PortB CS0 on the i.MX 6SoloX SABRE-AI board.
-----------------sf probe 1:0
----------------
4.Flash the ARM Cortex-M4 image to the selected NOR flash. The erase size is ${filesize}, around 64 Kbytes. This example assumes that it is 128 Kbytes.
-----------------sf erase 0x0 0x20000
sf write ${loadaddr} 0x0 ${filesize}
----------------
4.4.2Using an i.MX board as the host server to create a rootfs
Linux OS provides multiple methods to program images to the storage device. This section describes how to use the i.MX platform as a Linux host server to create the rootfs on an MMC/SD card or the SATA device. The following example is for an SD card. The device file node name needs to be changed for a SATA device.
1.Boot from NFS or other storage. Determine your SD card device ID. It could be mmcblk* or sd*. (The index is determined by the USDHC controller index.) Check the partition information with the command:
$ cat /proc/partitions
2.To create a partition on the MMC/SD card, use the fdisk command (requires root privileges) in the Linux console:
root@freescale ~$ sudo fdisk /dev/$SD
Replace $SD above with the name of your device.
3.If this is a new SD card, you may get the following message:
The device contains neither a valid DOS partition table, nor Sun, SGI or OSF disk label Building a new DOS disklabel. Changes will remain in memory only,until you decide to write them. After that the previous content won't be recoverable.
The number of cylinders for this disk is set to 124368.
There is nothing wrong with that, but this is larger than 1024,and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
The usual prompt and commands to partition the card are as follows. Text in boldface indicates what the user types.
Command (m for help): p
Disk /dev/sdd: 3965 MB, 3965190144 bytes
4 heads, 32 sectors/track, 60504 cylinders, total 7744512 sectors Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00080bff
Device Boot Start End Blocks Id System
4.As described in Flash memory maps , the rootfs partition should be located after the kernel image. The first 0x800000bytes can be reserved for MBR, bootloader, and kernel sections. From the log shown above, the Units of the current MMC/SD card is 32768 bytes. The beginning cylinder of the first partition can be set to "0x300000/32768 = 96." The last cylinder can be set according to the rootfs size. Create a new partition by typing the letters in bold:
Command (m for help): n e extended
p primary partition (1-4) Select (default p): p
Partition number (1-4): 1
First cylinder (1-124368, default 1): 96
Last cylinder or +size or +sizeM or +sizeK (96-124368, default 124368): Using default value 124368
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read $SD partition table
5.Check the partitions (see above) to determine the name of the partition. $PARTITION is used here to indicate the partition to be formatted. Format the MMC/SD partitions as ext3 or ext4 type. For example, to use ext3:
root@freescale ~$ mkfs.ext3 /dev/$PARTITION mke2fs 1.42 (29-Nov-2011)Filesystem label=OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
248992 inodes, 994184 blocks
49709 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1019215872
31 block groups
32768 blocks per group, 32768 fragments per group
8032 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
6.Copy the rootfs contents to the MMC/SD card. The name may vary from the one used below. Check the directory for
the rootfs desired. (Copy the *.ext2 to NFS rootfs).
mkdir /mnt/tmpmnt
mount -t ext3 -o loop /fsl-image-gui-imx6qsabresd.ext3 /mnt/tmpmnt
cd /mnt
mkdir mmcblk0p1
mount -t ext3 /dev/$PARTITION /mnt/mmcblk0p1
cp -af /mnt/tmpmnt/* /mnt/mmcblk0p1/
umount /mnt/mmcblk0p1
umount /mnt/tmpmnt
7.Type sync to write the contents to MMC/SD.
8.Type poweroff to power down the system. Follow the instructions in Running Linux OS on the target to boot the image
from the MMC/SD card.
NOTE
By default, v2013.04 and later versions of U-Boot support loading the kernel image and
DTB file from the SD/MMC vfat partition by using the fatload command. To use this
feature, perform the following steps:
1.Format the first partition (for example 32M) of the SD/MMC card with vfat
filesystem.
2.Copy zImage and the DTB file into the VFAT partition after you mount the VFAT
partition into your host computer.
3.Make sure that the zImage and DTB file name are synchronized with the file name
pointed to by the U-Boot environment variables: fdt_file and image. Use the print
command under U-Boot to display these two environment variables. For example:
print fdt_file image
4.U-Boot loads the kernel image and the DTB file from your VFAT partition
automatically when you boot from the SD/MMC card.
4.5How to boot the i.MX boards
When U-Boot is loaded onto one of the devices that support booting, the DIP switches can be used to boot from that device. The boot modes of the i.MX boards are controlled by the boot configuration DIP switches on the board. For help locating the boot configuration switches, see the quick start guide for the specific board as listed under References above.
The following sections list basic boot setup configurations. The tables below represent the DIP switch settings for the switch
blocks on the specified boards. An X means that particular switch setting does not affect this action.
4.5.1Booting from an SD card in slot SD1
The following table shows the DIP switch settings for booting from the SD card slot labeled SD1 on the i.MX 7Dual SABRE-SD boards.
4.5.2Booting from an SD card in slot SD2
The SD card slot that is labeled SD2 indicates that this slot is connected to the uSDHC pin SD2 on the processor. Most boards label this slot as SD2. This slot is referred to as SD2 in this document.
i.MX 6 SABRE-SD boards
The following table shows the DIP switch settings for booting from the SD card slot labeled SD2 and J500 on the i.MX 6 SABRE-SD boards. The SD2 card slot is located beside the LVDS1 connection on the back of the board.
i.MX 6SoloLite boards
The i.MX 6SoloLite boards have three SD card slots on the main board. The one on the end is labeled as the SD2 slot. The following table shows the DIP switch settings for booting from SD2.
The i.MX 6UltraLite EVK board has one TF card slot on the CPU board. This slot uses the USDHC2 controller. The following table shows the DIP switch settings for booting from the TF slot.
4.5.3Booting from an SD card in slot SD3
The SD card slot that is labeled SD3 indicates that this slot is connected to the uSDHC pin SD3 on the processor. Most boards label this slot as SD3. This slot is referred to as SD3 in this document.
i.MX 6 SABRE-AI boards
The following table shows the DIP switch settings to boot from an SD card in slot SD3 on i.MX 6 SABRE-AI boards.
i.MX 6SoloX SABRE-AI boards
The following table shows the DIP switch settings to boot from an SD card in slot SD3 on i.MX 6SoloX SABRE-AI boards.
i.MX 6 SABRE-SD boards
The following table shows the DIP switch settings for booting from SD3, also labeled as J507. The SD3 slot is located between the HDMI and UART ports.
4.5.4Booting from an SD card in slot SD4
The following table describes the dip switch settings for booting from an SD card in slot SD4.
The SD4 slot is on the center of the edge of the SoloX board.
4.5.5Booting from eMMC
eMMC 4.4 is a chip permanently attached to the board that uses the SD4 pin connections from the i.MX 6 processor. For more information on switch settings, see table "MMC/eMMC Boot Fusemap" in the IC reference manual.
The i.MX 6SoloLite EVK requires a daughter card with the eMMC chip mounted on it. The following table shows the boot switch settings to boot from eMMC4.4 on i.MX 6SoloLite EVK.
The following table shows the boot switch settings to boot from eMMC4.4 (SDIN5C2-8G) on i.MX 6 SABRE-SD boards.
4.5.6Booting from SATA
The following switch settings enable booting from SATA.
SATA booting is supported only by the i.MX 6Quad SABRE boards.
4.5.7Booting from NAND
The following table shows the DIP switch settings needed to boot from NAND on i.MX 6 SABRE-AI boards.
The following table shows the DIP switch settings needed to boot from NAND for i.MX 6SoloX SABRE-AI boards.
4.5.8Booting from SPI-NOR
Enable booting from SPI NOR on i.MX 6 SABRE-AI boards by placing a jumper on J3 between pins 2 and 3.
4.5.9Booting from EIM (Parallel) NOR
The following table shows the DIP switch settings to boot from NOR.