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:
In new iMX8QM and iMX8QXP BSP, it had implemented hardware partition to split the resource and memory regions. The default Android Auto BSP had given example for shared memory between M4 and A core, it is used for RPMSG. Here is an example to add a new shared memory for iMX8QXP MEK board with Android Auto P9.0.0_GA2.1.0 BSP, which can be accessed in both M4, Uboot and Linux Kernel. The new shared memory region is from 0xF6000000 to 0xFDFFFFFF, total 128MB, it covers the RPMSG region too. RPMSG shared memory is moved to 0xF6000000 ~ 0xF6BFFFFF, total 12MB. vendor_nxp_fsl-proprietary_uboot-firmware.patch SCFW patch for board file to change the old shared memory region (0x90000000~0x90BFFFFF) to new shared memory region (0xF6000000~0xFDFFFFFF). This patch is applied to android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/board-imx8qxp.c, after patched, copy this file to SCFW porting kit and build out a new SCFW image, put it to "android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/mx8qx-scfw-tcm.bin". vendor_nxp-opensource_uboot-imx.patch This is the Uboot patch to map the shared memory region, if Uboot doesn't need access these memory, this patch is not needed. vendor_nxp-opensource_kernel_imx.patch This is the kernel patch to map the shared memory region. Note: VPU reserved memory address shouldn't be changed, otherwise it will impact the VPU function. So the new reserved memory region had been moved to 0xF600000~0xFDFFFFFF. vendor_nxp_mcu-sdk-auto_SDK_MEK-MIMX8QX.patch M4 patch for RPMSG address changed from 0x90000000 to 0xF6000000. Note: 1. In this example, we put the two shared memory regions together, then it will not split the memory region used in Linux. Another reason for such modification is the limitation of memory region counts in SCFW. 2. Since the RPMSG shared memory had been moved from 0x90000000 to 0xF6000000, the M4 code who used shared memory should also be changed. 2019-07-29 Update: When "#define PHYS_SDRAM_2_SIZE  0x0" in Uboot, it will create a 0 size memory region, this will impact the Uboot shared memory patch. Added the "uboot_imx8_cpu.patch" to avoid such issue.
View full article
This is a series of documents that intend to help you grasp he concept of the System Controller Unit (SCU) / System Controller Firmware (SCFW).    Getting started Power management service  Resource management service Pad configuration service Timer service Miscellaneous service   Other Useful resources: https://community.nxp.com/docs/DOC-344684 (2019) i.MX 8 System Controller Unit and System Controller Firmware Overview (2018) Clusters & Infotainment: Introduction to the i.MX 8 System Controller Unit (2017 Slightly outdated, for correct boot sequence go to Chapter 5 System Boot of the Reference Manual) System Controller Firmware command line utility for QNX and Linux You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: The porting kit contains documentation and allows you to build the SCFW from source and do modifications to the board dependent parts: The API documents explain the System Controller Firmware API syntax and it has a section for introduction and general overview of the system. The port document contains information on what each board component function does and the overall process of porting the SCFW.
View full article
[中文翻译版] 见附件   原文链接: 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 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
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
[中文翻译版] 见附件   原文链接: 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
In order to improve the speed of compilation, VMWare Player 14.0 is installed on local hard disk, and Ubuntu 18.04 LTS is installed on a SSD with at least 500GB size and USB3.1 specification. When installing ubuntu 18.04 LTS to SSD, it should be allocated at least 350GB of disk space, because compiling this version of android requires a larger disk space. The following are detailed compilation steps: Part l Configuring Ubuntu 18.04 LTS 1. Installing Ubuntu 18.04 on VMplayer 14.0 After installation is done, root user should be set at first. # sudo passwd root Then follow these steps to configuration ubuntu 18.04 for environment of compiliation --Changing sources of ubuntu 18.04 mirror If you are Chinese users, you can do the step, which can improve your system performance. # sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # sudo geit /etc/apt/source.list Comment I.MX customers outside China do not need to modify Ubuntu source list, or can modify it to local mirror site of Ubuntu 18.04, which can improve the speed of software upgrade.    Delet all sources and copy following lines here, Then save it and exit Changing ubuntu source deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse    Then running these 2 commands to update sources and packages    # sudo apt-get update    # sudo apt-get upgrade 2. Installing packages for compiliation Packages for compiliation # sudo apt-get install flex bison gperf build-essential zlib1g-dev lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev tofrodos python-markdown libxml2-utils xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 gcc-multilib g++-multilib subversion openssh-server openssh-client uuid uuid-dev zlib1g-dev liblz-dev lzop liblzo2-2 liblzo2-dev git-core curl # sudo apt-get install u-boot-tools mtd-utils android-tools-fsutils openjdk-8-jdk device-tree-compiler aptitude libcurl4-openssl-dev nss-updatedb # sudo apt-get install chrpath texinfo gawk cpio diffstat gdisk m4 libz-dev libssl-dev Part 2 Compiling Android Q10.0.0_2.1.0 BSP 1. Downloading NXP source code for Android Q10.0.0_2.1.0    File name is imx-android-10.0.0_2.1.0.tar.gz.    Copy the file to ~/, and decompress it.    # cd ~/    # tar zxvf ./imx-android-10.0.0_2.1.0.tar.gz    Then “imx-android-10.0.0_2.1.0” directory is created at ~/, now run the command to download android source code. # source ./imx-android-10.0.0_2.1.0/imx_android_setup.sh Comment imx_android_setup.sh is a script file, which includes all steps needed by the environment of android Q10.0.0_2.1.0 BSP. If network environment is enough good, several hours later, it will be done. 2. Compiling Android Q10.0.0_2.1.0 Referring to steps in Android_User's_Guide.pdf, We summaries steps for compilation here: (1) Preparing cross-compile tool chain    In Android_User's_Guide.pdf, 2 kinds of tool chain are recommended for users. --- gcc-arm-8.3-2019.03-x86_64-aarch64-elf.tar.xz --- gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz    Users can select one of them, and then decompress it to /opt/ directory. On how to download them or more details, see Android_User's_Guide.pdf, page 3. Here we will use gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz as tool chain. (2) Beginning to Compile Android Q10.0.0_2.1.0 BSP    Since this version of Android BSP requires high memory capacity when compiling, if the memory configuration of the virtual machine is incorrect, it is very likely to cause the compilation to fail. The following is a list of variable tests for user reference: # cd android_build # export AARCH64_GCC_CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu- # source build/envsetup.sh # lunch evk_8mp-userdebug # ./imx-make.sh -j2 2>&1 | tee build-log.txt Part 3 Errors During Compilation 1. Allocating 8GB Memory For VMware Player # ./imx-make.sh -j1 2>&1 | tee build-log.txt 2. Allocating 12GB Memory For VMware Player # ./imx-make.sh -j4 2>&1 | tee build-log.txt # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again) # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again)       So if we use 4 thread to compile BSP, command for compilation will have to be run for 3 times. NXP TIC Team Weidong Sun 2020/4/30
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