MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

All Boards Creating App MP3 OpenEmbedded

ADB is very well known as the tool to manually install APK’s, but there are some other useful commands. ADB is a command line tool that acts as the bridge between you and your android device. I want to show you some of them, but first, let’s make sure we have everything needed to use ADB. Requirements First, you need to have Java and the Android SDK installed on your PC, you can download it from here: Java SDK: Java SE - Downloads | Oracle Technology Network | Oracle Android SDK: http://developer.android.com/sdk/index.html Once it is installed, it is recommended to update the SDK Manager Once you have done this, flash the Freescale Android BSP onto your board… Once you have installed it, you need to enable USB Debugging in the Developer Options of your board.        Here's the steps to enable USB debugging: Go to Settings. Click on "about tablet" Scroll down to the last row (Build Number) and tap that row 7 times. Return to the previous screen and click on "developer options" Confirm that "usb debugging" is checked. Once you enable it, your OS (assuming you are using Windows) will look for the Android ADB Interface driver. Windows systems are the only ones that need this ADB driver. After this procedure, you can now start using ADB. Open a terminal window and go to the platform-tools directory of your SDK installation to find the ADB program. The usual path to find it would be: adt-bundle-windows-x86 >> sdk >>platform-tools adb start-server                              ::  Starts the ADB server in case it is not running already adb kill-server                   :: Terminates de ADB server adb devices                        :: Checks  and prints the status of each device plugged to your PC  (If you don’t see your device, make sure USB debugging is enabled in your tablet.) adb install  'apk file'       :: It will install an apk to the tablet.   This apk must be located in the same folder where the adb is. adb uninstall 'apk file' :: It will uninstall an apk adb pull 'file'                                               :: It copies a file or directory (and sub-directories) from your device to the PC. adb push 'file'                          :: It copies a file of directory (and sub-directories) from your PC to the device. adb logcat                        :: Prints the logdata to the screen adb logcat –c                  :: Clears the buffer to remove any old log data. adb bugreport               :: Prints dumpsys, dumpstate and logcat. adb shell pm list packages –f    ::  List all installed packages adb shell input keyevent 26     :: Send the power button event to turn on/off the device adb shell screencap –p /sdcard/screen.png      :: Takes a screenshot of the android display adb shell screenrecord /sdcard/demo.mp4      :: Records any activity on the android display Using the window manager There is also a very useful tool to manage the display. This can be ran through a terminal connection to your board. You run this command from the following path /system/bin of your android BSP These are some of the commands available: wm density 'density number'              :: Changes the display density wm size 'display size'                                :: Changes your display’s resolution Using the activity manager In the same path is the activity manager which has several other commands for use: am start 'package'   :: Starts an activity am monitor                     :: Monitors activities am bug-report               :: Requests a bug report am restart                        :: Restarts the OS

This section for all Freescale i.MX users ranging from customers to designers to help provide the best solution to the most frequently encountered questions related to Freescale i.MX products. Products Below are links to pages containing links to documentation related to that product. i.MX Family i.MX6 Multimedia Applications Processors i.MX53 Multimedia Applications Processors i.MX51 Multimedia Applications Processors i.MX35 Multimedia Applications Processors i.MX31 Multimedia Applications Processors i.MX28 Multimedia Applications Processors i.MX27 Multimedia Applications Processors i.MX25 Multimedia Applications Processors i.MX21 Multimedia Applications Processors Topics Below are links to pages containing links to documentation related to that topic. 19-iMX_Serial_Download_Protocol.py All Boards 2D/3D Graphics All Boards Accessing Registers All Boards Audio All Boards Bluetooth Dongle All Boards Compiling RedBoot All Boards Configuring RedBoot All Boards Creating App Video All Boards Deploy NFS All Boards DirectFB All Boards FlexCAN All Boards Hardware Software All Boards How To Convert RVICE CP15 To OpenOCD All Boards How To Understand JTAG BSDL All Boards I2C-tools All Boards Java All Boards JTAG All Boards LTIB All Boards LTIB Config Ubuntu All Boards LTIB Creating Uimage Uboot All Boards NFS on Fedora All Boards NFS on Slackware All Boards NFS on Ubuntu All Boards OpenEmbedded All Boards Pdfreader All Boards PMIC Registers All Boards Qtopia All Boards Qtopia on Ubuntu All Boards Qt v2 All Boards RedBoot All Boards Serial Console All Boards TCP All Boards Tethering All Boards TFTP All Boards TFTP Fedora All Boards TFTP on OpenSuse All Boards TFTP on Ubuntu All Boards Theora Encoder All Boards Transfer Serial RedBoot All Boards U-boot All Boards Updating RedBoot Through RedBoot All Boards Video All Boards Video Host All Boards VMWare All Boards Wi-Fi All Boards X11 Android Demonstration Platform Exercising the i.MX Serial Download Protocol with a Python Script Gstreamer GTK How to Enable Second Display Showing Different Things on JB4.2.2 SabreSD How to Measure Signal Frequency by Using the Camera Sensor Interface of an i.MX i.MX as a USB Playback/Capture Device on One OTG Port i.MX Bootlets (i.MX233 EVK) i.MX USB Loader i.MXS Development Kit InternalI2C Linux Kernel Mxuart patch New Release of the i.MX OTP Tools V1.3.3 NFS OpenEmbedded Redboot Running ATK on Linux Script to Flash a Linux System into a SD card U-Boot Yoctoproject

Enter inside ~/ltibdir/rpm/BUILD and create a directory 'alpha': $ cd ltib/rpm/BUILD $ mkdir alpha Enter in 'alpha' dir and create setalpha.c file: $ cd alpha #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> #include <asm/arch/mxcfb.h>  int main(int argc, char **argv) {              int fb_fd;              struct mxcfb_gbl_alpha gbl_alpha;               if(argc != 2){                       printf("Usage: %s alpha_val[0-255]\n",argv[0]);                       return -1;              }               fb_fd = open("/dev/fb0",O_RDWR,0);              gbl_alpha.enable = 1;              gbl_alpha.alpha = atoi(argv[1]);              ioctl(fb_fd, MXCFB_SET_GBL_ALPHA, &gbl_alpha);              close(fb_fd);              return 0; } Compile it using this command: ./ltib -m shell LTIB> cd rpm/BUILD/alpha LTIB> gcc -I../linux/include setalpha.c -o setalpha In your board execute it: root@freescale /home$ /unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 480 -oh 640 -d 3 -r 4 -fr 5 qvga.yuv & While it is playing execute: root@freescale /home$ setalpha 128 root@freescale /home$ cat screen.raw > /dev/fb0 We used frame rate at 5 fps to have more time to execute next two commands.

This document is aimed to introduce seamless switch on rear view camera function in android P9 auto, and this can also be referenced for sharing dpu(display process unit) between A core and m4 core on imx8qxp/qm platform. OS: Android p9 auto beta. (linux needs some modifies). SDK_2.5.1_MEK-MIMX8QX for m4 core. Hardware platform: imx8qxp/qm mek board IT6263 lvds to hdmi cable. max9286 deserializer board. ov16035 camera. Hardware block：     Imx8qxp dpu block, for imx8qm there are two dpus:     Android/Linux and M4 shared dpu path:     The switch function is done by framegen0 unit in dpu, framegen unit can select 7 modes: primary src only second src only primary on second second on primary .....etc. for more details, please refer to the kernel codes at include/video/dpu.h, fgdm_t type. Seamless switch booting flow: Patches contain three main parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core, add ui ready rpmsg pipe. M4 code: modify dpu pipes, add ui ready rpmsg handle. AOSP init.rc scripts: add sending ui ready message scripts.

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch

Configuring U-Boot LTIB Creating Uimage Uboot U-boot FW Printenv FW Env File Add New i.MX5x Board on LTIB i.MX25 PDK I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard i.MX27 ADS Board Compiling U-Boot for i.MX27ADS Installing U-Boot on iMX27ADS i.MX31 ADS Board i.MX31ADS Compiling Uboot I.MX31ADS Installing Uboot i.MX31 PDK Board i.MX 31 PDK Board Screenshot I.MX31 PDK Board Flashing i.MX31 PDK Board DirectFB i.MX51 EVK Board i.MX51 EVK U-boot I.MX51EVK Install U-Boot i.MX51 EVK Compiling U-boot i.MX51 EVK Changing Env

