i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
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
$ git log --pretty=oneline --abbrev-commit 6f0c058 Linux 3.7-rc2 198190a Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 aeed41a arm64: fix alignment padding in assembly code 31fd84b use clamp_t in UNAME26 fix 8c1bee6 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 45bff41 perf python: Properly link with libtraceevent
View full article
Below is one implementation of i.MX as a USB Playback/Capture device on one OTG port. Design Block Diagram: Driver user space interface: As file /dev/gadget/g_audio file system : gadgetaudiofs_type usage: mount -t gadgetaudiofs path /dev/gadget /* if /dev/gadget is not exist, create it manually */ r/w interface open read write close ssize_t read(int fd, void *buf, size_t count); Notice: Attempts to read up to count bytes from file descriptor fd into the buffer starting at buf. On success, the number of bytes read is returned. This call may be blocked if device can't give enough data. Only if usb out pipe be broken(host stop audio player), return value is still positive and less than count. Error: Count must align with PCM audio frame size. If not -EFAULT as errorno. Notes: Audio frame size = audio sample size x audio channels. ssize_t write(int fd, void *buf, size_t count); Notice: Writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. On success, the number of bytes written is returned. This call will never be blocked, even if the internal ring buffer dose not have enough space to write. A successful return from write() that return value equal to count does not make any guarantee that data all have been put to internal ring buffer. For example, if ring buffer is empty and has 1K bytes space, while write count is 3K bytes, only the last 1K bytes will be put to the ring buffer! Key attribute for g_audio driver USB out pipe parameter: Sample width hard code to 16bits. static int out_sample_rate = 48000; static int out_channel = 2; #define OUT_EP_ALIGN (2 * out_channel) // 2 mean 2 bytes, sample width 16bits OUT_EP_ALIGN mean “read ring buffer” write/read align, if read/write length not align this value, throw out error. Read mean user space read system call, write mean driver internal copy req->buf to “read ring buffer”. #define OUT_EP_MAX_PACKET_SIZE (192) // out pipe max packet size, it based on out_sample_rate and out_channel. 192 = (48KHZ / 1000) * out_channel * sample_width(as bytes) 192 = (48000 / 1000 ) * 2 * 2; Hear 1000 based on: as_out_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int out_req_count = 256; /* out pipe queue count, this value dose not introduce extra audio latency ! */ #define AUDIO_READ_RINGBUF_LEN (23 * OUT_EP_MAX_PACKET_SIZE) /* 4416 bytes, max valid 23 * 192, about 23 ms at 48KHZ, this value determine out pipe max audio latency */ If “read ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } USB in pipe parameter: Sample width hard code to 16bits. static int in_sample_rate = 8000; static int in_channel = 2; #define IN_EP_ALIGN (2 * in_channel) // 2 mean 2 bytes, sample width 16bits IN_EP_ALIGN mean “write ring buffer” write/read align, if read/write length not align this value, throw out error. Write mean user space write system call, read mean driver internal copy “write ring buffer” to req->buf. #define IN_EP_MAX_PACKET_SIZE (32) // in pipe max packet size, it based on in_sample_rate and in_channel. 32 = (8KHZ / 1000) * in_channel * sample_width(as bytes) 32 = (8000 / 1000 ) * 2 * 2; Hear 1000 based on: as_in_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int in_req_count = 32; /* in pipe queue count, this value dose introduce extra audio latency ! Latency = 32ms */ #define AUDIO_WRITE_RINGBUF_LEN (32 * OUT_EP_MAX_PACKET_SIZE) /* 1024 bytes, max valid 32 * 32, about 32 ms at 8KHZ, this value and in_req_count determine in pipe max audio latency 32 + 32 = 64 ms*/ If “write ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } Test Environment. Ubuntu 10.0.4 LTS Kernel 3.0.0-15 64bit. Ubuntu 10.0.4 LTS Kernel 2.6.32-42 64bit. Test application. Test user space application based on http://www.rosoo.net/a/201107/14725.html I will attach modified code. Test procedure. /* I.MX28 EVK board audio ADC default input is MIC, so, set it to LINE IN */ amixer sset 'ADC Mux' 'LINE_IN'  /* insmod g_audio driver and create directory for gadgetaudiofs */ modprobe g_audio && mkdir /dev/gadget /* mount gadgetaudiofs */ mount -t gadgetaudiofs path /dev/gadget /* start read g_audio device application.   It read PCM data from g_audio_device and put it to alsa playback device.   It read from g_audio_device per read system call per period_size (300 bytes).   See alsa PCM playback configuration   stream : PLAYBACK access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 48000   exact rate : 48000 (48000/1)   msbits : 16   buffer_size : 1200 (frames) (buffer time is 1200 / 48000 = 25ms)   period_size : 300 (frames)   period_time : 6250 (ns) */ ./lplay /dev/gadget/g_audio /* start write g_audio device application. It read PCM data from alsa capture device and put it to g_audio_device. It write to g_audio_device per write system call per period_size (50 bytes). See alsa PCM capture configuration   stream : CAPTURE   access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 8000   exact rate : 8000 (8000/1)   msbits : 16   buffer_size : 200 (frames) (buffer time is 200 / 8000 = 25ms)   period_size : 50 (frames)   period_time : 6250 (ns) */ ./lrecord /dev/gadget/g_audio The two processes CPU utilization on I.MX28 EVK board is about 5~15%, if you change per g_audio_device read/write system call size more larger, the more smaller CPU utilization you will get, but at the same time the more audio latency you will get. Per read/write system call size should has relation will “read/write ring buffer” size in g_audio driver. For example, if per write system call size is larger than “write ring buffer” size, then every write system call will discard some part of write buffer data. During 15 hours lplay and lrecord long test, driver and application both use default configuration as upper description, summarily 271 times driver internal buffer full appear. In another test, driver keep default configuration, new test set microphone ALSA capture buffer to 250ms, ALSA capture read as unblock mode, other configuration as lrecord application, block read USB gadget device 200 x 192 bytes (waiting 200ms), then unblock read whole ALSA capture buffer, found about every 1.5s, ALSA buffer will less then 16bytes (4 sample) compare to 200 x 32 bytes. Clock Sync issue of echo cancellation based on this implementation: Note: USB clock domain different with play back and microphone, some buffer will be discard by USB audio driver. See this diagram: 1: Echo cancellation application will try best to read “USB Output Buffer”, so no buffer will be discarded from output. ( Application input and output based on the same clock). 2: “Host playback buffer” maybe overrun because:   A: Playback source unstable and host playback buffer not enough larger.   B: Clock(playback) quick than Clock(USB). 3: Echo cancellation application will try best to read “ALSA Buffer”, so no buffer will be discarded from “ALSA buffer”. (Application discard some samples of “ALSA Buffer”) 3: Echo cancellation application handle “USB Output Buffer” and “ALSA Buffer” based on “USB Output Buffer” that same time mean based on Clock(USB). We assume Echo cancellation application will insert or discard some samples of “ALSA Buffer” based on “USB Output Buffer”. 4: Echo cancellation application will send processed buffer to USB audio driver based on Clock(USB), so no buffer will be discard from “USB Input Buffer”. If Echo cancellation application said “ I don't have the ability to insert or discard some samples of “ALSA Buffer”, we need adjust the Clock(MIC) based the internal buffer level of Echo cancellation application. But I think the “internal buffer level” will be influenced by difference of the clocks, the buffer input and output task runtime loading, so it may not be reality to implement this, need do more test on this! Add USB get output/input buffer length interface Add USB SAIF(only for i.mx 28) set clock interface For i.MX28 SAIF clock based on 480MHz. The fraction divider is 16bit, that mean the mini step is 0x 0.0001. 0x 0.0001 * 480MHz = 7324.21875Hz. If master clock as 512x frame rate, the mini step of frame rate is 14.3Hz USB get output/input buffer length interface: IOCTL CMD: #define USBAUDIO_BUFFER_STATUS_GET \ _IOR('g', 200, struct usbaudio_buffer_status) structure: struct usbaudio_buffer_status{   /* all as bytes */   __u32 playbackBufferTotalLen;   __u32 playbackBufferCurrentLen;   __u32 microphoneBufferTotalLen;   __u32 microphoneBufferCurrentLen; }; usage: struct usbaudio_buffer_status bufferStatus; ioctl(fd, USBAUDIO_BUFFER_STATUS_GET, &bufferStatus); USB SAIF(only for i.mx 28) set clock interface. IOCTL CMD: #define USBAUDIO_SAIF_CLOCK_CONTROL \ _IOWR('g', 201, struct usbaudio_saif_clock_control) structure: struct usbaudio_saif_clock_control{   /* all as HZ -1 as invalid */   __u32 saifCurrentClock; /* read */   __u32 saifNextClock; /* write */ }; usage: struct usbaudio_saif_clock_control saifClkCtl; saifClkCtl.saifNextClock = -1; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); saifClkCtl.saifNextClock = saifClkCtl.saifCurrentClock + step; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); Compile sample: /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/include/ -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/Kernel/linux-2.6.35.3/include -L /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/lib/ lrecord.c -o lrecord -lasound
View full article
To use Android GDB for native code, take mediaserver as an example. Setup on board. adb push prebuilt/android-arm/gdbserver/gdbserver system/bin/ adb shell ps adb shell /system/bin/gdbserver :5039 --attach <PID> & Setup on host. source build/env.sh adb forward tcp:5039 tcp:5039 gdbclient mediaserver b createPlayer c
View full article
Procrank can be used to check if a process has memory leakage. Procrank will list four types of memory usage. For details refer to: http://elinux.org/Android_Memory_Usage Vss = virtual set size Rss = resident set size Pss = proportional set size Uss = unique set size Uss can be used to check if a process has memory leakage. If the Uss increases when some operations start and stop, this means there could be memory leakage. Procrank can get from: <myandroid>/out/target/product/<product_name>/system/xbin/procrank and also needs to push to the library you target: <myandroid>/out/target/product/< product_name >/system/lib/libpagemap.so
View full article
Introduction EMV stands for Europay, MasterCard and VISA, and is a global standard for inter-operation of integrated circuit cards (ICC) and ICC reader terminals (like point of sale (POS) terminals, automated teller machines (ATMs)) for authenticating credit and debit payment cards transactions. Any IC card reader must be certified to be EMV compliant. The EMV standard defines the interaction at the physical, electrical, data and application levels between the IC cards and IC card terminal. For the contact smartcards it is based on standard ISO/IEC 7816. Some of the i.MX embeds a Subscriber Identification Module (SIM) which was designed to facilitate the communication to a mobile phone SIM card. It could be used to communicate indirectly with a banking smartcard due to the listed limitations in regards to the EMV requirements. Electrical Limitations The POS terminal must support 1.8V, 3.3V, and 5V smartcards. Depending on the i.MX, 1.8V or 3.3V could be supported but not both, and 5V is definitely out of the range of the I/O supplies. => a level adapter component is required between the i.MX and the smartcard. Protocol Limitations The communication between the IC card and the reader is asynchronous (almost a UART), but based on a common clock for synchronous operation. The ISO7816 standard defines the following: 1 ETU = F / D * 1 / f ETU is Elementary Time Unit, which is somehow the nominal time to transmit a bit (0 or 1). F or Fi is the clock rate conversion integer. D or Di is the baud rate adjustment integer. f is the frequency of the communication clock used between the controller and the smartcard. Below is a partial list of what the controller must support to pass the EMV certification, and the known limitations of the SIM controller: - baud rate at x1 (Fi/Di=372/1) => default speed for all smart cards =>  supported. - baud rate at x2 (Fi/Di=372/2 = 186/1) => a higher speed for some smart cards => not supported. - baud rate at x4 (Fi/Di=372/4 93/1) => a higher speed for some smart cards => not supported. - message length of 12ETU => specified for T=0 type smart card => supported. - error of -0.2ETU on message length of 12ETU => 11.8ETU smart card => not supported. - message length of 11ETU => specified for T=1 type smart card => supported. - error of -0.2ETU on message length of 11ETU => 10.8ETU smart card => not supported. Conclusion For these reasons, the i.MX SIM controller does not allow to pass the EMV certification without the usage of an external controller that must care of all these missing features. The SIM can still be used to communicate with that external controller such Atmel AT83C26, NXP TDA8023, Terridian, or On Semi. Freescale does not have driver neither reference design to support that configuration. This company has the expertise to work with EMV certification for the i.MX258 + a companion smartcard controller: http://www.alcineo.com
View full article
Even though the Advanced Tool Kit is not a supported tool anymore, it can be used to provision the code and blow fuses of an i.MX device during manufacturing. This is true when the secure boot has been enabled, which means that the code downloaded by the ATK to the target must be signed, as it will be authenticated prior to its execution. Once in secure mode, the Serial Download boot mode (SDP) can only access a restricted range of addresses, which is documented in the DCD section of the reference manual. An attempt to write outside this allowed area will result in an error, and will make the ROM restart the SDP by considering this as an attack. To automatically detect the mode (engineering or secure/production) of the chip, the ATK writes data to a memory location, and by retrieving the response it knows the configuration. The response can be one of two values: 0x56787856 means that the chip is in engineering mode. 0x12343412 means that the chip is in production/secure mode. It should be known that there is a bug that prevents a secure chip from being handled correctly. For instance, to perform the automatic detection mentioned above, the tool writes to 0xFFFF_FFFF for the i.MX25 or even i.MX35. This address is invalid by being outside the allowed address range, so the ROM code aborts the current session, and restarts a new one. The attached DLL library fixes this issue by writing to an appropriate area like the free iRAM space. This will allow use of the ATK for a chip whose secure boot is enabled.
View full article
What is HTML5 Video? HTML5 video is an element for the purpose of playing videos or movies in HTML5 specification. HTML5 video is intended by its creators to become the new standard way to show video on the web without plugins. Video will be shown inside the web page, like flash. HTML5 Video Web Page <video> element example <video src="movie.mp4" poster="movie.jpg" controls> </video> HTML5 video page source example <html>           <head>           </head>            <body>                      <video src="http://10.192.225.226/movie.mp4" width="640" height="480"  controls="true">                      </video>            </body> </html> HTML5 Video Rendering Path Performance Data in i.MX6Q with Android ICS With LVDS display, H264@1080p@20Mbps Can reach 30 fps With HDMI 1080p display, H264@1080p@10Mbps Can reach 25 fps HTML5 Video Website Some HTML5 Video website when accessing with android platform www.youtube.com www.iqiyi.com HTML5 reference document SPEC         http://dev.w3.org/html5/spec/single-page.html?utm_source=dlvr.it&utm_medium=feed Wikipedia page        http://en.wikipedia.org/wiki/HTML5
View full article
The i.MX27 multimedia applications processors balance high performance with low power consumption through an intelligent combination of dedicated hardware video accelerators and a fast ARM926EJ-S™ core. Both the i.MX27 and the i.MX27L processors provide an array of connectivity options and robust security. The rich feature set of the i.MX 27 processors make them an excellent choice for video- and voiceover- IP (V2IP) cordless and mobile phones, intelligent remote controls, point-of-sale terminals, control devices, low to mid end PNDs and many other wireless applications. i.MX Family Comparison Product Information on Freescale.com i.MX27 Multimedia Applications Processor i.MX27L Multimedia Applications Processor Evaluation/Development Boards and Systems IMX27PDK:  i.MX27 Development Kit Bootloader Compiling U-Boot for iMX27ADS Installing U-Boot on iMX27ADS Embedded Software and Tools Android OS for i.MX Applications Processors Partners / 3rd-Party Development Tools STK5:  Starter-Kit V for TX Modules with Freescale i.MX Processors (Karo Electronics) Additional Resources i.MX27 ADS Adding USB Host2 i.MX27 D1 Capture Kernel 2.6.22 Compiling U-Boot for i.MX27ADS IMX27-ADS i.MX27 ADS Board Flashing I.MX27 ADS Board Video i.MX27 ADS Board TV Out i.MX 27 ADS Adding USB Host2 i.MX 27 ADS Board Video GST Encode i.MX 27 ADS Board Video GST Play i.MX 27 ADS Compiling Linux Kernel Mainline i.MX 27 mDDR Issue i.MX 27 PDK I.MX27 PDK Board Flashing IMX27-Lite-Kit i.MX 27 Video GST Caps Installing U-Boot on i.MX27ADS
View full article
If you want to use a USB camera (these types of cameras are also called 'Web Cameras') with GStreamer on i.MX6 devices (Linux Kernel version >= 3.035), you need to either load the module dynamically or compile and link statically selecting (Y) the following config on the Kernel configuration      Device Drivers -> Multimedia support -> Video capture adapters -> V4L USB devices -> <*> USB Video Class (UVC) After the Kernel image has been built, flash it into the target, plug the web cam, then on a (target) terminal run      gst-launch v4l2src ! mfw_v4lsink You should see what the camera is capturing on the display. In case you need to encode the camera src data, you need to place the encoder into the pipeline      gst-launch v4l2src num-buffers=100  ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false We are using a certain codec (codec=0 means mpeg4), check options using 'gst-inspect vpuenc'.
View full article
The i.MX28 family of multimedia applications processors is the latest extension of Freescale's ARM9 product portfolio. The i.MX28 family integrates display, power management, and connectivity features unmatched in ARM9-based devices, reducing system cost and complexity for cost sensitive applications. It also integrates CAN, USB and Ethernet connectivity with full AEC-Q100 automotive qualification for automotive applications. i.MX Family Comparison Product Information on Freescale.com i.MX280 i.MX280 Multimedia Applications Processor i.MX281 i.MX281 Multimedia Applications Processor i.MX283 i.MX283 Multimedia Applications Processor i.MX285 i.MX285 Multimedia Applications Processor i.MX286 i.MX286 Multimedia Applications Processor i.MX287 i.MX287 Multimedia Applications Processor Evaluation/Development Boards and Systems MCIMX28EVKJ: i.MX28 Evaluation Kit How to add support for a new NAND How to add a New on imx28 with Win CE Running a mainline kernel on a MX28EVK board How to enable SPI NOR boot for iMX28 (Spansion s25fl256s) Embedded Software and Tools Android OS for i.MX Applications Processors i.MX28 Software and Development Tool Resources Additional Resources Adding Support For a New NAND with i.MX28–NAND Analysis Adding Support For a New NAND with i.MX28 on Win CE Board bring-up and DDR initialization tools i.MX as a USB Playback/Capture Device on One OTG Port i.MX28: GPIO interrupt on both rising and falling edges How to enable SPI NOR boot for iMX28 (Spansion s25fl256s) Running a Mainline Kernel on an i.MX28 EVK Board Running mk_mx28_sd on Ubuntu 12.04 Ubuntu 12.04 64-bit Precise Pangolin Host Setup for Building i.MX28 L2.6.35_MX28_SDK_10.12_SOURCE Use LCD_D11 pin for enet reset in iMX28
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
i.MX6X Core Board HW User Guide.pdf
View full article
The i.MX31 multimedia applications processors are designed for a broad range of industrial, consumer and automotive applications. Based on an ARM1136JF-S™ core, both the i.MX31 and the i.MX31L processors are engineered to deliver powerful performance while minimizing power consumption. The rich feature set of the i.MX31 processors make them an excellent choice for portable media players, portable navigation devices, medical/industrial monitoring systems, automotive infotainment systems and many general embedded applications. i.MX Family Comparison Product Information on Freescale.com i.MX31 Multimedia Applications Processor Evaluation/Development Boards and Systems IMX31PDK:  i.MX31 Product Development Kit Getting Started Getting Started with the i.MX31PDK Board Flashing i.MX31 PDK Board I.MX31 PDK Board using RedBoot Miscellaneous Tutorials Blinking iMX31PDK LEDs using U-Boot How to Test i.MX31 RNGA Hardware? How to Test i.MX31 TvOut on i.MX31PDK How to Use Clock Out on i.MX31 Issues when interfacing Micron's 78nm mDDRs IMX31ADS Getting Started Getting Started with the i.MX31ADS Board Flashing I.MX31 ADS Board Miscellaneous Tutorials Booting Linux from NAND Flash on the i.MX31ADS Compiling Linux kernel from mainline to i.MX31ADS Issues when interfacing Micron's 78nm mDDRs Embedded Software and Tools Android OS for i.MX Applications Processors Partners / 3rd-Party Development Tools Starterkit STKa31 (Technology in Quality) Additional Resources i.MX31 ADS i.MX31 PDK i.MX31 PDK Board Alpha Blending i.MX31 PDK Board DirectFB i.MX31 PDK Board V4L tests i.MX31 PDK Contents i.MX31 PDK Setting Buttons and Jumpers i.MX31 Lite Kit
View full article
Freescale's ARM11™-based i.MX 35 processor family provides the perfect balance of performance, power consumption, connectivity, and media capabilities necessary to drive today's multimedia applications. i.MX35 Family Comparison i.MX Family Comparison Product Information on Freescale.com i.MX351 Multimedia Applications Processor i.MX353 Multimedia Applications Processor i.MX355 Multimedia Applications Processor i.MX356 Multimedia Applications Processor i.MX357 Multimedia Applications Processor Evaluation/Development Boards and Systems IMX35PDK: i.MX35 Product Development Kit (PDK) Embedded Software and Tools Android OS for i.MX Applications Processors i.MX35 Current Software Updates and Releases Additional Resources Develop a Simple OpenVG Application Under Linux: Tutorial i.MX35 PDK i.MX35 PDK Linux Booting SD I.MX35 PDK Board Flashing SD Card i.MX35 PDK Board Flashing NAND i.MX35 PDK NAND Flashing Kernel and Root File System Using RedBoot i.MX35 PDK NAND Creating and Flashing UBIFS image
View full article
Freescale's consumer and industrial i.MX 51 applications processors balance the performance, power consumption, connectivity and multimedia capabilities necessary to drive today's latest and greatest products. Freescale's automotive i.MX 51 processors provide what is necessary to steer today's most advanced automotive systems. i.MX51 Family Comparison i.MX Family Comparison Product Information on Freescale.com i.MX512 Applications Processor i.MX513 Applications Processor i.MX514 Applications Processor i.MX515 Applications Processor i.MX516 Applications Processor Evaluation/Development Boards and Systems IMX51EVK Evaluation Kit Bootloader Installing U-Boot on i.MX51EVK Flashing i.MX51EVK Working with mainline U-Boot Add new iMX5x board on LTIB Compiling U-Boot (from Freescale BSP) using LTIB Changing environment variables storage on U-Boot Linux Flashing Linux application only with SD card Reader Multimedia Using USB Camera Installing OpenCV Library (Open Computer Vision - Image Processing) Android Android without RamDisk Installing TTS library manually Running ADB over USB (iMX51 and Ubuntu communication) Ubuntu Using an USB Touchscreen (Karmic) Using Touchscreen (Lucid) Embedded Software and Tools Android OS for i.MX Applications Processors i.MX51 Current Software Updates and Releases Partners / 3rd-Party Development Tools STK5:  Starter-Kit 5 (Karo Electronics) Additional Resources Board bring-up and DDR initialization tools Develop a Simple OpenVG Application Under Linux: Tutorial i.MX 51 Android ADB over USB IMX51EVK i.MX51 EVK Board USB Camera i.MX51 EVK Compiling U-boot i.MX 51 EVK U-boot i.MX51 EVK Board Video i.MX51 EVK Board OpenCV i.MX51 EVK Board Flashing i.MX51 Flashing Linux Application Only with SD Card Reader I.MX51EVK Install U-Boot i.MX51 EVK Compiling U-boot i.MX51 EVK U-boot i.MX51 EVK Changing Env IMX51 Ubuntu USB TS i.MX 51 Ubuntu TS Lucid
View full article
Use the EPDC Unit Test to exercise your EPD panel 1.  Introduction The i.MX 6Solo/6DualLite and i.MX 6SoloLite processors contain an Electrophoretic Display Controller (EPDC) designed to drive E-INK(TM) EPD panels supporting a wide variety of TFT backplanes. Detailed information about the EPDC is available in the i.MX 6Solo/6DualLite and i.MX 6SoloLite Reference Manuals. Information about programming the EPDC and integrating support for a particular panel into the Linux BSP is provided in the Linux BSP Reference Manual. Now that you have your panel hardware and software integrated, how can you tell if it is all working? Or perhaps you're using a standard panel that doesn't seem to be working - how can you test it at the lowest level? The answer is the EDPC Unit Test. 2. Running the EPDC Unit Test Most i.MX processor hardware modules have an associated unit test in the unit_tests directory of the root file system image. The basics of running the EPDC unit test are simple. After logging in as root on the debug console, change to the unit tests directory and execute the test as follows: $ cd /unit_tests $ ./mxc_epdc_fb_test.out Without any arguments, the unit test runs thirteen individual tests and takes about 8 minutes to complete. You will get a lot of output on the panel and it may not be obvious that the images are displaying correctly. Running the unit test with no arguments is a nice automated way to make sure your panel is at least displaying something, and is not causing a crash or hang. But to really verify correctness each test should be run individually and the output carefully reviewed. This can be accomplished by passing a test number option as follows: $ ./mxc_epdc_fb_test.out -n 1 To show a list of all the available options, as well as a list of the individual test numbers, use the "-h" argument. The helpful output is shown below. $ ./mxc_epdc_fb_test.out -h EPDC framebuffer driver test program. Usage: mxc_epdc_fb_test [-h] [-a] [-p delay] [-u s/q/m] [-n ]         -h        Print this message         -a        Enabled animation waveforms for fast updates (tests 8-9)         -p        Provide a power down delay (in ms) for the EPDC driver                   0 - Immediate (default)                   -1 - Never                    ms - After ms milliseconds         -u        Select an update scheme                   s - Snapshot update scheme                   q - Queue update scheme                   m - Queue and merge update scheme (default)         -n        Execute the tests specified in expression                   Expression is a set of comma-separated numeric ranges                   If not specified, tests 1-13 are run Example: ./mxc_epdc_fb_test.out -n 1-3,5,7 EPDC tests: 1 - Basic Updates 2 - Rotation Updates 3 - Grayscale Framebuffer Updates 4 - Auto-waveform Selection Updates 5 - Panning Updates 6 - Overlay Updates 7 - Auto-Updates 8 - Animation Mode Updates 9 - Fast Updates 10 - Partial to Full Update Transitions 11 - Test Pixel Shifting Effect 12 - Colormap Updates 13 - Collision Test Mode 14 - Stress Test In addition to "-n" to run individual tests, the "-a" and "-u" options are provided to set animation mode and waveform used, respectively. These options make sense only for some of the individual tests, as noted in the next section. The "-u s" (snapshot) mode purposely does not allow pending updates, so some of the tests will cause the driver to issue the following warning in snapshot mode: imx_epdc_fb: No free intermediate buffers available. The "-p" (power down delay) option allows you to specify how soon the device driver automatically powers down the controller after all pending updates have completed. The default is 0 (zero), meaning power down immediately. Use "-1" to disable power down (i.e. never power down). Sidebar: You can use another unit test, "dump-clocks.sh", to view the state of the EPDC clocks (i.e. the power state of the module). In the example below, a "1" in the third column indicates that the clock is running; a "0" indicates the clock is gated: $ ./dump-clocks.sh | grep epdc epdc_pix_clk             pll5_video_main_clk       1   26666667 epdc_axi_clk             pll2_pfd2_400M             1  198000000 3.  Individual Test Details Important! The notes below assume you are running the version of the unit test binary in the tar file attached to this How-to. Please extract the file mxc_epdc_fb_tests.out from the tar file into your rootfs unit_tests directory before running the test. Most tests begin with a screen blank operation (all white pixels). Each test works with all three update schemes (snapshot, queue, queue and merge) unless otherwise noted. 3.1 Test 1: Basic Updates Draws the following patterns: Crosshatch Squares Text Ginger image Colorbar 3.2 Test 2: Rotation Updates Draws text, squares, crosshatch, and square outlines in all rotation modes: No rotation Clockwise (90 degrees) Upside down (180 degrees) Counterclockwise (270 degrees) The square outlines are drawn first in RGB format and then in Y8 format. 3.3 Test 3: Grayscale Framebuffer Updates Draws a top half black screen and then a colorbar, rotated clockwise. First draws in normal Y8 format and then in inverted Y8 format. 3.4 Test 4: Auto-waveform Selection Updates Draws several small squares using auto-waveform selection. Note: unlike the i.MX508 EPDC driver, the i.MX 6 driver does not report the final waveform selection to user-level applications. This test also verifies that squares at non-8-bit aligned pixels can be drawn. 3.5 Test 5: Panning Updates Draws a colorbar to an off-screen region. Draws the Ginger image to the frame buffer. Sets the focus (pan) to the colorbar, then updates portions of the screen. You should see the colorbar poke through. Slowly pans from Ginger to the entire colorbar. Use pan to flip between black and white buttons. Flashes buttons using pixel inversion. Flashes buttons using panning. 3.6 Test 6: Overlay Updates Switches between the frame buffer (FB) and the alternate (overlay) frame buffer as follows: Draws Ginger to the FB. Draws the colorbar to the alternate frame buffer. Shows the FB (Ginger). Shows the alternate FB (colorbar). Shows FB again (Ginger). Shows half FB, half alternate FB. Shows cutout region of alternate FB. Shows cutout in upper corner. Shows black screen. Shows clockwise-rotated text overlay in center. 3.7 Test 7: Auto-Updates Important! The auto-update mechanism must be enabled in the kernel configuration for this test to work. Enable it using the LTIB Kernel configuration menu item "Device Drivers->Graphics support->E-Ink Auto-update Mode Support." Also, please check the Linux BSP Release Notes for any issues with this feature. 3.8 Test 8: Animation Mode Updates Shows how normal (gray level) and monochrome (black and white) updates compare in appearance and performance. Quickly flashes back and forth between black and white screens. Draws normal squares. Draws black and white squares. Draws Ginger in gray scale and monochrome. Draws colorbar in gray scale and monochrome. Draws normal Y8 colorbar and monochrome colorbar. Draws inverted normal Y8 colorbar and inverted monochrome colorbar. You can run this test in animation mode using the "-a" command line option. Animation mode only updates monochrome pixels, so you will notice a drawing speed improvement. Also, you will see the implementation of one of the "rules" of using this mode: The screen must be blanked (all white or all black) when switching in and out of animation mode. 3.9 Test 9: Fast Updates Animates a square across the screen and down one side. This test can also be run in animation mode using "-a". See the animation mode notes in the Test 8 description above. 3.10 Test 10: Partial to Full Update Transitions Draws small gray squares using separate updates in partial update mode (only pixels that change are updated). Then re-draws the entire screen in one update using full update mode. In full update mode, you will notice the entire screen transition from black to the final grey value. 3.11 Test 11: Test Pixel Shifting Effect Draws a short, two pixel line and then sends two updates one pixel apart in distance and 5 seconds apart in time. Nothing much to see here; just verifies that a one pixel update shift works. 3.12 Test 12: Colormap Updates Creates a colormap and uses it to draw full screen blanks and to draw a color bar. In this test, you should follow along with the text printed in the debug console and verify each state: Screen should be black. Screen should be white now. Screen should still be white. Should be inverted color bar (white to black, left to right). Colorbar again, with no CMAP (black to white, left to right). Posterized colorbar. In the above output, "CMAP" means colormap and "Posterized colorbar" is a colorbar drawn from only black and white components. 3.13 Test 13: Collision Test Mode Draws two overlapping rectangles. Tests for collision on the first rectangle, which should result in the message: Collision test result = 0 Then draws the same overlapping rectangles, this time testing for collision on the second rectangle. The result should be: Collision test result = 1 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 3.14 Test 14: Stress Test Draws thousands of random rectangles on the screen in different rotations. Runs for about 8 minutes. This test must be explicitly specified on the command line; it does not run by default. For example: $ ./mxc_epdc_fb_test.out -n 14 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 4. Customizing A great way to know what's really going on in each test is to look at the source code. You may want to customize the source as well - say to add a new test that exercises some cool feature of your panel. Fortunately, the source is included in the BSP distribution so you can extract, customize, and rebuild it as needed. The magic of LTIB is beyond the scope of this article, but here are some hints: # Extract the unit test source from the imx-test package: $ ./ltib -m prep -p imx-test # Source is now in rpm/BUILD/imx-test-12.08.00/test/mxc_fb_test/mxc_epdc_fb_test.c (your package version number my be different). # Build from source: $ ./ltib -m scbuild -p imx-test # Deploy all unit test binaries to ltib rootfs directory: $ ./ltib -m scdeploy -p imx-test # Alternatively you can copy just the epdc unit test binary as follows: $ sudo cp rpm/BUILD/imx-test-12.08.00/platform/IMX6S/mxc_epdc_fb_test.out rootfs/unit_tests/ As noted in the Individual Test Details section, you should replace the file mxc_epdc_fb_test.c referenced above with the one found in the tar file attached to this How-to. 5. Something is wrong! Of course there are many things that can go wrong that are beyond the scope of this article, but assuming your hardware is working and the panel options are correctly configured in the BSP (again, beyond our scope), here are some things to check: Is the kernel configured correctly for EPDC support? Check that the following item is enabled in the LTIB Kernel configuration menu: "Device Drivers->Graphics support->E-Ink Panel Framebuffer." Are the U-boot kernel command line arguments set correctly for EPDC? For example, "video=mxcepdcfb:E060SCM consoleblank=0". The "consoleblank=0" command is useful to prevent entering low power suspend mode while you are testing. Does the "Tux" image display correctly on your panel after system boot? If so, the EPDC driver was a least able to perform the initial framebuffer update to your panel. Note: for Tux to display at boot, you need to disable LCDIF support at "Device Drivers->Graphics support->Support MXC ELCDIF framebuffer." Are there any EPDC-related error messages in the kernel log after boot? You can check with "dmesg | grep epdc".
View full article
The i.MX53 family of processors represents Freescale's next generation of advanced multimedia and power-efficient implementation of the ARM Cortex™-A8 core with core processing speeds up to 1.2 GHz. It is optimized for both performance and power to meet the demands of high-end, advanced applications. Ideal for a broad range of applications in the consumer, automotive, medical and industrial markets, the i.MX53 includes an integrated display controller, full HD capability, enhanced graphics and connectivity features. i.MX Family Comparison Product Information on Freescale.com i.MX534 Multimedia Applications Processor i.MX535 Multimedia Applications Processor i.MX536 Multimedia Applications Processor i.MX537 Multimedia Applications Processor Evaluation/Development Boards and Systems i.MX53 Quick Start Board Android How to enable WIFI support for iMX53 QSB Android IMX53 QSB android recovery mode Linux I.MX53 QSB Board Get Started How to flash a 4GB SD Card with the image used in training Enabling Dual Display in UBUNTU with the iMX53 QSB @running_dual_display SABRE Platform for Tablets based on i.MX53 Linux i.MX53 ARD Dual LVDS Enabling Dual LVDS panels i.MX53 USB Eth NFS Using an USB/Eth adapter to boot NFS User Applications i.MX53 Qt LVDS display Touch on Qt with LVDS display Embedded Software and Tools Android OS for i.MX Applications Processors i.MX53 Current Software Updates and Releases Partners / 3rd-Party Development Tools Rainbow-G11D:  i.MX53 Development Kit (iWave Embedding Intelligence) STKa53:  Starterkit STKa53 (Technology in Quality) DS-5:  ARM Development Studio 5 (ARM) Additional Resources Board Bring-up and DDR Initialization Tools Building QT5 for i.MX53 Change AUDMUX src_port causes "imx_ssi_irq mxc_ssi SISR 8003a3 SIER 180100 fifo_errs=XXXX" ConnectCore® i.MX53 / Wi-i.MX53 by Digi International Develop a Simple OpenVG Application Under Linux: Tutorial Embedded i.MX5x Application Development Kit for Android -$199 HDMI Audio Setting How to Enable the souphttpsrc Plugin on i.MX53 i.MX53 ARD Dual LVDS Imx53-fastboot-example i.MX53 Memory Calibration Script (AN4466) i.MX53 QSB Android Recovery Mode I.MX53 QSB Board Get Started i.MX53 QSB Board Video IMX53 QSB enable WIFI android i.MX53 QSB Ubuntu Dual Display i.MX53 Quick Start Board IMX53 SABRE AI i.MX53 Start-R Lab Exercise - Prof. Massimo Violante Politecnico of Torino i.MX53 Start-R Lab Exercise - Developing a loadable kernel module to manage GPIOs in i.MX53QSB i.MX53 USB Eth NFS i.MX53 Qt LVDS Display NOVPEK i.MX53 by NovTech Running Dual Display on i.MX53QSB bin2txt.pyw (U-boot splash screen support)
View full article