i.MX Processors Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Freescale's PF0100 PMIC should have VDDIO power tied to the same supply as the associated I2C supply on MX6. There is a momentary on-chip sneak path on power-up if VDDIO is wired per the i.MX6 SABRE-AI automotive development platform. As a result, I2C power rail P3V3_DELAYED rises prematurely due to backfeed from P3V3 through the I2C port. Note that on SABRE-AI, P3V3 powers up before P3V3_DELAYED. Existing SABRE-AI design: PF0100 VDDIO is wired to P3V3. Corrective action for mass production: Wire PF0100 VDDIO to P3V3_DELAYED; same supply as the associated I2C supplies on MX6 (NVCC_EIM0 and NVCC_GPIO). Laboratory results attached.
View full article
Product Family Features The i.MX6 series unleashes the industry’s first truly scalable multicore platform that includes single-, dual- and quad-core families based on the ARM® Cortex™-A9 architecture. Together with a robust ecosystem, i.MX6 series provides the ideal platform to develop a portfolio of end devices based on a single hardware design. With high-performance multimedia processing, pin*- and software- compatible product families and integrated power management, i.MX6 series is purpose built for the new era of smart devices. *4 of 5 families are pin-compatible The i.MX6 applications processor is a Energy-Efficient Solutions products. Automotive As drivers adopt personal and home-based smart devices, automotive manufacturers are bringing a similar experience in-vehicle. Able to meet demands of connectivity, real time data delivery, digital instrumentation, audio and multi-stream video, i.MX 6 series enables auto infotainment and instrument cluster designers to re-create today’s consumer technology experience in the car. Smart Devices The market for intelligent, multimedia centric, touch based devices is increasing exponentially. Not just for tablets or smartphones anymore, tomorrow's battery powered Smart Devices, Aero Infotainment systems, medical systems, enterprise-class intelligent control and data systems all must present data and user interface choices to the end user primarily through rich sound, video, voice, pictures and touch, rather than keyboards and mice. i.MX 6 series enables developers to deliver a more seamless natural user interface (NUI) experience, plus save time and costs by leveraging one design across a portfolio of devices. i.MX 6 Series Portfolio View the complete i.MX 6 Series; compare features and performance   Product Information i.MX6DL: i.MX 6DualLite Family of Applications Processors i.MX6S: i.MX 6Solo Family of Applications Processors i.MX6D: i.MX 6Dual Family of Applications Processors i.MX6Q: i.MX 6Quad Family of Applications Processors i.MX6SL: i.MX 6SoloLite Family of Applications Processors Design Resources i.MX 6 Series Software and Development Tools i.MX 6SoloLite Evaluation Kit SABRE Platform for Smart Devices SABRE Board for Smart Devices SABRE for Automotive Infotainment i.MX 6 Family Ecosystem Partners Partners / 3rd-Party Development Tools Development platform for i.MX 6Quad - Built to SABRE Lite design from Element 14 Element14's SabreLite Board Officially Supported by Adeneo Embedded's i.MX6 WEC7 BSP Emtrion's i.MX6 DIMM Modules and Kits i.Core M6 : i.Mx6 based SOM Industry-First Pico-ITX SBC based on i.MX6 from iWave Systems i.MX6 Q7 Development Kit by iWave Systems New PMIC to Support the i.MX6 Processor Family NovPek i.MX6Q/D by NovTech Video- iWave Launches Industry's first i.MX6 Solo/Dual Lite Based Pico-ITX Single Board Computer i.MX6 Q7 Development Kit by iWave Systems The Wandboard - ultra lowcost development board with i.MX6 Cortex-A9 processor SABRE Lite by Boundary Devices Nitrogen6X by Boundary Devices Additional Resources i.MX6 (All) Tips & Tricks Android data partition encryption on i.MX6 Android Graphic UI with GPU Hardware Acceleration Auto Insmod Kernel Modules Through Modprobe with Extra Parameter A Patch to Fix i.MX6 GPU Startup Issue Due to Memory Connection Qt Landing page De-interlace Capture Device Enabling MMU and Caches on i.MX6 Series Platform SDK Errata_ERR006282_Description_IMX_Community.pdf Fast GPU Image Processing in the i.MX 6x Freescale Yocto Project main page Gstreamer HW Design Checklist for i.MX6 How to Add Ethernet UI Support in ICS How to Support New WiFi Card in Android How to Support Recovery Mode for POR Reboot Based on i.MX6 Android R13.4.1 How to Trace the Low-Level Malloc i.MX6 Crystal Drive Level (24 MHz) EB830 i.MX6 Android 13.4.1.03 Patch Release i.MX6 Dual/6 Quad Power Consumption Measurement Scripts i.MX6 IPU Output Timing Generation Counters and Interrupts i.MX6 Platform SDK 1.1 Release i.MX6 VDD_SNVS_CAP Component Recommendation Linux Fast Boot on i.MX6 Sabresd Board LMbench Benchmarks on i.MX New PMIC to Support the i.MX6 Processor Family Memory Management on i.MX6 Android Patch to Support BT656 and BT1120 Output For i.MX6 BSP Prevent PMIC PF0100 Backfeed on i.MX6 Designs Using a USB Camera with GStreamer VAR-SOM-MX6, $52 i.MX6 System on Module i.MX6D/6Q (Dual/Quad) Tips & Tricks De-interlace Capture Device Android Power Management on i.MX6DQ/DL Android Graphic UI with GPU Hardware Acceleration Memory Management on i.MX6 Android iMX6QD How to add 24-bit LVDS support in Android i.MX6 D/Q L3.035_1.0.2 Patch Release i.MX6 D/Q L3.0.35_1.0.3 patch release i.MX6 D/Q L3.035_1.1.3 patch release i.MX6Q Ubuntu Fluxbox Multimedia with VPU & IPU HW Acceleration in Android Let Ubuntu NetworkManager Recognize BCM4330 Wireless Interface Auto Insmod Kernel Modules Through Modprobe with Extra Parameter Video Playback Performance Evaluation on i.MX6DQ Board Linux Fast Boot on i.MX6 Sabresd Board Linux Fast Boot on i.MX6Q Board: Building Steps New Ubuntu SD Card Demo Image for the i.MX6Q SABRE AI SDMA ap_to_ap Fixed Scripts (i.MX6DQ) Surround View Demo With Linux Fast Boot Review Surround View (D1) Demo on i.MX6 Test Digital Zoom of Camera Preview Using i.MX6Q to Build a Palm-Sized Heterogeneous Mini-HPC i.MX6DL (DualLite)  Tips & Tricks Android Power Management on i.MX6DQ/DL i.MX6 DL/S L3.035_3.0.4 patch release i.MX6SL (SoloLite)  Tips & Tricks Dithering Implementation for Eink Display Panel
View full article
i.MX6DQ HDMI dongle board uses BCM4330 which is SDIO interface as wireless module. When we try to run Ubuntu oneiric on HDMI dongle board, after correctly insmod bcm4330.ko, we found Ubuntu NetworkManger can't recognize this interface: the /var/log/syslog shows the following error: Jan  1 00:01:08 linaro-ubuntu-desktop NetworkManager[4787]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/wlan0, iface: wlan0) Jan  1 00:01:08 linaro-ubuntu-desktop NetworkManager[4787]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/wlan0, iface: wlan0): no ifupdown configuration found. Jan  1 00:01:08 linaro-ubuntu-desktop NetworkManager[4787]: <warn> /sys/devices/virtual/net/wlan0: couldn't determine device driver; ignoring... After using Google search, we found /sys/devices/virtual/net/wlan0 directory dose not has directory "device", this "device" directory should be exist at network interface, without it, NetworkManager will get error "couldn't determine device driver; ignoring...",  the "device" is just this network interface come from, and it should link to the real device under one hardware bus. While the bcm4330 Linux driver from Broadcom does not setup network interface real "device" so we need add this real "device" before the driver registers a network interface. Refer to the attached diff file for this modification
View full article
Wireless HW module on i.MX 6 DQ HDMI dongle board is bcm4330 that is SDIO interface. Modprobe  default configuration will only insmod bcm4330.ko without any kernel module parameter, while bcm4330,ko needs extra firmware binary and nvram configuration file absolute path/filename  as parameter like firmware_path=/lib/firmware/bcm4330/fw_bcm4330.bin nvram_path=/lib/firmware/bcm4330/nvram_bcm4330.txt. To auto insmod bcm4330 kernel module with those parameters by modprobe we need a modprobe configuration file. Now create this file at /etc/modprobe.d/bc4330.conf, it's content as below: #For BCM4330 special install requirement options bcm4330 firmware_path=/lib/firmware/bcm4330/fw_bcm4330.bin nvram_path=/lib/firmware/bcm4330/nvram_bcm4330.txt Of course we need copy correct firmware and nvram configuration file to directory as /etc/modprobe.d/bc4330.conf set.
View full article
Introduction LVDS display panel driving data flow: Display quality: To get the best display quality for 24bit LVDS display panel in Android, we should use 32bit framebuffer, make IPUv3 display Engine and LDB output 24bit pixels, since RGB component information is aligned from source to destination.  2 stages to enable display: Uboot splash screen and Kernel framebuffer Guidelines Uboot splash screen:    Change should be done in board file, like board/ freescale /mx6q_sabresd/mx6q_sabresd.c:    1. Set video mode in struct fb_videomode according to the new 24bit LVDS display panel’s spec(please, refer to the example at the end of this doc).    2. Set up pwm, iomux /display related clock trees in lcd_enable (). Note that these should be aligned with Kernel settings to support smooth UI transition        from Uboot splash screen to Kernel framebuffer .    3. Set the output pixel format of IPUv3 display engine and LDB to IPU_PIX_FMT_RGB24 when calling ipuv3_fb_init().    4. Set pixel clock according to the new 24bit LVDS display panel’s spec when calling ipuv3_fb_init().    5. If dual LDB channels are needed to support tough display video mode(high resolution or high pixel clock frequency), we need to enable both of the two LDB        channels and set LDB to work at split mode. LDB_CTRL register should be set accordingly in lcd_enable (). Kernel framebuffer :    As we may add ‘video=‘  and ‘ ldb =’ options in kernel bootup command line, Kernel code is more flexible to handle different LVDS display panels with various display color depth than Uboot code. For detail description of ‘video=’ and ‘ ldb =’ option, please refer to MXC Linux BSP release notes and Android User Guide. Some known points are:    1. Add a video mode in struct fb_videomode in drivers/video/ mxc / ldb.c according to the new 24bit LVDS display panel’s spec(please, refer to the example at        the end of this doc).    2. Set up pwm backlight/display related iomux in platform code.   3. Set appropriate ‘video=‘ option in kernel bootup command line, for example:        video=mxcfb0:dev= ldb,LDB-NEW,if =RGB24,fbpix=RGB32     4. Set appropriate ‘ ldb =‘ option in kernel bootup command line if dual LDB channels are needed to support tough display video mode, for example:        ldb =spl0 (IPUv3 DI0 is used)  or  ldb =spl1 (IPUv3 DI1 is used)    5. Set appropriate ‘ fbmem =‘ option in kernel bootup command line to reserve enough memory for framebuffer . For example, if we use 1280x800 LVDS panel        for fb0 and fb0 is in RGB32 pixel format, then ‘ fbmem =12M’ should be used, since the formula is:        fbmem = width*height*3(triple buf )* Bytes_per_pixel = 1280*800*3*4B=12MB An Example to Set struct fb_videomode :    Let’s take a look at the timing description quoted from a real 1280x800@60 24bit LVDS panel spec: And, standard linux struct fb_videomode definition in include/ linux / fb.h : struct fb_videomode {         const char *name;       /* optional */         u32 refresh;            /* optional */         u32 xres;         u32 yres;         u32 pixclock;         u32 left_margin;         u32 right_margin;         u32 upper_margin;         u32 lower_margin;         u32 hsync_len;         u32 vsync_len;         u32 sync;         u32 vmode;                 u32 flag; };    What we need to do is to set every field of struct fb_videomode correctly according to the timing description of LVDS display panel’s spec:     1. name: we can set it to ‘LDB-WXGA’.    2. refresh: though it’s optional, we can set it to typical value, that is, 60(60Hz refresh rate).    3. xres : the active width, that is, 1280.    4. yres : the active height, that is, 800.    5. pixclock : calculate with this formula – pixclock =(10^12)/ clk_freq . Here, typically, for this example, pixclock =(10^12)/71100000=14065.    6. left_margin / right_margin / hsync_len :        They are the same to HS Back Porch(HBP)/HS Front Porch(HFP)/HS Width(HW) in the spec. Since the spec only tells us that typically        HBP+HFP+HW=160. We may set left_margin =40, right_margin =40, hsync_len =80 .    7. upper_margin / lower_margin / vsync_len :        Similar to horizontal timing, the vertical ones can be set to upper_margin =10 , lower_margin =3, vsync_len =10 .    8. sync: Since the timing chart tells us that hsync / vsync are active low, so we don’t need to set FB_SYNC_HOR_HIGH_ACT or        FB_SYNC_VERT_HIGH_ACT. Moreover, clock polarity and data polarity are invalid, so we set sync to be zero here .    9. vmode : this is a progressive video mode, so set vmode t o FB_VMODE_NONINTERLACED .    10. flag: the video mode is provided by driver, so set flag to FB_MODE_IS_DETAILED .
View full article
Android Power Debug and Optimization Introduction Android Power Management on i.MX Overview How to do power optimization for Android on i.MX How to check high power consumption on i.MX How to debug suspend/resume problems on i.MX Introduction This document describes i.MX Android power issues debug and power consumption optimization. Android Power Management on i.MX Overview What Power Manager introduced by Android • Early Suspend    It is allow drivers like LCD, keypad backlight, touch-screen, gsensor , to be notified when user-space writes to /sys/power/ request_state to indicate that the user visible sleep state should change. These drivers will act as like Linux stand suspend() to let these devices entry in suspend for better battery life. • Late Resume    Late resume is matching with early suspend. It will resume the devices suspended during early suspend after the Stand Linux resume finished • Wake Locks     Wake locks are used by applications, services, kernel drivers to request CPU resources. A locked wakelock , depending on its type, prevents the system from entering suspend or other low-power states. It as a core member in android power management architecture from framework to kernel What introduced by i.MX to enhance the power framework BusFreq Support High bus, Low power audio bus and Low bus totally 3 system bus working points. Switching between these 3 bus mode according clock flags automatically. DDR running frequency will change according bus mode changing (highest 528/400MHz and lowest at 24MHz for MX6DQ/DL). CPUFreq The CPU frequency scaling device driver allows the clock speed of the CPUs to be changed on the fly. Once the CPU frequency is changed, the GP voltage will be changed to the voltage value. Enhance the default interactive governor for better performance on SDHC/GPU etc. System Power Profile Service and App (just for MX6DQ/DL) Support 3 profiles currently: Normal mode, Power Saving Mode and Performance Mode to get much better balance between performance and power consumption. Profiles can be customized according customers’ HW /MD design, including: CPU running max freq, trigger temperature, CPU running minimal freq, running cpu LDO bypass mode           i.MX6X has built-in LDO module, but also allows you to use external LDO suppliers. SW will provide the configuration using external LDO or internal LDO. How to do power optimization for Android on i.MX Suspend Mode All devices enter in suspend or low power Config GPIO PADs as High Z or input mode (depending on HW design,FSL provide Ref code) Cut off LDOs which no modules need (depending on HW design, FSL provide Ref code) DDR enter in self-refresh mode (FSL done) Config DDR IO Float pin to reduce the DDR IO consumption (FSL done) ARM core entry stop mode (WFI) (FSL done) All PLLs will cut off, just 32KHZ sleep clock living (FSL done) Notify the PMIC entry in standby to save some power (FSL done) User Idle Mode Optimization on device driver for WiFi, 3G, BT, screen brightness modules, etc., to save some power Let some device/GPIOs entry in suspend mode/low power mode Active power saving profile to reduce some system power loading. GPU 2D/3D auto entry in Stop/Standby mode if no activity needs update. (FSL done) Enable CPUFreq reduce ARM CORE power consumption (FSL done) Busfreq scanning to let system work at lower Freq to save power (FSL done) Audio/Video Playback Mode Optimization on device driver for WiFi, 3G, BT, screen brightness modules, etc., to save some power Let some device/GPIOs entry in suspend mode/low power mode Disable HW 3D acceleration for some Apps such as System UI, Music Player, etc., to save some power when System in IDLE or music playing mode. Enable CPUFreq and SOC WAIT mode, decrease CPU Freq/Voltage to save power for ARM CORE when no there is no task need cpu to handle(FSL done) Busfreq scanning will set bus work at low power audio bus mode to save some power (FSL done for audio case) DDR enter in self-refresh mode (FSL done for audio case) Reduce the screen brightness will save some power (for video case) VPU clock auto-gating to save power on SOC domain (for video case, FSL done) GPU 2D/3D auto-gating to save some power on SOC domain (FSL done) Try VDOA+IPU to bypass GPU in video playback(not comment for Android platform, pure Linux environment using this method, for it has some limitation such as the input/output size limit), this can save some power on DDR domain. How to check high power consumption on i.MX Idle Audio/Video Playback high power consumption Check the CPUFreq and  Bus_freq is enabled           cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor           cat /sys/devices/platform/imx_busfreq.0/enable Check whether the system bus working poing   For MX6Q:           cat /sys/kernel/debug/clock/osc_clk/pll2_528_bus_main_clk/periph_clk/mmdc_ch0_axi_clk/rate   For MX6DL/SL:           cat /sys/kernel/debug/clock/osc_clk/pll2_528_bus_main_clk/pll2_pfd_400M/periph_clk/mmdc_ch0_axi_clk/rate Check CPU Loading and Interrupt(cat /proc/interrupts) Check clock tree carefully to see which clocks arenot gated off  but no any modules need them.            powerdebug –d  -c SUSPEND MODE high power consumption Make sure all device entries are in suspend mode Make sure the system entry in DSM(measure the voltage &current of VDDARM_CAP, VDDSOC_CAP,DDR_1V5, VDD_HIGH…)      Some tips help to locate the problems Add debug message in device drivers which may lead high power consumption Enable PM debug in kernel Catch the waveform from these modules which may impact the high power consumption Remove devices from the board or do H/W rework to exclude some H/W problems How to debug suspend/resume problems on i.MX System could not entry in suspend mode Check below settings has been disabled: GPS has been disabled Don't connect USB cable to the board (adb will hold a wake lock) RIL will hold a wake lock if RIL failed to initialize (logcat -b radio) Setting->Application->Developer options->stay awake (stay awake not set) Check all wake locks which holed by kernel have been released          echo 15 > /sys/module/wakelock/parameters/debug_mask Check all user wake locks have been releaed          echo 15 > /sys/module/userwakelock/parameters/debug_mask System hang when resume or suspend Enable PM debug system to get more info about PM in kernel     make menuconfig  enable the PM debug sys [*] Power Management support                                                           [*]   Power Management Debug Support                                                           [*]     Verbose Power Management debugging Add no_console_suspend to the boot option for kernel         This makes the system print more useful info before entry in suspend Check the PMIC_STBY_REQ signal. Measure the VDDARM_IN Using Trace32 or ICE to locate the problem. Using RAMCONSOLE to dump the kernel log after reboot. Kernel resume back from suspend  but Android not    This is usually because of the wrong key layout file Use tool to get power key scan code        getevent  Correct the Keylayout         system/usr/keylayout/****.kl Correct the scandcode with your power key report value to Match the POWE key
View full article
Description about VPU & IPU usage in Android R13.4 GA release for i.MX6DQ
View full article
In this article, some experiments are done to verify the capability of i.MX6DQ on video playback under different VPU clocks. 1. Preparation Board: i.MX6DQ SD Bitstream: 1080p sunflower with 40Mbps, it is considered as the toughest H264 clip. The original clip is copied 20 times to generate a new raw video (repeat 20 times of sun-flower clip) and then encapsulate into a mp4 container. This is to remove and minimize the influence of startup workload of gstreamer compared to vpu unit test. Kernels: Generate different kernel with different VPU clock setting: 270MHz, 298MHz, 329MHz, 352MHz, 382MHz. test setting: 1080p content decoding and display with 1080p device. (no resize) 2. Test command for VPU unit test and Gstreamer The tiled format video playback is faster than NV12 format, so in below experiment, we choose tiled format during video playback. Unit test command: (we set the frame rate -a 70, higher than 1080p 60fps HDMI refresh rate)     /unit_tests/mxc_vpu_test.out -D "-i /media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.264 -f 2 -y 1 -a 70" Gstreamer command: (free run to get the highest playback speed)     gst-launch filesrc location=/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.mp4 typefind=true ! aiurdemux ! vpudec framedrop=false ! queue max-size-buffers=3 ! mfw_v4lsink sync=false 3. Video playback framerate measurement During test, we enter command "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" to make sure the CPU always work at highest frequency, so that it can respond to any interrupt quickly. For each testing point with different VPU clock, we do 5 rounds of tests. The max and min values are removed, and the remaining 3 data are averaged to get the final playback framerate. #1 #2 #3 #4 #5 Min Max Avg Dec Playback Dec Playback Dec Playback Dec Playback Dec Playback Playback Playback Playback 270M unit test 57.8 57.3 57.81 57.04 57.78 57.3 57.87 56.15 57.91 55.4 55.4 57.3 56.83 GST 53.76 54.163 54.136 54.273 53.659 53.659 54.273 54.01967 298M unit test 60.97 58.37 60.98 58.55 60.97 57.8 60.94 58.07 60.98 58.65 57.8 58.65 58.33 GST 56.755 49.144 53.271 56.159 56.665 49.144 56.755 55.365 329M unit test 63.8 59.52 63.92 52.63 63.8 58.1 63.82 58.26 63.78 59.34 52.63 59.52 58.56667 GST 57.815 55.857 56.862 58.637 56.703 55.857 58.637 57.12667 352M unit test 65.79 59.63 65.78 59.68 65.78 59.65 66.16 49.21 65.93 57.67 49.21 59.68 58.98333 GST 58.668 59.103 56.419 58.08 58.312 56.419 59.103 58.35333 382M unit test 64.34 56.58 67.8 58.73 67.75 59.68 67.81 59.36 67.77 59.76 56.58 59.76 59.25667 GST 59.753 58.893 58.972 58.273 59.238 58.273 59.753 59.03433 Note: Dec column means the vpu decoding fps, while Playback column means overall playback fps. Some explanation: Why does the Gstreamer performance data still improve while unit test is more flat? On Gstreamer, there is a vpu wrapper which is used to make the vpu api more intuitive to be called. So at first, the overall GST playback performance is constrained by vpu (vpu dec 57.8 fps). And finally, as vpu decoding performance goes to higher than 60fps when vpu clock increases, the constraint becomes the display refresh rate 60fps. The video display overhead of Gstreamer is only about 1 fps, similar to unit test. Based on the test result, we can see that for 352MHz, the overall 1080p video playback on 1080p display can reach ~60fps. Or if time sharing by two pipelines with two displays, we can do 2 x 1080p @ 30fps video playback. However, this experiment is valid for 1080p video playback on 1080p display. If for interlaced clip and display with size not same as 1080p, the overall playback performance is limited by some postprocessing like de-interlacing and resize.
View full article