Hi,      Here share the hardfloat rootfs making document and related pkgs, please feel free for download best regards Jack

The Register Programming Aid (RPA) provides a default DRAM PLL setting (DRAM frequency) based on the default setting supported in u-boot.  It is highly recommended to use the default DRAM frequency settings in the RPA for ease of use and to align with u-boot.  Otherwise, in addition to updating the RPA for the new DRAM frequency, the u-boot SPL code itself will need to be manually updated with the new DRAM PLL setting.   Should the user wish to change the DRAM frequency, the following steps are required:   First, the user needs to update the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to the desired DRAM frequency       2. Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054”.  The address “0x30360054” is for the DRAM PLL register address and its setting needs to be updated to the desired frequency.        Note that there is another place where the DRAM frequency is also updated “freq0 set 0x30360054” but it is automatically updated based on the setting above.    Below is a table of various frequencies to choose from.  For frequencies not listed in the table below, it is up to the user to calculate a new register setting based on the formula:     (24MHz x m)/(p x 2^s)   Where “m” represents the PLL_MAIN_DIV, “p” represents the PLL_PRE_DIV, and “s” represents the PLL_POST_DIV.  NOTE:  The DRAM frequency is double the DRAM PLL frequency DRAM_freq = DRAM_PLL x 2   The DRAM PLL register and bit settings are shown below:          The following table provides examples of the various settings to create the desired frequency:       For example, in the i.MX 8M Mini LPDDR4 RPA where the default DRAM frequency is 1500MHz, let’s assume that the user instead wants 1200MHz.    First, the user changes the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to 1200.   Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054” and replace “0xFA080” (original setting from DRAM frequency 1500MHz) with “0x000C8022” (updated for DRAM frequency 1200MHz).  Note that for a DRAM frequency of 1200MHz, the DRAM PLL is configured for 600MHz, as the DRAM frequency is double the DRAM_PLL.   The steps outlined above are sufficient in order to create a DDR script for use with the DDR stress test tool to run the calibration and execute the DDR stress test.  However, to deploy the generated code in SPL, more steps are needed as the u-boot SPL DDR driver does not automatically change the DRAM PLL according to the generated code. Hence the user will need to manually modify related code in u-boot.  It is highly recommended to work with a software engineer familiar with u-boot when making the following modifications.    3. Modify DRAM PLL configuration in uboot-imx/drivers/ddr/imx8m.c, specifically the code highlighted below (function call dram_pll_init).  Note that the files and file paths in u-boot change frequently, so if this particular file (or file path) does not exist in the current u-boot, simply search for dram_pll_init or ddr_init.   void ddr_init(struct dram_timing_info *dram_timing) { ……    debug("DDRINFO: cfg clk\n");      if (is_imx8mq())           dram_pll_init(DRAM_PLL_OUT_800M);      else          dram_pll_init(DRAM_PLL_OUT_750M); ……  }   In the above code, the user should update the macro “DRAM_PLL_OUT_750M” with the new DRAM PLL value.  Note that the default DRAM_PLL_OUT_750M results in the DRAM frequency of 1500MHz, where the DRAM frequency is double the DRAM PLL (as previously stated above).   For example, if the user desires to run the DRAM at 1200MHz, they would change the above to: dram_pll_init(DRAM_PLL_OUT_600M);   Note that DRAM_PLL_OUT_600M is a supported macro in the dram_pll_init() API.  If the desired DRAM PLL configuration does not exist in dram_pll_init(), you will need to add support in uboot-imx/arch/arm/mach-imx/imx8m.c  (as stated above, if this file path does not exist in the current u-boot simply search for dram_pll_init):   void dram_pll_init(enum dram_pll_out_val pll_val) { …… }   Related Links i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 

This is a tool can generate a DDR3 script easily for i.MX53 and only need input several parameters based on using DDR datasheet and system architecture. Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6SL LPDDR2 Script Aid through below link. i.Mx6SL LPDDR2 Script Aid Any questions are welcome!

