i.MX BSP Porting Guide
i.MX BSP Porting Guide
Document Number: IMXBSPPG
Rev. 1, 01/2017
i.MX BSP Porting Guide, Rev. 1, 01/2017
2
NXP Semiconductors
Contents
Section number
Title
Page
Chapter 1
Porting U-Boot from an i.MX 6/7 Reference Board to an i.MX 6/7 Custom Board
1.1
U-Boot Overview............................................................................................................................................................7
1.2
Obtaining the Source Code for the U-Boot.....................................................................................................................7
1.2.1 Preparing the Code...............................................................................................................................................8
1.3
Customizing the i.MX 6 or i.MX 7 Custom Board Code............................................................................................... 11
1.3.1 Changing the DCD Table for i.MX DDR3, LPDDR2, LPDDR3 Initialization.................................................. 11
1.3.2 Booting with the Modified U-Boot ..................................................................................................................... 12
1.3.3 Adding New Driver Initialization Code to Board Files....................................................................................... 13
1.3.4 Further Customization at System Boot................................................................................................................ 13
1.3.5 Customizing the Printed Board Name................................................................................................................. 14
1.4
Debugging.......................................................................................................................................................................14
1.4.1 Using JTAG Tool for Debugging........................................................................................................................ 14
1.4.2 Using printf for debugging...................................................................................................................................15
Chapter 2
Configuring the IOMUX Controller
2.1
IOMUX Overview.......................................................................................................................................................... 17
2.2
Information for Setting IOMUX Controller Registers....................................................................................................18
2.3
Using IOMUX in the Device Tree - Example................................................................................................................ 19
Chapter 3
Registering a New UART Driver
3.1
Enabling UART on Kernel Menuconfig.........................................................................................................................21
3.2
UART Settings................................................................................................................................................................21
3.3
File Names and Locations...............................................................................................................................................21
Chapter 4
Adding Support for SDHC
4.1
SDHC Overview............................................................................................................................................................. 23
Chapter 5
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
3
Section number
Title
Page
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver
5.1
SPI NOR Overview.........................................................................................................................................................25
5.2
Source Code Structure.................................................................................................................................................... 25
5.2.1 Configuration Options..........................................................................................................................................25
5.2.2 Selecting SPI NOR on the Linux Image.............................................................................................................. 26
5.3
Changing the SPI Interface Configuration......................................................................................................................26
5.4
Hardware Operation........................................................................................................................................................26
5.4.1 Software Operation.............................................................................................................................................. 27
Chapter 6
Connecting an LVDS Panel to an i.MX 6Dual/6Quad/6Solo/6DualLite Reference Board
6.1
LVDS Overview............................................................................................................................................................. 29
6.1.1 Connecting an LVDS Panel to the i.MX 6Dual/6Quad/6DualLite Reference Board..........................................29
6.2
Enabling an LVDS Channel............................................................................................................................................29
6.2.1 Locating Menu Configuration Options ............................................................................................................... 30
6.3
LDB Ports....................................................................................................................................................................... 30
6.3.1 Input Parallel Display Ports................................................................................................................................. 31
6.3.2 Output LVDS Ports.............................................................................................................................................. 32
6.4
Additional Information................................................................................................................................................... 32
Chapter 7
Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
7.1
CSI Overview..................................................................................................................................................................35
7.1.1 Required Software ...............................................................................................................................................35
7.1.2 i.MX 6Dual/6Quad/6Solo/6DualLite CSI Interfaces Layout.............................................................................. 36
7.1.3 Configuring the CSI Unit in Test Mode...............................................................................................................36
7.2
Adding Support for a New CMOS Camera Sensor........................................................................................................ 37
7.2.1 Adding a Camera Sensor Entry in Kconfig......................................................................................................... 37
7.2.2 Creating the Camera Sensor File......................................................................................................................... 38
7.2.3 Adding a Compilation Flag for the New Camera................................................................................................ 40
7.3
Using the I2C Interface...................................................................................................................................................41
7.3.1 Loading and Testing the Camera Module............................................................................................................43
i.MX BSP Porting Guide, Rev. 1, 01/2017
4
NXP Semiconductors
Section number
7.4
Title
Page
Additional Reference Information.................................................................................................................................. 43
7.4.1 CMOS Interfaces Supported by the i.MX 6Dual/6Quad/6Solo/6DualLite......................................................... 43
7.4.2 i.MX 6Dual/6Quad/6Solo/6DualLite CSI Parallel Interface............................................................................... 45
7.4.3 Timing Data Mode Protocols............................................................................................................................... 47
Chapter 8
Porting Audio Codecs to a Custom Board
8.1
Audio Overview..............................................................................................................................................................49
8.1.1 Common Porting Task......................................................................................................................................... 49
8.1.2 Porting the Reference BSP to a Custom Board (audio codec is the same as in the reference design)................ 50
8.1.3 Porting the Reference BSP to a Custom Board (audio codec is different than the reference design)................. 51
Chapter 9
Porting the Ethernet Controller Driver
9.1
Ethernet Controller Overview.........................................................................................................................................53
9.1.1 Pin Configuration................................................................................................................................................. 53
9.1.2 Source Code......................................................................................................................................................... 55
9.1.3 Ethernet Configuration.........................................................................................................................................55
Chapter 10
Porting USB Host1 and USB OTG
10.1 USB Overview for i.MX 6Dual/6Quad/6Solo/6DualLite/6UltraLite/7Dual..................................................................57
10.2 USB Overview for i.MX 6SoloLite/6SoloX...................................................................................................................59
Chapter 11
Revision History
11.1 Revision History............................................................................................................................................................. 61
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
5
i.MX BSP Porting Guide, Rev. 1, 01/2017
6
NXP Semiconductors
Chapter 1
Porting U-Boot from an i.MX 6/7 Reference Board to
an i.MX 6/7 Custom Board
1.1 U-Boot Overview
This chapter provides a step-by-step guide that explains how to add i.MX 6 and i.MX 7
custom board support for U-Boot.
This developer guide is based on the U-Boot v2016.03 package. For the i.MX patches,
see the release notes.
1.2 Obtaining the Source Code for the U-Boot
The following steps describe how to obtain the source code.
1. Install Yocto Project. See the Freescale Yocto Project User's Guide
(IMXLXYOCTOUG).
2. In Yocto Project, set the U-Boot preferred provider to uboot-imx. Confirm that the
sources/meta-fsl-bsp-release/imx/meta-fsl-arm/conf has the line PREFERRED_PROVIDER_uboot_mx6 = "u-boot-imx"
The U-Boot code is now located at <build directory>/tmp/work/<machine>-poky-linuxgnueabi/u-boot-imx/<version>/git, where <machine> can be one of the following:
• imx6qsabresd
• imx6qpsabresd
• imx6qsabreauto
• imx6dlsabresd
• imx6dlsabreauto
• imx6solosabreauto
• imx6slevk
• imx6sxsabresd
• imx6sxsabreauto
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
7
Obtaining the Source Code for the U-Boot
• imx7dsabresd
• imx6ul_14x14_evk
• imx6ull_14x14_evk
The U-Boot main directory is referred to as <UBOOT_DIR>. It is also assumed that your
shell working directory is <UBOOT_DIR>.
1.2.1 Preparing the Code
The following steps describe how to prepare the code.
1. Copy the board directory, as shown below:
$cp -R board/freescale/<mx6 or mx7>_<reference board name> board/freescale/<mx6 or
mx7>_<custom board name>
2. Copy the existing mx<reference board name>.h board configuration file as
mx<custom board name>.h, as shown below:
$cp include/configs/mx<reference board name>.h include/configs/mx<custom board name>.h
NOTE
The configuration files for the i.MX 6 or i.MX 7 are
located at include/configs. The files associated with the
boards are:
• i.MX 6 SABRE-SD:
• mx6sabresd_common.h
• mx6sabresd.h
• i.MX 6 SABRE-AI:
• mx6sabresd_common.h
• mx6qsabreauto.h
• i.MX 6SoloLite EVK:
• mx6slevk.h
• i.MX 6SoloX SABRE-SD:
• mx6sxsabresd.h
• i.MX 6SoloX SABRE-AI:
• mx6sxsabreauto.h
• i.MX 7Dual SABRE-SD:
• mx7dsabresd.h
• i.MX 6UltraLite EVK
• mx6ul_14x14_evk.h
• i.MX 6UltraLiteLite EVK
• mx6ullevk.h
i.MX BSP Porting Guide, Rev. 1, 01/2017
8
NXP Semiconductors
Chapter 1 Porting U-Boot from an i.MX 6/7 Reference Board to an i.MX 6/7 Custom Board
NOTE
You should pay attention to the following configurations
when using a new board.
• CONFIG_LOADADDR: Normally your zImage is
loaded to this address for boot.
• CONFIG_SYS_MALLOC_LEN: Heap memory size.
• CONFIG_STACKSIZE: Stack size.
• CONFIG_NR_DRAM_BANKS: Number of ddr banks.
• PHYS_SDRAM_SIZE: Configure the DDR size in MB.
• PHYS_SDRAM: Physical address for the DDR memory
• fdt_file: Configure "#define
CONFIG_DEFAULT_FDT_FILE <customer>.dtb" or
directly change "fdt_file=<customer>.dtb".
• Config file is important for U-Boot. It determines the
size, functionality, and performance of u-boot.bin.
3. Create a new file in <UBOOT_DIR>/configs/ for the new i.MX-based configuration.
The instruction is an example for the i.MX 6Quad board:
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6q<customer_board>/<customer
board>.cfg,MX6Q"
CONFIG_ARM=y
CONFIG_TARGET_MX6Q<customer_board>=y
CONFIG_SYS_MALLOC_F=y
CONFIG_SYS_MALLOC_F_LEN=0x400
CONFIG_DM=y
CONFIG_DM_THERMAL=y
NOTE
U-Boot project developers recommend adding any new
board to the MAKEALL script and running this script to
validate that the new code has not broken any other
platform build. This is a requirement if you plan to submit a
patch back to the U-Boot community. For further
information, see the U-Boot README file.
4. Rename
board/freescale/<mx6 or mx7><reference board name>/<mx6 or mx7><reference board name>.c
to
board/freescale/<mx6 or mx7><custom board name>/<mx6 or mx7><custom board name>.c.
5. Change the line
COBJS
:= <mx6 or mx7><reference board name>.o (inside board/freescale/<mx6 or
mx7><custom board
name>/Makefile)
to
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
9
Obtaining the Source Code for the U-Boot
obj-y
:= <mx6 or mx7><custom board name>.o
NOTE
The remaining instructions build U-Boot manually and do
not use Yocto Project.
6. Change the Kconfig.
For the Kconfig in board/<mx6 or mx7><customer board name>/:
if TARGET_<MX6 or MX7><CUSTOMER BOARD
NAME>
config SYS_BOARD
default "<mx6 or mx7><customer board
name>"
config SYS_VENDOR
default "freescale"
config SYS_CONFIG_NAME
default "<mx6 or mx7><customer
board>"
endif
The following is an example for the i.MX 6Quad SABRE-AI board:
if TARGET_MX6QSABREAUTO
config SYS_BOARD
default "mx6qsabreauto"
config SYS_VENDOR
default "freescale"
config SYS_CONFIG_NAME
default "mx6qsabreauto"
endif
Add new entry in arch/arm/cpu/armv7/<mx6 or mx7>/Kconfig:
config TARGET_<MX6 or MX7><CUSTOMER BOARD
NAME>
bool "Support <mx6 or mx7><customer board
name>"
select <MX6 cpu type>
select DM
select DM_THERMAL
source "board/freescale/<mx6 or mx6><customer board name>/Kconfig
The following is an example for the i.MX 6Quad SABRE-AI board:
config TARGET_MX6QSABREAUTO
bool "Support mx6qsabreauto"
select DM
select DM_THERMAL
source "board/freescale/mx6qsabreauto/Kconfig"
i.MX BSP Porting Guide, Rev. 1, 01/2017
10
NXP Semiconductors
Chapter 1 Porting U-Boot from an i.MX 6/7 Reference Board to an i.MX 6/7 Custom Board
7. Create a shell script under <UBOOT_DIR> named build_u-boot.sh.
The file contents are as follows:
#!/bin/bash
export ARCH=arm
export CROSS_COMPILE=<path to cross compiler prefix> (e.g.,
/opt/poky/1.4.1/sysroots/i686-pokysdk-linux/usr/bin/cortexa9hf-vfp-neon-poky-linuxgnueabi/arm-poky-linux-gnueabimake distclean;
make mx<custom board name>_config
make
8. Compile U-Boot by using $./build_u-boot.sh.
9. If everything is correct, you should now have u-boot.imx, which indicates that your
build setup is correct and ready to be customized.
The new i.MX custom board that you have created is an exact copy of the i.MX reference
board, but the boards are two independent builds. This allows you to proceed to the next
step: customizing the code to suit the new hardware design.
1.3 Customizing the i.MX 6 or i.MX 7 Custom Board Code
The new i.MX 6 or i.MX 7 custom board is a part of the U-Boot source tree, but it is a
duplicate of the i.MX 6 or i.MX 7 reference board code and needs to be customized.
The DDR technology is a potential key difference between the two boards. If there is a
difference in the DDR technology, the DDR initialization needs to be ported. DDR
initialization is coded in the DCD table, inside the boot header of the U-Boot image.
When porting bootloader, kernel or driver code, you must have the schematics easily
accessible for reference.
If there is a difference in the DDR technology between the two boards, the DDR
initialization needs to be ported. DDR initialization is coded in the DCD table, inside the
boot header of the U-Boot image. When porting bootloader, kernel or driver code, you
must have the schematics easily accessible for reference.
1.3.1 Changing the DCD Table for i.MX DDR3, LPDDR2, LPDDR3
Initialization
Before you initialize the memory interface, you need to configure the relevant I/O pins
with the right mode and impedance, and then initialize the MMDC module.
For how to generate calibration parameters for DDR, see i.MX 6 Series DDR Calibration
(AN4467). Users can also use the DDR script Aid and DDR stress tools in i.MX Design
and Tool Lists for DDR initialization.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
11
Customizing the i.MX 6 or i.MX 7 Custom Board Code
1. To port to the custom board, the DDR needs to be initialized properly.
2. Take a example for the i.MX 6Quad custom board. Open the file: board/freescale/
mx6<customer_board_name>/imximage.cfg to mx6q.cfg.
3. Modify all items in this file to match the memory specifications. These code blocks
are read by the ROM code to initialize your DDR memory.
1.3.2 Booting with the Modified U-Boot
This section describes how to compile and write u-boot.imx to an SD card.
If the DDR configuration (board/freescale/mx6<customer_board_name>/imximage.cfg)
was modified successfully, you can compile and write u-boot.imx to an SD card. To
verify this, insert the SD card into the SD card socket of the CPU board and power on the
board.
The following message should be displayed on the console if your board was based on
the i.MX 6Quad SABRE_SD:
U-Boot 2015.04-00240-gb8760a1 (Jul 10 2015 - 14:32:18)
CPU:
Freescale i.MX6Q rev1.2 at 792 MHz
CPU:
Temperature 36 C
Reset cause: POR
Board: MX6Q-Sabreauto revA
I2C:
ready
DRAM: 2 GiB
PMIC: PFUZE100 ID=0x10
NAND: 0 MiB
MMC:
FSL_SDHC: 0, FSL_SDHC: 1
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:
serial
Out:
serial
Err:
serial
switch to partitions #0, OK
mmc1 is current device
Net:
FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 0
=>
The following message should be displayed on the console if your custom board was
based on the i.MX 6SoloLite EVK:
U-Boot 2015.04-00240-gb8760a1 (Jul 10 2015 - 14:39:05)
CPU:
Freescale i.MX6SL rev1.2 at 396 MHz
CPU:
Temperature 38 C
Reset cause: POR
Board: MX6SLEVK
I2C:
ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC:
FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
In:
serial
Out:
serial
Err:
serial
i.MX BSP Porting Guide, Rev. 1, 01/2017
12
NXP Semiconductors
Chapter 1 Porting U-Boot from an i.MX 6/7 Reference Board to an i.MX 6/7 Custom Board
switch to partitions #0, OK
mmc1 is current device
Net:
FEC [PRIME]
Error: FEC address not set.
Normal Boot
Hit any key to stop autoboot:
=>
0
1.3.3 Adding New Driver Initialization Code to Board Files
The following steps describe how to add new driver and how to initialize code.
1. Find mx<customer_board>.c in board/freescale/mx<customer_board>/.
2. Edit mx<customer_board>.c and add new driver initialization code, including clock,
IOMUX, and GPIO.
3. Put driver initialization function into board_init or board_late_init.
NOTE
• The board_early_init_f() function is called at the very
early phase if you define
CONFIG_BOARD_EARLY_INIT_F. You can put the
UART/SPI-NOR/NAND IOMUX setup function
which requires to be set up at the very early phase.
• The board_init()function is called between
board_early_init_f and board_late_init. You can do
some general board-level setup here. If you do not
define CONFIG_BOARD_EARLY_INIT_F, do not
call printf before the UART setup is finished.
Otherwise, the system may be down.
• board_late_init() function is called fairly later. To
debug the initialization code, put the initialization
function into it.
1.3.4 Further Customization at System Boot
To further customize your U-Boot board project, use the first function that system boot
calls on:
board_init_f in "common/board_f.c"
board_early_init_f()
board_init()
All board initialization is executed inside this function. It starts by running through the
init_sequence_f[] array and init_sequence_r[] array of function pointers.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
13
Debugging
The first board dependent function inside the init_sequence_f[] array is
board_early_init_f(). board_early_init_f() is implemented inside board/freescale/
mx6<custom board name>.c.
The following line of code is most important:
...
setup_iomux_uart();
...
NOTE
If a device tree is used, the machine ID is not used. The
compatible string of the DTS file is used to match the board.
The device tree for file each boot variation is specified in the
machine configuration files in the meta-fsl-arm/conf/machine
directory.
1.3.5 Customizing the Printed Board Name
To customize the printed board name, use the checkboard() function.
This function is called from the init_sequence_f[] array implemented inside board/
freescale/mx6<custom board name>.c. There are two ways to use checkboard() to
customize the printed board name. The brute force way or by using a more flexible
identification method if implemented on the custom board.
To customize the brute force way, delete identify_board_id( ) inside checkboard() and
replace printf("Board: "); with printf("Board: i.MX on <custom board>\n");
If this replacement is not made, the custom board may use another identification method.
The identification can be detected and printed by implementing the
__print_board_info() function according to the identification method on the custom
board.
1.4 Debugging
There are two ways to do debugging:
• Using a JTAG tool
• Using printf
i.MX BSP Porting Guide, Rev. 1, 01/2017
14
NXP Semiconductors
Chapter 1 Porting U-Boot from an i.MX 6/7 Reference Board to an i.MX 6/7 Custom Board
1.4.1 Using JTAG Tool for Debugging
Generally, we use JTAG tool to debug at a very early stage, for example, before UART
initialization, or when it is difficult to debug with printf.
1. Make sure that your JTAG tool supports ARM® Cortex®-A9 cores on i.MX 6 and
supports ARM® Cortex®-A7 cores for i.MX 7Dual and 6UltraLite. It is
recommended to use TRACE32.
2. Load U-Boot (which is an elf file) in the root directory of U-Boot fully, or just
symbol (faster) to debug step by step.
NOTE
We can make optimization level 0 in compiling, which is
easier for debugging in JTAG tool.
1.4.2 Using printf for debugging
This is the most common method we use in debugging. You can print your value in the
driver for debugging.
NOTE
If you want to use printf in early stages, such as in board_init,
we can put UART initialization code earlier, such as in the
board_early_init_f().
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
15
Debugging
i.MX BSP Porting Guide, Rev. 1, 01/2017
16
NXP Semiconductors
Chapter 2
Configuring the IOMUX Controller
2.1 IOMUX Overview
Before using the i.MX pins (or pads), users must select the desired function and correct
values for characteristics such as voltage level, drive strength, and hysteresis. You can
configure a set of registers from the IOMUX controller.
i.MX 6Dual/6Quad
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6Dual/6Quad Applications Processor Reference Manual
(IMX6DQRM). For additional information about the IOMUX controller block, see the
"IOMUX Controller (IOMUXC)" chapter in the i.MX 6Dual/6Quad Applications
Processor Reference Manual (IMX6DQRM).
i.MX 6Dual/QuadPlus
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6Dual/6QuadPlus Applications Processor Reference Manual
(IMX6DQPRM). For additional information about the IOMUX controller block, see the
"IOMUX Controller (IOMUXC)" chapter in the i.MX 6Dual/6QuadPlus Applications
Processor Reference Manual (IMX6DQPRM).
i.MX 6DualLite
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6DualLite Applications Processor Reference Manual
(IMX6SDLRM). For additional information about the IOMUX controller block, see the
"IOMUX Controller (IOMUXC)" chapter in the i.MX 6DualLite Applications Processor
Reference Manual (IMX6SDLRM).
i.MX 6SoloLite
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
17
Information for Setting IOMUX Controller Registers
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM).
For additional information about the IOMUX controller block, see the "IOMUX
Controller (IOMUXC)" chapter in the i.MX 6SoloLite Applications Processor Reference
Manual (IMX6SLRM).
i.MX 6SoloX
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM).
For additional information about the IOMUX controller block, see the "IOMUX
Controller (IOMUXC)" chapter in the i.MX 6SoloX Applications Processor Reference
Manual (IMX6SXRM).
i.MX 7Dual
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 7Dual Applications Processor Reference Manual (IMX7DRM). For
additional information about the IOMUX controller block, see the "IOMUX Controller
(IOMUXC)" chapter in the i.MX 7Dual Applications Processor Reference Manual
(IMX7DRM).
i.MX 6UltraLite
For detailed information about each pin, see the "External Signals and Pin Multiplexing"
chapter in the i.MX 6UltraLite Applications Processor Reference Manual (IMX6ULRM).
For additional information about the IOMUX controller block, see the "IOMUX
Controller (IOMUXC)" chapter in the i.MX 6UltraLite Applications Processor Reference
Manual (IMX6ULRM).
2.2 Information for Setting IOMUX Controller Registers
The IOMUX controller contains four sets of registers that affect the i.MX 6Dual/6Quad/
6DualLite/6Solo/6SoloLite/6SoloX/6UltraLite/7Dual registers.
• General-purpose registers (IOMUXC_GPRx)-consist of registers that control PLL
frequency, voltage, and other general purpose sets.
• "Daisy Chain" control registers (IOMUXC_<Instance_port>_SELECT_INPUT)control the input path to a module when more than one pad may drive the module's
input
• MUX control registers (changing pad modes):
• Select which of the pad's eight different functions (also called ALT modes) is
used.
i.MX BSP Porting Guide, Rev. 1, 01/2017
18
NXP Semiconductors
Chapter 2 Configuring the IOMUX Controller
• Set the pad functions individually or by group using one of the following
registers:
• IOMUXC_SW_MUX_CTL_PAD_<PAD NAME>
• IOMUXC_SW_MUX_CTL_GRP_<GROUP NAME>
• Pad control registers (changing pad characteristics):
• Set pad characteristics individually or by group using one of the following
registers:
• IOMUXC_SW_PAD_CTL_PAD_<PAD_NAME>
• IOMUXC_SW_PAD_CTL_GRP_<GROUP NAME>
• Pad characteristics are:
• SRE (1 bit slew rate control)-Slew rate control bit; selects between FAST/
SLOW slew rate output. Fast slew rate is used for high frequency designs.
• DSE (2 bits drive strength control)-Drive strength control bits; selects the
drive strength (low, medium, high, or max).
• ODE (1 bit open drain control)-Open drain enable bit; selects open drain or
CMOS output.
• HYS (1 bit hysteresis control)-Selects between CMOS or Schmitt Trigger
when pad is an input.
• PUS (2 bits pull up/down configuration value)-Selects between pull up or
down and its value.
• PUE (1 bit pull/keep select)-Selects between pull up or keeper. A keeper
circuit help assure that a pin stays in the last logic state when the pin is no
longer being driven.
• PKE (1 bit enable/disable pull up, pull down or keeper capability)-Enable or
disable pull up, pull down, or keeper.
• DDR_MODE_SEL (1 bit ddr_mode control)-Needed when interfacing DDR
memories.
• DDR_INPUT (1 bit ddr_input control)-Needed when interfacing DDR
memories.
2.3 Using IOMUX in the Device Tree - Example
This is an example which shows how to use IOMUX in the Device Tree.
[email protected] { /* uSDHC4 */
fsl,card-wired;
vmmc-supply = <&reg_3p3v>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc4_1>;
};
[email protected] {
compatible = "fsl,imx6q-iomuxc";
reg = <0x020e0000 0x4000>;
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
19
Using IOMUX in the Device Tree - Example
0x17059
/* shared pinctrl settings */
usdhc4 {
pinctrl_usdhc4_1: usdhc4grp-1 {
fsl,pins = <
MX6QDL_PAD_SD4_CMD__SD4_CMD
MX6QDL_PAD_SD4_CLK__SD4_CLK
0x10059
MX6QDL_PAD_SD4_DAT0__SD4_DATA0
0x17059
MX6QDL_PAD_SD4_DAT1__SD4_DATA1
0x17059
MX6QDL_PAD_SD4_DAT2__SD4_DATA2
0x17059
MX6QDL_PAD_SD4_DAT3__SD4_DATA3
0x17059
MX6QDL_PAD_SD4_DAT4__SD4_DATA4
0x17059
MX6QDL_PAD_SD4_DAT5__SD4_DATA5
0x17059
MX6QDL_PAD_SD4_DAT6__SD4_DATA6
0x17059
};
};
....
};
>;
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
For details, see:
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
Documentation/devicetree/bindings/pinctrl/fsl,imx6*-pinctrl.txt
Documentation/devicetree/bindings/pinctrl/fsl,imx7*-pinctrl.txt
i.MX BSP Porting Guide, Rev. 1, 01/2017
20
NXP Semiconductors
Chapter 3
Registering a New UART Driver
3.1 Enabling UART on Kernel Menuconfig
Enable the UART driver on Linux® OS menuconfig. This option is located at:
-> Device Drivers
-> Character devices
-> Serial drivers
<*> IMX serial port support
[*] Console on IMX serial port
After enabling the UART driver, build the Linux kernel and boot the board.
3.2 UART Settings
By default, the UART is configured as follows:
•
•
•
•
•
Baud Rate: 115200
Data bits: 8
Parity: None
Stop bits: 1
Flow Control: None
3.3 File Names and Locations
There are three Linux source code directories that contain relevant UART files.
The header file is available in the directory <linux source code directory>/drivers/tty/
serial/
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
21
File Names and Locations
Table 3-1. Available Files-First Set
File
imx.c
Description
UART driver
i.MX BSP Porting Guide, Rev. 1, 01/2017
22
NXP Semiconductors
Chapter 4
Adding Support for SDHC
4.1 SDHC Overview
uSDHC has 14 associated I/O signals.
The following list describes the associated I/O signals.
Signal Overview
• The SD_CLK is an internally generated clock used to drive the MMC, SD, and SDIO
cards.
• The CMD I/O is used to send commands and receive responses to/from the card.
Eight data lines (DAT7~DAT0) are used to perform data transfers between the
SDHC and the card.
• The SD_CD# and SD_WP are card detection and write protection signals directly
routed from the socket. These two signals are active low (0). A low on SD_CD#
means that a card is inserted and a high on SD_WP means that the write protect
switch is active.
• SD_LCTL is an output signal used to drive an external LED to indicate that the SD
interface is busy.
• SD_RST_N is an output signal used to reset the MMC card. This should be
supported by the card.
• SD_VSELECT is an output signal used to change the voltage of the external power
supplier. SD_CD#, SD_WP, SD_LCTL, SD_RST_N, and SD_VSELECT are all
optional for system implementation. If the uSDHC is desired to support a 4-bit data
transfer, DAT7~DAT4 can also be optional and tied to high voltage.
Adding uSDHC support in the device tree
The following is an example for adding uSDHC support in the device tree:
[email protected] { /* uSDHC2 */
compatible = "fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 0x04>;
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
23
SDHC Overview
};
clocks = <&clks 164>, <&clks 164>, <&clks 164>;
clock-names = "ipg", "ahb", "per";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2_1>;
cd-gpios = <&gpio2 2 0>;
wp-gpios = <&gpio2 3 0>;
bus-width = <8>;
no-1-8-v;
keep-power-in-suspend;
enable-sdio-wakeup;
status = "okay";
usdhc1: [email protected] {
compatible = "fsl,imx6ul-usdhc", "fsl,imx6sx-usdhc";
reg = <0x02190000 0x4000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_USDHC1>,
<&clks IMX6UL_CLK_USDHC1>,
<&clks IMX6UL_CLK_USDHC1>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
};
For more information, see:
The binding document at linux/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt.
arch/arm/boot/dts/imx6ul.dtsi
arch/arm/boot/dts/imx6ul-14x14-evk.dts
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/boot/dts/imx6qdl-sabresd.dtsi
Support of SD3.0
SD3.0 requires 3.3 V and 1.8 V for signal voltage. Voltage selection needs to be
implemented on your platform.
Support of SDIO
In most situations, SDIO requires more power than SD/MMC memory cards. Ensure that
the power supply is in the SD slot while using SDIO, or apply an external power to SDIO
instead.
i.MX BSP Porting Guide, Rev. 1, 01/2017
24
NXP Semiconductors
Chapter 5
Configuring the SPI NOR Flash Memory Technology
Device (MTD) Driver
5.1 SPI NOR Overview
This chapter describes how to set up the SPI NOR Flash memory technology device
(MTD) driver.
This driver uses the SPI interface to support the SPI-NOR data Flash devices. By default,
the SPI NOR Flash MTD driver creates static MTD partitions.
The NOR MTD implementation provides necessary information for the upper-layer MTD
driver.
5.2 Source Code Structure
The SPI NOR MTD driver is implemented in the following file:
linux/drivers/mtd/devices/m25p80.c
Since the size is only 4 MB, we do not implement partitions for the SPI NOR.
5.2.1 Configuration Options
Freescale's BSP supports the following SPI NOR Flash models.
• "M25P32-VMW3TGB" "m25p32"
Those models are defined in the structure
static const struct spi_device_id m25p_ids[],
located at
drivers/mtd/devices/m25p80.c
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
25
Changing the SPI Interface Configuration
5.2.2 Selecting SPI NOR on the Linux Image
Follow these steps to enable support for SPI NOR:
1. Add the pinctrl for the SPI. For example:
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <
MX6QDL_PAD_EIM_D17__ECSPI1_MISO
MX6QDL_PAD_EIM_D18__ECSPI1_MOSI
MX6QDL_PAD_EIM_D16__ECSPI1_SCLK
>;
};
0x100b1
0x100b1
0x100b1
pinctrl_ecspi1_cs: ecspi1cs {
fsl,pins = <
MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000
>;
};
2. Enable the SPI. For example:
&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio3 19 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
status = "okay"; /* pin conflict with WEIM NOR */
};
flash: [email protected] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,m25p32";
spi-max-frequency = <20000000>;
reg = <0>;
};
5.3 Changing the SPI Interface Configuration
The i.MX 6 SoC has five ECSPI interfaces. The i.MX 7Dual SoC has four ECSPI
interfaces. By default, the BSP configures ECSPI-1 interface in the master mode to
connect to the SPI NOR Flash.
5.4 Hardware Operation
SPI NOR Flash is SPI compatible with frequencies up to 66 MHz.
i.MX BSP Porting Guide, Rev. 1, 01/2017
26
NXP Semiconductors
Chapter 5 Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver
The memory is organized in pages of 512 bytes or 528 bytes. SPI NOR Flash also
contains two SRAM buffers of 512/528 bytes each, which allows data reception while a
page in the main memory is being reprogrammed. It also allows the writing of a
continuous data stream.
Unlike conventional Flash memories that are accessed randomly, the SPI NOR Flash
accesses data sequentially. It operates from a single 2.7-3.6 V power supply for program
and read operations.
SPI NOR Flashes are enabled through a chip select pin and accessed through a three-wire
interface: serial input, serial output, and serial clock.
5.4.1 Software Operation
In a Flash-based embedded Linux system, a number of Linux technologies work together
to implement a file system.
The following figure illustrates the relationships between standard components.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
27
Hardware Operation
Figure 5-1. Components of a Flash-based file system
The MTD subsystem for Linux OS is a generic interface to memory devices such as
Flash and RAM which provides simple read, write, and erase access to physical memory
devices. Devices called mtdblock devices can be mounted by JFFS, JFFS2, and
CRAMFS file systems. The SPI NOR MTD driver is based on the MTD data Flash driver
in the kernel by adding SPI accesses.
In the initialization phase, the SPI NOR MTD driver detects a data Flash by reading the
JEDEC ID. The driver then adds the MTD device. The SPI NOR MTD driver also
provides the interfaces to read, write, erase NOR Flash.
i.MX BSP Porting Guide, Rev. 1, 01/2017
28
NXP Semiconductors
Chapter 6
Connecting an LVDS Panel to an i.MX 6Dual/6Quad/
6Solo/6DualLite Reference Board
6.1 LVDS Overview
This chapter describes how to connect the LVDS panel to an i.MX 6Dual/6Quad/6Solo/
6DualLite reference board. The i.MX 6Dual/6Quad/6Solo/6DualLite processor has an
LVDS display bridge (LDB) block that drives LVDS panels without external bridges.
The LDB supports the flow of synchronous RGB data from the IPU to external display
devices through the LVDS interface. This support covers the following activities:
• Connectivity to relevant devices-display with an LVDS receiver.
• Arranging the data as required by the external display receiver and by LVDS display
standards.
• Synchronization and control capabilities.
6.1.1 Connecting an LVDS Panel to the i.MX 6Dual/6Quad/
6DualLite Reference Board
The kernel command line for 24-bit LVDS panel (4 pairs of LVDS data signals) displays
the following line if the panel is properly connected:
video=mxcfb0:dev=ldb,if=RGB24
The kernel command line for 18-bit LVDS panel (3 pairs of LVDS data signals) displays
the following line if the panel is properly connected:
video=mxcfb0:dev=ldb,if=RGB666
6.2 Enabling an LVDS Channel
The LDB driver source code is available at linux/drivers/video/mxc/ldb.c.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
29
LDB Ports
When the LDB device is probed by the mxc display core driver, the driver uses platform
data information from DTS file to configure the LDB's reference resistor mode and also
tries to match video modes for external display devices with an LVDS interface. The
display signal polarities and LDB control bits are set according to the matched video
modes.
The LVDS channel mapping mode and the LDB bit mapping mode of LDB are set
according to the LDB device tree node set by the user.
An LVDS channel is enabled as follows:
1. Set the parent clock of ldb_di_clk and the parent clock rate.
2. Set the rate of ldb_di_clk.
3. Set the LDB in a proper mode, including display signals' polarities, LVDS channel
mapping mode, bit mapping mode, and reference resistor mode.
4. Enable both ldb_di_clk and its parent clock.
6.2.1 Locating Menu Configuration Options
Linux kernel configuration options are provided for the build-in status to enable this
module. To locate these options, perform the following steps:
1. Go to the root of the kernel tree.
2. Make menuconfig.
3. Follow this sequence: Device Drivers > Graphics support > MXC Framebuffer
support > Synchronous Panel Framebuffer > MXC LDB
6.3 LDB Ports
The following figure shows the LDB block.
i.MX BSP Porting Guide, Rev. 1, 01/2017
30
NXP Semiconductors
Chapter 6 Connecting an LVDS Panel to an i.MX 6Dual/6Quad/6Solo/6DualLite Reference Board
Figure 6-1. i.MX 6 LVDS Display Bridge (LDB) Block
i.MX 6SoloX LDB supports only one LVDS channel.
The LDB has the following ports:
•
•
•
•
Two input parallel display ports.
Two output LVDS channels
Control signals to configure LDB parameters and operations.
Clocks from the SoC PLLs.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
31
Additional Information
6.3.1 Input Parallel Display Ports
The LDB is configurable to support either one or two (DI0, DI1) parallel RGB input
ports. The LDB only supports synchronous access mode.
Each RGB data interface contains the following:
•
•
•
•
•
RGB data of 18 or 24 bits
Pixel clock
Control signals
HSYNC, VSYNC, DE, and one additional optional general purpose control
Transfers a total of up to 28 bits per data interface per pixel clock cycle
The LDB supports the following data rates:
• For dual-channel output: up to 170 MHz pixel clock (such as UXGA-1600 x 1200 at
60 Hz + 35% blanking)
• For single-channel output: up to 85 MHz per interface. (such as WXGA-1366 x 768
at 60 Hz + 35% blanking).
6.3.2 Output LVDS Ports
The LDB has two LVDS channels, which are used to communicate RGB data and
controls to external LCD displays either through the LVDS interface or through LVDS
receivers. Each channel consists of four data pairs and one clock pair, with a pair
indicating an LVDS pad that contains PadP and PadM.
The LVDS ports may be used as follows:
•
•
•
•
One single-channel output
One dual channel output: single input, split to two output channels
Two identical outputs: single input sent to both output channels
Two independent outputs: two inputs sent, each to a distinct output channel
6.4 Additional Information
For additional information, see the following reference materials:
• i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM)
• i.MX 6Solo/6DualLite Applications Processor Reference Manual (IMX6SDLRM)
• i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM)
i.MX BSP Porting Guide, Rev. 1, 01/2017
32
NXP Semiconductors
Chapter 6 Connecting an LVDS Panel to an i.MX 6Dual/6Quad/6Solo/6DualLite Reference Board
• i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM)
• i.MX 7Dual Applications Processor Reference Manual (IMX7DRM)
• i.MX Linux Reference Manual (IMXLXRM), included as a part of the Linux BSP
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
33
Additional Information
i.MX BSP Porting Guide, Rev. 1, 01/2017
34
NXP Semiconductors
Chapter 7
Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite
Camera Sensor with CSI
7.1 CSI Overview
This chapter provides information about how to use the expansion connector to include
support for a new camera sensor on an i.MX 6Dual/6Quad/6DualLite reference board.
It describes the following operations:
• Configuring the CSI unit in test mode (Configuring the CSI Unit in Test Mode)
• Adding support for a new CMOS sensor in the i.MX 6Dual/6Quad/6Solo/6DualLite
BSP (Adding Support for a New CMOS Camera Sensor)
• Setting up and using the I2C interface to handle your camera bus (Using the I2C
Interface)
• Loading and testing the camera module (Loading and Testing the Camera Module)
It also provides reference information about the following:
• Required software and hardware
• i.MX 6Dual/6Quad/6Solo/6DualLite reference CSI interfaces layout (i.MX 6Dual/
6Quad/6Solo/6DualLite CSI Interfaces Layout)
• CMOS sensor interfaces (CSI) supported by the i.MX 6Dual/6Quad/6Solo/6DualLite
(IPU) (CMOS Interfaces Supported by the i.MX 6Dual/6Quad/6Solo/6DualLite)
• i.MX 6Dual/6Quad/6Solo/6DualLite SABRE-SD CSI parallel interface (i.MX
6Dual/6Quad/6Solo/6DualLite CSI Parallel Interface)
• i.MX 6Dual/6Quad/6Solo/6DualLite CSI test mode (Timing Data Mode Protocols)
7.1.1 Required Software
In Freescale BSPs, all capture devices support the V4L2 standard.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
35
CSI Overview
Therefore, only the CMOS-dependent layer needs to be modified to include a new CMOS
sensor. All other layers are developed to work with V4L2.
Required development tools are as follows:
• i.MX 6 Linux OS L3.10.9 or newer
7.1.2 i.MX 6Dual/6Quad/6Solo/6DualLite CSI Interfaces Layout
The following figure shows the camera interface layout on an i.MX 6Solo/6DualLite
SABRE-SD board.
Figure 7-1. Camera Interface Layout
CSI0 is used as a parallel sensor input interface. CSI1 is used as a MIPI sensor input
interface.
7.1.3 Configuring the CSI Unit in Test Mode
This chapter uses the test mode for its example scenario of a new camera driver that
generates a chess board.
When you set the TEST_GEN_MODE register, the device is in test mode, which is used
for debugging. The CSI generates a frame automatically and sends it to one of the
destination units. The sent frame is a chess board composed of black and configured
color squares. The configured color is set with the registers PG_B_VALUE,
PG_G_VALUE, and PG_R_VALUE. The data can be sent in different frequencies
according to the configuration of DIV_RATIO register.
i.MX BSP Porting Guide, Rev. 1, 01/2017
36
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
When CSI is in test mode, configure the CSI unit with a similar configuration to the
described settings in the following table. Call ipu_csi_init_interface() to configure the
CSI interface protocol, formats, and features.
Table 7-1. Settings for Test Mode
Bit Field
Value
Description
CSI0_DATA_DEST
0x4
Destination is IDMAC via SMFC
CSI0_DIV_RATIO
0x0
SENSB_MCLK rate = HSP_CLK rate
CSI0_EXT_VSYNC
0x1
External VSYNC mode
CSI0_DATA_WIDTH
0x1
8 bits per color
CSI0_SENS_DATA_FORMAT
0x0
Full RGB or YUV444
CSI0_PACK_TIGHT
0x0
Each component is written as a 16 bit word where the MSB is written to
bit #15. Color extension is done for the remaining least significant bits.
CSI0_SENS_PRTCL
0x1
Non-gated clock sensor timing/data mode.
CSI0_SENS_PIX_CLK_POL
0x1
Pixel clock is inverted before applied to internal circuitry.
CSI0_DATA_POL
0x0
Data lines are directly applied to internal circuitry.
CSI0_HSYNC_POL
0x0
HSYNC is directly applied to internal circuitry.
CSI0_VSYNC_POL
0x0
VSYNC is directly applied to internal circuitry.
7.2 Adding Support for a New CMOS Camera Sensor
To add support for a new CMOS camera sensor to your BSP, create a device driver to
support it.
This device driver is the optimal location for implementing initialization routines, the
power up sequence, power supply settings, the reset signal, and other desired features for
your CMOS sensor. It is also the optimal location to set the parallel protocol used
between the camera and the i.MX 6Dual/6Quad/6Solo/6DualLite.
Perform the following three steps on the i.MX 6Dual/6Quad/6Solo/6DualLite BSP to
create a device driver:
1. Add a camera sensor entry in Kconfig.
2. Create the camera file.
3. Add compilation flag for the new camera sensor.
These steps are described in detail in the following subsections.
7.2.1 Adding a Camera Sensor Entry in Kconfig
Select specific camera drivers in the following location (as shown in figure below):
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
37
Adding Support for a New CMOS Camera Sensor
Device Drivers > Multimedia support > Video capture adapters V4L platform devices > MXC
Video For Linux Camera > MXC Camera/V4L2 PRP Features
support
Figure 7-2. MXC Camera/V4L2 PRP Features Support Window
To add a new camera sensor entry on the Kconfig camera file, perform the following
steps:
1. Enter the following command into the display specific folder:
$ cd linux/drivers/media/video/mxc/capture
2. Open the Kconfig file:
$ gedit Kconfig &
3. Add the entry where you want it to appear:
config MXC_IPUV3_CSI0_TEST_MODE
tristate "IPUv3 CSI0 test mode camera support"
depends on !VIDEO_MXC_EMMA_CAMERA
---help--If you plan to use the IPUv3 CSI0 in test mode with your MXC
system, say Y here.
7.2.2 Creating the Camera Sensor File
The camera sensor file enables camera initialization, reset signal generation, power
settings, and all sensor-specific code.
i.MX BSP Porting Guide, Rev. 1, 01/2017
38
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
NOTE
Before connecting a camera sensor to the i.MX 6Dual/6Quad/
6Solo/6DualLite board, you must check whether the sensor is
powered with the proper supply voltages and whether the
sensor data interface has the correct VIO value. Power supply
mismatches can damage either the CMOS or the i.MX 6Dual/
6Quad/6Solo/6DualLite.
Create a file with the required panel-specific functions in the following path:
linux/drivers/media/video/mxc/capture/
The camera file-ipuv3_csi0_chess.c-must include the functions described in table below
and may include additional functions and macros required for your driver.
Table 7-2. Required Functions
Function Name
Function Declaration
Description
ioctl_g_ifparm
static int ioctl_g_ifparm(struct
v4l2_int_device *s, struct v4l2_ifparm
*p)
V4L2 sensor interface handler for VIDIOC_G_PARM ioctl
ioctl_s_power
static int ioctl_s_power(struct
v4l2_int_device *s, int on)
V4L2 sensor interface handler for VIDIOC_S_POWER ioctl. Sets
sensor module power mode (on or off)
ioctl_g_parm
static int ioctl_g_parm(struct
v4l2_int_device *s, struct
v4l2_streamparm *a)
V4L2 sensor interface handler for VIDIOC_G_PARM ioctl. Get
streaming parameters.
ioctl_s_parm
static int ioctl_s_parm(struct
v4l2_int_device *s, struct
v4l2_streamparm *a)
V4L2 sensor interface handler for VIDIOC_S_PARM ioctl. Set
streaming parameters.
ioctl_g_fmt_cap
static int ioctl_g_fmt_cap(struct
v4l2_int_device *s, struct v4l2_format
*f)
Returns the sensor's current pixel format in the v4l2_format
parameter.
ioctl_g_ctrl
static int ioctl_g_ctrl(struct
v4l2_int_device *s, struct v4l2_control
*vc)
V4L2 sensor interface handler for VIDIOC_G_CTRL. If the
requested control is supported, returns the control's current value
from the video_control[] array. Otherwise, it returns -EINVAL if the
control is not supported.
ioctl_s_ctrl
static int ioctl_s_ctrl(struct
v4l2_int_device *s, struct v4l2_control
*vc)
V4L2 sensor interface handler for VIDIOC_S_CTRL. If the
requested control is supported, it sets the control's current value in
HW (and updates the video_control[] array). Otherwise, it returns EINVAL if the control is not supported.
ioctl_init
static int ioctl_init(struct
v4l2_int_device *s)
V4L2 sensor interface handler for VIDIOC_INT_INIT. Initialize
sensor interface.
ioctl_dev_init
static int ioctl_dev_init(struct
v4l2_int_device *s)
Initializes the device when slave attaches to the master.
ioctl_dev_exit
static int ioctl_dev_exit(struct
v4l2_int_device *s)
De-initializes the device when slave detaches to the master.
After the functions have been created, you need to add additional information to
ipuv3_csi0_chess_slave and ipuv3_csi0_chess_int_device. The device uses this
information to register as a V4L2 device.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
39
Adding Support for a New CMOS Camera Sensor
The following ioctl function references are included:
static struct v4l2_int_slave ipuv3_csi0_chess_slave = {
.ioctls = ipuv3_csi0_chess_ioctl_desc,
.num_ioctls = ARRAY_SIZE(ipuv3_csi0_chess_ioctl_desc),
};
static struct v4l2_int_device ipuv3_csi0_chess_int_device = {
...
.type = v4l2_int_type_slave,
...
};
static int ipuv3_csi0_chess_probe(struct i2c_client *client,const struct i2c_device_id *id)
{
...
retval = v4l2_int_device_register(&ipuv3_csi0_chess_int_device);
...
}
It is also necessary to modify other files to prepare the BSP for CSI test mode. Change
the sensor pixel format from YUV to RGB565 in the ipu_bg_overlay_sdc.c file so that
the image converter does not perform color space conversion and the input received from
the CSI test mode generator is sent directly to the memory. Additionally, modify
mxc_v4l2_capture.c to preserve CSI test mode settings which are set by the
ipuv3_csi0_chess_init_mode() function in the ipuv3_csi0_chess.c file.
7.2.3 Adding a Compilation Flag for the New Camera
After camera files are created and the Kconfig file has the entry for your new camera,
modify the Makefile to create the new camera module during compilation.
The Makefile is located in the same folder as your new camera file and Kconfig: linux/
drivers/media/video/mxc/capture.
1. Enter the following into the i.MX 6Dual/6Quad/6Solo/6DualLite camera support
folder:
$ cd linux/drivers/media/video/mxc/capture
2. Open the i.MX 6Dual/6Quad/6Solo/6DualLite camera support Makefile.
$ gedit Makefile &
3. Add the cmos driver compilation entry to the end of the Makefile.
ipuv3_csi0_chess_camera-objs := ipuv3_csi0_chess.o
obj-$(CONFIG_MXC_IPUV3_CSI0_TEST_MODE) += ipuv3_csi0_chess_camera.o
i.MX BSP Porting Guide, Rev. 1, 01/2017
40
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
The kernel object is created by using the ipuv3_csi0_chess.c file. You should have the
following files as output:
•
•
•
•
•
ipuv3_csi0_chess_camera.mod.c
ipuv3_csi0_chess.o
ipuv3_csi0_chess_camera.o
ipuv3_csi0_chess_camera.mod.o
ipuv3_csi0_chess_camera.ko
7.3 Using the I2C Interface
Many camera sensor modules require a synchronous serial interface for initialization and
configuration.
This section uses the linux/drivers/media/video/mxc/capture/ov5642.c file as its example
code. This file contains a driver that uses the I2C interface for sensor configuration.
After the I2C interface is running, create a new I2C device to handle your camera bus. If
the camera sensor file (called mycamera.c in the following example code) is located in
the same folder as ov5642.c, the code is as follows:
struct i2c_client * mycamera_i2c_client;
static s32 mycamera_read_reg(u16 reg, u8 *val);
static s32 mycamera_write_reg(u16 reg, u8 val);
static const struct i2c_device_id mycamera_id[] = {
{"mycamera", 0},
{},
};
MODULE_DEVICE_TABLE(i2c, mycamera_id);
static struct i2c_driver mycamera_i2c_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "mycamera",
},
.probe = mycamera_probe,
.remove = mycamera_remove,
.id_table = mycamera_id,
};
static s32 my_camera_write_reg(u16 reg, u8 val)
{
u8 au8Buf[3] = {0};
au8Buf[0] = reg >> 8;
au8Buf[1] = reg & 0xff;
au8Buf[2] = val;
if (i2c_master_send(my_camera_i2c_client, au8Buf, 3) < 0) {
pr_err("%s:write reg error:reg=%x,val=%x\n",__func__, reg, val);
return -1;
}
return 0;
}
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
41
Using the I2C Interface
static s32 my_camera_read_reg(u16 reg, u8 *val)
{
u8 au8RegBuf[2] = {0};
u8 u8RdVal = 0;
au8RegBuf[0] = reg >> 8;
au8RegBuf[1] = reg & 0xff;
if (2 != i2c_master_send(my_camera_i2c_client, au8RegBuf, 2)) {
pr_err("%s:write reg error:reg=%x\n",__func__, reg);
return -1;
}
if (1 != i2c_master_recv(my_camera_i2c_client, &u8RdVal, 1)) {// @ECA
pr_err("%s:read reg error:reg=%x,val=%x\n",__func__, reg, u8RdVal);
return -1;
}
}
*val = u8RdVal;
return u8RdVal;
static int my_camera_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
...
my_camera_i2c_client = client;
...
}
static __init int mycamera_init(void)
{
u8 err;
err = i2c_add_driver(&mycamera_i2c_driver);
if (err != 0)
pr_err("%s:driver registration failed, error=%d \n",__func__, err);
return err;
}
static void __exit mycamera_clean(void)
{
i2c_del_driver(&mycamera_i2c_driver);
}
module_init(mycamera_init);
module_exit(mycamera_clean);
Check ov5642.c for the complete example code.
After creating the new I2C device driver, add a new I2C node to your platform dts file.
You may modify the dts file at this point to specify features about your camera such as
the CSI interface used (CSI0 or CSI1), the MCLK frequency, and some power supply
settings related to the module.
You can now read and write from/to the sensor in the camera sensor file by using the
following:
retval = mycamera_write_reg(RegAddr, Val);
retval = mycamera_read_reg(RegAddr, &RegVal);
i.MX BSP Porting Guide, Rev. 1, 01/2017
42
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
7.3.1 Loading and Testing the Camera Module
If your camera driver has been created as a kernel module, as in the example in this
chapter, the module must be loaded prior to any camera request attempt.
According to the Makefile information, the camera module is named
ipuv3_csi0_chess_camera.ko.
To load the V4L2 camera interface and CSI in test mode, execute the following
commands:
[email protected] /unit_tests$ modprobe ipuv3_csi0_chess_camera
[email protected] /unit_tests$ modprobe mxc_v4l2_capture
To test the video0 input (camera), an mxc_v4l2_overlay test is included in the BSP. If the
imx-test package has also been included, open the unit test folder and execute the test.
[email protected] ~$ cd /unit_tests/
[email protected] /unit_tests$ ./mxc_v4l2_overlay.out
7.4 Additional Reference Information
This section provides reference information about the following:
• CMOS Interfaces Supported by the i.MX 6Dual/6Quad/6Solo/6DualLite
• i.MX 6Dual/6Quad/6Solo/6DualLite CSI Parallel Interface
• Timing Data Mode Protocols
7.4.1 CMOS Interfaces Supported by the i.MX 6Dual/6Quad/
6Solo/6DualLite
The camera sensor interface, which is a part of the image processing unit (IPU) module
on the i.MX 6Dual/6Quad/6Solo/6DualLite, handles CMOS sensor interfaces. The i.MX
6Dual/6Quad/6Solo/6DualLite IPU is able to handle two camera devices through its CSI
ports: one connected to the CSI0 port and the other to the CSI1 port. Both CSI ports are
identical and provide glueless connectivity to a wide variety of raw/smart sensors and TV
decoders.
Each of the camera ports includes the following features:
• Parallel interface
• Up to 20-bit input data bus
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
43
Additional Reference Information
•
•
•
•
•
• A single value in each cycle
• Programmable polarity
Multiple data formats
• Interleaved color components, up to 16 bits per value (component)
• Input Bayer RGB, Full RGB, or YUV 4:4:4, YUV 4:2:2 Component
order:UY1VY2 or Y1UY2V, grayscale and generic data
Scan order: progressive or interlaced
Frame size: up to 8192 x 4096 pixels
Synchronization-video mode
• The sensor is the master of the pixel clock (PIXCLK) and synchronization
signals.
• Synchronization signals are received by using either of the following methods:
• Dedicated control signals-VSYNC, HSYNC-with programmable pulse
width and polarity.
• Controls embedded in the data stream following loosely the BT.656 protocol
with flexibility in code values and location.
• The image capture is triggered by the MCU or by an external signal (such as a
mechanical shutter).
• Synchronized strobes are generated for up to six outputs-the sensor and camera
peripherals (flash, mechanical shutter...).
Frame rate reduction by periodic skipping of frames.
For details, see the "Image Processing Unit (IPU)" chapter in the i.MX 6Dual/6Quad
Applications Processor Reference Manual (IMX6DQRM) or i.MX 6Solo/6DualLite
Applications Processor Reference Manual (IMX6SDLRM). The following figure shows
the block diagram.
i.MX BSP Porting Guide, Rev. 1, 01/2017
44
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
Figure 7-3. IPU Block Diagram
Several sensors can be connected to each of the CSIs. Simultaneous functionality (for
sending data) is supported as follows:
• Two sensors can send data independently, each through a different port.
• One stream can be transferred to the VDI or IC for on-the-fly processing while the
other one is sent directly to system memory.
The input rate supported by the camera port is as follows:
• Peak: up to 180 MHz (values/sec).
• Average (assuming 35% blanking overhead) for YUV 4:2:2.
• Pixel in one cycle (BT.1120): up to 135 MP/sec, such as 9 Mpixels at 15 fps.
• Pixel on two cycles (BT.656): up to 67 MP/sec, such as 4.5 Mpixels at 15 fps.
• On-the-fly processing may be restricted to a lower input rate.
If required, additional cameras can be connected though the USB port.
7.4.2 i.MX 6Dual/6Quad/6Solo/6DualLite CSI Parallel Interface
The CSI obtains data from the sensor, synchronizes the data and the control signals to the
IPU clock (HSP_CLK), and transfers the data to the IC and/or SMFC.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
45
Additional Reference Information
The CSI parallel interface (shown in figure below) provides a clock output (MCLK),
which is used by the sensor as a clock input reference. The i.MX 6Dual/6Quad/6Solo/
6DualLite requests either video or still images through a different interface between the
processor and the camera module. In most situations, the interface is a synchronous serial
interface such as the I2C. After the frame has been requested, the camera module takes
control of the CSI bus, and uses synchronization signals VSYNC, HSYNC, DATA_EN
and PIXCLK to send the image frame to the i.MX 6Dual/6Quad/6Solo/6DualLite. The
camera sensor creates PIXCLK based on MCLK input.
Figure 7-4. Parallel Interface Layout
In parallel interface, a single value arrives in each clock, except in BT.1120 mode when
two values arrive per cycle. Each value can be 8-16 bits wide according to the
configuration of DATA_WIDTH. If DATA_WIDTH is configured to N, then 20-N LSB
bits are ignored.
Therefore, you never need CSI0_DAT[3:0], unless you are using BT.1120 mode, because
the maximum pixel width is 16 (CSI0_DAT[19:4]). The expansion port 2 includes
CSI0_DAT[19:4], but only CSI0_DAT[19:10] are used for the CSI data bus (10-bit wide
data). CSI0_DAT[9:4] are shared with other interfaces and are used for audio and I2C.
CSI can support several data formats according to SENS_DATA_FORMAT
configuration. When the data format is YUV, the output of the CSI is always YUV444even if the data arrives in YUV422 format.
The polarity of the inputs can be configured using the following registers:
i.MX BSP Porting Guide, Rev. 1, 01/2017
46
NXP Semiconductors
Chapter 7 Supporting the i.MX 6Dual/6Quad/6Solo/6DualLite Camera Sensor with CSI
•
•
•
•
SENS_PIX_CLK_POL
DATA_POL
HSYNC_POL
VSYNC_POL
The following table describes the camera parallel interface provided by the i.MX 6Dual/
6Quad/6Solo/6DualLite:
Table 7-3. CSI0 Parallel Interface Signals
Signal
IPU Pin
Description
MCLK
CSI0_MCLK
Master Clock (Output)
PIXCLK
CSI0_PIXCLK
Pixel Clock
VSYNC
CSI0_VSYNC
Vertical Synchronization signal
HSYNC
CSI0_HSYNC
Horizontal Synchronization signal
DATA_EN
CSI0_DATA_EN
Data Enable or Data ready
DATA[19:10]
CSI0_DAT [19:10]
Pixel data bus, optional to [19:4]
Timing Data Mode Protocols, explains how the timing data mode protocols use these
signals. Not all signals are used in each timing data mode protocol.
7.4.3 Timing Data Mode Protocols
The CSI interface supports the following four timing/data protocols:
•
•
•
•
Gated mode
Non-gated mode
BT.656 (Progressive and interlaced)
BT.1120 (Progressive and interlaced)
In gated mode, VSYNC is used to indicate beginning of a frame, and HSYNC is used to
indicate the beginning of a raw. The sensor clock is always ticking.
In non-gated mode, VSYNC is used to indicate beginning of a frame, and HSYNC is not
used. The sensor clock only ticks when data is valid.
In BT.656 mode, the CSI works according to recommendation ITU-R BT.656. The
timing reference signals (frame start, frame end, line start, line end) are embedded in the
data bus input.
In BT1120 mode, the CSI works according to recommendation ITU-R BT.1120. The
timing reference signals (frame start, frame end, line start, line end) are embedded in the
data bus input.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
47
Additional Reference Information
For details, see the i.MX 6Dual/6Quad Applications Processor Reference Manual
(IMX6DQRM) or i.MX 6Solo/6DualLite Applications Processor Reference Manual
(IMX6SDLRM).
i.MX BSP Porting Guide, Rev. 1, 01/2017
48
NXP Semiconductors
Chapter 8
Porting Audio Codecs to a Custom Board
8.1 Audio Overview
This chapter describes how to port audio drivers from the Freescale reference BSP to a
custom board.
This procedure varies depending on whether the audio codec on the custom board is the
same as, or different than the audio codec on the Freescale reference design. This chapter
first describes the common porting task and then various other porting tasks.
8.1.1 Common Porting Task
In order to use the ALSA Audio function, CPU DAI driver, CODEC DAI driver and DAI
LINK driver (Machine driver) should be registered in the device tree, and accordingly
there must be three nodes in board specified dts file. An example of detailed nodes can be
found in arch/arm/boot/dts/imx6qdl-sabresd.dtsi:
/* DT binding for CPU DAI driver */
ssi2: [email protected] {
fsl,mode = "i2s-slave";
status = "okay";
};
/* DT binding for CODEC DAI driver */
codec: [email protected] {
compatible = "wlf,wm8962";
reg = <0x1a>;
clocks = <&clks 169>;
DCVDD-supply = <&reg_audio>;
/*
DBVDD-supply = <&reg_audio>;
/*
AVDD-supply = <&reg_audio>;
/*
CPVDD-supply = <&reg_audio>;
/*
MICVDD-supply = <&reg_audio>;
/*
PLLVDD-supply = <&reg_audio>;
/*
SPKVDD1-supply = <&reg_audio>; /*
SPKVDD2-supply = <&reg_audio>; /*
gpio-cfg = <
0x0000 /* 0:Default */
0x0000 /* 1:Default */
0x0013 /* 2:FN_DMICCLK */
1.8v
1.8v
1.8v
1.8v
3.3v
1.8v
4.2v
4.2v
*/
*/
*/
*/
*/
*/
*/
*/
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
49
Audio Overview
};
>;
0x0000 /* 3:Default */
0x8014 /* 4:FN_DMICCDAT */
0x0000 /* 5:Default */
/* DT binding for DAI LINK driver */
sound {
compatible = "fsl,imx6q-sabresd-wm8962",
"sl,imx-audio-wm8962";
model = "wm8962-audio";
si-controller = <&ssi2>;
udio-codec = <&codec>;
};
audio-routing =
"Headphone Jack", "HPOUTL",
"Headphone Jack", "HPOUTR",
"Ext Spk", "SPKOUTL",
"Ext Spk", "SPKOUTR",
"MICBIAS", "AMIC",
"IN3R", "MICBIAS",
"DMIC", "MICBIAS",
"DMICDAT", "DMIC";
mux-int-port = <2>;
mux-ext-port = <3>;
hp-det-gpios = <&gpio7 8 1>;
/*active low*/
mic-det-gpios = <&gpio1 9 1>;
/*active low*/
NOTE
The specific meaning of the device tree binding can be checked
up in binding doc located in Documentation/devicetree/
bindings/sound/.
8.1.2 Porting the Reference BSP to a Custom Board (audio
codec is the same as in the reference design)
When the audio codec is the same in the reference design and the custom board, ensure
that the I/O signals and the power supplies to the codec are properly initialized in order to
port the reference BSP to the custom board.
Devicetree uses pin control group for I/O signals' configuration, there are some examples
in arch/arm/boot/dts/imx6qdl-sabresd.dtsi and the definitions of those pin control groups
can be found in arch/arm/boot/dts/imx6qdl.dtsi.
The essential signals for wm8962 codec are as follows:
• I2C interface signals
• I2S interface signals
• SSI external clock input to wm8962
The following table shows the required power supplies for the wm8962 codec.
i.MX BSP Porting Guide, Rev. 1, 01/2017
50
NXP Semiconductors
Chapter 8 Porting Audio Codecs to a Custom Board
Table 8-1. Required Power Supplies
Power Supply Name
Definition
Value
PLLVDD
PLL supply
1.8 V
SPKVDD1
Supply for left speaker drivers
4.2 V
SPKVDD2
Supply for right speaker drivers
4.2 V
DCVDD
Digital core supply
1.8 V
DBVDD
Digital supply
1.8 V
AVDD
Analog supply
1.8 V
CPVDD
Charge pump power supply
1.8 V
MICVDD
Microphone bias amp supply
3.3 V
8.1.3 Porting the Reference BSP to a Custom Board (audio
codec is different than the reference design)
When adding support for an audio codec that is different than the one on the Freescale
reference design, create new ALSA drivers in order to port the reference BSP to a custom
board. The ALSA drivers plug into the ALSA sound framework, which allows the
standard ALSA interface to be used to control the codec.
The source code for the ALSA driver is located in the Linux kernel source tree at linux/
sound/soc. The following table shows the files used for the wm8962 codec support:
Table 8-2. Files for wm8962 Codec Support
File Name
Definition
imx-pcm-dma.c
• Shared by the stereo ALSA SoC driver, the esai driver, and the spdif driver.
• Responsible for preallocating DMA buffers and managing DMA channels.
fsl_ssi.c
• Register the CPU DAI driver for the stereo ALSA SoC
• Configures the on-chip SSI interfaces
wm8962.c
• Register the stereo codec and Hi-Fi DAI drivers.
• Responsible for all direct hardware operations on the stereo codec.
imx-wm8962.c
• Machine layer code
• Create the driver device
• Register the stereo sound card.
NOTE
If using a different codec, adapt the driver architecture shown in
table above accordingly. The exact adaptation depends on the
codec chosen. Obtain the codec-specific software from the
codec vendor.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
51
Audio Overview
i.MX BSP Porting Guide, Rev. 1, 01/2017
52
NXP Semiconductors
Chapter 9
Porting the Ethernet Controller Driver
9.1 Ethernet Controller Overview
This chapter explains how to port the Ethernet controller driver to the i.MX 6 or i.MX 7
processor.
Using Freescale's standard driver makes porting to the i.MX 6 simple. Porting needs to
address the following three areas:
• Pin configuration
• Source code
• Ethernet connection configuration
9.1.1 Pin Configuration
The Ethernet Controller supports three different standard physical media interfaces: a
reduced media independent interface (RMII), a media independent interface (MII), and a
4-bit reduced RGMII.
In addition, the Ethernet Controller includes support for different standard MAC-PHY
(physical) interfaces for connection to an external Ethernet transceiver. The i.MX
Ethernet Controller supports the 10/100 Mbps MII, and 10/100 Mbps RMII. The i.MX
6Dual/6Quad/6Solo/6DualLite/6SoloX FEC also supports 1000 Mbps RGMII, which
uses 4-bit reduced GMII operating at 125 MHz.
A brief overview of the device functionality is provided here. For details, see the Ethernet
chapter of the following documents:
• i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM)
• i.MX 6Solo/6DualLite Applications Processor Reference Manual (IMX6SDLRM)
• i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM)
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
53
Ethernet Controller Overview
• i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM)
• i.MX 7Dual Applications Processor Reference Manual (IMX7DRM)
• i.MX 6UltraLite Applications Processor Reference Manual (IMX6ULRM)
In MII mode, there are 18 signals defined by the IEEE 802.3 standard and supported by
the EMAC. MII, RMII, and RGMII modes use a subset of the 18 signals. These signals
are listed in the following table.
Table 9-1. Pin Usage in MII RMII and RGMII Modes
Direction
EMAC Pin
Name
MII Usage
RMII Usage
RGMII Usage (not supported by i.MX
6SoloLite)
In/Out
FEC_MDIO
Management Data Input/Output Management Data
Input/output
Management Data Input/Output
Out
FEC_MDC
Management Data Clock
General output
Management Data Clock
Out
FEC_TXD[0]
Data out, bit 0
Data out, bit 0
Data out, bit 0
Out
FEC_TXD[1]
Data out, bit 1
Data out, bit 1
Data out, bit 1
Out
FEC_TXD[2]
Data out, bit 2
Not Used
Data out, bit 2
Out
FEC_TXD[3]
Data out, bit 3
Not Used
Data out, bit 3
Out
FEC_TX_EN
Transmit Enable
Transmit Enable
Transmit Enable
Out
FEC_TX_ER
Transmit Error
Not Used
Not Used
In
FEC_CRS
Carrier Sense
Not Used
Not Used
In
FEC_COL
Collision
Not Used
Not Used
In
FEC_TX_CLK
Transmit Clock
Not Used
Synchronous clock reference (REF_CLK,
can connect from PHY)
In
FEC_RX_ER
Receive Error
Receive Error
Not Used
In
FEC_RX_CLK
Receive Clock
Not Used
Synchronous clock reference (REF_CLK,
can connect from PHY)
In
FEC_RX_DV
Receive Data Valid
Receive Data Valid RXDV XOR RXERR on the falling edge
and generate CRS of FEC_RX_CLK.
In
FEC_RXD[0]
Data in, bit 0
Data in, bit 0
Data in, bit 0
In
FEC_RXD[1]
Data in, bit 1
Data in, bit 1
Data in, bit 1
In
FEC_RXD[2]
Data in, bit 2
Not Used
Data in, bit 2
In
FEC_RXD[3]
Data in, bit 3
Not Used
Data in, bit 3
Because i.MX 6 has more functionality than it has physical I/O pins, it uses I/O pin
multiplexing.
Every module requires specific pad settings. For each pad there are up to eight muxing
options called ALT modes. For further explanation, see IOMUX chapter in the following
documents:
• i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM)
i.MX BSP Porting Guide, Rev. 1, 01/2017
54
NXP Semiconductors
Chapter 9 Porting the Ethernet Controller Driver
• i.MX 6Solo/6DualLite Applications Processor Reference Manual (IMX6SDLRM)
• i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM)
• i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM)
• i.MX 7Dual Applications Processor Reference Manual (IMX7DRM)
• i.MX 6UltraLite Applications Processor Reference Manual (IMX6ULRM)
Note in designs with an external Ethernet PHY may require an external pin configured as
a simple GPIO to reset the Ethernet PHY before enabling physical clock. Otherwise,
some PHYs fail to work correctly.
9.1.2 Source Code
The source code for the Freescale Ethernet Linux environment is located under the linux/
drivers/net/ethernet/freescale/ directory. It contains the following files:
Table 9-2. Source Code Files
File Names
• fec.h
• fec_main.c
• fec_ptp.c
Descriptions
FEC low-level Ethernet driver:
The driver uses the following compile definitions:
CONFIG_FEC: enables the Ethernet Controller driver.
9.1.3 Ethernet Configuration
This section mainly covers Ethernet driver bring up issues. For more information about
Ethernet MAC configuration, see the following documents:
• i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM)
• i.MX 6Solo/6DualLite Applications Processor Reference Manual (IMX6SDLRM)
• i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM)
• i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM)
• i.MX 7Dual Applications Processor Reference Manual (IMX7DRM)
• i.MX 6UltraLite Applications Processor Reference Manual (IMX6ULRM)
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
55
Ethernet Controller Overview
Note the following during Ethernet driver bring up:
• Configure all I/O pins used by MAC correctly in dts files.
• Check physical input clock and power, physical led1 and led2 lighten on if clock and
power input are ok.
• Make sure that MAC tx_clk has the right clock input. Otherwise, MAC cannot work.
• Make sure that the MAC address is set and valid.
By default, the Ethernet driver gets the MAC address from the Ethernet node property
"local-mac-address" in dts file. If dts does not have the property, the driver get the MAC
address from fuse. If the fuse does not burn the MAC address, the driver gets the MAC
address from the Ethernet registers set by the bootloader. If no legal MAC address exists,
MAC malfunctions. In this example, add the MAC address in the U-Boot command line
for kernel, such as "fec.macaddr=0x00,0x01,0x02,0x03,0x04,0x05" in bootargs.
The Ethernet driver and hardware are designed to comply with the IEEE standards for
Ethernet auto-negotiation. For a description of using flow control in full duplex and
more, see the Ethernet chapter in the following documents:
• i.MX 6Dual/6Quad Applications Processor Reference Manual (IMX6DQRM)
• i.MX 6Solo/6DualLite Applications Processor Reference Manual (IMX6SDLRM)
• i.MX 6SoloLite Applications Processor Reference Manual (IMX6SLRM)
• i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM)
• i.MX 7Dual Applications Processor Reference Manual (IMX7DRM)
• i.MX 6UltraLite Applications Processor Reference Manual (IMX6ULRM)
i.MX BSP Porting Guide, Rev. 1, 01/2017
56
NXP Semiconductors
Chapter 10
Porting USB Host1 and USB OTG
10.1 USB Overview for i.MX 6Dual/6Quad/6Solo/6DualLite/
6UltraLite/7Dual
There are up to four USB ports on i.MX 6Dual/6Quad/6Solo/6DualLite/6UltraLite/7Dual
serial application processors:
•
•
•
•
USB OTG port
USB H1 port
USB HSIC1 port
USB HSIC2 port
NOTE
There is no HSIC2 port on i.MX 6SoloLite.
The following power supplies must be provided:
•
•
•
•
5V power supply for USB OTG VBUS
5V power supply for USB H1 VBUS
3.3V power supply for HSIC1/2 port
3.15 +/- 5%V power supply for USB OTG/H1 PHY. Since this power can be routed
from USB OTG/H1 VBUS, it indicates that if either of the power supplies is
powered up, the USB PHY is powered as well. However, if neither can be powered
up, an external power supply is needed.
For the USB OTG port, the following signals are used:
•
•
•
•
•
•
•
USB_OTG_CHD_B
USB_OTG_VBUS
USB_OTG_DN
USB_OTG_DP
USBOTG_ID
USBOTG_OC_B
one pin is used to control USB_OTG_VBUS signal
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
57
USB Overview for i.MX 6Dual/6Quad/6Solo/6DualLite/6UltraLite/7Dual
The following signals, needed to set with proper IOMUX, are multiplexed with other
pins.
NOTE
For the USBOTG_ID pin, a pin which has an alternate
USBOTG_ID function must be used.
• USBOTG_ID
• USBOTG_OC_B
• one pin used to control USB_OTG_VBUS signal
For USB H1 port, the following signals are used:
•
•
•
•
USB_H1_VBUS
USB_H1_DN
USB_H1_DP
USBH_OC_B
The following signals are multiplexed with other pins, and need to set with proper
IOMUX:
• USBH_OC_B
For USB HSIC 1/2 port, the following signals are used:
•
•
•
•
H2_STROBE
H3_STROBE
H2_DATA
H3_DATA
The following signals are multiplexed with other pins, and need to set with proper
IOMUX:
•
•
•
•
H2_STROBE
H3_STROBE
H2_DATA
H3_DATA
To secure HSIC connection, the USB HSIC port must be powered up before the USB
HSIC device
For i. MX 6SoloLite, there is only one HSIC port, so only H2_xxx signals are used.
i.MX BSP Porting Guide, Rev. 1, 01/2017
58
NXP Semiconductors
Chapter 10 Porting USB Host1 and USB OTG
10.2 USB Overview for i.MX 6SoloLite/6SoloX
There are up to three USB ports on i.MX 6 SoloLite/6SoloX serial application
processors:
• USB OTG1 port
• USB OTG2 port
• USB HSIC1 port
The following power supplies must be provided:
•
•
•
•
5V power supply for USB OTG1 VBUS
5V power supply for USB OTG2 VBUS
3.3V power supply for HSIC1 port
3.15 +/- 5%V power supply for USB OTG1/OTG2 PHY. Since this power can be
routed from USB OTG1/OTG2 VBUS, it indicates that if either of the power
supplies is powered up, the USB PHY is powered as well. However, if neither can be
powered up, an external power supply is needed.
For the USB OTG1 port, the following signals are used:
•
•
•
•
•
•
•
USB_OTG1_CHD_B
USB_OTG1_VBUS
USB_OTG1_DN
USB_OTG1_DP
USBOTG1_ID
USBOTG1_OC_B
one pin is used to control USB_OTG1_VBUS signal
The following signals, needed to set with proper IOMUX, are multiplexed with other
pins.
NOTE
For the USBOTG_ID pin, a pin which has an alternate
USBOTG_ID function must be used.
• USBOTG_ID
• USBOTG_OC_B
• one pin used to control USB_OTG_VBUS signal
For USB OTG2 port, the following signals are used:
• USB_OTG2_VBUS
• USB_OTG2_DN
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
59
USB Overview for i.MX 6SoloLite/6SoloX
• USB_OTG2_DP
• USBOTG2_OC_B
The following signals are multiplexed with other pins, and need to set with proper
IOMUX:
• USBOTG2_OC_B
For USB HSIC 1 port, the following signals are used:
• H2_STROBE
• H2_DATA
The following signals are multiplexed with other pins, and need to set with proper
IOMUX:
• H2_STROBE
• H2_DATA
To secure HSIC connection, the USB HSIC port must be powered up before the USB
HSIC device
i.MX BSP Porting Guide, Rev. 1, 01/2017
60
NXP Semiconductors
Chapter 11
Revision History
11.1 Revision History
This table provides the revision history.
Table 11-1. Revision history
Revision number
Date
Substantive changes
0
09/2016
Initial release
1
01/2017
Deleted obsolete information.
i.MX BSP Porting Guide, Rev. 1, 01/2017
NXP Semiconductors
61
Revision History
i.MX BSP Porting Guide, Rev. 1, 01/2017
62
NXP Semiconductors
How to Reach Us:
Information in this document is provided solely to enable system and software
Home Page:
nxp.com
implementers to use NXP products. There are no express or implied copyright licenses
Web Support:
nxp.com/support
information in this document. NXP reserves the right to make changes without further
granted hereunder to design or fabricate any integrated circuits based on the
notice to any products herein.
NXP makes no warranty, representation, or guarantee regarding the suitability of its
products for any particular purpose, nor does NXP assume any liability arising out of
the application or use of any product or circuit, and specifically disclaims any and all
liability, including without limitation consequential or incidental damages. ìTypicalî
parameters that may be provided in NXP data sheets and/or specifications can and do
vary in different applications, and actual performance may vary over time. All operating
parameters, including ìtypicals,î must be validated for each customer application by
customerís technical experts. NXP does not convey any license under its patent rights
nor the rights of others. NXP sells products pursuant to standard terms and conditions
of sale, which can be found at the following address:
nxp.com/SalesTermsandConditions.
NXP, the NXP logo, Freescale, and the Freescale logo are trademarks of NXP B.V. All
other product or service names are the property of their respective owners.
ARM, the ARM logo, and Cortex are registered trademarks of ARM Limited (or its
subsidiaries) in the EU and/or elsewhere. All rights reserved.
© 2017 NXP B.V.
Document Number: IMXBSPPG
Rev. 1
01/2017
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement