After rework the board, enable two OTG controllers in Linux DTB file and disable VBUS valid comparator when in suspend mode by clear USB_OTGx_PHY_CTL2 bit 16.  Then we get the following power data on suspend mode  Suspend Mode     ****  The page is under internal check ****

Summary of the Issue: We have had customers reporting failure to run MC and SC production parts at 1GHz or higher frequencies. The signature of the fail is that the system will hang once it tries to ramp from the boot frequency of 800MHz to 1GHz or higher. The root cause was tracked to the setting of the LDO_VOLT_CHANGE_EN fuse in production parts. The LDO_VOLT_CHANGE_EN fuse sets the LDO boot voltage to either 1.15V (indicated by a fuse setting of “1”) or 1.1V  (indicated by a fuse setting of “0”). In production parts the fuse is set to “1”, i.e. 1.15V, since this is the optimal setting based on characterization data. On pre-production units the LDO voltage was set to the lower setting of 1.1V (i.e. fuse set to “0”). The reason this is a problem with MC/SC parts is because the fuse is read by the ROM during boot and overwrites the LDO ramp rate bits in the PMU_MISC2 register based on the setting of the fuse. When the LDO_VOLT_CHANG_EN fuse is set to “1” then the LDO ramp up time to spec voltage is set (in PMU_MISC2) to 500uS instead of the 50uS assumed by the CPUFreq driver. This will cause the system to hang when transitioning from the boot frequency to a higher frequency/voltage point since the required voltage to support the higher frequency is not yet present. In real terms, customers who have production i.MX 6Quad/6Dual/6DualLite and 6 Solo parts have seen failures to ramp their products to 1GHz or higher frequencies. This is completely fixed by a software patch that corrects the LDO ramp setting in the PMU_MISC_2 register by setting it back to the fastest ramp time. Note that the LDO_VOLT_CHANGE_EN fuse is not in the reference manual since it is not a customer visible fuse. It is programmed and locked at final test. This is a mandatory fix for all customers. Affected Parts: i.MX 6Quad – all SC and MC parts, consumer and automotive. Industrial MC parts not yet shipping. i.MX 6Dual – all SC and MC parts, consumer and automotive. Industrial MC parts not yet shipping. i.MX 6DualLite – all MC parts consumer parts. Automotive and industrial MC parts not yet shipping. i.MX 6Solo – all MC consumer parts. Automotive and industrial MC parts not yet shipping. Patch Availability and Location: Patches exist for both Linux and Android. They are available on freescale.com. See below for more details. i.MX 6Quad – www.freescale.com/imx6q i.MX 6Dual – www.freescale.com/imx6d i.MX 6DualLite – www.freescale.com/imx6dl  i.MX 6Solo – www.freescale.com/imx6s Select the “Software and Tools” tab and then expand the section “Updates and Patches”.  The relevant patches are: Linux – L3.0.35_1.1.1_LDO_PATCH (i.MX 6Quad/6Dual) Linux – L3.0.35_3.0.3_LDO_PATCH (i.MX 6DualLite/6Solo) Android – IMX6_R13.4103_ANDROID_LDO_PATCH (i.MX 6Quad/6Dual/6DualLite/6Solo) Communication Roll-out: i.MX FAE’s: done (via maillist). Will post copy of this email to i.MX support space by end of day 1 st March. i.MX DFAE’s: 8 th March. Customer notification: 8 th March. i.MX community: 8 th March (to coincide with customer notification). We are also working on an engineering bulletin that describes the change for customers who are not using our provided Linux and Android BSP’s. Target date: TBD. But goal is to make this available on/around mid-March. Best regards, Amanda and Kyle This document was generated from the following discussion: i.MX 6 Series LDO Ramp Issue: Linux and Android Patches Now Available

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345322 

RidgeRun provides a fully featured Embedded Linux Software Development Kit for Freescale iMX6 based applications processors. Freescale iMX6 platform delivers high performance, power efficient applications processors with a robust support network and software portfolio including open source. The complete platform allows for differentiation and rapid development of applications from wireless handsets to other multimedia-enhanced devices. The i.MX6 series processors are a scalable multicore platform that includes single-, dual- and quad-core families based on the ARM® Cortex™-A9 architecture. This architecture is a robust - cross industry and product platform. Whether your product is targeted at consumer electronics, industrial, automotive or security related, this flexible, scalable architecture combined with RidgeRun's easy-to-use SDK's and extension products allows you to concentrate your effort of differentiating features and not product infrastructure. FEATURES Boot loader 2013.07 Linux kernel 3.0.35-4.0.0 Gstreamer-0.10.36 Freescale gst-plugins 3.0.7 Hardware based audio and video codecs SD and NFS file system support Boot from SD3, SD4 or SPI-NOR with an easy installation (Boundary devices boards only) Toolchain to linaro 2012.03 for software floating point and 2013.03 for hardware floating point support For more info please contact: [email protected] or Please Click -> Contact Us

Here are two patchs: Patch 1: 0001-I.MX6-SSI_ASRC_P2P_Capture-for-SabreSD-board-Kernel-.patch Patch 2: 0001-I.MX6-SSI_ASRC_P2P-Capture-for-SebreSD-board.patch Patch 1 is based on patch 2.     memory <-- ASRC_Output FIFO | ASRC_Input FIFO <-- SSI_RX FIFO <-- Audio Codec                                              |           |     ASRC Out clk ASRCK1 <---|           |--->   ASRC In clk None                                              |           |     ASRC OutPut width            |           |       ASRC InPut width and data format     is set by arecord            <---|           |--->   is set by ASRC P2P parameter     parameter                          |           |                                             |           |     support 44100/48000          |           |       support 44100/48000     and S24_LE/S16_LE     <---|           |--->   and S24_LE/S16_LE    You can use:     arecord -Dhw:0,1 -c 2 -f S16_LE/S24_LE -r 44100/48000 XXX.wav     aplay XXX.wav     to test this patch.

ESAI module in i.MX6D/I.MX6D/I.MX6DL/I.MX6S supports several RESET funtions: Reset ESAI Core, Reset both Transmitter and Receiver, Reset Transmitter individually, Reset Receiver individually, Reset Transmitter FIFO and Reset Receiver FIFO. Below is a simple diagram for these RESET functions, which shows reset object and related register configurations. 1.Reset ESAI Core After setting ESAI_ECT ERST bit to be 1, ESAI core and configuration registers will be reset, but Transmitter and Recevier FIFOs can't be reset by the operation. 2. Reset both Transmitter and Receiver After setting ESAI_PCRC & ESAI_PRRC to be 0x000, Transmitter and Receiver can both be reset, The RESET is also called "Personal Reset" in it's reference manual. About PCRC & PRRC bits functionality, we can see the table: From the table, ESAI_PCRC=0x000 and ESAI_PRRC=0x000 will make ESAI disconnet external ESAI pins, and ESAI's Tranmitter and Receiver can't communicate with external audio codec.  See ESAI_PCRC and ESAI_PRRC register below: ---ESAI_PCRC register ---ESAI_PRRC register There are 12 bits in each register to contorl "DISCONNECTION" OR "CONNECTION" with ESAI pins. So for normal operations of ESAI, these 2 registers can't be changed. 3.Reset Transmitter & Receiver individually By setting ESAI_TCR[TPR]=1, Transmitter can be reset individually, and not affect Receiver. By setting ESAI_RCR[RPR]=1, Receiver can be reset individually, and not affect Transmitter . In reference manual, the reset is called "personal reset / individual reset", actually they means the same thing: --Reset Transmitter individually. --Reset Receiver individually. 4.Reset Transmitter FIFO and Reset Receiver FIFO ---By setting ESAI_TFCR[TFR]=1, Tranmitter FIFIO can be reset. ---By setting ESAI_RFCR[RFR]=1, Receiver FIFO can be reset. The Reset requires ESAI is operational, which means at least one pin is defined as an ESAI pin. NXP TIC team Weidong Sun

i work with IMX6q,i find VDI is not work,And the video picture has Horizontal stripe. i want to know how should i make VDI work? FAE tell me enable g_vdi_enable in mxc_v4l2_tvin.c.but i do it already.The VDI don't  still work. please help me, many thanks

Downloading and building the V4L2 examples V4L2 examples - v0.1 are available at https://github.com/rogeriorps/v4l2-examples To download, just clone the project: $ git clone https://github.com/rogeriorps/v4l2-examples.git Available demos Example1: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OVERLAY Example2: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OUTPUT Known issues

If you cannot access the www.youtube.com, you may watch the citrix demo in Youku, the link as fellow: Citrix Receiver for Linux is a software client to access the desktops, applications, and data easily and securely from many types of Linux devices. About Installing Citrix Receiver,please go to Citrix website Receiver The i.MX 6DQ processor incorporates the hardware accelerators Video Processing Unit(VPU) and 3D/2D Graphics Processing Unit. By taking the advantage of i.MX 6DQ hardware accelerators, Freescale integrates H264 hardware decoder to Citrix Receiver for Linux on i.MX6DQ Ubuntu. With accelerated hardware decoding, the computing is offloaded and better performance is achieved. Configuration in the demo: Hardware i.MX6Q: i.MX 6Quad Processors: Quad Core, ARM® Cortex®-A9 Core 1920x1080 HDMI panel Software: Linux kernel 3.0.35 Ubuntu 12.04 hardfloat rootfs Citrix Receiver13.1 with Freescale H264 plug-in