Attached is the Kernel needed to construct the following image: i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Bad and Ugly gstreamer plugins has their own special licensing, so it cannot be released formally inside any tarball. (I do not understand it deeply, if you want more info, please go to GStreamer: Licensing advice) But you can add it on your own image, and you only need to change the local.conf Please, add the following code to your local.conf: LICENSE_FLAGS_WHITELIST = "commercial" COMMERCIAL_AUDIO_PLUGINS ?= " \ gst-plugins-ugly-mad \ gst-plugins-ugly-mpegaudioparse \ " COMMERCIAL_VIDEO_PLUGINS ?= " \ gst-plugins-ugly-mpeg2dec \ gst-plugins-ugly-mpegstream \ gst-plugins-bad-mpegvideoparse \ " CORE_IMAGE_EXTRA_INSTALL += " \ packagegroup-fsl-gstreamer \ gst-plugins-base-videotestsrc \ gst-plugins-bad-fbdevsink \ gst-ffmpeg alsa-utils \ gst-plugins-good-isomp4 \ " Please, note that this will not install *every* plugin from ugly or bad. It will only install the plugins from the list. Go to Yocto Training - HOME Go to Task #8 - Build kernel manually using created toolchain

Description about VPU & IPU usage in Android R13.4 GA release for i.MX6DQ

Hi All, The i.MX6 Android R13.4-GA.03 patch release is now available on www.freescale.com ·         Files available # Name Description 1 IMX6_R13.4.03_ANDROID_PATCH This patch release is based on the i.MX 6 Android R13.4   release. The purpose of this patch release is correct the PFD workflow in   U-Boot, fix the miscalibration issue for the thermal sensor and corrects   ramp-up time of the internal LDOs

Development environment: i.MX6Q SabreSD w/ L3.0.35_1.1.0_121218 release. Quoting from Wikipedia about exFAT (exFAT - Wikipedia, the free encyclopedia) as following: exFAT (Extended File Allocation Table) is a Microsoft file system optimized for flash drives. [3] It is proprietary and patent-pending. [1] It is supported in Windows XP and Windows Server 2003 with update KB955704, [2] Windows Embedded CE 6.0, Windows Vista with Service Pack 1, [4] Windows Server 2008, [5] Windows 7, Windows 8, Windows Server 2008 R2 (except Windows Server 2008 Server Core), Mac OS X Snow Leopard starting from 10.6.5, [6] Mac OS X Lion and OS X Mountain Lion. The history of support exFAT in Linux was since from 2.6.x, it involves several parts that will be described followingly. Part 1: Linux Kernel            Enable FUSE (Filesystem in userspace) feature in Kernel Config, then build a new uImage and module if set it to be "M"; Part 2: fuse-2.9.2.tar.gz            Download fuse-2.9.2.tar.gz from http://sourceforge.net/projects/fuse/files/fuse-2.X/, untar it, then build it with following commands: ./configure --prefix=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/usr --host=`/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc -dumpmachine` --enable-lib --enable-util --enable-example --exec-prefix=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/usr make sudo make install Part 3: exfat-utils-1.0.1.tar.gz            Download exfat-utils-1.0.1.tar.gz from http://code.google.com/p/exfat/downloads/list, untar it, then build it with following command: sudo scons SYSROOT=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs DESTDIR=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/sbin CC=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc AR=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ar RANLIB=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ranlib STRIP=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-strip install Part 4: fuse-exfat.git git clone git://sources.progress-linux.org/git/releases/baureo-backports/packages/fuse-exfat.git  fuse-exfat.git cd fuse-exfat.git Replace the root SConstruct with the attached one, then execute command: sudo scons SYSROOT=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs DESTDIR=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/sbin CC=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc AR=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ar RANLIB=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ranlib STRIP=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-strip install After all above steps done, you can check whether the necessary files under your rootfs like I did as following: http://en.wikipedia.org/wiki/ExFAT#cite_note-uspatent-2alanz@alanz-VirtualBox:~/i.MX6_L3.0.35_121218/ltib$ find ./rootfs/ -name *exfat*./rootfs/sbin/exfatlabel ./rootfs/sbin/mount.exfat ./rootfs/sbin/fsck.exfat ./rootfs/sbin/dumpexfat ./rootfs/sbin/exfatfsck ./rootfs/sbin/mount.exfat-fuse ./rootfs/sbin/mkexfatfs ./rootfs/sbin/mkfs.exfat alanz@alanz-VirtualBox:~/i.MX6_L3.0.35_121218/ltib$ find ./rootfs/ -name *fuse*./rootfs/usr/include/fuse ./rootfs/usr/include/fuse/fuse_common_compat.h ./rootfs/usr/include/fuse/fuse_compat.h ./rootfs/usr/include/fuse/fuse_lowlevel_compat.h ./rootfs/usr/include/fuse/fuse_opt.h ./rootfs/usr/include/fuse/fuse_lowlevel.h ./rootfs/usr/include/fuse/fuse.h ./rootfs/usr/include/fuse/fuse_common.h ./rootfs/usr/include/fuse.h ./rootfs/usr/src/linux/include/linux/fuse.h ./rootfs/usr/lib/libfuse.so ./rootfs/usr/lib/libfuse.a ./rootfs/usr/lib/libfuse.so.2.9.2 ./rootfs/usr/lib/libfuse.la ./rootfs/usr/lib/libfuse.so.2 ./rootfs/sbin/mount.exfat-fuse Check Steps can be referenced by the steps presented on internet. NOTE: The directory name "/home/alanz/i.MX..." should be revised per your self development environment.

