i.MX53 System Development User’s Guide Supports i.MX53 MX53UG Rev.
How to Reach Us: Home Page: www.freescale.com Web Support: http://www.freescale.com/support USA/Europe or Locations Not Listed: Freescale Semiconductor, Inc. Technical Information Center, EL516 2100 East Elliot Road Tempe, Arizona 85284 +1-800-521-6274 or +1-480-768-2130 www.freescale.
Contents Paragraph Number Title Page Number Contents About This Guide Audience ......................................................................................................................... xvii Organization................................................................................................................... xviii Essential Reference.......................................................................................................... xix Suggested Reading.....................
Contents Paragraph Number Title Page Number Chapter 3 Understanding the IBIS Model 3.1 3.2 3.3 3.4 3.4.1 3.5 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.7 3.8 IBIS Structure and Content.............................................................................................. 3-1 Header Information.......................................................................................................... 3-2 Component and Pin Information..........................................................................
Contents Paragraph Number Title Page Number Chapter 5 Setting up Power Management 5.1 5.2 5.2.1 5.3 5.3.1 5.3.2 5.4 5.5 5.5.1 5.6 5.6.1 5.6.2 i.MX53 Internal LDOs..................................................................................................... 5-1 Interfacing the i.MX53 Processor with the DA9053 ....................................................... 5-3 Connecting Power and Communication Signals ......................................................... 5-6 Interfacing the i.
Contents Paragraph Number Page Number Title Chapter 8 Using the Clock Connectivity Table Chapter 9 Configuring JTAG Tools for Debugging 9.1 9.2 Accessing Debug with a JTAG Scan Chain (ARM tools) ............................................... 9-1 Accessing Debug with a JTAG Scan Chain (other JTAG tools)...................................... 9-4 Chapter 10 Porting the On-Board-Diagnostic-Suite (OBDS) to a Custom Board 10.1 10.2 10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 10.2.6 10.2.7 10.2.8 10.2.
Contents Paragraph Number 12.2.2 12.2.3 12.3 12.4 12.5 Title Page Number Changing the Configuration File ............................................................................... 12-3 Android's Memory Map ............................................................................................ 12-3 Initializing Android........................................................................................................ 12-4 Modifying the init.rc Partition Locations ............................
Contents Paragraph Number Page Number Title Chapter 16 Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver 16.1 16.2 16.3 16.4 16.4.1 16.4.2 16.4.3 16.4.4 16.5 16.6 Source Code Structure ................................................................................................... 16-1 Configuration Options ................................................................................................... 16-1 Selecting SPI NOR on the Linux Image ....................................
Contents Paragraph Number 18.4.5 18.5 Title Page Number Adding BSP Support for a New Boot Command to Select CLAA057VA01CT LCD ...... 18-14 i.MX53 Display Interface Helpful Information ........................................................... 18-15 Chapter 19 Connecting an LVDS Panel to an i.MX53 Reference Board 19.1 19.2 19.2.1 19.2.2 19.3 19.3.1 19.3.2 19.4 Connecting an LVDS Panel to the i.MX53 EVK Board................................................ 19-1 Enabling an LVDS Channel..................
Contents Paragraph Number Title Page Number Chapter 22 Porting the Fast Ethernet Controller Driver 22.1 22.2 22.3 Pin Configuration........................................................................................................... 22-1 Source Code ................................................................................................................... 22-2 Ethernet Configuration ..................................................................................................
Figures Figure Number Title Page Number Figures 1-1 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 2-15 2-16 2-17 2-18 2-19 2-20 2-21 2-22 2-23 2-24 2-25 2-26 2-27 2-28 2-29 3-1 3-2 3-3 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 Boot Configuration Bus Isolation Resistors............................................................................ 1-8 i.MX53 Ball-Grid Array ......................................................................................................... 2-1 i.
Figures Figure Number 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8 5-9 5-10 5-11 5-12 5-13 6-1 6-2 6-3 6-4 6-5 6-6 6-7 8 9-1 9-2 9-3 12-1 12-2 12-3 12-4 15-1 15-2 16-1 18-1 18-2 Title Page Number Display of Other Signals Available on an Assigned Ball ..................................................... 4-10 Choosing the Ball Diagram Tab Displays the Device’s Ball Map ........................................ 4-11 Basic Substring Text Searching ...................................
Figures Figure Number 18-3 18-4 19-1 20-1 20-2 20-3 20-4 20-5 Title Page Number Graphics Support Options Menu......................................................................................... 18-10 i.MX53 Board Display Interface Layout ............................................................................ 18-15 i.MX53 LVDS Display Bridge (LDB) Block ....................................................................... 19-3 Camera Interface Layout............................................
Figures Figure Number Title Page Number i.MX53 System Development User’s Guide, Rev.
Tables Table Number Title Page Number Tables 1-1 1-2 1-3 1-4 1-5 1-6 2-1 2-2 2-3 2-4 3-1 3-2 3-3 3-4 3-5 3-6 5-1 5-2 5-3 5-4 7-1 7-2 8-1 12-1 13-1 13-2 14-1 14-2 14-3 15-1 15-2 15-3 16-1 16-2 16-3 17-1 18-1 18-2 18-3 18-4 18-5 Design Checklist ..................................................................................................................... 1-1 DDR Vref Resistor Sizing Guideline ......................................................................................
Tables Table Number 18-6 18-7 18-8 20-1 20-2 20-3 21-1 21-2 22-1 22-2 Title Page Number 720P TV Example Variables ................................................................................................. 18-7 Sample Values ....................................................................................................................... 18-9 Required Functions .............................................................................................................
About This Guide The i.MX53 multimedia applications processor (i.MX53) is Freescale Semiconductor, Inc.’s latest addition to a growing family of multimedia-focused products that offer high performance processing optimized for the lowest power consumption. The i.MX53 processors feature Freescale’s advanced implementation of the ARM Cortex-A8™ core which operates at speeds as high as 1.2 GHz.
About This Guide Organization This guide is a compendium of application notes organized in two parts. The first part covers aspects of hardware design and bring-up, and the second focuses on software development. Part I, “Hardware Design and Bring-up” covers topics that aid you in the design of a custom printed circuit board design utilizing the i.MX53.
About This Guide • • • Chapter 21, “Porting Audio Codecs to a Custom Board” Chapter 22, “Porting the Fast Ethernet Controller Driver” Chapter 23, “Porting USB Host1 and USB OTG” Essential Reference You should have access to an electronic copy of the latest version of the i.MX53 Multimedia Applications Processor Reference Manual (MCIMX53RM) and i.MX53xD Applications Processors for Consumer Products (IMX53CEC).
About This Guide Book titles in text are set in italics Internal signals are written in all lowercase Prefix to denote hexadecimal number Prefix to denote binary number Instruction syntax used to identify a source GPR Instruction syntax used to identify a destination GPR Abbreviations for registers are shown in uppercase text. Specific bits, fields, or ranges appear in brackets. For example, MSR[LE] refers to the little-endian mode enable bit in the machine state register.
About This Guide Definitions and Acronyms (continued) Term Definition CODEC Coder/decoder or compression/decompression algorithm—Used to encode and decode (or compress and decompress) various types of data. CPU Central Processing Unit—generic term used to describe a processing core. CRC Cyclic Redundancy Check—Bit error protection method for data communication. CSI Camera Sensor Interface DMA Direct Memory Access—an independent block that can initiate memory-to-memory data transfers.
About This Guide Definitions and Acronyms (continued) Term Definition IrDA Infrared Data Association—a nonprofit organization whose goal is to develop globally adopted specifications for infrared wireless communication. ISR Interrupt Service Routine. JTAG Kill JTAG (IEEE Standard 1149.1) A standard specifying how to control and monitor the pins of compliant devices on a printed circuit board. Abort a memory access.
About This Guide Definitions and Acronyms (continued) Term Definition RGBA RGBA color space stands for Red Green Blue Alpha. The alpha channel is the transparency channel, and is unique to this color space. RGBA, like RGB, is an additive color space, so the more of a color you place, the lighter the picture gets. PNG is the best known image format that uses the RGBA color space.
About This Guide i.MX53 System Development User’s Guide, Rev.
Part I Hardware Design and Bring-up The chapters that follow cover topics that aid you in the hardware design, bring-up, and debug of your custom printed circuit board utilizing the i.MX53. i.MX53 System Development User’s Guide, Rev.
Hardware Design and Bring-up i.MX53 System Development User’s Guide, Rev.
Chapter 1 Design Checklist This chapter provides a design checklist for i.MX53-based systems. The design checklist contains recommendations for optimal design. Where appropriate, the checklist also provides an explanation so that users have a greater understanding of why certain techniques are recommended. All supplemental tables referenced by the checklist appear following the design checklist table. Table 1-1.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations EIM Recommendations 3. When EIM boot signals are used as the system’s EIM signals or GPIO outputs after boot, use a passive resistor network to select the desired boot mode for development boards. Because only resistors are used, EIM bus loads can cause current drain, leading to higher (false) supply current measurements.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations JTAG Recommendations 9. Do not use external pull-up or pull-down resistors on JTAG_TDO. JTAG_TDO is configured with an on-chip keeper circuit such that the floating condition is eliminated if an external pull resistor is not present. An external pull resistor on JTAG_TDO is detrimental. See Table 1-5 for a summary of the JTAG interface. 10.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations Miscellaneous Signal Recommendations 16. Tie FASTR_ANA and FASTR_DIG connections to GND FASTR_ANA and FASTR_DIG are reserved for Freescale manufacturing use only. 17. Float TEST_MODE or tie it to GND. TEST_MODE is for Freescale factory use only. This signal is internally connected to an on-chip pull-down device. 18. Float the USB_H1_GPANAIO and USB_OTG_GPANAIO outputs.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations 25. USB I/O D+, D–, and UID contacts on the i.MX device — require external ESD (electro-static discharge) damage protection. Power Recommendations 26. Comply with the power-up and power-down sequence guidelines as described in the data sheet to guarantee reliable operation of the device.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations 30. If feeding an external clock into the device, CKIL can The logic high level driven into CKIL should be be driven DC-coupled with ECKIL floated. approximately NVCC_SRTC_POW. Do not exceed NVCC_SRTC_POW or damage/malfunction may occur. The CKIL signal should not be driven if the NVCC_SRTC_POW supply is off. This can lead to damage or malfunction.
Design Checklist Table 1-1. Design Checklist (continued) Check Box Recommendation Explanation/Supplemental Recommendations SATA Recommendations 34. The impedance calibration process requires connecting a 191 Ω 1% reference resistor on SATA_REXT to ground. Mount this resistor close to the associated BGA ball.
Design Checklist 1.1 Boot Configuration Bus Isolation Resistors Figure 1-1 shows the boot configuration bus isolation resistors referenced in recommendation 3. SW4_3V3 IMX_LDO _1V8 SW4_3V3 20 19 18 17 16 15 14 13 12 11 SW4_3V3 S1 SW _DI P- 10/SM 1 2 3 4 5 6 7 8 9 10 0 0 0 0 0 0 0 0 0 0 0 0 0 R 13 R 12 R 11 R 10 R9 R8 R7 R6 DNP DNP DNP DNP DNP 10 R5 10 5 BT_C FG 1_7 BT_C FG 1_6 BT_C FG 1_5 BT_C FG 1_4 BT_C FG 1_3 BT_C FG 1_2 BT_C FG 1_1 BT_C FG 1_0 4.7K 4.7K 4.7K 4.
Design Checklist Table 1-2. DDR Vref Resistor Sizing Guideline (continued) 1.3 Number of DRAM Packages with 2 μA Vref Input Current Resistor Divider Value (2 resistors) 4 1 kΩ 0.5% 4 1.5 kΩ 0.1% Avoiding I2C Conflicts Table 1-3 shows a spreadsheet for avoiding avoid I2C conflicts (see recommendation 7). Table 1-3.
Design Checklist 1.4 JTAG Signal Termination Table 1-5 is a JTAG termination chart (see recommendation 9 and recommendation 10). Table 1-5. JTAG Interface Summary JTAG Signal i.
Chapter 2 i.MX53 Layout Recommendations This chapter provides recommendations to assist design engineers with the correct layout of their i.MX53x-based system. The majority of the chapter discusses the implementation of the DDR interface, but it also provides recommendation for power, the TV encoder, SATA, LVDS, reference resistors, and ESD and related emissions. This chapter uses the i.MX53 Quick Start board as its reference when illustrating the key concepts. Refer to the existing i.
i.MX53 Layout Recommendations Figure 2-2. i.MX53 Package Information Maintaining the recommended footprint of a 12 mils pad, which allows an air gap of 19.5-mils between pads, is critical for ease of fanout. If using the Allegro tool, optimal practice is to use the footprint as created by Freescale. If not using the Allegro tool, use the Allegro footprint export feature (supported by many tools).
i.MX53 Layout Recommendations 2.1.1 Fanout Figure 2-3 shows the fanouts for the i.MX53 for two different layers. Figure 2-3. i.MX53 Fanouts The fanout scheme creates a four quadrant structure that facilitates the placement of decoupling capacitors on the bottom side of the PCB. This keeps them closer to the power balls, which is critical for minimizing inductance and ensuring high-speed transient current demand by the processor. A correct via size is critical for preserving adequate routing space.
i.MX53 Layout Recommendations 2.2 Stackup High-speed design requires a good stackup in order have the right impedances for the critical traces. This also determines the constraints for routing and spacing. The recommended stackup is 8-layers, with the layer stack as shown in Figure 2-4: Figure 2-4. Layer Stack Figure 2-5 shows a working stack-up implementation: Figure 2-5. Stackup Requirements i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations 2.3 DDR Connection Information The DDR2 and DDR3 interface is one of the most critical for i.MX53 routing. It requires having the controlled impedance for the single ended traces at 50 Ω and for the differential pairs at 100 Ω. Figure 2-6 shows the block diagram of the DDR2/DDR3 interface with the i.MX53 from the reference design boards. Figure 2-6. Connection Between i.
i.MX53 Layout Recommendations and keep the propagation delay to the minimum. Follow the reference board layout as a guideline for memory placement and routing. Figure 2-7 shows the final placement of the memories and the decoupling capacitors. The blue figure shows the top layer and the red figure shows the bottom layer. Figure 2-7. Final Placement of Memories and Decoupling Capacitors 2.
i.MX53 Layout Recommendations Routing by byte group requires better control of the signals of each group. It is also a little more difficult for analysis and constraint settings. However, its advantage is that the constraint to match lengths can be applied to a smaller group of signals. This is often more achievable once the constraints are properly set. Table 2-2 explains how to route the signals by byte group. Table 2-2. DDR2/DDR3 Routing by Byte Group Length i.
i.MX53 Layout Recommendations 2.5.1 1 Gbyte Topologies The 1 Gbyte option has four memories. For good practice, adhere to the following recommendations: • Have a balanced routing for the “T” connection. • Avoid having many layer transitions. • Do not cross split planes during the routing. Figure 2-8 shows the topology for the ADDR/CMD/CTRL signals. It has a tree topology. Note the balanced T routing. DDR Top DDR Bottom DDR Top DDR Bottom i.MX53 Figure 2-8.
i.MX53 Layout Recommendations If the data bus is two byte groups by memory, the topology is fly-by, as shown in Figure 2-10. DDR Top DDR Bottom DDR Top DDR Bottom i.MX53 Figure 2-10. Topology for Data Bus of Two Byte Groups by Memory Figure 2-11 shows the clock routing topology. Clock routing uses a fly-by topology. The i.MX53 provides two sets of clocks that are identical in timing and drive. This allows the user to select either clock pair to route to the DDR devices.
i.MX53 Layout Recommendations The ADDR/CMD signals should be routed as shown in Figure 2-12 Figure 2-12. ADDR/CMD Signal Routing Figure 2-13 shows the CTRL signals topology: Figure 2-13. CTRL Signal Topology Figure 2-14 shows the data bus routing topology. Figure 2-14. Data Bus Routing Topology i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Figure 2-15 shows the clock routing topology. Figure 2-15. Clock Routing Topology i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations 2.5.3 DDR2 Routing Examples Figure 2-16–Figure 2-21 show examples for the routing of DDR2 memories. These figures are a guideline of the routing by layer. Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-16. Top DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-17. Internal 1 DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-18. Power Plane 1 DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-19. Power Plane 2 DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-20. Internal 2 DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Yellow Meaning Color Meaning ADD/CMD/CTRL Signals Purple Data Byte Group 1 Soft Blue Data Byte Group 3 White Clocks Soft Pink Data Byte Group 0 Blue DDR_1V8 Green Data Byte Group 2 Pink DDR_VREF Figure 2-21. Bottom DDR2 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Table 2-3 shows the total etch of the signals for the byte 0 and byte 1 groups. Table 2-3. Total Signal Etch (DDR2) 1 1 Signals Length (Mils) DRAM_D0 667.16 DRAM_D1 663.66 DRAM_D2 666.01 DRAM_D3 663.89 DRAM_D4 662.69 DRAM_D5 663.41 DRAM_D6 668.31 DRAM_D7 664.02 DRAM_DQM0 663.5 DRAM_SDQS0 663.62 DRAM_SDQS0_B 668.24 DRAM_D8 668.57 DRAM_D9 663.69 DRAM_D10 664.28 DRAM_D11 666.39 DRAM_D12 664.75 DRAM_D13 668.45 DRAM_D14 664.65 DRAM_D15 663.
i.MX53 Layout Recommendations 2.5.4 2-Gbyte Routing Examples Figure 2-22–Figure 2-27 show examples for the routing of 2-Gbyte DDR memories. These figures are a guideline of the routing by layer. NOTE The Quick Start board referenced in the beginning of this chapter does not use 8 DDR chips. The following screen shots are from the validation board layout. i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-22. Top 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-23. Internal 1 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-24. Power Plane 1 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-25. Power Plane 2 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-26. Internal 2 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Color Legend Color Meaning Color Meaning Yellow ADD/CMD/CTRL Signals White Clocks Soft Blue Data Byte Group 3 Blue DDR_1.5V Soft Pink Data Byte Group 0 Pink DDR_VREF Green Data Byte Group 2 Orange DDRQ_1.5V Purple Data Byte Group 1 White Clocks Figure 2-27. Bottom 8-DDR3 Routing i.MX53 System Development User’s Guide, Rev.
i.MX53 Layout Recommendations Table 2-4 shows the total etch of the signals for the byte 0 and byte 1 groups. Table 2-4. Total Signal Etch (DDR3) 2.6 Signals Length (Mils) DRAM_D0 616.034 DRAM_D1 612.886 DRAM_D2 613.808 DRAM_D3 612.701 DRAM_D4 617.177 DRAM_D5 614.486 DRAM_D6 614.743 DRAM_D7 613.145 DRAM_DQM0 612.794 DRAM_SDQS0 615.633 DRAM_SDQS0_B 614.36 DRAM_D8 615.063 DRAM_D9 611.525 DRAM_D10 616.758 DRAM_D11 614.928 DRAM_D12 614.521 DRAM_D13 612.822 DRAM_D14 612.
i.MX53 Layout Recommendations • • Decouple using distributed 0.01 μF and 0.1 μF capacitors by the regulator, controller, and devices. Place one 0.1 μF near the source of VREF, one near the VREF pin on the controller, and two between the controller and the devices. The following recommendations apply to the VTT voltage reference plane. • Place the VTT island on the component side layer at the end of the bus behind the DRAM devices. • Use a wide-island trace for current capacity.
i.MX53 Layout Recommendations Figure 2-28 shows the dimensions of a stripline and microstrip pair. Figure 2-29 shows the differential pair routing. Figure 2-28. Microstrip and Stripline Differential Pair Dimensions Figure 2-29. Differential Pair Routing • • 2.10 The space between two adjacent differential pairs should be greater than or equal to twice the space between the two individual conductors. The skew between LVDS pairs should be within the minimum recommendation (± 100 mil).
i.MX53 Layout Recommendations • • • • • USB_OTG_RREFEXT SATA_REXT LVDS_BG_RES TVDAC_VREF DRAM_CALIBRATION Freescale recommends the use of a resistor of 1% tolerance or better with a connection that is made through a short trace. The resistance of the connecting trace should be as low as possible (< 1 Ω). The ground return should be short and direct to the ground plane. NOTE The reference resistor and the connection should be placed away from noisy regions.
i.MX53 Layout Recommendations i.MX53 System Development User’s Guide, Rev.
Chapter 3 Understanding the IBIS Model This chapter explains how to use the IBIS (input output buffer information specification) model, which is an Electronic Industries Alliance standard for the electronic behavioral specifications of integrated circuit input/output analog characteristics. The model is generated in ACII text format and consists of multiple tables that capture current vs. voltage (IV) and voltage vs. time (VT) characteristics of the buffer.
Understanding the IBIS Model 3.2 Header Information The first section of an IBIS file provides the basic information about the file and its data. Table 3-1 explains the header information notation. Example 3-1 shows what header information looks like in an IBIS file. Table 3-1. Header Information Keyword Required Description [IBIS Ver] Yes Version of IBIS Specification this file uses. [Comment char] No Change the comment character.
Understanding the IBIS Model Table 3-2. Component and Pin Information (continued) Keyword Required Comment [Manufacturer] Yes The name of the component manufacturer [Package] Yes This keyword contains the range (minimum, typical and maximum values) over which the packages’ lead resistance, inductance, and capacitance vary (the R_pkg, L_pkg, and C_pkg parameters). [Pin] Yes This keyword contains the pin-to-buffer mapping information.
Understanding the IBIS Model 3.4 Model Information The [Model Selector] keyword provides a simple means by which several buffers can be made optionally available for simulation at the same physical pin of the component, as shown in Example 3-3. Example 3-3. Model Selector Keyword Example [Pin] signal_name model_name R_pin AA4 JTAG_TDI gpio 0.307112 … [Model Selector] gpio gpio_iods0hvf GPIO, 2.7V, Low Drive, Fast SR gpio_iods0hvs GPIO, 2.7V, Low Drive, Slow SR …… L_pin C_pin 5.51128nH 0.
Understanding the IBIS Model 3.4.1 Ramp and Waveform Keywords Table 3-3 defines the keywords that provide the information about an output or I/O buffer, and Example 3-4 shows what they look like in an IBIS file. Table 3-3. Ramp and Waveform Keywords Keyword Required Comment [Ramp] Yes Basic ramp rate information, given as a dV/dt_r for rising edges and dV/dt_f for falling edges, see Equation 3-1. [Rising Waveform] No The actual rising (low to high transition) waveform, provided as a VT table.
Understanding the IBIS Model • [Ramp] effectively averages the transitions of the device, without providing any details on the shapes of the transitions themselves. All detail of the transition ledges would be lost. The VT data should be included under two [Rising Waveform] and two [Falling Waveform] sections, each containing data tables for a Vcc-connected load and a Ground-connected load (although other loading combinations are permitted).
Understanding the IBIS Model 3.5 Model Golden Waveforms Golden waveforms are a set of waveforms simulated using known ideal test loads. They are useful for verifying the accuracy of behavioral simulation results against the transistor level circuit model from which the IBIS model parameters originated. Figure 3-3 shows a generic test load network.
Understanding the IBIS Model 3.6.1 [Model Selector] ddr This model has the following parameters: voltage, mode of operation, drive strength, ODT enable/disable. Mode of operation Controlled by the IOMUXC_SW_PAD_CTL_GRP_DDR_TYPE[26:25] register in IOMUXC (IOMUX controller) DDR_SEL bits.
Understanding the IBIS Model 3.6.3 [Model Selector] lvio This model has no controllable parameters. Its associated pins are used as input only (for boot, reset) and cannot be configured. The listed drive strength and slew rate options in the IBIS file have no meaning. 3.6.4 [Model Selector] uhvio This model has the following parameters: voltage, drive strength, slew rate.
Understanding the IBIS Model 3.6.5 List of Pins Not Modeled in the i.MX53 IBIS File Table 3-5 provides a list of analog or special interface pins that are not modeled in the i.MX53 IBIS file: Table 3-5.
Understanding the IBIS Model Correlation Level A means for categorizing I/O buffer characterization data based on how much the modeling engineer knows about the processing conditions of a sample component and which correlation metric he or she used.
Understanding the IBIS Model i.MX53 System Development User’s Guide, Rev.
Chapter 4 Using the IOMUX Design Aid This chapter explains how to use of the IOMUX system design aid (IOMux.exe), which facilitates the assignment of internal signals to external device balls/pins. The IOMUX design aid performs the following functions: • Makes signal assignments for the supported i.
Using the IOMUX Design Aid 4.2.1 Identifying Signal Conflicts with the Signal Selection Pane Figure 4-1 shows the application window after the following sequence: 1. Launch IOMux.exe application. 2. Select Device > i.MX35 TO2.1. 3. Check all UARTS (UART1, UART2, and UART3). 4. Expand the signals UART3_RXD_MUX and UART3_TXD_MUX. Figure 4-1. Application Window after Expanding UARTs 2 and 3 of i.MX35 TO2.1 The orange highlighting in the signal selection pane indicates conflicts between signals.
Using the IOMUX Design Aid bolding indicates that UART2_CTS conflicts with UART3_TXD_MUX. All conflicts on a ball are bolded so that the user knows the conflicts exist. Figure 4-2. Hovering Mouse over a Signal to Show Other Signals Sharing that Ball/Pin i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid Hovering the mouse over the same signal, UART3_TXD_MUX, in the signals tab on the right-hand side of the screen is another way to show a list of signals shared on a given ball or pin (see Figure 4-3). Note that unlike in the signal selection pane, the list in the signals tab does not indicate conflicts. Figure 4-3. Hovering Mouse over a Signal in the Signals Tab i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid Conflicts are resolved by reassigning signals. However, before reassigning signals, it is important to check for potential conflicts. This is done by expanding signals in the signal selection pane. Figure 4-4 demonstrates this by expanding the signal UART3_RTS. Notice that the ball option U4 for UART3_RTS is highlighted in yellow, which indicates that selecting U4 for this signal would conflict with a previously assigned signal on that ball (which is not shown in the figure).
Using the IOMUX Design Aid In this example, the conflicts are resolved by assigning V13 to UART3_RXD_MUX and T13 to UART3_TXD, as shown in Figure 4-5. Notice that the original ball assignments for these two signals are now highlighted in yellow, which indicates that conflicts exist if the signals are assigned to those balls. All the conflicts in our example have now been resolved. Figure 4-5.
Using the IOMUX Design Aid Figure 4-6 shows the signals tab after right-clicking on the UART2_TXD_MUX row. This brought up the contextual menu for entering a comment. Clicking on the menu brings up a text entry field where the user may enter text, which is circled in purple in the example. Figure 4-6. Signal Tab with Comment Entry Menu i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid After the user enters the desired text and clicks okay, the comment is added to the signals tab in the signal notes column, as shown in Figure 4-7. Figure 4-7. UART2_TXD_MUX with Note i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid Once finished with changes, users should use File > Save As to save the design for future use or reference. Figure 4-8 shows the dialog box. The native format for a design is XML. Users may choose to instead save the a new design in RTF or TXT formats (notice the “ *” in the title bar). However, the actual design is only saved if it is saved as an XML file. Navigate to a desired directory on the host machine and then change the design’s filename, if desired.
Using the IOMUX Design Aid 4.3 Toggling the Alternate View of the Signals Tab The alternate view of the signals tab may be seen by selecting View > Shared Signals, as shown in Figure 4-9. This view allows users to see which other signals may be routed to a particular ball, thus allowing users to quickly see which signals are sacrificed by any particular signal assignment. Figure 4-9. Display of Other Signals Available on an Assigned Ball i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid 4.3.1 Finding Assigned Signal Locations with the Ball Diagram Tab For some signals, proximity to other devices may be an issue because of critical routing. Use the ball diagram tab to see where assigned signals are located on the actual package. Hovering the mouse over a ball produces a pop up list that shows all signals that are capable of being connected to that ball. The actual assigned signal is bolded, as shown in Figure 4-10.
Using the IOMUX Design Aid 4.4 Using the Search Box to Find Specific Signals or Balls Use the search box (circled in purple in Figure 4-11) to find a specific signal or ball. This conducts a basic substring search that highlights search hits in green, as shown in Figure 4-11. Figure 4-11. Basic Substring Text Searching i.MX53 System Development User’s Guide, Rev.
Using the IOMUX Design Aid 4.5 IOMUX Features Guide This section provides a guide to the IOMUX features. Figure 4-12 shows a screenshot of the IOMUX application window with the addition of labels for the main areas. Each labeled area is discussed in greater detail in the following subsections. Figure 4-12. IOMux.exe Application Window Overview 4.5.1 Title Bar The title bar shows the application name.
Using the IOMUX Design Aid • • View—used to change view settings Help—used to display application version information about the IOMUX application 4.5.2.1 File Menu Figure 4-13 provides a partial view of the application window, showing the expanded options for the file menu. Note that some options list a keystroke combination that can be used as an alternative to selecting it through the file menu. Figure 4-13.
Using the IOMUX Design Aid 4.5.2.2 Device Menu Figure 4-14 provides a partial view of the application window, showing the expanded options for the device menu. Figure 4-14. Detailed View of the Device Menu Use the device menu to choose the desired device for your design. This menu only shows supported device and package options. If the current design has unsaved changes and any item in the device menu is selected, the application issues a warning to the user that there are unsaved changes. 4.5.2.
Using the IOMUX Design Aid Update Conflicts 4.5.2.4 This item cannot be enabled unless the Auto-Detect option is unselected. Selecting “Update Conflicts” manually forces the design’s assignments to be checked. Usually this option is used for very large designs with many signals to speed up the selection. Help Menu Figure 4-16 provides a partial view of the application window, showing the expanded options for the help menu.
Using the IOMUX Design Aid The following list explains each column’s function: Peripheral/Signal This column contains the peripheral and signal names, delimited by the first underscore in the name. The naming convention comes from the Excel spreadsheets that have previously been used to manually make IOMUX assignments. ALT-Mode/Ball This column contains the ALT-mode and package ball/pin assigned to each signal, separated by a hyphen.
Using the IOMUX Design Aid i.MX53 System Development User’s Guide, Rev.
Chapter 5 Setting up Power Management This chapter discusses how to supply and interface the i.MX53 multimedia applications processor with two different power management integrated circuits (PMICs): DA9053 from Dialog and LTC3589-1 from Linear Technology. The extra components required for the interface are as follows: • For the DA9053 interface, add an extra regulator RT8010 to supply the 3.3 V USB power domain • The LTC3589-1 can supply all power rails except DDR.
Setting up Power Management If either of these bits are cleared, the internal LDO source provides the respective PLL supply. If they are set, the fuse is blown and PLL power must be provided from the external pad, which is not recommended due to possible noise injections or other issues. Figure 5-1 shows the internal LDOs. i.MX53 VDD_REG 1.8 V 2.5 V VDD_ANA_PLL NVCC_RESET 1.3 V VDD_DIG_PLL VDDA VDDAL1 VP Figure 5-1. Internal LDOs i.MX53 System Development User’s Guide, Rev.
Setting up Power Management 5.2 Interfacing the i.MX53 Processor with the DA9053 The power up sequence of the device is one time programmable and must be specified when ordering the device. Figure 5-2 shows the power-up sequence for this specific interface. VLDO1 (Always on) VBUCKPRO VBUCKPERI VLDO6 VLDO8 VLDO10 VBUCKCORE VBUCKMEM VBUCKPERI/SW VLDO2 VLDO5 VLDO4 VLDO7 VLDO3 VLDO9 RT8010 Figure 5-2. Power-up Sequence i.MX53 System Development User’s Guide, Rev.
Setting up Power Management Table 5-1 shows the i.MX53 voltage rails, their power requirements, and their associated DA9053 regulator. Most of the supply domains have flexible voltage and can be adjusted or supplied with a different regulator depending on application needs. Table 5-1. i.
Setting up Power Management Table 5-1. i.MX53 Voltage Rails and Associated DA9053 Regulator (continued) (continued) Voltage Rail VDD_FUSE NVCC_NANDF NVCC_SD1 NVCC_SD2 NVCC_PATA NVCC_KEYPAD NVCC_GPIO NVCC_FEC NVCC_EIM_ MAIN NVCC_EIM_SEC Description Fusebox program supply (Write only) Ultra high voltage I/O (UHVIO) supplies UHVIO_L UHVIO_H UHVIO_UH Nominal Voltage Associated DA9053 Regulator Voltage Set Point of DA9053 Regulator (V) Current Capability (mA) Power up Sequence Set at the DA9053 3.
Setting up Power Management Table 5-1. i.MX53 Voltage Rails and Associated DA9053 Regulator (continued) (continued) Voltage Rail 1 Description Nominal Voltage Associated DA9053 Regulator Voltage Set Point of DA9053 Regulator (V) Current Capability (mA) Power up Sequence Set at the DA9053 VP S-ATA PHY Core power supply 1.3 LDO5 1.3 100 4 VPH S-ATA PHY I/O supply voltage 2.5 VBUCKPERI_ SW 2.475 1000 4 External DCDC part number is RT8010 5.2.
Setting up Power Management DA9053 i.
Setting up Power Management Figure 5-5 shows the power-up sequence of the interface that results from the connections shown in Figure 5-3 and Figure 5-4. i.
Setting up Power Management 5.3 Interfacing the i.MX53 Processor with LTC3589-1 The LTC3589-1 has flexible options for enabling and sequencing the regulator enables. The regulators are enabled using input pins or the I2C serial port. To define a power-on sequence, tie the enable of the first regulator to be powered up to the wake pin. Connect the first regulator’s output to the enable pin of the second regulator, and so on. One or more regulators may be started in any sequence.
Setting up Power Management I2C Acknowledge 5.3.2 The acknowledge signal is used for handshaking between the master and the slave. When the LTC3589-1 is written to, the LTC3589-1 acknowledges its write address and subsequent register address and data bytes. When the LTC3589-1 is read from, it acknowledges its read address and 8-bit status byte. An acknowledge pulse (active low) generated by the LTC3589-1 lets the master know that the latest byte of information was transferred.
Setting up Power Management Table 5-2. i.MX53 Voltage Rails and Associated LTC3589-1 Regulator (continued) Voltage Rail Description NVCC_CKIH ESD protection of the CKIH pins, Fuse read supply and 1.8 V bias for the UHVIO pads NVCC_LCD GPIO digital power supplies NVCC_JTAG Nominal Voltage Associated LTC3589-1 Regulator Voltage Set Point of LTC3589-1 Regulator (V) Current Capability (mA) Power up Sequence Set at the LTC3589-1 1.8 Note 1 1.8 125 2 1.8 or 2.775 LDO3 2.8 250 3 LDO3 2.
Setting up Power Management Table 5-2. i.MX53 Voltage Rails and Associated LTC3589-1 Regulator (continued) Voltage Rail NVCC_RESET Associated LTC3589-1 Regulator Voltage Set Point of LTC3589-1 Regulator (V) Current Capability (mA) Power up Sequence Set at the LTC3589-1 1.8 or 2.775 Note 1 1.8 125 2 Nominal Voltage Description LVIO USB_H1_ VDDA25 USB_OTG_ VDDA25 NVCC_XTAL USB_PHY analog supply, oscillator amplifier analog supply 2.5 SW3 2.
Setting up Power Management LTC3589-1 i.MX53 SW1 VDDGP SW2 VCC LDO2 VDDA, VDDAL1 VP VDD_DIG_PLL SW4 NVCC_NANDF NVCC_SD1 NVCC_SD2 NVCC_KEYPAD NVCC_EIM_MAIN NVCC_EIM_SEC NVCC_PATA NVCC_GPIO NVCC_FEC NVCC_CSI USB_H1_VDDA33 USB_OTG_VDDA33 LDO1 NVCC_SRTC_POW SW3 USB_H1_VDDA25 USB_OTG_VDDA25 NVCC_XTAL VDD_REG VPH NVCC_LVDS NVCC_LVDS_BG LDO3 TVDAC_DHVDD TVDAC_AHVDDRGB NVCC_LCD NVCC_JTAG LDO4 LDO4 VDD_FUSE VDD_ANA_PLL NVCC_CKIH NVCC_RESET Figure 5-8. Power Connections Block, cont. (LTC3589-1) i.
Setting up Power Management LTC3589-1 i.MX53 VCC WAKE VDD_ANA_PLL EN2 EN1 NVCC_EMI_DRAM EN3 EN4 EN_LDO2 EN_LDO34 GPIO PGOOD VSTB PMIC_STBY_REQ PWR_ON PMIC_ON_REQ DISP0_DAT14 IRQ PBSTAT Optional SCL EIM_EB2 SDA KEY_ROW3 Figure 5-9. Communication Signals Connections Block (LTC3589-1) i.MX53 System Development User’s Guide, Rev.
Setting up Power Management i.MX53 – VDD_ANA_PLL LT3481 RUN/SS Figure 5-10. Communication Signals Connections Block, cont. (TPS73201, LT3481) i.MX53 System Development User’s Guide, Rev.
Setting up Power Management 5.5.1 Powering-up the Interface Figure 5-11 shows the interface’s power-up sequence. i.
Setting up Power Management 5.6 Additional Device Information This section provides additional product information for the DA9053 PMIC subsystem and the LTC3589-1 PMIC subsystem. 5.6.1 DA9053 The DA9053 is a power management IC that includes the necessary sources to supply the i.MX53. That main features that enable this interface are: • 4 buck converters and 10 programmable LDOs, capable of supplying all i.
Setting up Power Management 9%8&.&25( 9%8&.352 90(0B6: 9%8&.0(0 9''287 X+ 93(5,B6: 9%8&.3(5 9''287 Figure 5-12 shows the DA9053 application block diagram. X) X+ X) X) X+ X+ X) X) X+ P %$&./,*+7 %2267 ZLWK /(' &855(17 &21752/ %$77(5< 6:,7&+ %8&. 0(0 %8&. 3(5, 9''287 9%8&.[ 9''5() 86% &+$5*(5 &21752/ ' %8&. &25( 90(0B6:B(1 93(5,B6:B(1 ' %8&. 352 '96 '$& %$&.
Setting up Power Management Table 5-3 shows the generated supply domains. Table 5-3. Generated Supply Domains Regulator Supplied pins Supplied voltage Supplied max current External component Notes Buckcore VBUCKCO V0.5–2.075 V RE ± 3% accuracy default 1.8 V 2000 mA 2.2/1.0 μH DVC, 2 MHz, 25 mV steps DVC ramp with controlled slew rate; pull-down resistor switch off Buckpro VBUCKPR 0.5–2.075 V O ±3% accuracy default 1.2 V 1000 mA 2.2/1.
Setting up Power Management Table 5-3. Generated Supply Domains (continued) Regulator Supplied pins Supplied voltage Supplied max current External component Notes LDO9 VLD09 1.25–3.6 V ±3% accuracy default 2.5 V 100 mA 1.0 μF High PSSR, low noise, 50 mV steps, TOP trimmed, optional hardware control from GPI12, common supply with LDO10 LDO10 VLD10 1.2–3.6 V ±3% accuracy default 1.8 V 250 mA 2.2 μF High PSSR, low noise, 50 mV steps, common supply with LDO9 Backup VBBAT 1.1–3.
Setting up Power Management Figure 5-13 shows a typical application block guide. 9,1 9 72 9 /' ) 9&25( 9 72 9 $7 $ ) 965$0 9 72 9 $7 $ 6: ) 0(025< 9 72 9 $7 P$ + /7& 6: ) + $1$/2* 9 $7 P$ 9 9 9 9 $7 P$ + 9,1 /' B67'%< 957& 9 $7 P$ 6: /' ) ) /' ) + 6: $% & 6: &' 962& 9 72 9 $7 $ (1$%/(6 %%B287 3:5B21 :$.
Setting up Power Management i.MX53 System Development User’s Guide, Rev.
Chapter 6 Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor This chapter explains the interface between the i.MX53 processor and DDR2 and DDR3 memories. It includes the routing guidelines, pictures, and examples. 6.1 i.MX53 SDRAM Controller Signals The SDRAM controller can be interfaced with LPDDR2-S, DDR2, and DDR3 memories. The DDR controller from the i.MX53 uses the following signals to interface the memories: • Data bus and its buffer control signals — DRAM_D0 – DRAM_D31.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor Figure 6-1 shows the block diagram of the DDR2/DDR3 interfaced with the i.MX53 from the reference design boards. DDR2/3 A[13:0] i.MX53 A[15:0] DRAM_D[31:0] SD[31:0] CS0 CS0/CS1 CLK… CKE0, SDCLK0,SDCLK0_B CKE1, SDCLK1,SDCLK1_B WE… SDWE… DDR2/3 A[13:0] SD[31:0] CS1 CLK… WE… Figure 6-1. Connection Between i.MX53 Processor and DDR2 and DDR3 i.MX53 System Development User’s Guide, Rev.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor 6.2 i.MX53 Memory Interface Figure 6-2 shows the DDR2 connection. The DDR2 device is the H5PS2G83AFR. Figure 6-2. DDR2 Memory Connection Figure 6-3 shows the DDR3 memory connections. The DDR3 device is the EDJ2116DASE. The DDR2 and DDR3 memory connections differ in the following ways: • RESET and VREF signals. • DDR3 DQS signals are connected as differential pairs to the memory. i.MX53 System Development User’s Guide, Rev.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor Figure 6-3. DDR3 Memory Connection 6.3 Configuring the DDR2 JTAG Script The following code shows an example of how to configure the DDR2 memory for the i.MX53 processor: Example 6-1. DDR2 JTAG Script Configuration //*========================================================================================== ====== //* Copyright (C) 2010, Freescale Semiconductor, Inc.
Interfacing DDR2 and DDR3 Memories with the i.
Interfacing DDR2 and DDR3 Memories with the i.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem setmem 6.
Interfacing DDR2 and DDR3 Memories with the i.
Interfacing DDR2 and DDR3 Memories with the i.
Interfacing DDR2 and DDR3 Memories with the i.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor The SCh has a 32 bit data bus. Therefore, DSIZ = 32 bit width. Enable the SDRAM controller as follows: setmem /32 0x63FD9000 = 0xC3190000 6.5.2 Power Down Register Figure 6-5 shows the power down register’s bit fields, access, and reset values.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor • • • tXPDLL = greater of 10 CK tFAW= 15 CK tCL= 6 Enable as follows: setmem /32 0x63FD900C = 0x555952E3 6.5.4 Timing Configuration 1 Register Figure 6-7 shows the timing configuration 1 register’s bit fields, access, and reset values.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor 6.5.5 Timing Configuration 2 Register Figure 6-7 shows the timing configuration 2 register’s bit fields, access, and reset values. Access: Read/Write 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 R — W Reset 0 0 0 0 tDLLK 0 0 0 0 1 1 0 0 0 9 8 — 1 1 1 0 0 0 0 7 6 5 tRTP 0 0 0 0 1 4 3 2 tWTR 0 0 1 1 0 tRRD 0 0 1 0 Figure 8.
Interfacing DDR2 and DDR3 Memories with the i.MX53 Processor i.MX53 System Development User’s Guide, Rev.
Chapter 7 Avoiding Board Bring-Up Problems This chapter provides recommendations for avoiding typical mistakes when bringing up a board for the first time. These recommendations consist of basic techniques that have proven useful in the past for detecting board issues and address the three most typical bring-up pitfalls: power, clocks, and reset. A sample bring-up checklist is provided at the end of the chapter. 7.
Avoiding Board Bring-Up Problems 7.2 Using a Current Monitor to Avoid Power Pitfalls Excessive current can cause damage to the board. Avoid this problem by using a current-limiting laboratory supply that has a current read-out to power the main power to the board when bringing up the board for the first time. This allows the main power to be monitored, which makes it easy to detect any excessive current. 7.
Avoiding Board Bring-Up Problems 7.5 Sample Board Bring-Up Checklist Table 7-2 provides a sample board bring-up checklist. Note that the checklist incorporates the recommendations described in the previous sections. Blank cells should be filled in during bring-up as appropriate. Table 7-2. Board Bring-Up Checklist Checklist Item Details Owner Findings & Status Note: The following items must be completed serially. 1. Perform a visual inspection.
Avoiding Board Bring-Up Problems Table 7-2. Board Bring-Up Checklist (continued) Checklist Item Details Measure boot mode frequencies. Set the boot mode switch for each boot mode and measure the following, (depending on system availability: • NAND (probe CE to verify boot, measure RE frequency) • SPI-NOR (probe slave select and measure clock frequency) • MMC/SD (measure clock frequency) This verifies the specified signals’ connectivity between the i.
Chapter 8 Using the Clock Connectivity Table This chapter explains how to use the i.MX53 clocking connectivity. This information can help users save power by disabling clocks to unused modules. Table 8-1 describes the available clock sources and lists the maximum frequencies that are supported by design. In some cases if maximum frequency is used, users need to divide the clock inside the module in order to meet the protocol requirements.
Using the Clock Connectivity Table Table 8-1. Clock Roots (continued) Clock Root Name (from CCM) Description Target Frequency [MHz] ssi1_clk_root Root for SSI-1 clock 66.5 ssi2_clk_root Root for SSI-2 clock 66.5 ssi3_clk_root Root for SSI-3 clock 66.5 usb_phy_clk_root Root for USB_PHY (24 Mhz) 24 ieee_cemx_clk_root Root for IEEE RTC clock 66.
Using the Clock Connectivity Table Clock gating is done with the low power clock gating (LPCG) module based on a combination of the clock enable signals. For more information about how the clock gating signals are logically combined, refer to the LPCG section in the CCM chapter of the i.MX53 reference manual. NOTE In some cases, a clock is part of a protocol and is sourced from a pad (mainly through IOMUX). Such clocks do not appear in the clock connectivity table.
Using the Clock Connectivity Table i.MX53 System Development User’s Guide, Rev.
Chapter 9 Configuring JTAG Tools for Debugging This chapter explains how to configure JTAG tools for debugging. The JTAG module is a standard JEDEC debug peripheral. It provides debug access to important hardware blocks, such as the ARM processor and the system bus, which can give users access and control over the entire SoC.
Configuring JTAG Tools for Debugging Once the latest firmware is installed, follow these steps to configure the JTAG scan chain on the RVI box: 1. Connect RVI to the i.MX53 board using the JTAG ribbon cable. 2. Using the order shown below, configure the scan chain with the following connections: TDI → Unknown → Unknown → ARMCS-DP → Cortex-A8 (see Figure 9-1).
Configuring JTAG Tools for Debugging 3. Update the CoreSight base address as follows: a) Right click on Cortex-A8 Device. b) Select configuration. c) Set CoreSight base address to = 0xC0008000. Figure 9-2. Updating the CoreSight Base Address 4. Save the configuration. i.MX53 System Development User’s Guide, Rev.
Configuring JTAG Tools for Debugging After following the recommended steps, the RVDS JTAG scan chain should look like Figure 9-3. Note this screenshot shows the resulting scan chain when using ARM RVDS v3.1 tools. Figure 9-3. i.MX/Cortex-A8 RVDS JTAG Scan Chain After setting up the JTAG scan chain, RVI can connect to the i.MX53’s core. This is the only required step; no initialization scripts are necessary.
Part II Software Development The chapters that follow aid you in software development for your product utilizing the i.MX53 Board Support Package. i.MX53 System Development User’s Guide, Rev.
Software Development i.MX53 System Development User’s Guide, Rev.
Chapter 10 Porting the On-Board-Diagnostic-Suite (OBDS) to a Custom Board The on-board diagnostic suite (OBDS) is a set of validation software used during the board bring up phase and also to validate the boards produced during mass manufacturing for defects. OBDS is run to test out specific IP blocks of the i.MX53 SoC and the associated hardware on the board.
Porting the On-Board-Diagnostic-Suite (OBDS) to a Custom Board 10.2 Customizing OBDS for Specific Hardware This section explains how to customize the OBDS for the following hardware modules: • Section 10.2.1, “UART (serial port) Test” • Section 10.2.2, “DDR Test” • Section 10.2.3, “Audio Test” • Section 10.2.4, “IPU Display Test” • Section 10.2.5, “I2C Test” • Section 10.2.6, “SD/MMC Test” • Section 10.2.7, “LED Test” • Section 10.2.8, “Ethernet (FEC) Loopback Test” • Section 10.2.9, “SPI-NOR Test” 10.
Porting the On-Board-Diagnostic-Suite (OBDS) to a Custom Board 10.2.3 Audio Test The audio test first performs I2C communications between the i.MX53 and the SGTL5000 audio codec. The test then outputs audio data via the SSI/I2S interface to the audio codec. The ~/diag-obds/src/drivers/audio folder contains the files that implement the audio test. If a different SSI port is used, make the necessary IOMUX changes to the ~/diag-obds/src/mx53/hardware.c file. 10.2.
Porting the On-Board-Diagnostic-Suite (OBDS) to a Custom Board 10.2.8 Ethernet (FEC) Loopback Test The test requires a loopback Ethernet cable, which is described in the OBDS user guide. There is only one FEC in the i.MX53 SoC. No customization is required and code from OBDs can be run as-is. 10.2.9 SPI-NOR Test This test verifies the interface between the i.MX53 ECSPI-1 module and the SPI-NOR flash.
Chapter 11 Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board This chapter provides a step-by-step guide that explains how to add i.MX53 custom board support to U-Boot. This developer's guide is based on U-Boot version rel_imx_2.6.35_10.12.01_RC4, which is present as a package on the LTIB-based Linux BSP at http://opensource.freescale.com/git?p=imx/uboot-imx.git. For an introduction to the use of U-Boot firmware with i.MX processors, read AN4173, “U-Boot for i.
Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board NOTE U-Boot project developers recommend adding any new board to the MAKEALL script and to run this script in order to validate that the new code has not broken any other’s platform build. This is a requirement if you plan to submit a patch back to the U-Boot community. For further information, consult the U-Boot README file. 4. Rename board/freescale/mx53_/mx53_.
Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board 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. 11.3.1 Changing the DCD Table for i.MX53 DDR3 Initialization Initializing the memory interface requires configuring the relevant I/O pins with the right mode and impedance and initializing the ESDCTL module. 1.
Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board All board initialization is executed inside this function. It starts by running through the init_sequence[] array of function pointers. The first board dependent function inside init_sequence[] array is board_init(). board_init() is implemented inside board/freescale/mx53_.c. At this point the most important tip is the following line of code: ...
Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board Err: serial Net: FEC0 Reference Board: U-Boot > i.MX53 System Development User’s Guide, Rev.
Porting U-Boot from an i.MX53 Reference Board to an i.MX53 Custom Board i.MX53 System Development User’s Guide, Rev.
Chapter 12 Porting the Android Kernel Android releases for the i.MX53 processor are divided into three main parts: the bootloader (U-Boot or redboot), the kernel, and the Android framework. This chapter explains how to port an Android kernel to any platform that is based on the i.MX53 chip. The easiest way to apply kernel modifications to any i.MX platform is to use an existing Android release either for the i.MX51 or i.MX53 processor. 12.
Porting the Android Kernel 12.2.1 Enabling and Disabling Default Resources Users can add or remove resources that are enabled by default on the EVK board configuration by entering make menuconfig under myandroid/kernel_imx. Figure 12-1 shows the menu option screen. Figure 12-1. Linux Kernel Configuration Menu This menu allows users to enable or disable drivers that are part of the Android framework’s included Linux image. Make your selections and exit the menu. After you exit, the system creates the .
Porting the Android Kernel 12.2.2 Changing the Configuration File After the system has created the .config file, users can change the configuration file to enable the environment variables required by the Android image. Configuration files for different platforms are located at: myandroid/kernel-imx/arch/arm/config/ Choose the appropriate configuration file for your platform and double check the .
Porting the Android Kernel Android's memory map hardcodes three of its four main blocks to a specific value. The final block uses whatever memory remains after the other three blocks have defined their boundaries. This remaining block of memory is used by the system memory as standard RAM memory for loading the kernel and apps execution. Figure 12-2 shows how the Android's memory map is organized on a 512 Mbyte system. Figure 12-2.
Porting the Android Kernel 12.4 Modifying the init.rc Partition Locations The init.rc file mounts the three main partitions—system, cache, and data—on the image. By default, these partitions are mounted from the SD/MMC controller. If you have these partitions stored on another Flash source, modify the following lines to choose from the specific NVM.
Porting the Android Kernel Most enhancement implementations are located at kernel/drivers/staging/android. NOTE Android also handles the hardware abstraction layer (HAL) between the Linux kernel and the android library stack. These drivers are related to specific hardware modules such as GPS, Bluetooth, or radio. Figure 12-4. Hardware Abstraction Layer This chapter does not cover these implementations. For information about HAL porting, please refer to the Android developer website at http://source.
Chapter 13 Configuring the IOMUX Controller (IOMUXC) Before using the i.MX53 pins (or pads), users must select the desired function and correct values for characteristics such as voltage level, drive strength, and hysteresis. They do this by configuring a set of registers from the IOMUXC. For detailed information about each pin, see the “External Signals and Pin Multiplexing” chapter in the i.MX53 Applications Processor Reference Manual.
Configuring the IOMUX Controller (IOMUXC) – 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.
Configuring the IOMUX Controller (IOMUXC) • pi—PAD Control Offset 13.2.2 Configuring IOMUX Pins for Initialization Function The mx53.c file contains the initialization functions for all peripherals (such as UART, I2C, and Ethernet).
Configuring the IOMUX Controller (IOMUXC) // Set pin as 0 reg = readl(GPIO7_BASE_ADDR + 0x0); reg &= ~0x80; writel(reg, GPIO7_BASE_ADDR + 0x0); If done correctly, the pin PATA_DA_1 on the i.MX53 toggles when booting. 13.3 Setting Up the IOMUXC in Linux The folder linux/arch/arm/mach- contains the specific machine layer file for your custom board. For example, the machine layer file used on the i.MX53 boards are linux/arch/arm/mach-mx5/mx53_.c.
Configuring the IOMUX Controller (IOMUXC) The variables are as follows: • 0x620—PAD Control Offset • 0x2A0—MUX Control Offset • 4—MUX Mode • 0x888—Select Input Offset • 3—Select Input • MX53_UART_PAD_CTRL—Pad Control For all addresses and register values, check the IOMUX chapter in the i.MX53 Applications Processor Reference Manual. 13.3.2 Machine Layer File The mx53_.c file contains structures for configuring the pads.
Configuring the IOMUX Controller (IOMUXC) Define the pad on iomux-mx53.h file as follows: #define MX53_PAD_ATA_DA_1__GPIO_7_7IOMUX_PAD(0x614, 0x294, 1, 0x0, 0, NO_PAD_CTRL) Parameters: • 0x614—PAD Control Offset • 0x294—MUX Control Offset • 1—MUX Mode • 0x000—Select Input Offset • 0—Select Input • NO_PAD_CTRL—Pad Control To register the pad, add the previously defined pin to the pad description structure in the mx53_.c file, as shown in the following code.
Chapter 14 Registering a New UART Driver Because Linux already has a UART driver for the i.MX53, configure the UART pads on the IOMUX registers. This chapter explains how to configure the UART pads, enable the UART driver, and test that the UART was set up correctly. 14.1 Configuring UART Pads on IOMUX The IOMUX register must be set up correctly before the UART function can be used. This section provides example code to show how to do this.
Registering a New UART Driver 14.2 Enabling UART on Kernel Menuconfig Enable the UART driver on Linux menuconfig. This option is located at: -> Device Drivers -> Character devices -> Serial drivers <*> MXC Internal serial port support [*] Support for console on a MXC/MX27/MX21 Internal serial port After enabling the UART driver, build the Linux kernel and boot the board. 14.
Registering a New UART Driver Table 14-2 lists the UART files that are available on the directory /arch/arm/plat-mxc/include/mach/ Table 14-2. Available Files—Second Set File Description mxc_uart.h UART header containing UART configuration and data structures iomux-.h IOMUX pads definitions Table 14-3 lists the UART files that are available on the directory /arch/arm/mach-mx5/ Table 14-3.
Registering a New UART Driver i.MX53 System Development User’s Guide, Rev.
Chapter 15 Adding Support for the i.MX53 ESDHC This chapter explains how to add support for the i.MX53 ESDHCV2-1/2/4 and ESDHCV3-3 controller. The multimedia card (MMC)/secure digital (SD)/secure digital input output (SDIO) host driver implements a standard Linux driver interface for the enhanced MMC/SD host controller (ESDHC). The host driver is part of the Linux kernel MMC framework.
Adding Support for the i.MX53 ESDHC Table 15-1. Structure Descriptions Struct member ocr_mask vendor_ver caps Control the voltage on SD pads to be high voltage (around 3.0 V) or low voltage (around 1.8 V). ‘0’ stands for low voltage range Optional output Vendor version Modes of operation - data transfer modes min_clk Minimum SD operating frequency in Hz. max_clk Maximum SD operating frequency in Hz. clk_flg reserved card_fixed card_inserted_state 15.2 Description 0 clock disabled, 1 Clock enabled.
Adding Support for the i.MX53 ESDHC { .flags = IORESOURCE_IRQ, }, }; struct platform_device mxcsdhcXX_device = { .name = "mxsdhci", .id = YY, .num_resources = ARRAY_SIZE(mxcsdhcXX_resources), .resource = mxcsdhcXX_resources, }; Variables have values as follows: • XX can be 1, 2, 3 or 4 depending on the SD port. • YY can have a value between 0 and 3. • SD1’s ID is 0; SD2's ID is 1; SD3's ID is 2; and SD4's ID is 3. Declare the structures as externs in /linux/arch/arm/mach-mx5/devices.
Adding Support for the i.MX53 ESDHC 400 KHz and 50 MHz. sdhc_get_card_det_status() and sdhc_write_protect() functions are used for card detection and write protection. 15.2.4 Setting Up Card Detection The SD connector includes an output pin (CD) that changes its state according to the card insertion status. In some cases, CD is not connected to the processor. In those cases, the function should return true to signal that the card is always connected.
Adding Support for the i.MX53 ESDHC ... }; Then link GPIO interrupts with start and end functions in the resource structure of the SD interface in the mx53_.c file located at /linux/arch/arm/mach-mx5/mx53_.c static void __init mxc_board_init(void) { ... /* SD card detect irqs */ if (board_is_mx53_()) { ... // SD2 Card support for i.MX53 custom board mxcsdhc2_device.resource[2].start = IOMUX_TO_IRQ(MX53_PIN_GPIO_4); mxcsdhc2_device.resource[2].
Adding Support for the i.MX53 ESDHC 15.3.1 ESDHC Interface Features The ESDHC has 15 associate I/O signals with the following functions. • The SD_CLK is an internally generated clock used to drive the MMC, SD, 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 ESDHC and the card. • The SD_CD# and SD_WP are card detection and write protection signals directly routed from the socket.
Adding Support for the i.MX53 ESDHC transmission level. The i.MX53 ESDHC includes three instances of the Enhanced Secured Digital Host Controller Version 2 (ESDHCv2) within the ports 1, 2 and 4. ESDHC port 3 on the i.MX53 can be configured to work either as ESDHCv3 or ESDHCv2. Table 15-3 shows the supported operation modes. Table 15-3.
Adding Support for the i.MX53 ESDHC Figure 15-2 shows another example i.MX53 SD interface layout. Figure 15-2. Second Example i.MX53 SD Interface Layout Note that some SD interface card detection and write protection pins are not propagated from the SD card to the i.MX53 in all hardware implementations. Also note that SD4 is shared with PATA pins. The second example board provides the connection to the four SD interfaces provided by the ESDHC in the i.MX53. i.MX53 System Development User’s Guide, Rev.
Chapter 16 Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver This chapter explains how to set up the SPI NOR Flash memory technology device (MTD) driver. This driver uses the SPI interface to support Atmel data Flash. By default, the SPI NOR Flash MTD driver creates static MTD partitions to support Atmel data Flash. The NOR MTD implementation provides necessary information for the upper layer MTD driver. 16.
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver Table 16-1. Parameter Variables (continued) Variable Definition 256 Number of bytes per page 8 Offset NOTE If you want to use another data flash model, add it on the last structure. Be sure the flash models are compatible with the Atmel data flashes. 16.3 Selecting SPI NOR on the Linux Image Table 16-2 provides information for each supported device. Table 16-2.
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver Bootloader starts from address 0 and has a size of 1 Mbyte. Kernel starts from address 1 Mbyte and has a size of 3 Mbytes. NOTE You may create more partitions or modify the size and names of these ones. To add more partitions, define another structure on the mxc_dataflash_partitions variable. 4. To get to the SPI NOR MTD driver, use the command ./ltib -c when located in the . 5.
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver Table 16-3. CSPI Parameters (continued) 16.4.3 CSPI Parameter Name ECSPI-2 &mxcspi2_device CSPI &mxcspi3_device Changing the Chip Select To change the chip select used, locate the file at arch/arm/mach-mx5/mx53_.c and use the static struct spi_board_info mxc_dataflash_device[] __initdata structure. Replace the value of ".chip_select" variable with the desired chip select value. For example, .
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver 16.6 Software Operation In a Flash-based embedded Linux system, a number of Linux technologies work together to implement a file system. Figure 16-1 illustrates the relationships between standard components. Figure 16-1. Components of a Flash-Based File System The MTD subsystem for Linux is a generic interface to memory devices, such as Flash and RAM, which provides simple read, write, and erase access to physical memory devices.
Configuring the SPI NOR Flash Memory Technology Device (MTD) Driver i.MX53 System Development User’s Guide, Rev.
Chapter 17 Setting Up the Keypad Port (KPP) The KPP is designed to interface with the keypad matrix with 2-point contact or 3-point contact keys. The KPP is designed to simplify the software task of scanning a keypad matrix. With appropriate software support, the KPP is capable of detecting, debouncing, and decoding one or multiple keys pressed simultaneously on the keypad. Because Linux already contains a driver for the i.
Setting Up the Keypad Port (KPP) 17.2 Creating a Custom Keymap The input.h file defines codes for general keyboards, as follows. ... #define #define #define #define #define #define #define #define #define #define ... KEY_HOME KEY_UP KEY_PAGEUP KEY_LEFT KEY_RIGHT KEY_END KEY_DOWN KEY_PAGEDOWN KEY_INSERT KEY_DELETE 102 103 104 105 106 107 108 109 110 111 Use these labels or add new ones to create your custom keymap. 17.3 Configuring the Pads with the Machine Layer File The mx53_.
Setting Up the Keypad Port (KPP) 3. Add the keymapping matrix as follows: static u16 keymapping[16] = { KEY_UP, KEY_DOWN, KEY_MENU, KEY_BACK, KEY_RIGHT, KEY_LEFT, KEY_SELECT, KEY_ENTER, KEY_F1, KEY_F3, KEY_1, KEY_3, KEY_F2, KEY_F4, KEY_2, KEY_4, }; 4. Change the KEYS according to input.h labels and your keypad layout. 5. Add the following structure to configure the keypad: static struct keypad_data keypad_plat_data = { .rowmax = 4, .colmax = 4, .learning = 0, .delay = 2, .matrix = keymapping, }; 6.
Setting Up the Keypad Port (KPP) Evtest displays the information of every key event. Event: Event: Event: Event: Event: Event: Event: Event: time time time time time time time time 862.980003, 863.110002, 863.620003, 863.750002, 865.560003, 865.730002, 866.150003, 866.
Chapter 18 Supporting the i.MX53 Reference Board DISP0 LCD This chapter explains how to support a new LCD on an i.MX53-based board, using display port 0. There are two options for adding support for a new LCD panel without modifying the BSP: letting the BSP calculate the timings using VESA defaults or reducing the blanking time. VESA and reduced blanking work for many LCDs but fail for some devices because of timing configuration constraints.
Supporting the i.MX53 Reference Board DISP0 LCD 18.1 Supported Display Interfaces The i.MX53 processor supports the display interfaces shown in Figure 18-1. Figure 18-1. Available Display Interfaces Table 18-1 describes the available interfaces. Table 18-1. Available Interfaces Feature Number of ports Legacy I/F MIPI/DSI high-speed I/F Analog TV-out (composite, S-video, component) IPU (in i.MX53) Two: Full dual-display support Parallel and serial.
Supporting the i.MX53 Reference Board DISP0 LCD Table 18-1. Available Interfaces Feature VGA output LVDS I/F IPU (in i.MX53) Driven by TVE (Not supported in TO1) Up to WSXGA+ @ 60 Hz, 24 bpp (WSXGA+: 1680x1050) Up to UXGA or 2xWXGA @ 60 Hz, 24 bpp (UXGA: 1600x1200, WXGA: 1366x768 Note: VGA output is not supported on i.MX53 TO1 processors 18.
Supporting the i.MX53 Reference Board DISP0 LCD Figure 18-2 shows the interface between an i.MX53-based board and Chunghwa CLAA057VA01CT 5.7” VGA LCD. Figure 18-2. Interface The LCD panel requires HSYNC, VSYNC, DE, PIXCLK, and part of the RGB data interface (DISPB_DATA[17:0]). No additional signals, such as a reset signal or serial interface initialization routine commands (SPI or I2C), are required. The backlight unit is controlled by a GPIO signal generated by the i.
Supporting the i.MX53 Reference Board DISP0 LCD Table 18-2. Timing Parameters (continued) Parameter Symbol Min Typ Max Unit Active frame height VDISP — 480 — Line Vertical refresh rate FV 55 60 65 Hz Screen width or horizontal cycle HP 750 800 900 PIXCLK HSYNC pulse width HSW 1 1 1 PIXCLK Horizontal back porch HBP 46 46 46 PIXCLK Horizontal front porch HFP 64 114 214 PIXCLK HDISP — 640 — PIXCLK Active frame width 18.
Supporting the i.MX53 Reference Board DISP0 LCD Table 18-3. Parameter Information Argument Name Definition Units Values M Timing calculated using VESA(TM) NA M R Timing using reduced blanking NA R Bits per pixel on frame buffer bits Decimal value (16 or 24) LCD refresh rate Hz Decimal value bpp refresh When is included in the mode_option argument parameters, the timing is not calculated. Instead, it is extracted from BSP code.
Supporting the i.MX53 Reference Board DISP0 LCD Table 18-5 shows how the values in this example correspond to the argument names defined in Table 18-3. Table 18-5.
Supporting the i.MX53 Reference Board DISP0 LCD For example, the kernel command for an XGA LVDS connected to LVDS0 using DI1 as the primary display interface is as follows: video=mxcdi0fb:RGB24,LDB-XGA di1_primary 18.3.3 Modifying the Bits per Pixel Setting The default bits per pixel setting is 16 bits. To change the default value to another depth, modify the relevant lines in the mxc_ipuv3_fb.c file located at /rpm/BUILD/linux/drivers/video/mxc/mxc_ipuv3_fb.c Example 18-4.
Supporting the i.MX53 Reference Board DISP0 LCD The video parameter format is :,x[M][R][-][@][i][m][-][@] with variables between square brackets optional. Table 18-7 provides sample values for an interface. Table 18-7.
Supporting the i.MX53 Reference Board DISP0 LCD 18.4 Adding Support for a New LCD If neither VESA nor reducing the blanking calculation works for your LCD or if you need a special function, add the support for the new LCD in the BSP. Perform the following steps to modify the i.MX53 BSP to add the support for synchronous panels: 1. 2. 3. 4. 5. Add a display entry in the ltib catalog. Create the madglobal LCD panel file. Add compilation flag for the new display.
Supporting the i.MX53 Reference Board DISP0 LCD config FB_MXC_CLAA057VA01CT_SYNC_PANEL depends on FB_MXC_SYNC_PANEL tristate "CLAA CLAA057VA01CT Panel" 18.4.2 Creating the LCD Panel File (initialization, reset, power settings, backlight) Because power settings are handled by the ATLAS APL PMIC and other voltage regulators, the display driver must configure the APL PMIC during initialization to set up the power voltage configuration if this has not already been done.
Supporting the i.MX53 Reference Board DISP0 LCD }, }; Be careful to use the same name for the new platform device entry as the name included in madglobal:mxcfb_CLAA057VA01CT.c for the driver. 3. static struct platform_driver lcd_driver = { .driver = { .name = "lcd_CHUNGHWA_CLAA057VA01CT"}, .probe = lcd_probe, .remove = __devexit_p(lcd_remove), .suspend = lcd_suspend, .resume = lcd_resume, }; Register the device at //rpm/BUILD/linux/arch/arm/mach-mx5/madglobal:mxc53_.
Supporting the i.MX53 Reference Board DISP0 LCD Note that a new object, mxcfb_CLAA057VA01CT.o, is created when CONFIG_FB_MXC_CLAA057VA01CT_SYNC_PANEL flag is set. The LCD module with the initialization and de-initialization routines is only available to the kernel after this object has been created. If the LCD does not need a particular configuration, you may omit the usage of the LCD file and discard any changes on Kconfig and Makefile. 18.4.
Supporting the i.MX53 Reference Board DISP0 LCD }; Use this new mxc_fb_platform_data struct to register DISP0 in the mxc_init_fb() function, as follows. static int __init mxc_init_fb(void) { ... memcpy(&fb_data[0], &CLAA057VA01CT_fb_data, sizeof(struct mxc_fb_platform_data)); mxc_register_device(&mxc_disp_devices[0], NULL); ... return 0; } This code replaces the default WVGA panel settings with the new LCD entry. 18.4.
Supporting the i.MX53 Reference Board DISP0 LCD return 0; } 4. Modify the boot command with the following code. EVK U-Boot > setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp CLAA057VA01CT nfsroot=${serverip}:${nfsroot},v3,tcp' EVK U-Boot > run bootcmd_mmc 18.5 i.MX53 Display Interface Helpful Information TFT panels are handled by the i.
Supporting the i.MX53 Reference Board DISP0 LCD The example board’s two display interface (DI) modules are each configured to handle one or more different kind of panels. The DI module is responsible for the timing waveforms for each signal in its display’s interface. It is composed of the following: • 8 sets of waveform generators (PIN1–PIN8) that control signals associated with the DI’s clock, such as VSYNC and HSYNC.
Chapter 19 Connecting an LVDS Panel to an i.MX53 Reference Board This chapter explains how to connect the LVDS panel to an i.MX53 reference board. The i.MX53 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.
Connecting an LVDS Panel to an i.MX53 Reference Board The LVDS channel mapping mode and the LDB bit mapping mode of LDB are set according to the boot up LDB option chosen by the user. If the user has not specified an option but the video mode can be found in the local video mode database, the driver chooses an appropriate LDB setting. If no video mode is matched, nothing is done in probe function. Users can set up the LDB later by using ioctrls.
Connecting an LVDS Panel to an i.MX53 Reference Board 19.3 LDB Ports Figure 19-1 shows the LDB block. Figure 19-1. i.MX53 LVDS Display Bridge (LDB) Block The LDB has the following ports: • Two input parallel display ports. • Two output LVDS channels • Control signals to configure LVDS parameters and operations. • Clocks from the SoC PLLs. i.MX53 System Development User’s Guide, Rev.
Connecting an LVDS Panel to an i.MX53 Reference Board 19.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.
Chapter 20 Supporting the i.MX53 Camera Sensor Interface CSI0 This chapter provides information about how to use the expansion connector to include support for a new camera sensor on an i.MX53 reference board. It explains how to do the following: • Configure the CSI unit in test mode (Section 20.3, “Configuring the CSI Unit in Test Mode”) • Add support for a new CMOS sensor in the i.MX53 BSP (L2.6.31_10.07.11) (Section 20.
Supporting the i.MX53 Camera Sensor Interface CSI0 20.2 i.MX53 CSI Interfaces Layout Figure 20-1 shows the camera interface layout on an i.MX53-based board. Figure 20-1. Camera Interface Layout Only CSI0 is used for the purpose of this document. The usage of CSI1 depends on its availability on the board being used. 20.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.
Supporting the i.MX53 Camera Sensor Interface CSI0 20.4 Adding Support for a New CMOS Camera Sensor To add support for a new CMOS camera sensor to your BSP, first create a device driver for supporting 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.
Supporting the i.MX53 Camera Sensor Interface CSI0 $ 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. 20.4.2 Creating the Camera Sensor File The camera sensor file enables camera initialization, reset signal generation, power settings, CSI configuration and all sensor-specific code.
Supporting the i.MX53 Camera Sensor Interface CSI0 Table 20-2. Required Functions (continued) Function name Function declaration Description 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, sets the control's current value in HW (and updates the video_control[] array). Otherwise, returns -EINVAL if the control is not supported.
Supporting the i.MX53 Camera Sensor Interface CSI0 2. Open the i.MX53 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 sensor_clock.o obj-$(CONFIG_MXC_IPUV3_CSI0_TEST_MODE) += ipuv3_csi0_chess_camera.o The kernel object is created 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.
Supporting the i.
Supporting the i.MX53 Camera Sensor Interface CSI0 Check ov3640.c for the complete example code. After creating the new I2C device, add the following lines to your platform file (located at /rpm/BUILD/linux/arch/arm/mach-mx5/mx53_.c). static struct mxc_camera_platform_data camera_data = { .analog_regulator = "VSD", .mclk = 24000000, .csi = 0, .pwdn = camera_pwdn, }; static struct i2c_board_info { .type = "ov3640", .addr = 0x3C, .platform_data = (void }, { .type = "adv7180", { .
Supporting the i.MX53 Camera Sensor Interface CSI0 20.6 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 any camera request attempt. According to the Makefile information, the camera module is named ipuv3_csi0_chess_camera.ko.
Supporting the i.MX53 Camera Sensor Interface CSI0 20.7.1 CMOS Interfaces Supported by the i.MX53 The camera sensor interface, which is part of the image processing unit (IPU) module on the i.MX53, handles CMOS sensor interfaces. The i.MX53 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.
Supporting the i.MX53 Camera Sensor Interface CSI0 For details, refer to the “Image Processing Unit (IPU)” chapter in the i.MX53 Applications Processor Reference Manual. Figure 20-4 shows the block diagram. Figure 20-4. 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.
Supporting the i.MX53 Camera Sensor Interface CSI0 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.MX53. The camera sensor creates PIXCLK based on MCLK input. Figure 20-5. Parallel Interface Layout In parallel interface, a single value arrives in each clock—except in BT.1120 mode when two values arrive per cycle.
Supporting the i.MX53 Camera Sensor Interface CSI0 Table 20-3. CSI0 Parallel Interface Signals (continued) Signal IPU Pin Description DATA_EN CSI0_DATA_EN Data Enable or Data ready DATA[19:10] CSI0_DAT [19:10] Pixel data bus, optional to [19:4] Section 20.7.3, “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. 20.7.
Supporting the i.MX53 Camera Sensor Interface CSI0 i.MX53 System Development User’s Guide, Rev.
Chapter 21 Porting Audio Codecs to a Custom Board This chapter explains 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 explains the common porting task and then the different porting tasks. 21.
Porting Audio Codecs to a Custom Board 21.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, users must 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. The iomux-mx53.h file contains the definitions for all i.MX53 pads.
Porting Audio Codecs to a Custom Board Table 21-2. Files for sgtl Codec Support File Name Definition sgtl5000.c • Registers the stereo codec and Hi-Fi DAI drivers. • Responsible for all direct hardware operations on the stereo codec. imx-3stack-sgtl5000.c • Machine layer code • Creates the driver device • Registers the stereo sound card. NOTE If using a different codec, adapt the driver architecture shown in Table 21-2 accordingly. The exact adaptation will depend on the codec chosen.
Porting Audio Codecs to a Custom Board i.MX53 System Development User’s Guide, Rev.
Chapter 22 Porting the Fast Ethernet Controller Driver This chapter explains how to port the fast Ethernet controller (FEC) driver to the i.MX53 processor. Using Freescale’s standard (FEC) driver makes porting to the i.MX53 simple. Porting needs to address the following three areas: • Pin configuration • Source code • Ethernet connection configuration 22.
Porting the Fast Ethernet Controller Driver 22.2 Source Code The source code for the Freescale FEC Linux environment is located under the ../ltib/rpm/BUILD/linux/drivers/net directory. It contains the following files: Table 22-2. Source Code Files File Names FEC low-level Ethernet driver: • fec.h • fec.c MAC Switch software • fec_switch.h • fec_switch.c IEEE 1588 PTP (network time sync) • fec_1588.h • fec_1588.c MPC52xx PowerPC Ethernet Driver • fec_mpc52xx.h • fec_mpc52xx.c • fec_mpc52xx_phy.
Chapter 23 Porting USB Host1 and USB OTG The USB Host1 and the USB OTG signals do not multiplex with other pins on the i.MX53. Therefore, it is not necessary to port IOMUX settings for these interfaces when moving to a new platform. The only required setup is as follows: • For the USB Host1 PHY — Supply USB_H1_VDDA33 with 3.3 V — Supply USB_H1_VDDA25 with 2.5 V • For the USB OTG PHY — Supply USB_OTG_VDDA33 with 3.3 V — Supply USB_OTG_VDDA25 with 2.
Porting USB Host1 and USB OTG i.MX53 System Development User’s Guide, Rev.
Appendix A Revision History Table A-1 provides a revision history for this user guide. Table A-1. i.MX53 System Development User Guide Document Revision History Rev. Number Date Substantive Change(s) Rev 1 3/2011 • In Table 1-1, "Design Checklist," changed “CCR CAMPx_EN” to “CCM_CCR[CAMPx_EN],” under the recommendation 11 and EMI to EIM under the recommendations 3, 4 and 5. • In Section 4.2, “IOMUX Tool Walkthrough,” the following introductory text was added to the first paragraph: “The i.
Revision History i.MX53 System Development User’s Guide, Rev.
Revision History i.MX53 System Development User’s Guide, Rev.