Wir laden Sie zum i.MX 6 Workshop in Mainz recht herzlich ein. Bei diesem Workshop wird Ihnen der Controller von Freescale im Detail erklärt. Neben der Vorstellung der Entwicklungsumgebungen steht der Gedankenaustausch mit den Referenten und Entwicklern ganz weit oben. Melden Sie sich jetzt an! Zielgerichtet aus der Praxis für die Praxis phyFLEX i.MX 6 Workshop Schulungen sind Investitionen, die sich durch Zeitgewinn und sichere Designs in kürzester Zeit amortisiert haben. Sie sichern vorhandenes Wissen und passen Arbeitsweisen an Weiterentwicklungen des Marktes an. Neue Controller mit erweiterten Fähigkeiten und neuen Hardwareansätzen erfordern erweitertes Wissen. Betriebssysteme und moderne Entwicklungsumgebungen bieten andere Arbeitsweisen, die der Komplexität heutiger Projekte gerecht werden. Ihre Weiterbildung ist uns wichtig. Termine: 07.11.2013 in Mainz Zeit: 9:00 Uhr bis 18:00 Uhr Begrüßung unserer Gäste ab 8:30 Uhr in der Robert-Koch-Straße 37 in 55129 Mainz. Workshopinhalt: Agenda Ab 8:30          Empfang in der Robert-Koch- Str. 37, 55129 Mainz 09:00 – 09:15 Begrüßung der Gäste und Vorstellung der Referenten 09:15 – 10:30 Vorstellung des Prozessors, Herr Rodrigue Simonneau, Freescale 10:30 – 10:45 Kaffeepause 10:45 – 11:45 Vorstellung Hardware (Modul & Carrier Board)                         - der i.MX 6 in unseren Produktfamilien                         - verfügbare Features des phyFLEX-i.MX 6 Moduls                        - Applikationsplatine: Welche Schnittstellen stehen schon im Kit zur Verfügung?                        - Mögliche Bestückungsvarianten des Serienmoduls 11:45 – 12:15 Zeit für Fachgespräche mit den Entwicklern 12:15 – 13:00 Mittagspause 13:00 – 14:00 Führung durch die Produktion 14:00 – 15:00 Digital Imaging mit i.MX 6 - Einführung in die Kameraschnittstellen des i.MX 6 - Konzepte zum Anschluss von Kameramodulen - Überblick über das Software-Interface 15:00 – 16:15 Vorstellung der Linux Entwicklungsumgebung bis hin zum Erarbeiten eines Beispiels                       - LiveDVD mit Eclipse                        - Beispiel-Programm unter Eclipse zur Ansteuerung der GPIO Platine              - Grafik Demos mit OpenGL und Mpeg Decoder               - Benchmark zum Anzeigen der Leistung einzelner Cores 16:15 – 16:45       Zeit für Fachgespräche mit den Entwicklern 16:45 – 17:00     Kaffeepause 17:00 – 18:15        Vorstellung Windows Embedded Compact 7              - Welche neuen Features stehen unter WEC7 zur Verfügung?                - Erste Schritte in WEC7 auf der phyFLEX-i.MX6              - Applikations-Debugging über USB Active Sync               - Verwendung der Remote Tools des Plattform Builders 18:15           Zeit für Fachgespräche mit den Entwicklern Am Tag des Workshops besteht die Möglichkeit ein Phytec i.MX 6 Kit (Linux oder WEC7) käuflich zu erwerben. Geben Sie gleich bei Ihrer Anmeldung an, ob an einem Kauf gernerelles Interesse besteht. Nutzen Sie diese Möglichkeit und melden Sie sich gleich zum i.MX 6 Workshop in Mainz an: Anmeldung Für nähere Fragen und Anmeldung steht Ihnen unser Vertriebsteam gerne zur Seite: Telefon: + 49 (0) 6131/ 9221-32 Unsere Produkte zum i.MX 6 finden Sie hier.

In the older code, headphone router is always on, it is not a good choose for low power demand. This patch uses imx_hp_jack_gpio.jack_status_check to instead of w->event. It enables Ext Spk and disables Headphone Jack when Headphone Jack is plug in, it disables Headphone Jack and enables Ext Spk when Headphone is out.

