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:
Hi everybody, The attached document walks you through to build a Linux image for UDOO Quad board with QT5 support by using a Yocto Project build environment. The Kernel used in this process is 3.14.52. I hope you find it useful. Best regards, Carlos
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
This is a workaround—this page needs to be updated to add instructions for multi-touch support. Based on Freescale BSP 11.05. The LVDS panel (MCIMX-LVDS1) has a serial multi-touch controller, eGalax. As a workaround to have it supported on directly on Qt, we can force the driver to behave as a single touch. To do this: 1 - Edit the file ltib/rpm/BUILD/linux-2.6.35.3/drivers/input/touchscreen/egalax_ts.c adding the following line: + #define FORCE_SINGLE_POINTER_SUPPORT 1 2 - Compile the kernel ./ltib -m scbuild -p kernel 3 - Copy the new kernel to Card/Memory and boot it. 4 - Start your Qt app: $ Xfbdev -screen 1024x768 -mouse tslib,,device=/dev/input/event0  & $ export DISPLAY=:0.0 $ ./yourQTapp Note: You can read the touch events with "evtest" $ evtest  /dev/input/event0 or tslib apps: $ export TSLIB_TSDEVICE=/dev/input/event0 $ ts_print
View full article
Issue Description When WM8960 is working as master mode and target sample rate is 44100Hz or 48000Hz, it's found no sound can be heard on some i.MX boards. Impact Software Baseline: Linux 4.1.15_2.0.0 release or previous versions. Impact Hardware Platform: MCIMX6UL-EVKB, MCIMX6ULL-EVK and MX7SABRE boards which have WM8960 as Audio Codec. Root Cause When WM8960 is working as master mode, if input MCLK is 12.288MHz and configure "PLLPRESCALE =2 and SYSCLKDIV[1:0] =1", wrong BCLK and LRCLK output maybe got on some boards. And then it causes no sound output. Solutions After change the WM8960 PLL setting from “PLLPRESCALE =2 and SYSCLKDIV[1:0] =1” to “PLLPRESCALE =1 and SYSCLKDIV[1:0] =2”, the failure parts can work normally. See attached patch. The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1
View full article
Platform: i.MX8MP EVK, SDK 2.16   The rpmsg debug will stuck at rpmsg_queue_recv/rpmsg_lite_send when we use Step Over debug with JLink. The error log on Linux side: [ 42.422658] remoteproc remoteproc0: kicking vq index: 1 [ 42.524256] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (1, err:-62) [ 42.524286] remoteproc remoteproc0: kicking vq index: 0 [ 42.628566] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62)   The demo source code of rpmsg in SDK uses  RL_BLOCK, this flag will cause communication stuck during debug. while (msg.DATA <= 100U) { (void)PRINTF("Waiting for ping...\r\n"); (void)rpmsg_queue_recv(my_rpmsg, my_queue, (uint32_t *)&remote_addr, (char *)&msg, sizeof(THE_MESSAGE), ((void *)0), RL_BLOCK); msg.DATA++; (void)PRINTF("Sending pong...\r\n"); (void)rpmsg_lite_send(my_rpmsg, my_ept, remote_addr, (char *)&msg, sizeof(THE_MESSAGE), RL_BLOCK); }   The solution for rpmsg step over debug is that we need to use RL_DONT_BLOCK in sdk. Zhiming_Liu_1-1752035942335.png    
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-342719 
View full article
Use Raspberry Pi Debug Probe with OpenOCD and i.MX93 FRDM   This document explains the integration process of the Raspberry Pi Debug Probe (Very low cost debugger) with the OpenOCD (On Chip Debugger) tool with the i.MX93 FRDM board.   Also, we will use GDB (GNU DeBugger) to interact with the OpenOCD.   1. Install and Configure OpenOCD   Update and install dependencies sudo apt update sudo apt install build-essential libtool automake pkg-config libusb-1.0-0-dev libhidapi-dev libftdi1-dev libjim-dev jimsh   Clone the OpenOCD repo git clone https://github.com/openocd-org/openocd.git cd openocd   Run ./bootstrap to create the configuration file git submodule update --init --recursive ./bootstrap ./configure --enable-cmsis-dap --enable-hidapi   Make OpenOCD make -j$(nproc) sudo make install   Download the configuration file for i.MX93 You can dowload the  imx93.cfg  in the Table 2. Software requirements on Ubuntu PC of the AN14367 Then, copy the downloaded file to the openocd/tcl/target/ as below: cp ../imx93_new-b42b7c4cac18508442d3df035cec1c6d.cfg tcl/target/imx93.cfg   2. Create UDEV rules   sudo nano /etc/udev/rules.d/99-openocd.rules Add the below in that file: ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"   Reload rules sudo udevadm control --reload-rules && sudo udevadm trigger   3. Connecting the Hardware   To make the DAP works in the i.MX93 FRDM, we must rework the board removing the resistors R3017 and R3018:   frdm_r3017r3018_sch.png frdm_r3017r3018.png   Now, we need to connect the Raspberry Pi Debug Probe with the SWD (P14) of our i.MX93 FRDM board:   FRDM-IMX93.jpeg   rpdebug.jpeg   4. Running the Debug Session   In this moment, with the RP Debug Probe connected, we can Boot the i.MX93 FRDM board and run the below command to start the OpenOCD: $ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg   tic-mpu@tic-mpu:~/Debug_test/openocd$ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg Open On-Chip Debugger 0.12.0+dev-02429-ge4c49d860 (2026-03-21-23:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz Warn : DEPRECATED: auto-selecting transport "swd". Use 'transport select swd' to suppress this message. Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6633861A33A1B2C Info : CMSIS-DAP: SWD supported Info : CMSIS-DAP: Atomic commands supported Info : CMSIS-DAP: Test domain timer supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR 0x5ba02477 Info : imx93.a55.0: hardware has 6 breakpoints, 4 watchpoints Info : [imx93.a55.0] external reset detected Info : [imx93.a55.0] Examination succeed Info : [imx93.m33] Cortex-M33 r1p0 processor detected Info : [imx93.m33] target has 8 breakpoints, 4 watchpoints Info : [imx93.m33] Examination succeed Info : [imx93.ahb] Examination succeed Info : [imx93.a55.0] starting gdb server on 3333 Info : Listening on port 3333 for gdb connections Info : [imx93.m33] starting gdb server on 3334 Info : Listening on port 3334 for gdb connections Info : [imx93.ahb] gdb port disabled   From the Logs, we can see we have two ports: 3333 for Cortex A55 [imx93.a55.0] 3334 for Cortex M33 [imx93.m33]   Install gdb-multiarch   Now, we can install GDB: sudo apt install gdb-multiarch And start a Debug session: $ gdb-multiarch ~/linux-imx/vmlinux   $ gdb-multiarch ~/linux-development/linux-imx/vmlinux GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/tic-mpu/linux-development/linux-imx/vmlinux... (gdb) target extended-remote localhost:3333 Remote debugging using localhost:3333 0x00000000fff118fc in ?? ()   A simple example of how to read a register with GDB: (gdb) x/xw 0x43810000 0x43810000: 0x02010001     Happy debugging!     Best regards, Salas. 
View full article
the enclosed code is based on How to fuse key through nvmem on i.MX93 - NXP Community and modified for the imx8mp, this article about how to fuse mac address via fuse command in the uboot or nvmem in the kernel  ================================================================ Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design.  Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.
View full article
Why SWPDM? i.MX8MMINI, i.MX8MNANO and IMX8MPLUS  In order to process human voice, it is required to have the best audio resolution in the incoming data captured by the microphones. This mean, having a resolution of 16bits is not enough to capture all the information to properly process the voice. Voice processing requires a peripheral capable of capture data on a 32bits resolution within the range of the most common sample rates (16kHz, 44.1kHz, 48Khz, etc.). On the i.MX8M family there is a peripheral which fulfill those requirements and is called MICFIL. MICFIL is a peripheral which convert PDM (Pulse Density Modulation) data to PCM (Pulse-Code Modulation) data. The PDM format encode the analog signal in just one bit. Where 1 means the signal is increasing in amplitude while 0 means the opposite. In the other hand, the PCM format encode the data in 8, 16, or 32 bits. The advantage of PDM is that the creation of microphones is cheaper than having PCM microphones but then you will need a software or hardware which do the conversion for PDM to PCM since PDM cannot be processed. This is the reason of the MICFIL peripheral. However, not all the MICFIL's on the difference SOMs are the same. While the i.MX8MPLUS has a resolution of 32bits its smaller brothers do not. i.MX8MMINI and i.MX8MNANO have a MICFIL which only allows a resolution up to 16bits. For most of the cases it will be enough but not for voice processing. Nevertheless, not everything is lost; As mentioned previously, the PDM to PCM conversation can be done by hardware or by software. NXP also have the algorithm in software to do the conversation. Therefore, if a Mini or Nano is being used for voice processing it is fully recommended to use the ALSA SWPDM Plugin and avoid MICFIL peripheral.   Using the Plugin   In order to use the plugin, it is required to change the DTB to  imx8mm-evk-8mic-swpdm.dtb , when using the i.MX8MM or  imx8mn-evk-8mic-swpdm.dtb , when using the i.MX8MN. In order to do so follow the next steps: Please notice below example if for Mini. For Nano will be the same just changing the DTB name to imx8mn-evk-8mic-swpdm.dtb. # Stop at U-boot u-boot=> edit fdtfile edit: imx8mm-evk-8mic-swpmd.dtb u-boot=> saveenv u-boot=> boot   The change in the DTB is required to disable MICFIL so Linux can receive the raw data and sent it to the plugin. However, the plugin is not enabled by default, users need to explicit add the plugin to their ALSA pipeline. The way of doing so is by adding the following device to  /etc/asound.conf : pcm.cic { type cicFilter slave "hw:imxswpdmaudio,0" delay 100000 gain 0 OSR 48 }   Where: pcm.cic : Is an arbitrary name which allow ALSA to find the requested devices when setting the  -D  flag with  arecord  or  aplay . type cicFilter : This is the plugin type which is named with the algorithm name. slave: Name of the physical or virtual device which will be controlled by the cicFilter plugin. The recommendation is to always have the actual hardware connected to this plugin. delay : Amount of time in microsecond which the plugin won't write to the buffer, but it still does the conversion. The value could be between 100us to 1'000,000us. By removing the property from the structure, the delay will be set to 0. gain : A value between 0 and 100. OSR : Is related to the quality of the signal by increasing the PDM sample rate. With a higher valuer a best quality on the audio can be achieved. However, keep in mind than having a higher value will also require more memory to store all the new data due to the oversampling. The valid values for the OSR are: 48, 64, 96, 128, and 192. With all being said, the only thing left is to test the plugin by running the following command: $ arecord -D cic -c4 -r16000 -f s32_le --period-size=96 -d5 -v test.wav   Data Flow   When using PDM Microphones the default data flows is as shown in figure 1. Where the data is capture in the MICFIL peripheral and when it get to the Sound Drivers the data is already converted to PCM, so from the Kernel perspective the data is treaty as PCM values and the conversion from PDM to PCM is done under the hardware. JuanJorge_Mendoza_0-1739902609782.png However, with the changes we made earlier on the device tree and adding the plugin on /etc/asound.conf the data flows is as follow: JuanJorge_Mendoza_1-1739903680590.png Where the conversion from PDM to PCM is done just before giving the buffer to the application layer; Thus, conversion is made on User Space and the kernel is aware data have a PDM format. Another difference you can see is that MICFIL is disable and instead the datalines are controlled by SAI5. This is true for i.MX8MM, i.MX8MN, and i.MX8MP. Although for the application is a transparent change the truth is that the entire pipeline change, so please be aware of how the data is flowing to your application.   Integration With AFE   The next and final step is integrating the plugin with AFE and VoiceSeeker. The integration of SWPDM requires to apply a patch to the SWPDM repository. The patch changes the amount of period sizes allowed on the plugin. By default, the plugin only allows certain values which are:  48 Samples = 3ch x 4bytes format x 16samples = 192 bytes. 48 Samples = 2ch x 4bytes format x 48samples = 384 bytes. 48 Samples = 4ch x 4bytes format x 48samples = 768 bytes. 96 Samples = 4ch x 4bytes format x 96samples = 1,536 bytes. Although, AFE and VoiceSeeker are extremely configurable, 48 or 96 samples for the algorithm is too small. Meaning that the SWPDM should support a bigger period size, not all the way around. By applying the attached file, the plugin can have a period size from 64 bytes (1ch and 16 samples) up to 16,384 bytes (4ch and 1024 samples). However, the number of samples can vary depending on the OSR value and the number of channels. Once the patch has been applied in must be installed on: /usr/lib/alsa-lib (if the repository is being built on a standalone environment). AFE opens a device called mic  for capture the microphones' input. This device can have anything below it. By default, have the following definition on /etc/asound.conf  (after following the steps described on the TODO.md file). # mic represents the physical source (capture) pcm.mic { type plug slave.pcm "hw:micfilaudio,0" }   The devices opens the MICFIL driver, but on this case MICFIL is disable, which means the definition of the device must change. From above cic  device the definition can be copy and paste and then tweak one parameter. The delay must be set to 0 by removing the property or setting it explicitly on the structure. If this step if forgotten this might cause some underrun issues. The device definition will be: pcm.mic { type cicFilter slave "hw:imxswpdmaudio,0" delay 0 gain 0 OSR 48 }   The last thing to do will be running AFE with VoiceSeeker as usual. $ /unit_tests/nxp-afe/voice_ui_app & $ /unit_tests/nxp-afe/afe libvoiceseekerlight &   Considerations and Restrictions With all that said, there are few things left to mention, which are the considerations and restrictions on the plugin itself. These are good things to know before adding the plugin into any application. The plugin is supported from the Linux BSP 5.15.32. Currently the plugin only supports up to 4 channels. Plugin only outputs a S32_LE format (if required another format please use MICFIL). By applying above patch, the period size must be a multiple of 16, due to a limitation on the algorithm itself, rather than the plugin. The driver only allows to have one mic per data-line while MICFIL allows to have two microphones per data-line. The SWPDM Plugin is based on the External Plugin: I/O Plugin. This means it also have the restriction of this ALSA plugin, being the following restriction the most important one: "The I/O-type plugin is a PCM plugin to work as the input or output terminal point, i.e. as a user-space PCM driver". In other words, there can't be any device/plugin on top of it, not even a "plug" type. 
View full article
SW Environment Setup: 1. Prepare L5.10.35 Yocto and build Image  The prebuilt image also is available and useable. 2. Flash image to the SD card  Refer to the Yocto User Guide. 3. Compile flash.bin without M4 and flash it to sdcard (flash.bin as attachment)  make SOC=iMX8QM flash sudo dd if=flash.bin of=/dev/sde bs=1k seek=32 conv=fsync HW Environment Setup: Prepare the imx8qm MEK CPU board and base board and DB9 male cable, connect to CAN0 and CAN1 female connector on base board. (Pin to Pin connection) Capture.JPG User Case: 1. Power on board and configure specify dtb file in uboot  setenv fdt_file imx8qm_mek.dtb 2. Boot up and config bitrate for can0 and can1 in kernel root@imx8qmmek:~# ip link set can0 up type can bitrate 500000 root@imx8qmmek:~# ip link set can1 up type can bitrate 500000 3. Check CAN0 and CAN1 devices root@imx8qmmek:~# ifconfig can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 85 can1: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 86 3. Run candump for CAN1 root@imx8qmmek:~# candump can1 & [1] 1215 [ 65.624580] can: controller area network core [ 65.630225] NET: Registered protocol family 29 [ 65.641158] can: raw protocol 4. Run cansend for CAN0 root@imx8qmmek:~# cansend can0 5A1#11.2233.44556677.88 can1 5A1 [8] 11 22 33 44 55 66 77 88   The above red is output result from CAN1.
View full article
MAX resolution 1024 x 768 Factory Details:      Long name:    Freescale: Hardware (VPU) Encoder      Class:            Codec/Encoder/Video      Description:    Encodes raw YUV 4:2:0 data to MPEG4 SP, H.264 BP or H.263 (Annex J, K (RS=0 and ASO=0) and T) elementary data;Enco des raw YUV 4:2:0, 4:2:2 horizontal, 4:2:2 vertical or 4:0:0 data into MJPEG elementary data;      Author(s):       Multimedia Team <[email protected]>      Rank:             primary (256) Plugin Details:      Name:                    mfw_vpuencoder      Description:            Encodes Raw YUV Data to MPEG4 SP, H.264 BP or H.263 data. For H.263 P0, the source frame rate must be 3000 0/1001 fps      Filename:               /usr/lib/gstreamer-0.10/libmfw_gst_vpu_enc.so      Version:                  2.0.2      License:                  unknown      Source module:        gst-fsl-plugin      Binary package:       Gstreamer Multimedia Plugins (Freescale)      Origin URL:              http://www.freescale.com GObject   +----GstObject         +----GstElement               +----MfwGstVPU_Enc Pad Templates:    SINK template: 'sink'       Availability: Always       Capabilities:          video/x-raw-yuv                   format: I420                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: YV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: NV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y42B                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y444                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]    SRC template: 'src'        Availability: Always        Capabilities:            video/mpeg                             width: [ 48, 1280 ]                           height: [ 32, 720 ]                   mpegversion: 4                 systemstream: false            video/x-h263                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            video/x-h264                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            image/jpeg                             width: [ 48, 8192 ]                            height: [ 32, 8192 ] Element Flags:    no flags set Element Implementation:    Has change_state() function: 0x2b01c98c    Has custom save_thyself() function: gst_element_save_thyself    Has custom restore_thyself() function: gst_element_restore_thyself Element has no clocking capabilities. Element has no indexing capabilities. Element has no URI handling capabilities. Pads:    SRC: 'src'      Implementation:      Pad Template: 'src'    SINK: 'sink'      Implementation:        Has chainfunc(): 0x2b01de28        Has custom eventfunc(): mfw_gst_vpuenc_sink_event        Has bufferallocfunc(): mfw_gst_vpuenc_buffer_alloc      Pad Template: 'sink' Element Properties:    name                : The name of the object                          flags: readable, writable                          String. Default: null Current: "mfwgstvpu_enc0"    codec-type          : selects the codec type for encoding                          flags: readable, writable                          Enum "MfwGstVpuEncCodecs" Default: 2, "std_avc" Current: 2, "std_avc"                             (0): std_mpeg4        - STD_MPEG4                             (1): std_h263           - STD_H263                             (2): std_avc             - STD_AVC                             (7): std_mjpg           - STD_MJPG    profile             : enable time profile of the vpu encoder plug-in                          flags: readable, writable                          Boolean. Default: false Current: false    width               : width of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 48 - 8192 Default: 48 Current: 0    height              : height of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 32 - 8192 Default: 32 Current: 0    bitrate             : target bitrate (in kbps) at which stream is to be encoded - 0 for VBR and others for CBR                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 0 Current: 32768    gopsize             : gets the GOP size at which stream is to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 30 Current: 30    qp                  : gets the quantization parameter - range is 0-51 - will be ignored for CBR (bitrate!=0)                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    max-qp              : Maximum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 51 Current: 4294967295    min-qp              : Minimum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 0 Current: 4294967295    gamma               : gamma value for CBR - tells VPU the speed on changing qp - lower will cause better video quality                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32768 Default: 24576 Current: 24576    intrarefresh        : 0 - Intra MB refresh is not used. Otherwise - At least N MB's in every P-frame will be encoded as intra MB 's.                          flags: readable, writable                          Unsigned Integer. Range: 0 - 3600 Default: 0 Current: 0    h263profile0        : enable encoding of H.263 profile 0 when codec-type is set to std_h263                          flags: readable, writable                          Boolean. Default: false Current: false    loopback            : disables parallelization for performance - turn off if pipeline with decoder                          flags: readable, writable                          Boolean. Default: true Current: true    intra-qp            : Quantization parameter for I frame. When this value is -1, the quantization parameter for I frames is auto matically determined by the VPU. In MPEG4/H.263 mode, the range is 1.C31; in H.264 mode, the range is from 0.C51. This is ignored for STD_MJPG                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    crop-left           : The left crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-top            : The top crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-right          : The right crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-bottom         : The bottom crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    rotation-angle      : Pre-rotation angle - should be 0, 90, 180 or 270                          flags: readable, writable                          Unsigned Integer. Range: 0 - 270 Default: 0 Current: 0    mirror-direction    : mirror direction from source image to encoded image                          flags: readable, writable                          Enum "MfwGstVpuEncMirDir" Default: 0, "none                " Current: 0, "none                "                             (0): none                     - MIRDIR_NONE                             (1): vertical mirroring     - MIRDIR_VER                             (2): horizontal mirroring - MIRDIR_HOR                             (3): both directions       - MIRDIR_HOR_VER    h264-byte-stream    : Generate H.264 byte stream format of NALU. Take effect for H.264 stream only.                          flags: readable, writable                          Boolean. Default: true Current: true
View full article
i.MX8M_DDR3L_register_programming_aid is created for DDR3L validation board.
View full article
This is a hack to support programming EEPROM I2C devices for MX28 boot. See post at: Re: mx28 boot issues with SSP (SD card) *** USE AT YOUR OWN RISK ***
View full article
When using SSI Slave Mode for ASRC_P2P function (https://community.freescale.com/docs/DOC-95342), the waveform of the converted 24bit data is abnormal(have some values between 0 and 1). When using SSI Master Mode, these abnormal data disappear. This patch shows how to enable SSI Master Mode based on ASRC_P2P patches. Because SSI Master Mode uses fixed data width for LRCLK(32bits for each L or R), and the SSI Dual FIFO Mode is not supported for ASRC_P2P, the converted 16bit data is not well supported in this patch. Suggestions: If you want to convert the audio data to 16bit, you can use SSI Slave Mode; if you want to convert the audio data to 24bit, you can use SSI Master Mode.
View full article
Several customers met uuu failure because their board doesn't use same CC logic (ptn5110) of i.MX8MM EVK. For this problem it's able to disable CC logic and to force device mode of u-boot. Shared the patch based on 4.14.78 for reference.
View full article
Based on example code provided in AN4466 I've written a simple memory calibration script for ARM DS-5 that runs same steps and prints out results for DQS, read and write calibration. This script can be run on new boards in order to find optimum calibration settings for the memory controller. Prior to running this script it is necessary to run standard memory initialization script! When bringing up new board: obtain default memory initialization script for memory type you're using (for example from DDR stress tester package) and modify the memory controller settings according to memory device you are going to use. run DDR stress tester with the given configuration on target frequency you're going to use to make memory works with given settings (default values for calibration are  fine in most cases unless there's issues with PCB and/or routing). run memory init script and then the attached script to obtain calibrated values. Re-test Vladan
View full article
19-iMX_Serial_Download_Protocol.py zip file
View full article
NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. The aggregator portion of the i.MX Power Profiling System sits between the "smart" current sensor boards and the host computer. It provides power and signal connections to each connected sensor board. The communication is done over I2C, where three I2C bus extenders (PCA9518) effectively provide a dedicated bus to each I2C device, to better allow for cabling.  More information will follow... A photo, layout images and schematic attached below.   MBED source for the FRDM-KL25Z is available here: 30848-KL25Z-AGGREGATOR    Smart Sensor Connections At each smart sensor header JP0-JP13, these are the connections provided: 5V: powers the 3.3V regulator on each sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX0: I2C clock line  SDA/RX0: I2C data line  SWD_CLK:  global line for triggering smart sensors to make measurements RESET_B:  global line for resetting all smart sensor boards SWD_IO_n: individual select line for each smart sensor I2C Bus Connection Three I2C bus extenders (PCA9518) provide buffered connections between the FRDM board and all the connected smart sensors. The bus extenders were added to allow for longer cables between the aggregator and the smart sensor boards. Each bus extender has five ports and along with connections that allow extending the bus to more bus extenders. Gate Supply The aggregator contains a boost regulator that boost the 5V input from the FRDM board to 12V. The boosted voltage is fed to each of the smart sensor headers. It's used by the smart sensor board to pull up the gates of the switching FETs above any of the rails under test by at least 4.5V in order to benefit from a lower Rds(on). Caution must be exercised with some older FRDM boards since the 5V from the USB connection passes through diodes with a maximum current of 200mA.  The boost regulator and the load presented by the smart sensor boards may exceed the diode's limit and damage it. (Yes, it's happened... two older FRDM-KL25Z boards were used during development. One of them failed with the diode shorted (~0.05 Ohms), so everything kept working. The other failed with a  short of ~45 Ohms, so it kind of worked but not really...) Application Code for Aggregator  To date, application code has only been developed for the FRDM-KL25Z board. The latest application code resides at: https://os.mbed.com/users/r14793/code/30848-KL25Z-AGGREGATOR/, with the latest binary attached below. SWD Programming of Smart Sensors  Connectors J5 and JP15 are provided as an adapter for programming the smart sensor boards via SWD. JP15 provides power to the smart sensor board, since they have no direct 3.3V input for the KL05Z. An SWD programmer (or suitably modified FRDM-KL05Z board) connects to J5. Both connections use 10-pin 0.05"-spaced ribbon cables. Additionally, when a smart sensor is connected to JP15, J6 provides access to the UART pins of the smart sensor (the I2C pins on the smart sensor also mux out the UART of the KL05Z). No hardware changes are necessary at all; changing the code running on the smart sensor is all that's required. In fact, during the initial prototyping of the smart sensors, the serial UART connection was used instead of I2C. Modify Aggregator To Use SWD Dongle To Program Smart Sensor:  Add a wire as shown on the bottom side of the aggregator board as shown below. This ties 3.3V on the aggregator to the debug header, enabling the voltage level translators on the dongle to communicate with the KL05Z on the smart sensor board.  
View full article
Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link. i.MX6SX DDR3 Script Aid Please find i.MX6UL DDR3 Script Aid through below link. I.MX6UL DDR3 Script Aid Please find i.MX6SL LPDDR2 Script Aid through below link.. i.Mx6SL LPDDR2 Script Aid History: 0.03 1. update ZQ_LP2_HW_ZQCS         2. add MMDC SW reset         3. add disable DQS gating and reset read FIFO Any questions are welcome!
View full article
The i.MX 6 Linux L3.10.17_1.0.3 Patch release is now available. Patch Release Notes can be found on  www.freescale.com . This release supports the following i.MX 6 reference boards: ·        i.MX 6 Quad/DualLite/Solo SABRE SD ·        i.MX 6 Quad/DualLite/Solo SABRE Auto ·        i.MX 6 SoloLite This patch release is based on the i.MX 6 Linux L3.10.17_1.0.0 GA release. Release changes the following components: ·        Kernel branch: imx_v2013.04_3.10.17_1.0.0_ga ·        U-Boot branch: imx_3.10.17_1.0.0_ga ·        Graphics: gpu-viv-bin-mx6q, 3.10.17_1.0.3 ·        Graphics: gpu-viv-g2d, 3.10.17_1.0.3 ·        Graphics: Xorg-driver, 3.10.17_1.0.3 More detailed patch description: Please consult the release notes document.
View full article