Issue: kernel panic when repeating plug/unplug USB device(e.g. USB flash disk) in Linux 4.1.15 The issue is in kernel BLOCK DEVICE, this is not a hardware related issue(happens to all devices running L4.1.15 or L4.4.x), please refer to following link on kernel.org for more details and fixes: blockdev kernel regression (bugzilla 173031) - Patchwork 

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. Overview The i.MX Power Profiler system consists of one to fourteen "smart" current sensors, an aggregator shield, and a Kinetis FRDM board (the FRDM-KL25 has been used in prototyping but the FRDM-K64F and FRDM-K66F should also be fully compatible). One of the biggest improvements of this system over its preceeding dual-range measurement system is that the microcontroller on each sensor board allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler has only a single MCU for all sensors, so only one measurement can be made at a time.  It is intended to be used to instrument one to fourteen rails of a target i.MX appliation board. Ideally, the target board will have been designed with a matching/mating power sense footprint for each rail to be measured.  Each smart sensor can sense current in three ranges with three current sense amplifiers. They are "smart" because each sensor board has a Kinetis KL05Z on it to control the switching FETs and to digitize the analog signals (the sense amplifier outputs and the target's power supply rail voltage). A 1% voltage regulator on each smart sensor provides a good voltage reference right next to the KL05Z to ensure better ADC accuracy. Each smart sensor board communicates via I2C. The aggregator shield has three I2C bus extenders (PCA9518) which essentially provide a dedicated I2C bus for each of the connected smart sensors. The FRDM board's I2C is also connected to one of the bus extenders ports. Individual GPIO lines are routed to each smart sensor's connected along with a ganged reset and trigger line for all of the connected smart sensors. A boost regulator generates almost 12V from the FRDM board's 5V supply, which is used for all the switching FETs on the smart sensor boards. The FRDM board's 5V rail is also routed to each smart sensor, which is regulated down to 3.3V locally on each connected smart sensor. Here is a photo of the very first prototypes after moving to 10-pin 0.05" spaced headers and ribbon cables instead of FFC: The smart sensor is intended to mate with through-hole current sense tap points on the target i.MX application board. Three holes spaced at 0.05" each. When not instrumented with sensor, a short needs to be placed across the outer two pins so that the board will function normally. The through hole connections provide physical protection to the target board, keeping traces from getting ripped off. The ground connection in the center provides a reference for meauring the rail voltage on the target board. A partial layout example of the implementation of the current sense footprint is below, where two 0805 shorting resistors in parallel are placed on each side of the holes. The top trace connects to the regulator output and the bottom to the load, usually an i.MX power supply rail. To include the current sense footprint into a board during the design phase, it should be configured as in the following partial schematic:  Every effort should be made to place the feedback on the i.MX side of the sense points so that the regulator compensates for the additional series resistance of the smart sensor, which effectively eliminates the additional series resistance the smart sensor adds. The Feedback should be before the smart sensor if the switching supply won't tolerate the additional series resistance (i.e., output becomes unstable).

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