Q: Looking at the datasheet, why a 14.7KOhm pulldown and a 4.7KOhm pullup must be used? When useing 4.7KOhm resistors in series from an MCU to control the boot pins, pull up is ok, but pull down is not. The EIM boot pins only see 4.7KOhm and not 14.7KOhm as recommended in the design guide. How did we determine those resistor values? at boot there is a pull-up of 100KOhm in the pad if I understand well, 4.7KOhm would do the job as well as 14.7K. right? A: 4.7k will work fine for pull-up or pull-down. 10k pull-downs is to limit current drain while allowing use of simple SPST switches to configure boot-up. There are on-chip 100k pull resistors, so this limits max resistor size. This document was generated from the following discussion: EIM boot resistor value

Ridgerun SDK for iMX6 based boards now supports the X11 protocol. The server-client based protocol is now supported by our professional SDK using hardware floating point which enables a high performance and provides all the advantages that comes with X.  In the RidgeRun SDK you'll also find complete integration of Qt4.8.5 using an X-based windowing system. We currently support Matchbox and Enlightenment which is a complete desktop environment. Contact RidgeRun for more details at : [email protected] or Please Click -> Contact Us RidgeRun Home Page : www.ridgerun.com RidgeRun iMX6 based solutions : iMX6 Based Solutions

[中文翻译版] 见附件   原文链接： Add a new shared memory region on Android Auto P9.0.0_GA2.1.0 BSP 

In L2.6.35_11.09.01_ER BSP Uboot, the MMC driver was updated, but there is issue that when you modified some uboot code, the MMC driver has chance to fail to work. The root cause is that mmc->has_init hasn't been initialized. Sometimes the value will be not zero, then mmc driver will be skipped for initialization. Attached is the patch to fix this issue in L2.6.35_11.09.01_ER BSP Uboot.

Question: Did we tested active PCIe components while the Cortex-A9 was in Sleep Mode (suspend to memory)? Answer: It's a known issue that PCIe can't support suspend/resume. And can't be built in kernel image if the system want suspend/resume. I think PCIe will be active while core is in sleep more. Is it different scenario? No, the pcie core is not active, it is in L2 state after suspend, and it can't resume back to L0 state when system resume is called. So, DO NOT let pcie do suspend operation right now. BTW, the tested device: * INTEL x1 1000M CT network card. * INTEL iwl wifi cards. * x1 pcie to usb3.0 card Yes, this patch had been tested on imx_3.0.35_4.0 release, and would be merged into next 3.0.35 release. TO1.2 is used. We tested the Patch against imx_3.0.35_4.0 release

The patch is based on jb4.3_1.1.1-ga_rc2. Merge some commits from kitkat.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345672 

The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system?

This tutorial describes the complete procedure for calibrating a touchscreen display using Weston, specifically validated with the DY1212W LVDS panel on the following NXP development platforms: i.MX93‑EVK FRDM‑i.MX95 FRDM‑i.MX8MP While the initial calibration performed by Weston works only temporarily, this guide will walk you through configuring the system so that the calibration becomes persistent across reboots. The steps below include performing the initial calibration, editing Weston’s configuration, creating a calibration helper script, and applying udev rules to store the calibration matrix automatically.   Temporary Touchscreen Calibration To begin, run the following command to perform an initial calibration of your touchscreen: weston-touch-calibrator LVDS-1   After running this command, your display should be correctly calibrated. However, this calibration is not persistent, and you will need to recalibrate after every reboot unless you complete the persistence steps below.   Making the Calibration Persistent Follow the steps below to ensure that calibration settings are preserved across system restarts. Step 1: Edit the Weston Configuration File Open the following file: /etc/xdg/weston/weston.ini Under the [libinput] section, add these lines: [libinput] touchscreen_calibrator=true + calibration_helper=/usr/bin/save-calibration.sh This enables the calibration helper script that will automatically save your settings. Step 2: Create the Calibration Helper Script Create a new script at: /usr/bin/save-calibration.sh   Insert the following content: #!/bin/bash # Store the transformation arguments for the resistive touchscreen as udev rule echo 'SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{ID_INPUT_TOUCHSCREEN}=="1", ENV{LIBINPUT_CALIBRATION_MATRIX}="'$2' '$3' '$4' '$5' '$6' '$7'"' >> /etc/udev/rules.d/touchscreen.rules   Make the script executable: chmod 755 /usr/bin/save-calibration.sh   Step 3: Restart Weston and Recalibrate Restart the Weston service: systemctl restart weston   Run the calibration tool again to generate the persistent settings: weston-touch-calibrator LVDS-1 reboot   Conclusion After completing all of the steps above, your touchscreen calibration will now persist across reboots, ensuring a consistent user experience even after powering off the board. This configuration allows the system to automatically store and apply calibration data through a udev rule generated by your helper script. If you encounter any issues or require further assistance, feel free to reach out. Best regards, Chavira