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:
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343344 
View full article
This document shows the steps for the creation of Archlinux and kernel 4.18.5 on the UDOO board. Required material: UDOO board, Ubuntu 16.04 and SD card. Firts we need u-boot (universal bootloader), for that reason we need update the host. $ sudo apt-get update Then we need the file *.img and SPL for the file system $ wget http://os.archlinuxarm.org/os/imx6/boot/udoo/SPL $ wget http://os.archlinuxarm.org/os/imx6/boot/udoo/u-boot.img Kernel 4.18.5 and file system: $ sudo mkdir archlinux $ wget http://os.archlinuxarm.org/os/ArchLinuxARM-armv7-latest.tar.gz $ sudo tar -xzvf  ArchLinuxARM-armv7-latest.tar.gz $ sudo rm -rf *.tar.gz You must have the following files Now  We are going to burn the memory, we need a 16Gb of space: We need to make sure it is empty Then partitions: $ sudo fdisk /dev/sdc O, P, N, P, 1 space, 8192 default, W At the end the sdc is partition, then create the filesystem partition $ sudo mkfs.ext4 /dev/sdc1 The working directory $ sudo mkdir mnt mount the partition 1 $ sudo mount /devsdc1 mtn/ Now we where the kernel and filesystem are and copy all the file in mnt: $ sudo cp -vr * ~/mnt/ Once it finish we execute $ sync then unmount the partition of sdc1: $ sudo umount mnt/ Now is moment to load the SPL and u-boot: and $ sync we retire the sd and turn on the board. Now you are on ArchLinux. user: alarm                  root: Root Pass: alarm                 pass: root Now the firts thing we must do it is upgrade the keys: $ pacman -key --init $ pacman -key --populate archlinuxarm $ pacman -Syyuu We can add another user: $ useradd - m -g user  -s /bin/bash user_name $ passwd user_name $ paman -S sudo $ visudo Root ALL= (ALL) ALL user_name ALL=(ALL) ALL $ exit For the graphic we are going to install the xorg: $ sudo pacman -S xorg-server $ sudo pacman -S xorg-apps Now we can execute startx and observe the windows of xorg $ startx To have a windows gestor: $ sudo pacman -S sddm $ sudo pacman -S plasma kde-applications $ sudo systemctl enable sddm Reboot and you are ArchLinux graphics windows
View full article
This document explains the pad implementation and its relationship with the System Controller Firmware pad configuration service. There are two components to pad configuration in the SCFW, there are the modules that generate the signals that will ultimately appear on the physical pad, let's say GPIO/Ethernet/I2C/UART etc... and then there is the part that configures the muxing of the pad (what signal is going to be outputted through the specific pad), the drive strength of the pad, pull selection, etc, this is the part that the SCFW pad service configures. Introduction‌ The i.MX8 has three types of I/Os: 1.8V only I/Os 3.3V only I/Os 1.8V / 3.3V I/Os Dual Voltage I/Os Note: USB High Speed Inter-Chip (HSIC) and Ethernet interfaces have specific integration schemes with dedicated features. They are a modified versions of the above I/O types. HSIC are a special kind of I/O modified to sustain 480Mbps data rates ENET I/Os are modified versions of Dual Voltage I/Os to support 2.5V operations All of these I/Os have "common features" and "technology specific features" which depend on the type of I/O and the chip manufacturing process (FDSOI in the i.MX8QM case) I/O common features Muxing capability of up to 4 signals Each Pad can have up to 4 signals, only one signal can be present in the pad. To select the signal that will output on the pad simply look at the Pinmux spreadsheet and use the desired alternative, for instance in the following image SCU_GPIO0_00 has 3 options, SCU_GPIO (ALT0 - GPIO controlled directly by the SCU), SCU_UART0_RX (ALT1 - SCU UART receiver) or LSIO_GPIO0_IO28 (ALT3 - Low speed I/O GPIO).   Pads without GPIO functionality (i.e. without the GPIO option in the pinmux spreadsheet) are implemented for one purpose only, these pins are connected directly to the module that drives them and they feature their own physical interface. Examples are XTAL pins, DDR pins and SCU PMIC interface (shown above). Mode of operation All GPIO types support four modes of operation: Normal mode Data is being driven directly to the pad (an internal signal of 1 shows in the pad as a 1 and vice-versa) and the pad works either as an output or as an input but not both at the same time. The output buffer while on this mode looks like this: Open drain Data is being driven through an open drain configuration, the output on the pad switches between 0 and high-z. The pad works either as an output or as an input but not both at the same time, e.g. if the Output Buffer is enabled the Input Buffer is disabled. This is how the output buffer looks like on Open drain mode: Open drain and input Output buffer acts as in open drain mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to simultaneously read the signal at the pad while driving it. Output and input Output buffer acts as in normal mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to read the signal at the pad while driving it. Wake-up capability Each I/O can be configured to wake-up the device, the following configuration options are available: OFF I/O cannot wake-up the system Low detect Generate wake-up event when the pad remains in low-level High detect Generate wake-up event when the pad remains in high-level Rising edge Generate wake-up event on rising edge detection Falling edge Generate wake-up event on falling edge detection Technology specific features Some of the available features for each pad depend on two factors: Chip manufacturing process (FDSOI or LPP) I/O type (1.8V, 3.3V or Dual Voltage) The i.MX8QM is manufactured using FDSOI technology and it features all of the three available I/O types. Drive strength Drive strength options vary within I/O types and chip manufacturing options. The available options for a FDSOI chip are: 1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength options Drive strength of 1mA Drive strength of 2mA Low drive strength (50 ohms) Drive strength of 2mA Drive strength of 4mA High drive strength (33 ohms) Drive strength of 4mA Drive strength of 8mA Drive strength of 6mA Drive strength of 12mA Drive strength of 8mA Drive strength of 10mA Drive strength of 12mA High-speed drive strength Pull Select The pull select available options are almost the same for all I/O types (1.8V being the exception) and they also depend on chip manufacturing process. The available options for a FDSOI chip are: Pull select options for FDSOI Bus-keeper (only available for 1.8V) Pull-up Pull-down No Pull (Disabled) A bus-keeper or bus-holder is used to keep the last state on the bus. In normal operation it makes no difference, but once the bus is tri-stated it keeps the last logic level in the bus to prevent the bus from floating. Compensation The compensation feature is only available on Dual Voltage I/Os. Dual Voltage I/Os have a different implementation, they require: Voltage reference generator - which provides a voltage reference to the supply detector and compensation cell Supply detector - detects automatically whether the I/O is being supplied with 1.8V or 3.3V and broadcasts this information to compensation cell and I/O  Compensation cell - adjusts drive strength of dual voltage I/Os depending on Process Voltage and Temperature (PVT) conditions. The default configuration takes care of adjusting this parameters and no further modifications are required. Pad configuration service SCFW API Mux selection The very first function that needs to be called to configure a pad is: sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso);‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the muxing alternative and setting the common features, its parameters are: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. mux - The mux setting that you require, basically Alt0 -> 0, Alt1 -> 1, Alt2 -> 2 and Alt3-> 3, the pinmux spreadsheet contains the required information (take a look at I/O common features above). config - Used to select the desired mode of operation (take a look at I/O common features above), the available options are declared under sc_pad_config_t Normal mode - SC_PAD_CONFIG_NORMAL Open Drain mode - SC_PAD_CONFIG_OD Open Drain and input - SC_PAD_CONFIG_OD_IN Output and input - SC_PAD_CONFIG_OUT_IN iso - This is the low-power isolation configuration (take a look at I/O common features above). The available options are declared under sc_pad_iso_t ISO_OFF - SC_PAD_ISO_OFF ISO_EARLY - SC_PAD_ISO_EARLY ISO_LATE - SC_PAD_ISO_LATE ISO_ON - SC_PAD_ISO_ON For instance to configure M40_I2C0_SCL with its UART alternative in normal mode with low-power isolation off, the call would look like this: sc_pad_set_mux(ipc, SC_P_M40_I2C0_SCL, 1, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);‍‍‍‍‍‍‍‍‍‍ Pad configuration To configure drive strength and pull select options the technology specific functions need to be used (FDSOI for i.MX8QM): sc_pad_set_gp is being used by our Linux team because it admits the passing of the configuration parameters as a single value and this eases the handling on the device tree, but you should aim to use the technology specific functions. sc_err_t sc_pad_set_gp_28fdsoi(sc_ipc_t ipc, sc_pad_t pad, sc_pad_28fdsoi_dse_t dse, sc_pad_28fdsoi_ps_t ps);‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the drive strength (DSE) and pull select settings (PS) for the specified pad, here is a break down of the parameters it uses: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. dse - The desired drive strength configuration (see Technology specific features above). DSE settings depend on the I/O type being used, the available options for each I/O type are defined under sc_pad_28fdsoi_dse_t: ENET pads capable of operating at 2.5V are a subset of dual voltage I/Os, the dse options available for these pads are the same as normal dual voltage I/Os. i.e. High drive and low drive. ps - The desired pull select configuration (see Technology specific features above). The available options are defined under sc_pad_28fdsoi_ps_t: To determine whether a GPIO pad is 1.8V, 3.3V or Dual Voltage one can look at the pinmux spread sheet, the supply for the pad will indicate what implementation of the GPIO is used. For instance: pads under VDD_SIM_1P8_3P3 are Dual voltage I/Os pads under VDD_SCU_1P8 are 1.8V I/Os pads under VDD_ADC_3P3 are 3.3V I/Os taking the same example as above we could configure the M40_I2C0_SCL as follows: sc_pad_set_gp_28fdsoi(ipc, SC_P_M40_I2C0_SCL, SC_PAD_28FDSOI_DSE_DV_LOW, SC_PAD_28FDSOI_PS_NONE);‍‍‍‍‍‍‍‍‍‍‍‍‍ Configuration under Linux Linux configures pads through the device tree, the full documentation of the binding is under Documentation/devicetree/bindings/pinctrl/fsl,imx8qxp-pinctrl.txt. but here is an extract: * Freescale i.MX8QXP IOMUX Controller Required properties: - compatible: "fsl,imx8qxp-iomuxc" - fsl,pins: each entry consists of 2 integers. Its format is <pin_id pin_config>. pin_config definition: - i.MX8QXP have different pad types, please refer to below pad register definitions, the pinctrl driver will just write the pin_config into the hardware register.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The driver uses the following API: sc_err_t sc_pad_set_gp (sc_ipc_t ipc, sc_pad_t pad, uint32_t ctrl) ‍‍‍ Instead of configuring each parameter individually as done with sc_pad_set_gp_28fdsoi it configures the pad as if writing to a register, the bitfield format is under the binding documentation but it is as follows: struct _hw_pad_iomux_bitfields0 { uint32_t GP : 19; /*!< [18:0] GP controls. */ uint32_t WAKEUP : 3; /*!< [21:19] Wakeup controls. */ uint32_t WAKEUP_ENB : 1; /*!< [22] Wakeup write enable. */ uint32_t LPCONFIG : 2; /*!< [24:23] Low-power config. */ uint32_t CONFIG : 2; /*!< [26:25] Config. */ uint32_t IFMUX : 3; /*!< [29:27] Mux. */ uint32_t GP_ENB : 1; /*!< [30] GP write enable. */ uint32_t IFMUX_ENB : 1; /*!< [31] Mux write enable. */ } B; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ All the configurations mentioned above can be configured, but they are done in a single pass, e.g. Muxing, Configuration (Norma, Open Drive, etc...), Wakeup control, and GP controls are for Pull Select Drive Strenght etc... Check the Reference Manual Chapter for IOMUXD for the register definition for each pad. References For more details refer to the sc_fw_api.pdf document: Chapter 1.3.3 Pad Configuration Service Chapter 6 Pad List Chapter 9.3 (SVC) Pad Service System Controller Firmware 101 
View full article
gst-inspect is a tool to to get documentation about GStreamer elements. Pipeline Check installed GST elements gst-inspect | tail -1 Check installed FSL GST elements gst-inspect | grep imx Element documentation gst-inspect <gst element>
View full article
UUU is an evolution of MFGTools. The introduction of UUU detail you can see the uuu.pdf file.. Please download uuu.exe and follow the UUU introduction. Here are some running examples. If you are not familiar with uuu, you can refer to them firstly. Under Windows (should be as admin): • For SD card:  Linux:  .\uuu -b sd_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard • For EMMC:  Linux:  .\uuu -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard  or  .\uuu.exe uuu.auto  Android:  .\uuu_imx_android_flash.bat -f imx8mm -u trusty Under Linux: • For EMMC  Linux:  sudo .\uuu uuu.auto If you download BSP release from nxp.com, you could find a file uuu.auto in the package. This is a preset script that can be executed directly (default for EMMC). You could change the script based on your requirement. Copy the uuu.exe under the release package, then execute the instructions. For UUU tool the prebuilt image and document are here: • https://github.com/NXPmicro/mfgtools/releases • UUU.pdf is snapshot of wiki   Environment PC: Window 10 64bit Board: i.MX8MMLPDDR4 EVK BSP: Q10.0.0_2.0.0 Demo images Screen: MX8-DSI-OLED1 Downloading android images to i.MX 8M Mini EVK LPDDR4 via UUU Tool 1\Hardware Preparations (1) Make the board enter serial download mode. For Rev. B boards, change the first two bits of board's sw1101 to 10 (from 1-2 bit) to enter serial download mode. For Rev. C boards, change the first four bits of board's sw1101 to 1010 (from 1-4 bit) to enter serial download mode. (2) Connecting J901to PC USB by a USB OTG cable. (3) Connecting J301(usb type c) to PC USB. (4) Plugging adapter into Power Jack (J302) (5) Power on i.MX 8M Mini EVK LPDDR4 board via SW101 Switch When first connect the board to PC, windows 10 64bit can’t automatically install FT2232D  driver from official website of manufacture, you need to Install the usb to uart driver manually: https://www.ftdichip.com/Drivers/D2XX.htm Download the setup executable and then install it. When installed success you can see the usb serial port can be used. 2\Downloading UUU Tool For the UUU binary file, download it from github: uuu release page on github. For the Q10.0.0_2.0.0 version use the UUU 1.3.124 version. For Linux OS, download the file named "uuu". For Windows OS, download the file named "uuu.exe". Here I use win10 system, so I download the uuu.exe file.   3\Download the Q10.0.0_2.0.0 Demo images for i.MX8MM   Now all the android os for i.MX products are here: Android OS for i.MX Applications Processors. Decompress release_package/android-10.0.0_2.0.0_image_8mmevk.tar.gz for LPDDR4 board. The package contains the image files and uuu_imx_android_flash tool. Copy uuu.exe to the directory of Q10.0.0_2.0.0 Demo images. 4\ Execute the uuu_imx_android_flash to flash image Power on the board. Open the serial port terminal and setting as following: Open a command line window. For the use and the Options for uuu_imx_android_flash tool details can see the Table 2 in the Android_Quick_Start_Guide. Here I use the OLED screen, to test MIPI panel output, need execute the tool with "-d mipi-panel". So here I use the .\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel . When I use the download I meet the follow question: C:\Work\Products\Android BSP\New folder\Q10.0.0_2.0.0 Demo images\android-10.0.0_2.0.0_image_8mmevk>.\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel This script is validated with uuu 1.3.124 version, it is recommended to align with this version. dtbo is supported dual slot is supported dynamic partition is supported You do not have sufficient privilege to perform this operation.   So here can change to use the Windows PowerShell, it works well and finished download.   Power off the board. 5\Boot up the board from emmc Set boot mode For Rev. C boards: Change sw1101 to 0110110010 and change sw1102 to 0001101000 if you want to boot from SD card. Change sw1101 to 0110110001 and change sw1102 to 0001010100 if you want to boot from eMMC. Set the U-Boot environment variables for the MIPI panel display U-Boot > setenv bootargs console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200 init=/init androidboot.console=ttymxc1 androidboot.hardware=freescale cma=800M@0x400M-0xb80M androidboot.primary_display=imx-drm firmware_class.path=/vendor/firmware transparent_hugepage=never androidboot.wificountrycode=CN androidboot.lcd_density=240 U-Boot > saveenv Then use the boot to boot up and then display on OLED screen.   Hope this can do help for some users. Best Regards Rita
View full article
When I am planing to develop some features in Uboot, I found it has lots limitation without interrupt. For example, to have camera preview in Uboot. Polling in Uboot results non sync when camera preview and hard to keep code simple and clean. I decided to take some time survey interrupt and it is time to share it.   This patch (shown as attachment) is to enable the interrupt. It also has the sample code to set GPIO interrupt as well. The test below showed Uboot can get the interrupt when pressing Volume up key. Special thanks for Anson Huang for patient discussing with me on this.   irqinfo is the command to enable Volume up interrupt. The log do_irq is print when Uboot got the interrupt.   Original Attachment has been moved to: 0001-Enable-interrupt-on-i.MX6Q-SabreSD.patch.zip
View full article
  When considering EIM bursts (performance, burst length, etc) we should take into account, that some parameters (maximum burst length, which defines length in clocks of back-to-back EIM access) depend on master, which performs the access (EIM always service as slave). The EIM can split a master burst in order to meet own settings, but the EIM cannot join two master accesses. So, the maximum  burst length is defined by master.  Usually three options are applied for EIM burst accesses : - ARM block copy instructions (LDM / STM) ; - ARM NEON copy instructions (VLDM / VSTM) ; - i.MX SDMA.   Below are some details regarding these options.   1. ARM. ARM provide recommendations below about the fastest way to copy memory on a Cortex-A8. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html   According to section 8.1.2 (Supported AXI transfers) of ARM Cortex-A9 Technical Reference Manual, it is possible to get maximum 64 bytes (16 beats x 4 bytes) burst for read and 8 bytes burst for write. “INCR N (N:1-16) 32-bit read transfers INCR N (N:1-2) for 32-bit write transfers” http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388i/DDI0388I_cortex_a9_r4p1_trm.pdf 2. SDMA.   According to section 55.4.3.1 (Burst DMA Unit) of the i.MX6 DQ RM : “Perform up to 8-beat read and write bursts to the ARM platform memory, which optimizes throughput when accessing SDRAM-type devices because of an internal, 36-byte FIFO”. This means, that burst length of the SDMA cannot be greater than 32 bytes (8 beat x 4 bytes). As for performance and implementation of SDMA approach, please look at the following : “Measure SDMA Memory To Memory Copy Performance on i.MX6Q” https://community.freescale.com/docs/DOC-103127
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is the detailed programming aid for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6UL/ULL/ULZ (consolidated RPA). The last work sheet tab in the tool formats the register settings for use with the ARM DS5/RealView debugger. It can be manually converted by the user to a DCD file format used by uboot or other bootloaders (note the removal of debugger specific commands in this tab). The programming aids were developed for internal NXP validation and development boards.   This tool serves as an aid to assist with programming the DDR interface of the MX6UL/ULL/ULZ and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool.   The following are some general notes regarding this tool: Refer to the "How To Use" tab in the tool as a starting point to use this tool. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance.  
View full article
The i.MX27 PDK, with Smart Speed™ technology, is a completely integrated hardware and software solution designed to simplify product development so you can focus on the critical differentiation needed for market success. Reduce development time and design products that have power to spare, even when running multiple applications simultaneously. Receive stellar Ethernet and video performance in a system design that dramatically reduces power consumption. Features i.MX27 Applications Processor - ARM9™ 128 MB DDR SDRAM 256 MB NAND FLASH Power Management (PMIC MC13783) + Power Circuitry Audio HS USB PHY Touch Controller 10/100 Ethernet port Accelerometer MMA7450L (Freescale) User I/O Connectivity (FM, 802.11, Bluetooth, USB OTG, USB HS) Button 2.7" TFT Display 2MP Camera Module SD card, ATA HDD External Connectors (dock, headphones, TV out, GPS) Microphone Speaker Debug Ethernet Port Debug Serial Port JTAG Reset, Interrupt, Boot Switches Debug LEDs CodeTest Interface Power Source Current/Power Monitoring
View full article
The latest i.MX28 BSP provided by Freescale (10.12) is based on a 2.6.35 kernel. If you want to use the latest and greatest kernel version from kernel.org, follow the steps below. 1. Get the mainline kernel: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git(this is only done once) git checkout -b yourlocalbranch origin/master 2. Export the toolchain PATH=/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/:$PATH export PATH export CROSS_COMPILE=arm-none-linux-gnueabi- export ARCH=arm 3. Build the kernel make mxs_defconfig make uImage sudo cp arch/arm/boot/uImage /tftpboot (In this example /tftpboot is the directory used to send files via TFTP) 4. Kernel command line: On U-boot change the following parameter of the kernel command line: console=ttyAM0,115200 to console=ttyAMA0,115200 5. On LTIB You can still use LTIB to provide the root file system. ./ltib -c Target System Configuration Options ----> Unselect [] boot up with tty and login If this option is selected the serial port will fail to open as it still uses ttyAM0 instead of ttyAMA0. 6. Boot the kernel via TFTP and mount the rootfs via NFS.
View full article
As the Voice over IP (VoIP) market grows, the next evolution of the market is Video and Voice over IP (V2IP). iWave’s iW-RainboW-G15S is a Pico-ITX Single Board Computer (SBC) which has a Freescale’s i.MX6 DualLite ARM Cortex-A9 core based CPU which can operate up to 800MHz speed/core with 1GB (expandable) DDR3 RAM. iWave has provided V2IP on iWave’s Pico ITX i.MX6 which gives more quality in video and audio streaming. iWave has expertise in HD video streaming over V2IP. The SIP(Session Initiation Protocol) protocol for connection between i.MX6 PICO ITX board and host PC which is used in the application Linphone through network (Ethernet). Linphone is a comprehensive solution consisting of an extensive set of algorithms and codecs designed for Digital Voice and Video applications. Above design can be utilized for peer to peer communication between i.MX6 PICO ITX single board computer and PC with Android OS. The i.MX6 single board computer and PC are connected to an Ethernet. The Audio CODEC used on the iMX6 PICO ITX dev board is ALC5610 from Realtek with inbuilt Headphone amplifier and MIC which is used to provide a complete audio solution for portable products. The video pixel rates are typically from 25 MHz up to 297 MHz, but HDMI can support higher rates up to 340 MHz’s i.MX6 PICO ITX board supports LVDS connector to connect different LVDS LCDs. It also supports backlight connector with 15V 300mA output for LCD backlight. iWave's i.MX 6 PICO ITX SBC supports 8/10bit CMOS Camera Interface. External clock for camera is provided using on board Oscillator of frequency 26MHz. i.MX6 CPU supports MIPI CSI interface. The V2IP systems use some existing standard video codec and audio codec to reduce the program material to a bit stream and then use an Internet Protocol (IP) network to carry that bit stream encapsulated in stream of IP packets. This is typically accomplished using some variant of the RTP protocol. Freeescale i.MX6 multimedia applications processor provides sufficient power to provide high-quality audio through wideband audio, in-call audio and video recording on flash. Image: V2IP on iWave’s Android i.MX6 Pico ITX Single Board Computer Video Streaming Platform feature: Pico ITX board with i.MX6 dual lite CPU 320X240p camera OS: Android jelly-bean (4.3) MIC HDMI with 1920X1080p display Android NDK and SDK H264 video codec Freescale’s VPU     For further information or enquiries please write to [email protected] or visit www.iwavesystems.com
View full article
MX6UL_DDR3_调校_应用手册_V3_20160511.doc
View full article
i.MX8M_DDR3L_register_programming_aid is created for DDR3L validation board.
View full article
Q: Looking at the datasheet, why a 14.7KOhm pulldown and a 4.7KOhm pullup must be used? When useing 4.7KOhm resistors in series from an MCU to control the boot pins, pull up is ok, but pull down is not. The EIM boot pins only see 4.7KOhm and not 14.7KOhm as recommended in the design guide. How did we determine those resistor values? at boot there is a pull-up of 100KOhm in the pad if I understand well, 4.7KOhm would do the job as well as 14.7K. right? A: 4.7k will work fine for pull-up or pull-down. 10k pull-downs is to limit current drain while allowing use of simple SPST switches to configure boot-up. There are on-chip 100k pull resistors, so this limits max resistor size. This document was generated from the following discussion: EIM boot resistor value
View full article
This work is the result of my daughter's idea, she finished it with my guidance. Cradle-1 Palmsize mini-HPC World's first full function heterogeneous mini-HPC, this is what it looks like: 1 Architecture         Overall:  CPU+GPU heterogeneous, 4 nodes, connected by a 100M Ethernet switcher;         Nodes: FreeScale I.MX6 Quad core mini-pc, with 4 ARM Cortex-A9 cores and 1 Vivante GC2000 GPU 2  Software         OS:   Ubuntu 11.10 linaro         OpenCL driver: Vivante GC2000 OpenCL driver         Compiler:  C/C++: gcc 4.6.1, Fortan90/95:  gfortran 4.6.1,         MPI Parallel Computing: MPICH2 1.4-1         NFS network file system: nfs-kernel-server 1.2.4         SSH security:   openssh   1:5.8 3 Hardware         The hardware of all nodes are the same, only the software configurations are slightly different. One of them was assigned as the master node, the others are slave nodes. They were TV sticks originally, with android 4.0 installed. The node's hardware specification is:         CPU: 4 1.2G Cortex-A9 cores         GPU: 1 Vivante GC2000 GPU         RAM: 1G DDR         ROM: 8G SD         NIC:   usb2.0 100M Ethernet Adapter (this NIC is not the TV stick's component, we added it)         WIFI: 150M         Display Interface:  HDMI         Network Switcher: 5 port 100M Ethernet Switcher 4  Network         Each node has one USB2.0 NIC and one WIFI interface, the WIFI is used as the backup connection for NIC connection. Network configurations are:         IP Address assignment:  (baby1 - baby4 are the four computing nodes)         baby1: 100M NIC 192.168.10.1 WIFI 192.168.0.111         baby2: 100M NIC 192.168.10.2 WIFI 192.168.0.112         baby3: 100M NIC 192.168.10.3 WIFI 192.168.0.113         baby4: 100M NIC 192.168.10.4 WIFI 192.168.0.114 5  Performance         Cradle-1 has 16 1.2G ARM Cortex-A9 cores and 4 Vivante GC2000 GPU cores, the total computing power of these 20 computing devices is more than 100GFLOPS,   more powerful than an ordinary desktop. The whole machine is only a little bigger than a palm, and the total power consumption is less than 15 watts.          The overall architecture of Cradle-1 is almost the same as Chinese Tianhe-1A or the Titan in the oak ridge lab. they used the same set of software, LINUX+OPENCL+OPENMPI. Cradle-1 supports C/C++, Fortran90/95. And almost all kinds of parallel computing algorithms can run on it, the only difference is the scale.         We coded a MPI parallel computing program for large matrix multiplication with 4 processes, each process had 5 threads, four threads for the four CPU cores, and one thread for GPU computing. 6 Appearance Front Back Top Left Right One node, it has three interfaces, the right is HDMI interface, upper-left is the wireless adapter for keyboard and mouse, down-left is the power connection. One node is running Ubuntu 11.10. Coded a simple OpenCL program to display OpenCL driver information On a notebook, using remote desktop access function to obtan the node baby1's desktop. This is the sign in desktop of baby1 node. Baby 1 has X11VNC server installed. sign in baby1, open a terminal Ran a MPI testing program, ensuring that all babies (baby1 - baby4) were working     Any comments? please mail to [email protected]
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-345359 
View full article
Play MPEG4 Video only gst-launch filesrc location=test.mpeg ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink H.264 Video only gst-launch filesrc location=test.avi ! mfw_avidemuxer ! mfw_vpudecoder codec-type=std_avc ! mfw_v4lsink AVI(H264+MP3) gst-launch filesrc location=test.avi ! mfw_avidemuxer name=demux demux. !  mfw_vpudecoder \     codec-type=std_avc ! mfw_v4lsink demux. ! queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink MP4(H264+MP3) gst-launch filesrc location=test.mp4 ! mfw_mp4demuxer name=demux demux. ! \    mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink demux. ! \    queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink <mp3_decoder_plugin> can be replaced by mad RAW Video Test gst-launch videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 !  mfw_v4lsink
View full article
Sorry I can't find a place to share this input file. It is to reproduce the VPU JPEG decoder issue I reported in Corrupted MJPG decoding result with FSL 3.10.17 BSP on i.MX6Q VPU​
View full article
imx7 supports TRULY-WVGA-TFT3P5581E display, the connector is J30, which is a connector on the imx7d board, normally, one can find the part number from BOM file, but imx7 Sabre-SDB board  BOM file missed this information. got connector information from expert team as below: The connector manufacture’s part number is: DF40C-24DS-0.4V(51)   For more detailed information about sabre board information information is available from nxp.com in the Design files for i.MX7Dual   For data sheet of this, which is under NDA, if you need it, pls create a salesforce case to get this, I couldn’t post this on public community.
View full article