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:
This document explains how to create a DS-5 project to compile and debug the SDK and OBDS for iMX6 and iMX28 respectively. Attached you can find the .ds file for the iMX28 needed to debug in DS-5.
View full article
This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130. It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0_130130 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/elftosb/elftosb.spec dist/lfs-5.1/lkc/lkc.spec dist/lfs-5.1/mux_server/mux_server.spec dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory: pkgs/elftosb-2.6.35.3-1385779630.patch pkgs/elftosb-2.6.35.3-1385779630.patch.md5 pkgs/lkc-1.4-lib.patch pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation elftosb compilation issue fixed by added -lm to LIBS in the elftosb-2.6.35.3-1.1.0/makefile.rules NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.
View full article
This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130.  It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_12.04_64bit_OS.patch a) The patch modifies the following files:    dist/lfs-5.1/base_libs/base_libs.spec    dist/lfs-5.1/lkc/lkc.spec    dist/lfs-5.1/mux_server/mux_server.spec    dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory:    pkgs/lkc-1.4-lib.patch    pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.
View full article
When boot from battery, then plug in 5V cable, the actual charging current can't reach the preset charging current. It is because the HEADROOM_ADJ is not correctly set. Please use attached mx28_chargingcurrent_limit_bootfrombattery.patch. Grace
View full article
Question: When working with v1.6.0.55 using the standard profile for i.MX35 the tool fails most of the time when transferring the target root file system, on v1.6.0.42 it works just fine. The tags on the internal git don’t clearly mention a tool version, but a BSP. Wwhat are the differences between v1.6.0.55 and v1.6.0.42? Or to which tag(or commit) they correspond on git? Answer: 1.6.042 commit by looking at "Apps/MfgTool.exe/docs/changelog.txt": 1ca2a16df736ac51979a67423fef6a09bed6b7e2 And 1.6.055: "06a4f9190e34297b7273fc4bb4a92737e5bc837f"
View full article
Question: How to enable HAB on the MX28, following the recommendations of AN4555 to get the "get_hab_status()" function working, but has run into an issue. Question #1 They believe they have all the HAB components worked out that are inputs to the efltosb tool as they are able to successfully run U-boot to the interactive prompt.  However, at the point where they:     - call the rvt_report_status() function, their board says "### ERROR ### Please RESET the board ###".      - call the rvt_entry(), their board prints some garbage characters on the screen and then hangs. This suggests that there is something wrong with the clock that in turn affects the baudrate on the serial console causing the above behavior. Question #2 Is there a concept of a "Bound Signature" in HABv4 as there is in HABv3? Any chance the addresses for the rvt_ calls are incorrect? Can you provide the u-boot source? Either Bound signature verification or UID is never mentioned in the HABv4 Application Note. So I suppose it is not supported. We have made assumptions about the RVT function pointer offsets.  The HAB 4 API does not explicitly say the offsets but uses a rvt_base::function_name notation.  We have assumed that function pointers are placed in order, at every word offset beyond the RVT header.  We have confirmed the RVT header exists at the latest address in the reference manual based on a memory dump but we cannot be certain the function offsets we have setup are correct. As far as source code, we modeled our changes for our mx28 board off of the hab.c and hab.h files available from the mainline u-boot for the mx6 architecture. This is basically the same code get_hab_status code that is written in the AN4555 document.  We did HAB API function pointer addresses to match the updated RVT base address and assumed offsets. Answer: Here are the first 3 instructions from report_status(), could your customer check the instructions from the address which they called is correct? <report_status>: :   b087b570        addlt   fp, r7, r0, ror r5 :   1c0e1c05        stcne   12, cr1, [lr], {5} :   22182433        andscs  r2, r8, #855638016      ; 0x33000000
View full article
In Chinese Twitter: Sino Weibo, one famous distributor mentioned “i.MX28 is the best choice in ARM9 core-based processor, no ‘one of’”. With high integration of analog module and digital module, i.MX28 is attracting more and more engineers in various applications. Despite its advantage, there are some mistakes one may commit or issues they may meet. The note records a number of issues/mistakes. Each case in the note comes from a real story. I hope the note will help you in your development work. And It is definitely welcomed for everyone to add your own content to the note.The more you share, the more you get.
View full article
Qt framework Qt is a cross-platform complete development framework with tools designed to streamline the creation of stunning native applications and amazing user interfaces for desktop, embedded and mobile platforms. Qt's cross-platform full framework and tools enables developers to target various desktop, embedded, mobile and real-time operating systems with one code base. Qt brings freedom to the developer saving development time, adding efficiency and ultimately shortening time to market. Building Qt Compile Qt for i.MX28 Building QT5 for i.MX53 Building QT for i.MX6 Qt on iMX6 Installing tools Installing and Configuring QT Creator (Ubuntu) Qt5 with Qt3D over Wayland rootfs Demos Qt5 Cinematic Experience Demo on i.MX6 Video - IMx 53 Qt5 qt3d demo Qt5 with Qt3D over Wayland rootfs Information Qt5 on i.MX6  DO's and DONT's Best Practices for QML
View full article
An i.MX50 customer encountered such kernel bug recently. Android UI has no response, because the suspend work queue is blocked:     suspend       pm_suspend         enter_state           suspend_prepare / suspend_finish             pm_prepare_console / pm_restore_console               vt_move_to_console                 vt_waitactive                   vt_event_wait                     wait_event_interruptible Confimed the same bug can also happen on imx6SL which is running linux 3.0.35. e.g. by echo standby/mem > /sys/power/state It takes over thousand suspend/resume cycles to reproduce the problem. The bug fix has been merged since linux 3.6: commit a7b12929be6cc55eab2dac3330fa9f5984e12dda
View full article
Tested on imx28 EVK Rev. D. When plug-in or plug-out cable on eth0 port, eth1 port (and vice versa) will also be reset and the communication will be interrupted. Reason: Both Ethernet PHYs on EVK board share the same GPIO as their reset pin, in software the function name is mx28evk_enet_gpio_init. So any call to pdata->init() in fec.c will reset both PHY at the same time. In order to avoid such problem, you have to use 2 individual GPIO for the PHY reset.
View full article
The new i.MX OTP Tools release is now available on http://www.freescale.com/, under this link. Change details: Fixes an issue with the rom-plugin device firmware that is used by BitBurner and otp_burner tools to program fuses. These tools are part of IMX_OTP_TOOLS package.    The plugin was failing to check the status whether the data packets have been received or not.    As such, at times before receiving data from host the firmware was processing the usb buffer    with previously sent or received data resulting in incorrect values being programmed. To fix    this issue we modified the firmware to make sure we receive the data before processing the usb buffer.                 Here is the sequence of usb transfers (protocol):                 1.            Cmd-phase: Host send cmd to write to otp register with cmd type, register index and number of registers to write                 2.            Data-phase: Host send data for values to write to otp register.                 3.            Status-phase: Device sends status to host                 4.            Cmd-phase: Host send cmd to read otp register to verify data written was correct                 5.            Data-phase: Device send data from otp registers                 6.            Status-phase: Device sends status to host   The problem was at #2 wherein device would process usb buffer before confirming whether data has received or not.
View full article
i.MX28 GPIO pins only support the following IRQ types: IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, IRQ_TYPE_LEVEL_HIGH and IRQ_TYPE_LEVEL_LOW. IRQ_TYPE_EDGE_BOTH is not supported. It application requires interrupt on both rising and falling edges, software can set the IRQ type to level trigger and set the polarity in reverse to the current GPIO input level. Below is the example. value = gpio_get_value(pdata->id_gpio) ? 1 : 0; if (value)     set_irq_type(gpio_to_irq(pdata->id_gpio), IRQ_TYPE_LEVEL_LOW); else     set_irq_type(gpio_to_irq(pdata->id_gpio), IRQ_TYPE_LEVEL_HIGH); ... When GPIO input value is low, set the IRQ type to IRQ_TYPE_LEVEL_HIGH. When the GPIO input value is high, set the IRQ type to IRQ_TYPE_LEVEL_LOW. Do the same checking in the GPIO IRQ handler. In this way, interrupts on both edges can be captured. This document was generated from the following discussion: i.MX28: GPIO interrupt on both rising and falling edges
View full article
i.MX25 for Industrial and General Embedded The i.MX25 family of multimedia applications processors extends the Freescale ARM9™ portfolio and makes the industrial and general embedded market a key focus of i.MX with the integration of many new features. Speed up to 400 MHz, low power consumption and multiple connectivity options support the growing needs of industrial and general embedded products, while allowing customers to reduce their overall system bill of materials cost. The i.MX258 processor provides additional security features making it the ideal solution for payment terminal (POS), or any other type of product needing secure system boot and tamper detection. i.MX25 for Automotive Today's drivers expect more connectivity in more places from more things—phones, media players and, increasingly, cars. Bluetooth™ connectivity is becoming the norm as more people keep their hands on the wheel instead of on the phone. Connectivity and compatibility with media players is becoming a requirement as consumers' media investment goes digital. The challenge: how can designers support high-end features such as connectivity and media playback without charging high-end prices? The i.MX25 family of processors offers integration that tailors itself to the connectivity requirements of today's automobile but eliminates expensive parts not needed for a cost-conscious infotainment system. The i.MX25 applications processor is a Freescale Energy-Efficient Solutions product. Product Information on Freescale.com i.MX257: Multimedia Applications Processor i.MX251: Multimedia Applications Processor i.MX253: Multimedia Applications Processor i.MX255: Multimedia Applications Processor i.MX258: Multimedia Applications Processor Additional Resources i.MX25 PDK Board I.MX25 PDK Board Get Started i.MX25 PDK Board Flashing NAND i.MX25 PDK Board Flashing SPI NOR i.MX25 PDK Board Flashing SD Card i.MX25 PDK Board Running Linux I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard I.MX25 PDK Using FEC i.MX25: When using 120MHz UPLL as clock source, GPT counter returns unexpected results Limitations of the i.MX SIM Controller to Pass the EMV Certification
View full article
Some i.MX25 customers reported an issue for the GPT timer, when using 120MHz (240MHz UPLL divided 2) clock source as the GPT per_clk, the timer will not be increased all the time in free-run mode. If using 66.5MHz IPG clock and 133MHz PER clock as the clock source, there are no such issue. There are 4 test cases in the attached test code. Case 0: in CCM_MCR, set bit 5 as 0 for 133MHz HCLK as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b001 ipg_clk (66.5MHz). There is no issue, the GPT counter is fixed at 4 between old_cnt and new_cnt. Case 1: in CCM_MCR, set bit 5 as 0 for 133MHz HCLK as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b010 ipg_clk_highfreq (133MHz). There is no issue, the GPT counter is fixed at 8 between old_cnt and new_cnt. Case 2: in CCM_MCR, set bit 5 as 1 for 240MHz UPLL divided by 2 as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b001 ipg_clk (60MHz). There is no issue, the GPT counter is fixed at 4 between old_cnt and new_cnt. Case 3: in CCM_MCR, set bit 5 as 0 for 240MHz UPLL divided by 2 as the gpt_per_clk source;  in GPT_CR bit[8:6], set 0b010 ipg_clk_highfreq (120MHz). There is issue, the GPT counter is not a fixed value between old_cnt and new_cnt, and sometimes it will be negative. Count 9874: 4 old_cnt: 0x188849dc new_cnt: 0x188849e0 Count 9877: 12 old_cnt: 0x18918400 new_cnt: 0x1891840c Count 9915: 4 old_cnt: 0x189aea90 new_cnt: 0x189aea94 Count 9937: -12 old_cnt: 0x18a42458 new_cnt: 0x18a4244c Count 9967: 4 old_cnt: 0x18adb17c new_cnt: 0x18adb180 In fact, it is not an issue, when using UPLL as the GPT clock source, the maxim frequency should be 60MHz. That's why all other three test case is OK and it only failed on this case.
View full article
When flashing a Linux System on a SD card using the script mk_mx28_sd on a Ubuntu 12.04 host, one needs to modify it so partitions are created correctly.  Just follow these steps on the console: $ cd $SDK/L2.6.35_10.12.01_SDK_scripts $ cat > first_partition_sector.patch << EOF diff -Naur a/mk_mx28_sd b/mk_mx28_sd --- a/mk_mx28_sd        2010-10-06 09:47:42.000000000 -0500 +++ b/mk_mx28_sd        2012-11-30 13:38:34.508199154 -0600 @@ -178,7 +178,7 @@ n p 1 -1 +2048 +32M t b EOF $ patch -p1 < first_partition_sector.patch then, you can run the mk_mx28_sd command again with the device as parameter                $ cd $LIB $ export PATH=$PATH:$SDK/L2.6.35_10.12.01_SDK_scripts $ mk_mx28_sd /dev/$SDX
View full article
This describes how to perform frequency measurements of an external signal by using the Camera Sensor Interface (CSI) of an i.MX21/25/35 processor. Principle: A way to measure the frequency of a digital signal is to count the number of received rising or falling edges during a known amount of time. The CSI embeds a 16-bit frame counter. When programmed in non-gated clock mode, this counter increases at any rising edge on the VSYNC signal. Other signals of this interface could be ignored such: MCLK, PIXEL_CLK, HSYNC, DATA. Software example for the i.MX25: void CSI_init(void){       unsigned int tmp_value = 0;       /* It assumes that the VSYNC I/O is set to CSI mode */       /* Disable IPG_PER_CSI to save power consumption */       *((unsigned int *) CCM_CGR0) &= ~(0x1<<0);       /* HCLK_CSI and IPG_CLK_CSI should be enabled. */       *((unsigned int *) CCM_CGR0) |= (0x1<<18);       *((unsigned int *) CCM_CGR1) |= (0x1<<4);       /* Configuration of CSI_CSICR1 in non-gated clock mode */       tmp_value = 0;       tmp_value |= (1<<8);    // sync FIFO clear       tmp_value |= (1<<30);   // ext vsync enable       *((unsigned int *) CSI_CSICR1) = tmp_value;       // Reset frame counter       *((unsigned int *) CSI_CSICR3) |= (1<<15); } Then, every T seconds, the software has to read the register CSI_CSICR3. The 16-bit size field from bit 16 shows the current value of the frame counter (FRMCNT). This regular or irregular read could be done based on a GPT to have a known time reference. It is easy to calculate the frequency of the signal: Frequency = FRMCNT / T (Hz). At any time, the frame counter can be reset thanks to the bit 15 of the register CSI_CSICR3. NOTES: MCLK does not need to be enabled. The input frequency should not be higher than what can electrically support the VSYNC input. Please, refer to each i.MX datasheet for more information.
View full article
GStreamer has a simple feature to enable tracing, allowing the developer to do basic debugging. These can be done in two ways: Adding the parameter --gst-debug=LIST to the pipeline (a pipeline is a executed gst-launch command) Prepending the environment variable GST_DEBUG=LIST' LIST is a a comma-separated argument, indicating the GStreamer elements to trace. For example, if one needs to trace the sink element      $ GST_DEBUG=*sink*:5 gst-launch playbin2 uri=file:///sample.avi or      $ gst-launch playbin2 uri=file:///sample.avi --gst-debug=*sink*:5 Both commands produces the same log. In case want to trace for than one element, so can simple add the <element>:5, for example      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi The number 5 indicates the log category, where 5 is the highest (the most verbose log you can get) and 0 produces no output (5=LOG, 4=DEBUG, 3=INFO, 2=WARN, 1=ERROR). Log can be huge in each pipeline run. One way to filter it is using the grep command. Before grepping, one needs to redirect the standard error to the standard output (GStreamer log goes always to stderr), so      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi 2>&1 | grep <filter string> In case the log needs to be shared, it is important to remove the 'color' of the log, again, one just needs to add the parameter --gst-debug-no-color or prepend the env variable GST_DEBUG_NO_COLOR=1 ----- More shell variables that GStreamer react, can be found here https://developer.gnome.org/gstreamer/0.10/gst-running.html
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
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
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